Rätt tidpunkt att generera en CSR: En guide till smartare certifikathantering

Du har genererat fler certifikatsigneringsförfrågningar än du kan räkna, förmodligen utan att tänka särskilt noga på tidpunkten. Ändå är det ögonblick då du skapar en CSR det absolut bästa tillfället att upprätthålla din organisations regler, eftersom nyckelstorlek, signeringsalgoritm och identitetsfält alla bestäms just där, innan CA ens ser begäran. En certifikatsigneringsförfrågan (CSR) är ett signerat meddelande som innehåller en offentlig nyckel och identitetsuppgifter som ett system skickar till en certifikatutfärdare för att erhålla ett digitalt certifikat; den privata nyckeln lämnar aldrig begärarens system. Få tidpunkten och detaljerna rätt, så överensstämmer certifikaten med policyn och går igenom granskningar.

Den här guiden beskriver exakt när du behöver en ny CSR, var generering av CSR tenderar att gå fel, och hur PKI-, säkerhets-, plattforms- och compliance-team kan göra skapandet av CSR till ett styrt, repeterbart steg snarare än en engångsuppgift.

Key Takeaways

• En CSR kombinerar en publik nyckel och identitetsuppgifter (vanligt namn, alternativa ämnesnamn, organisationsfält), signerade med matchande privata nyckel, som aldrig lämnar begärarens system.
• En ny CSR krävs för tre händelsefamiljer: att skapa en ny identitet, uppdatera nycklar eller härda algoritmer och återupprätta förtroende efter en hierarkiändring i CA- eller PKI-systemet.
• DigiCerts Trust Pulse-undersökning (2 juli 2025) fann att 45 % av företagen hade certifikatrelaterade driftstopp under det senaste året, och 37.5 % spårade ett avbrott specifikt till ett utgånget certifikat.
• CA/Browser Forums omröstning SC-081v3 minskar den maximala giltigheten för offentliga TLS till 200 dagar i mars 2026, 100 dagar i mars 2027 och 47 dagar i mars 2029, vilket multiplicerar den förnyelsedrivna CSR-volymen ungefär åtta gånger för en typisk fastighet.
• PKI-, säkerhets-, plattforms- och efterlevnadsteamen äger var och en en distinkt åtgärd; ägar-/åtgärdsmatrisen och beslutstabellen nedan visar exakt vad och vem.

Hoppa till: Sammanfattning | Vad ett CSR är | Data bakom brådskandet | Beslutstabell | Ägar-/åtgärdsmatris | Vad man ska göra härnäst | Vanliga frågor

Sammanfattning för PKI-, säkerhets-, plattforms- och efterlevnadsteam

Om du leder en av dessa funktioner, här är beslutet som den här artikeln stöder och en snabbchecklista för att agera utifrån det.

• PKI-team: standardisera CSR-generering baserat på godkända algoritmer och nyckelstorlekar, och upprätthåll SAN-noggrannhet innan en begäran ens når CA.
• Säkerhetsteam: Bekräfta att privata nycklar genereras och lagras i en HSM, ett nyckelvalv eller en säker enklav, aldrig på en delad byggbox.
• Plattform-/DevSecOps-team: automatisera generering av CSR via ACME eller EST för fastigheter med hög churn så att förnyelsevolymen under 47-dagarsschemat inte blir en manuell flaskhals.
• Compliance-team: Bekräfta att varje väg från CSR till certifikat producerar ett granskningsbart spår som mappar till era myndighetskontroller, oavsett vilken CA som utfärdar certifikatet.

Vad ett CSR är och vad som händer när du skapar ett

Innan tidpunkten anges är det bra att vara exakt om vad en CSR egentligen är, eftersom "när" naturligt följer ur "vad". Ordlistan nedan definierar de termer som är viktigast.

• Begäran om certifikatsignering (CSR): en signerad begäran som sammankopplar en publik nyckel med identitetsuppgifter och ber en certifikatutfärdare att utfärda ett certifikat. Den kan byggas från ett nyligen genererat nyckelpar ("återkodning") eller från en privat nyckel du redan innehar ("förnya").
• Vanligt namn (CN): det primära identitetsfältet i en certifikatbegäran, historiskt sett värdnamnet som ett certifikat säkrar, även om moderna klienter validerar mot SAN istället.
• Ämnesalternativ (SAN): en eller flera ytterligare identiteter, såsom värdnamn eller IP-adresser, som ett certifikat är giltigt för. Dagens webbläsare och klienter använder SAN, inte CN, så en begäran som utelämnar eller anger dem felaktigt kan förstöra en tjänst i produktion.
• Privat nyckel: Den hemliga halvan av nyckelparet, genererad tillsammans med CSR:n och aldrig skickad till CA:n. CSR:n i sig innehåller endast den publika nyckeln och är inte känslig; den privata nyckeln är den tillgång som ska skyddas.

Certifikatutfärdarens (CA) signatur på det resulterande certifikatet är det som hindrar en angripare från att stjäla en kopierad offentlig nyckel och begära ett certifikat de inte har något anspråk på. I praktiken sker processen i två steg. För det första, när CSR :n genererats , har du en ren chans att bekräfta att SAN:erna är korrekta och att begäran använder godkända algoritmer som överensstämmer med resten av din säkerhet. För det andra kontrollerar CA:n detaljerna, signerar begäran och returnerar ett certifikat som binder din offentliga nyckel till den identitet du angav. En slarvig begäran, en föråldrad algoritm eller ett tomt fält studsar vid dörren eller, värre, utfärdas som ett certifikat som i tysthet inte uppfyller dina säkerhets- och efterlevnadsregler. När certifikatet har utfärdats, driftsätt certifikatet, lås den matchande privata nyckeln och testa paret mot policyn innan det publiceras.

Uppgifterna bakom brådskan

Två oberoende anskaffade datapunkter, plus en arbetsbelastningsuppskattning, kvantifierar vad som händer när CSR-genereringen förblir manuell medan certifikatens livslängd krymper:

• 45 % av företagen upplevde driftstopp kopplade till en certifikatrelaterad incident under det senaste året, och 37.5 % spårade ett avbrott specifikt till ett utgånget certifikat., enligt DigiCerts Trust Pulse-undersökning, publicerad 2 juli 2025.
• Maximal giltighetstid för offentliga TLS fasas ut till 200 dagar i mars 2026, 100 dagar i mars 2027 och 47 dagar i mars 2029., bekräftad av CA/Browser Forums omröstning SC-081v3 och Sectigos Analys den 14 april 2025 av samma schema.
• Uppskattning av förnyelsearbetsbelastning: Ett dödsbo som hanterar ungefär 1 000 certifikatförnyelser per år genererar idag över 8 000 CSR- och förnyelsehändelser per år när certifikaten har begränsats till 47 dagar, en åttafaldig ökning som ingen manuell process absorberar.
• Ingen av undersökningssiffrorna är specifik för en enskild orsak, men båda beskriver vad som händer när certifikatutfärdande är beroende av att en person slutför ett manuellt steg i tid, vilket är precis det beroende som automatiserad CSR-generering är utformad för att eliminera.

När du behöver en ny CSR

En ny CSR är aldrig något man producerar i en kalender; det är något som specifika händelser kräver. Dessa händelser sorteras in i tre familjer, och att veta vilken familj man tillhör säger direkt om ett nytt nyckelpar är aktuellt.

Att skapa en ny identitet

Det här är den familj som de flesta först föreställer sig. Det tydligaste fallet är att starta en helt ny tjänst, en webbserver, en VPN-gateway, ett internt API, en lastbalanserare, där det inte finns något befintligt nyckelpar att ärva, så du börjar från ingenting. Att begära ett offentligt TLS-certifikat från en CA som DigiCert eller Let's Encrypt matar in din CSR som startindata. Gör det till en vana att logga varje ny begäran i ditt inventarium så fort den skapas, så att förnyelsedatumet aldrig överraskar dig senare.

Två mindre uppenbara medlemmar i samma familj är enheter och pipelines. Ansluten hårdvara bygger vanligtvis en CSR på själva enheten under tillverkning eller provisionering, och skapar sin egen identitet från första uppstarten; en nätverksansluten medicinsk sensor måste till exempel presentera en CSR och samla in ett identitetscertifikat innan ett sjukhusnätverk överhuvudtaget släpper in den. DevOps-pipelines befinner sig i den motsatta änden av livslängdsskalan och lutar sig mot protokoll som Automated Certificate Management Environment (ACME) och Enrollment over Secure Transport (EST) för att skapa CSR:er och kortlivade certifikat på egen hand. Oavsett om certifikatet varar i fem år eller fem minuter, och om en människa eller en Kubernetes-kontroller ber om det, gäller inte regeln: ingen ny identitet utan en CSR bakom sig.

Uppfriskande nycklar och härdande algoritmer

Den andra familjen handlar om certifikat som redan finns men inte bör fortsätta att gälla oförändrade. När ett närmar sig utgångsdatum antingen pensionerar du det eller förnyar det, och sund policy innebär att man förlänger nyckeln samtidigt snarare än att återanvända den gamla. En förnyelse som medför ett nytt nyckelpar behöver en ny CSR, punkt; återanvändning av samma nyckel förlänger bara din exponering om den någonsin komprometteras. Färsk CSR, ny privat nyckel , det är hela rotationspunkten. Och om en nyckel dyker upp i ett intrång, vänta inte på dess förnyelsedatum; utfärda allt som berörs på en gång, den kryptografiska versionen av att byta lås efter att du förlorat dina nycklar.

Rotation handlar inte bara om kalendern. Algoritmer åldras i takt med att kryptanalysen utvecklas och datorkraften blir billigare, så det som såg starkt ut för ett decennium sedan ser nu osäkert ut. Att flytta ett certifikat till en starkare algoritm eller en längre nyckel ändrar den publika nyckeln, vilket kräver ytterligare en CSR, och detta kommer bara att bli vanligare när svaga algoritmer tas ur bruk. Det hotande fallet är postkvantkryptografi (PQC): en tillräckligt kapabel kvantdator som kör Shors algoritm skulle förstöra dagens publika nyckelalgoritmer, RSA , ECDSA och Diffie-Hellman, som säkrar nyckelutbyte och signaturer, medan symmetriska chiffer som AES och moderna hashar bara försvagas och förblir säkra med större parametrar som AES-256. PQC är inte längre teoretiskt: NIST slutförde sina tre första postkvantstandarder i augusti 2024 ( FIPS 203 / ML-KEM för nyckeletablering, och FIPS 204 / ML-DSA och FIPS 205 / SLH-DSA för signaturer), så kvantresistenta algoritmer är driftsättbara idag. Kombinerat med risken "skörda nu, dekryptera senare", där data som samlas in idag kan låsas upp när hårdvaran mognar, är tidig inventering och planering av kryptoagilitet genom Encryption Consultings PQC Center of Excellence och 9-fas PQC-beredskapsplan en mycket skonsammare väg än att vänta på att bli tvingad in i den.

Återupprätta förtroende efter förändring

Den tredje familjen är den som team tenderar att glömma tills den har övertaget över dem: en förändring av själva förtroendegrunden. Byt från en CA till en annan, eller flytta din PKI från lokalt till molnet, och hierarkin under varje certifikat förändras. Varje certifikat som utfärdats under den gamla hierarkin måste begäras på nytt för att återuppbygga förtroendet, vilket innebär en CSR per certifikat. Den verkliga faran är att tappa koll på vad du innehar, så före en migrering av denna storlek, redovisa varje befintligt certifikat först med hjälp av ett certifikatidentifieringspass , och utfärda sedan på nytt så snabbt du kan, med automatisering som bär bördan istället för att någon ska slita igenom ett kalkylblad för hand.

Där CSR-generering tenderar att gå fel

Eftersom en CSR innehåller så mycket information som CA måste kontrollera, får små misstag oerhört stora konsekvenser. Några återkommande problem är värda att hålla utkik efter.

Saknade eller felaktiga SAN:er hamnar högst upp på listan. Eftersom klienter nu validerar mot SAN:er kan en begäran som utelämnar dem, eller listar fel, utlösa avbrott som är besvärliga att diagnostisera. Att automatisera skapandet av CSR:er via en certifikathanteringsplattform tar bort stavfel och framtvingar konsekventa mallar så att rätt namn alltid finns med.

Sedan finns det en utbredning av inkonsekventa, icke-standardiserade PKI. Olika team genererar CSR:er på sitt eget sätt, vissa verktyg använder i tysthet föråldrade algoritmer som standard, och plötsligt misslyckas era certifikat med efterlevnadsgranskningar utan goda skäl. Standardiserade mallar åtgärdar detta genom att säkerställa att alla begär certifikat med samma godkända algoritmer, namngivningskonventioner och organisationsdetaljer. Granskningar blir snabbare och billigare som ett resultat.

Osäker nyckellagring är den tysta mördaren. I samma ögonblick som en privat nyckel skapas på en delad bygglåda, eller skickas mellan maskiner för enkelhetens skull, har du i praktiken överlämnat kontrollen över den till alla som kan nå dessa system. Nycklar bör skapas och förvaras i det system som använder dem, helst skyddade av en hårdvarusäkerhetsmodul (HSM), nyckelvalv eller säker enklav. Behandla 2048-bitars RSA som golv snarare än mål: NIST:s riktlinjer anger att den bara har tillräcklig styrka fram till ungefär slutet av decenniet, så för allt som är långlivat är 3072-bitars RSA eller en elliptisk kurvnyckel som P-256 det klokare valet. CSR:n i sig behöver ingen sådan sekretess, eftersom den bara innehåller den publika nyckeln och dina subjektuppgifter; den privata nyckeln är den tillgång som ska skyddas.

Slutligen går det helt enkelt inte att skala upp manuell generering av CSR. Utan automatisering skapas förnyelseförfrågningar sent, och team hamnar i en frenetisk rusning för att distribuera ersättningar innan de gamla certifikaten löper ut, precis den typ av brandövning som leder till avbrott. Att spåra varje certifikat och dess utgångsdatum i en automatiserad plattform, och använda protokoll som ACME eller EST för att generera CSR:er i stor skala, eliminerar paniken i processen.

Beslutstabell: Matcha CSR-situationer med rätt svar

Använd den här checklistan för att koppla en händelse som utlöser ett CSR till den rekommenderade åtgärden, den operativa ägaren och det resultat du bör förvänta dig.

Användningsfall	Rekommendation	Operativ ägare	Förväntat resultat
Ny offentlig service	Generera CSR med fullständig SAN-lista; använd ACME där CA stöder det	Plattform/DevSecOps-teamet	Certifikat utfärdat och driftsatt utan ett manuellt SAN-fel
Rutinmässig förnyelse	Rotera nyckelparet vid varje förnyelse istället för att återanvända det	PKI-teamet	Minskat exponeringsfönster om någon enskild nyckel senare komprometteras
Misstänkt nyckelkompromiss	Utfärda omedelbart ett nytt CSR; vänta inte på förnyelsedatumet	Säkerhetsteam	Komprometterad nyckel återkallad och ersatt innan den kan missbrukas
Uppgradering av algoritm eller nyckelstorlek	Generera en ny CSR mot den starkare algoritmen eller den längre nyckeln	PKI-teamet	Överensstämmelse med gällande kryptografiska minimikrav för hela fastigheten
Migrering av CA- eller PKI-hierarki	Inventera alla befintliga certifikat och utfärda dem sedan på nytt via automatisering	PKI-team med efterlevnadsgodkännande	Inga överblivna certifikat kvar som litar på en pensionerad hierarki
Enhets- eller pipeline-provisionering	Använd ACME eller EST för att generera CSR:er vid tillverkning eller driftsättning	Plattform/DevSecOps-teamet	Konsekvent, policykompatibel identitet utfärdad utan mänsklig inblandning

Var CSR sitter i ett certifikatprogram för vuxna

Det är lätt att tänka på en CSR som en engångsuppgift, men den ligger längst fram i en livscykel som aldrig riktigt tar slut. Varje certifikat måste begäras, utfärdas, registreras i en inventering, distribueras dit det behövs, förnyas innan det löper ut och slutligen tas ur drift, och de flesta organisationer jonglerar med tiotusentals av dem, ibland betydligt fler. Felaktigt hanterade certifikat är en ledande orsak till både avbrott och dataintrång, och kostnaderna ökar snabbt.

Anledningen till att generering av CSR är så viktig är att det är den tidigaste och renaste platsen att genomdriva styrning. Nyckelstorlek, algoritmval och identitetsfält är alla låsta innan certifikatet ens existerar. Om CSR:n är rätt är det mycket mer troligt att det resulterande certifikatet klarar granskningar och beter sig i produktion. Identifiering och inventering visar vad du redan har; CSR:er är där allt nytt börjar. Mogna program gör skapandet av CSR till ett automatiserat, policystyrt steg som på ett tydligt sätt matar in i utfärdande, provisionering, förnyelse och återkallelse, snarare än en manuell syssla som varje team hanterar på sitt eget sätt.

Ägare och åtgärdsmatris per team

Team	Ansvar	Nyckelåtgärd
PKI-teamet	Äger CSR-standarder, algoritmgodkännande och policy för nyckelstorlekar	Publicera och tillämpa en standard CSR-mall för alla certifikattyper
Säkerhetsteam	Äger skydd av privata nycklar och komprometteringsrespons	Bekräfta att alla privata nycklar genereras inuti en HSM, ett nyckelvalv eller en säker enklav
Plattform/DevSecOps-teamet	Äger automatiserad CSR-generering i pipelines och enhetsflottor	Koppla ACME eller EST till CI/CD och provisioneringsarbetsflöden före 100-dagarsfasen
Compliance-teamet	Äger revisionsbevis för varje väg från CSR till certifiering	Bekräfta att CSR och utfärdandeloggar uppfyller relevanta myndighetskontroller

Vad göra här näst

• PKI-team: granska nuvarande CSR-mallar för algoritm- och nyckelstorlekskonsekvens före 100-dagars giltighetsstadiet i mars 2027.
• Säkerhetsteam: verifiera att ingen privat nyckel någonsin genereras utanför en HSM, ett nyckelvalv eller en säker enklav.
• Plattformsteam: Pilotera ACME eller EST för CSR-generering på era tjänster med högst churn detta kvartal.
• Compliance-team: bekräfta att ert revisionsramverk redan accepterar automatiserade CSR- och utfärdandeloggar som bevis, eller lyft fram luckan nu.

Hur kan krypteringskonsulting hjälpa?

Encryption Consultings CertSecure Manager är en leverantörsneutral lösning för hantering av certifikatlivscykeln som samlar identifiering, automatisering, registrering, policytillämpning och integrationer på ett ställe. Den standardiserar och automatiserar CSR-generering så att varje begäran innehåller rätt algoritmer, SAN och identitetsfält, vilket eliminerar den inkonsekvens som så ofta spårar ur revisioner. Genom att automatisera förnyelser förhindras avbrott som uppstår på grund av att certifikat löper ut obemärkt, och dess rollbaserade åtkomstkontroller håller privata nycklar och begäranden endast i händerna på de som ska röra dem.

• CertSecure-chef: standardiserar CSR-generering och certifikatlivscykelhantering över offentliga och privata CA:er från ett enda gränssnitt.
• CBOM-säker: kryptografisk upptäckt och en kryptografisk materiallista som katalogiserar varje certifikat och nyckel före en CA-migrering eller algoritmuppgradering, så att ingenting återutfärdas i blindo. CBOM: från inventering till intelligens Guiden täcker omvandling av det lagret till ett pågående kryptoagilitetsprogram.
• PQC-beredskap och kryptoflexibilitet: CSR- och algoritmbeslut som fattas idag fortsätter in i övergången efter kvantum. PQC:s kompetenscentrum och 9-fas PQC-beredskap en färdplan som hjälper dig att planera migreringen innan den tvingas på dig.

Oavsett om du hanterar publika, privata eller båda, ger CertSecure Manager dig en enda, skalbar plattform för att hålla certifikatoperationerna konsekventa från den allra första CSR:n till den slutliga återkallingen.

För mer information om CertSecure Manager, besök: Här

För mer information om våra produkter och tjänster, besök: Här

Relaterad läsning från Encryption Consulting

• Att välja ett certifikatregistreringsprotokoll: ACME vs. EST vs. SCEP vs. CMP täcker de automatiserade protokoll som refereras ovan för att generera CSR:er i stor skala.
• Persistenta DCV- och DNS-kopplingar täcker automatisering av domänvalideringssteget som följer efter inlämning av CSR, före deadline för TLS-certifikat på 47 dagar.
• Hur man bygger ett kryptografiskt inventarium (CBOM) utökar disciplinen för certifikatidentifiering som refereras ovan till att omfatta hela din kryptografiska tillgång.
• Guide för migrering av kvantkryptografi efter kvantkryptering (9 faser) lägger fram färdplanen för kryptoagilitet som följer algoritmdriven CSR-återutgivning.

Slutsats

Att generera en CSR kommer aldrig att vara den mest glamorösa delen av ditt jobb, men det är en av de mest betydelsefulla. I det ögonblick du skapar den begäran bestämmer du dig för om ett certifikat ska överensstämma med din säkerhetspolicy eller tyst glida bort från den. Att veta när en ny CSR verkligen behövs, nya tjänster, nyckelroterande förnyelser, algoritmuppgraderingar, CA-migreringar, DevOps- arbetsbelastningar och enhetsprovisionering, innebär att du arbetar före livscykeln istället för att reagera på den.

De organisationer som hanterar detta väl är inte de som genererar CSR:er manuellt och hoppas på det bästa. Det är de som har gjort CSR-generering till ett standardiserat, automatiserat, policydrivet steg, backat upp av stark nyckellagring, konsekventa mallar och fullständig insyn i varje certifikat de äger. I takt med att certifikatens livslängd krymper mot 47-dagarsgolvet och migreringen till postkvantalgoritmer ökar, blir den disciplinen bara mer värdefull. Behandla den enkla CSR:n som den policykontrollpunkt den verkligen är, och resten av din certifikathantering blir mycket enklare.

Denna vägledning granskas var sexmånadersdag för evigt populära förklarande artiklar som denna, och omedelbart när CA/Browser Forum, NIST eller en större CA ändrar vad dessa processer kräver.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste lärdomen från Rätt tidpunkt att generera en CSR: En guide till smartare certifikathantering?

Inget enskilt tillfälle täcker varje certifikat. En ny CSR krävs när en ny identitet skapas, när nycklar uppdateras eller algoritmer härdas, och när förtroende återupprättas efter en hierarkiförändring hos en CA eller PKI. Att få CSR:n rätt vid vart och ett av dessa tillfällen är det renaste sättet att genomdriva nyckelstorlek, algoritm och identitetspolicy innan ett certifikat ens existerar.

Varför är detta viktigt för hantering av företagscertifikats livscykel?

CA/Browser Forums omröstning SC-081v3 minskar den maximala giltighetstiden för offentliga TLS till 200 dagar år 2026, 100 dagar år 2027 och 47 dagar år 2029. Med den takten genererar en licens med 1 000 certifikat över 8 000 förnyelser per år istället för ungefär 1 000, och DigiCerts Trust Pulse-undersökning fann att 45 % av företagen redan hade certifikatrelaterad driftstopp under det senaste året. Manuell CSR-generering kan inte absorbera den volymen.

Vilka team är ansvariga för att agera utifrån denna vägledning?

PKI-team äger CSR-standarder, algoritmgodkännande och policy för nyckelstorlek; säkerhetsteam äger skydd av privata nycklar och komprometteringshantering; plattforms- och DevSecOps-team äger automatisering av CSR-generering i pipelines och enhetsflottor; och compliance-team äger bekräftelsen att varje CSR-till-certifikat-väg producerar ett granskningsbart spår. Ägar-/åtgärdsmatrisen ovan delar upp detta per team.

Vilka risker ökar om detta ämne hanteras manuellt?

Manuell generering av CSR-nummer introducerar saknade eller felaktiga SAN:er, inkonsekventa algoritmer mellan team, privata nycklar som genereras på oskyddade delade system och sena förnyelseförfrågningar som leder till brandövningar. DigiCerts Trust Pulse-undersökning fann att 37.5 % av avbrotten spårades direkt till ett utgånget certifikat, en risk som växer eftersom certifikat måste utfärdas på nytt var 100:e eller 47:e dag istället för årligen.

Hur minskar automatisering risken för certifikatavbrott?

Genom att automatisera genereringen av CSR genom protokoll som ACME och EST elimineras det mänskliga steg som är mest sannolikt att man missar en förnyelsedatum eller felkonfigurerar ett SAN. Kombinerat med en automatiserad plattform för certifikatlivscykeln som spårar varje utgångsdatum, förvandlar automatiseringen förnyelse från en manuell brandövning till en bakgrundsprocess som inte är beroende av att någon kommer ihåg att agera i tid.

Vilka mätvärden bör team spåra efter implementeringen?

Spåra andelen CSR:er som genereras genom en automatiserad, policystyrd process kontra manuellt, antalet certifikat med SAN-avvikelser eller algoritmundantag som upptäckts före utfärdande, andelen misslyckade förnyelser eller nära-miss-fall, och genomsnittlig tid från skapande av CSR till distribution av certifikat. Rapportera dessa kvartalsvis eftersom certifikatens livslängd fortsätter att krympa.

Hur kopplas detta till 47-dagars TLS-certifikatberedskap?

CA/Browser Forums schema minskar den maximala giltighetstiden för publika TLS-certifikat till 200 dagar den 15 mars 2026, 100 dagar den 15 mars 2027 och 47 dagar den 15 mars 2029. Eftersom varje förnyelse kräver en ny CSR, kommer en licens som inte har automatiserat CSR-genereringen vid 100-dagarsfasen inte att kunna hålla jämna steg när kadensen når 47 dagar. Att standardisera CSR-genereringen nu är det som gör den beredskapen möjlig.

Hur bör detta hanteras i multimoln- eller hybrid-PKI-miljöer?

Standardisera CSR-generering på en CA-agnostisk certifikatlivscykelplattform, såsom CertSecure Manager, så att samma mallar, algoritmer och godkännandepolicy gäller oavsett vilket moln, CA eller intern PKI som utfärdar ett givet certifikat. Detta undviker att CSR-logiken behöver byggas om separat för varje molnleverantör eller privat CA, och håller granskningssynligheten enhetlig över en hybrid- eller multimolnegendom.