Inuti nyckelceremonin: PKI, HSM, processen, människorna och varför det är viktigt

Publicerad: augusti 2025. Uppdaterad: augusti 2026. Granskad av Encryption Consultings PKI- och HSM-rådgivningsteam.

När folk pratar om grunderna för digitalt förtroende menar de vanligtvis kryptering , certifikat och infrastruktur för offentliga nycklar (PKI) . Nästan ingen av dem har sett processen som faktiskt skapar det förtroendet: nyckelceremonin där en certifikatutfärdares rotnyckel skapas, inuti ett valv, under videoinspelning, inför vittnen som skriver under en loggbok innan de går.

Det här inlägget är en djupdykning i den processen. Det tar upp vem som leder en nyckelceremoni, hur M-of-N-kvorum och split knowledge faktiskt fungerar, var HSM :s FIPS-gräns ligger, varför en offline-rot och en online-utfärdande CA är ceremonier av olika ordning, hur säkerhetskopiering och deposition av det resulterande nyckelmaterialet fungerar, vad man ska kontrollera före ceremonidagen och de fellägen som förvandlar en rutinmässig ceremoni till ett revisionsfynd.

Vad är en nyckelceremoni, och varför är det viktigt?

En nyckelceremoni är den formella, kontrollerade procedur där ett kryptografiskt nyckelpar genereras, aktiveras och säkras, vanligtvis för en certifikatutfärdare (CA) , men även för företagsrotnycklar, kodsigneringsnycklar eller annat kryptografiskt material av högt värde. Det är lika delar teknisk procedur, säkerhetskontroll och efterlevnadskrav. Oavsett om nyckeln tillhör en offentligt betrodd rot-CA, ett nationellt e-ID-system eller ett privat företags interna PKI, finns ceremonin för att ge alla nedströms, förlitande parter, revisorer och organisationen själv, verifierbar försäkran om att nyckeln skapades under strikt, dokumenterad kontroll.

En viktig ceremoni är viktig av tre konkreta skäl:

• Transparens skapar förtroende. Processen bevittnas, loggas och dokumenteras så att externa granskare och förlitande parter inte behöver lita på CA:ns ord för hur nyckeln skapades.
• Distribuerat förtroende minskar risken. Kvorumbaserade kontroller innebär att ingen enskild person, oavsett hur högt uppsatt, kan generera, komma åt eller missbruka nyckeln ensam.
• Efterlevnad kräver det. WebTrust för certifieringsmyndigheter, ETSI-standarder och ramverk som PCI DSS och eIDAS alla kräver en dokumenterad, bevittnad nyckelgenereringsprocess för CA-nycklar.

Tänk på det som den kryptografiska motsvarigheten till att prägla valuta: alla som förlitar sig på den valutan behöver försäkran om att den producerades korrekt, säkert och under kontroller som de kan verifiera i efterhand. WebTrust-principerna och kriterierna för certifieringsmyndigheter är den revisionsstandard som de flesta offentligt betrodda certifieringsmyndigheter mäts mot, och nyckelgenereringsceremonier är en av dess mest granskade händelser.

Vilka är involverade i en nyckelceremoni?

Ingen enskild person leder en nyckelceremoni, och det är poängen. Rollfördelning är kontrollen, inte en formalitet kring den. En typisk ceremoni tilldelar:

• Ceremoniadministratör. Äger manuset, ordnar varje steg och är den enda personen som har behörighet att avvika från det, och endast genom att pausa och dokumentera varför.
• Kryptoansvariga / nyckelförvaltare. Var och en innehar en andel av kvorumet, vanligtvis ett smartkort eller en PED-nyckel, och presenterar den endast när skriptet kräver det.
• System- eller HSM-administratör. Sköter HSM- och Security World-verktygen under ceremoniadministratörens ledning.
• Vittnen. Oberoende personal (eller, för offentliga rotceremonier, en extern revisor) som övervakar varje steg, bekräftar att ingenting hände utanför manuskriptet och signerar loggen.
• Skrivare. Loggar varje åtgärd, tidsstämpel och deltagare i realtid; denna logg är revisionsbeviset.
• Revisor. För offentliga CA:er som granskats av WebTrust eller ETSI närvarar en oberoende kvalificerad revisor och intygar separat att ceremonin överensstämde med det godkända manuset.

Ingen roll kan slutföra en ceremoni ensam. Det är avsiktligt: ​​en ceremoniadministratör utan vittne har ingen oberoende bekräftelse på att manuskriptet följdes, och en kryptoansvarig utan kvorum kan inte låsa upp någonting på egen hand.

Vad är M-of-N-kvorum, delad kunskap och dubbel kontroll?

Dessa tre principer, hämtade direkt från NIST SP 800-57 del 1 :s riktlinjer för nyckelhantering, är det som gör en ceremoni motståndskraftig mot både insiderkompromisser och enkla mänskliga fel.

1. M-av-N kvorum innebär att HSM är konfigurerad så att en definierad delmängd (M) av en större grupp av nyckelpersoner (N) måste vara fysiskt närvarande för att auktorisera en känslig åtgärd. Ett kvorum på 3 av 5 innebär att fem personer har ett kort vardera, och tre personer, men aldrig färre, måste visa upp dem tillsammans. En för låg tröskel försvagar säkerheten; en för hög tröskel riskerar driftstopp när poliser är på resa eller inte är tillgängliga.
2. Delad kunskap betyder att ingen enskild person någonsin har tillräckligt med information för att rekonstruera nyckeln på egen hand. Varje förvaltares kort eller PED-nyckel skyddar endast ett fragment av auktoriseringsmaterialet, inte själva den privata nyckeln i en form som de skulle kunna extrahera och använda oberoende av varandra.
3. Dubbel kontroll innebär att minst två behöriga personer måste agera tillsammans för att utföra känsliga operationer, generering, säkerhetskopiering eller återställning, så en enda komprometterad eller tvingad person kan inte agera ensidigt.

Tillsammans är dessa tre principer anledningen till att en stulen bärbar dator, en tvingad administratör eller en enda dålig aktör inombords inte räcker för att äventyra en korrekt genomförd ceremoni. Kvorumet måste samlas fysiskt, och loggen registrerar exakt vem som gjorde det.

Vilken roll spelar HSM, och var ligger FIPS-gränsen?

Hårdvarusäkerhetsmodulen är där den privata nyckeln faktiskt genereras, och där den stannar . Inom HSM:s manipulationssäkra kryptografiska gräns, definierad och testad enligt FIPS 140-3 , skapas nyckelmaterialet med hjälp av en validerad slumptalsgenerator, som används för att signera rotcertifikatet, och förblir sedan antingen förseglad inuti modulen eller lämnas endast som en krypterad, inslagen backup-blob. Den privata nyckeln i klartext korsar aldrig den gränsen. Om den gjorde det skulle hela premissen för ceremonin, att ingen kan extrahera eller missbruka nyckeln, kollapsa.

FIPS 140-3 är den nuvarande amerikanska och kanadensiska standarden för validering av kryptografiska moduler, och den ersatte FIPS 140-2. NIST:s CMVP-övergångsschema flyttar alla återstående FIPS 140-2-certifikat till den historiska listan den 21 september 2026, varefter nya federala upphandlingar kräver 140-3-validerade moduler. För nyckelceremonier för rot- och mellanliggande CA-certifikat är säkerhetsnivå 3, som kräver identitetsbaserad operatörsautentisering och manipuleringsdetektering med svar, den praktiska nivån som de flesta offentligt betrodda CA:er och reglerade företag specificerar; vissa implementeringar kräver nivå 4:s extra skydd mot miljö- och icke-invasiva attacker.

Vad detta innebär operativt: innan ceremonin, bekräfta den exakta HSM-firmwareversionen och att dess FIPS-valideringscertifikat täcker de algoritmer och nyckelstorlekar du planerar att generera. En ceremoni som genererar en nyckel på ovaliderad firmware, eller på en modul som körs i ett icke-FIPS-godkänt läge, kan ogiltigförklara revisionsloggen även om varje procedurkontroll har följts korrekt.

Offline Root vs. Online Issuing CA: Varför distributionstopologi förändrar ceremonin

De flesta PKI-hierarkier följer samma form: en självsignerad rot-CA högst upp, en eller flera mellanliggande (utfärdande) CA:er under den, och slutgiltiga entitetscertifikat utfärdade av dessa mellanliggande. Den strukturen finns specifikt för att hålla rotens exponering till ett minimum, och den avgör direkt hur varje lagers nyckelceremoni körs.

Aspect	Rot-CA	Mellanliggande/utfärdande CA
Nätverksstatus	Offline, med avstånd mellan ceremonier	Online, ansluten till CA/RA-programvara
Fysisk plats	Låst valv eller kassaskåp, avstängt eller förseglat när det inte används	Säkert datacenter, aktivt i drift
Ceremonifrekvens	Sällsynt, vanligtvis en gång vid hierarkiskapandet, sedan endast för förnyelse eller DR	Mer frekvent, vid utfärdande, förnyelse eller rotation
Typiskt antal vittnen	Högst: flera tjänstemän, oberoende vittnen, ofta en extern revisor	Måttlig: kryptoansvariga plus internt vittne
Konsekvens av kompromiss	Katastrofal, hela hierarkin måste återkallas och utfärdas på nytt	Allvarligt men begränsat, återkalla och utfärda på nytt den berörda mellanprodukten

Eftersom en komprometterad rot ogiltigförklarar alla certifikat som någonsin utfärdats under den, får rotceremonier den största stringensen en PKI-hierarki har att erbjuda: dedikerat valvutrymme, videoinspelning från valvöppning till valvstängning, notariebekräftade loggböcker i fall med högsta säkerhet och flera oberoende vittnen. Mellanliggande CA-ceremonier följer fortfarande ett manus, kvorum och dubbel kontroll, men det operativa fotavtrycket är mindre eftersom en komprometterad mellanliggande är en begränsad, återställningsbar händelse snarare än en existentiell.

För en steg-för-steg-genomgång av en specifik ceremoni för en offentlig rot-CA-nyckel, inklusive hur rotautentitet verifieras i efterhand, se vår utbildningsartikel om rot-CA-nyckelceremonin.

Hur går en nyckelceremoni egentligen till?

Viktiga ceremonier improviseras aldrig. Varje ceremoni följer ett förskrivet, förhandsgodkänt manus, ibland kallat en byggbok, så ingenting bestäms i rummet. Den allmänna sekvensen ser ut så här:

1. Förberedelse. Roller tilldelas, rummet säkras (videoövervakning, manipuleringssäker försegling, begränsad åtkomst) och ceremonimanuskriptet slutförs och godkänns i förväg.
2. HSM och miljökonfiguration. HSM och all stödjande infrastruktur, för Entrust nShield-distributioner inkluderar detta Remote File System (RFS) som lagrar den krypterade Security World, installeras, härdas och anslutningstestas innan något nyckelmaterial berörs.
3. Skapande av Security World eller motsvarande domän. HSM-operatorn initierar den skyddade miljön som kommer att lagra nycklarna, definiera algoritm, nyckelstyrka och kvorumpolicy, och den konfigurationen lagras både på HSM och krypteras på RFS eller motsvarande.
4. Definition av kvorum. M-of-N-tröskeln är inställd och registrerad i skriptet.
5. Personalisering och distribution av kort eller PED-nycklar. Varje vårdnadshavares kort skapas, PIN-skyddas och överlämnas till dem under bevittnade bevittnade vittnesmål, sedan loggas och förvaras säkert när det inte används aktivt.
6. Nyckelgenerering och certifiering. Rot- eller mellanliggande nyckelpar genereras inom HSM:s FIPS-gräns, och motsvarande certifikat skapas och, för en rot, självsigneras; för en mellanliggande, signeras av den överordnade CA:n.
7. Dokumentation och signering. Skrivarens realtidslogg, vittnesunderskrifter och videoinspelning sammanställs i revisionspaketet.
8. Försegling och förvaring. Korten förvaras i manipuleringsförseglade påsar i ett kassaskåp, säkerhetskopior krypteras och flyttas till en sekundär säker plats, och HSM förseglas eller stängs av till nästa schemalagda ceremoni.

Varje steg i den sekvensen existerar eftersom att hoppa över det tar bort bevis som en revisor, eller en angripares försvarsadvokat, senare skulle begära.

Hur säkerhetskopieras och deponeras viktigt material?

En ceremoni som genererar en nyckel och aldrig säkerhetskopierar den har skapat en enda felpunkt förklädd till en säkerhetskontroll. Säkerhetskopiering sker inom samma bevittnade session med dubbla kontroller som genereringen, inte som en eftertanke:

• Krypterad export eller kloning. Nyckelmaterialet exporteras i radbruten form (aldrig klartext) till en säkerhetskopia, en klonad HSM eller en krypterad Security World / RFS-säkerhetskopiafil, beroende på leverantör.
• Delad vårdnad om säkerhetskopian. Säkerhetskopieringsmediet, och eventuella kort eller PED-nycklar som krävs för att återställa det, är uppdelade på förvaltare och lagras på geografiskt separata, åtkomstkontrollerade platser så att ingen förlust av en enskild plats förstör både den aktiva nyckeln och dess enda kopia.
• Escrow för reglerade miljöer. Vissa efterlevnadssystem och policyer för nyckelhantering inom företaget kräver en dokumenterad depositionskopia som förvaras under gemensam kontroll (ofta juridisk plus säkerhetsmässig), med en egen åtkomstlogg separat från den dagliga verksamheten.
• Periodisk återställningstestning. En säkerhetskopia som aldrig har återställts är en hypotes, inte en återställningsplan. För den operativa sidan av att testa HSM-säkerhetskopior och redundansväxling under produktionsbelastning, se vårt inlägg om HSM-kluster och hög tillgänglighet.

Samma principer för M-av-N-kvorum och dubbel kontroll som styr generering styr återställning. En återställningsprocedur som bara behöver en person för att återställa en rotnyckel har i tysthet återinfört den enda felpunkten som den ursprungliga ceremonin var utformad för att eliminera.

Vad behöver du före ceremonidagen? (Förutsättningar för integration)

De flesta problem med ceremonin är egentligen problem före ceremonin som uppstår för sent för att kunna åtgärdas ordentligt. En fungerande checklista för förkunskapskrav täcker fyra områden:

• Miljö. Fysisk plats säkrad, nätverksisolering bekräftad (rotceremonier ska inte ha någon live nätverksväg ut), video- och inspelningsutrustning testad i förväg.
• Personal. Varje roll tilldelad med namn, identitetsverifiering slutförd, kvorum bekräftat som tillgängligt för hela sessionen, säkerhetskopior identifierade ifall en namngiven vårdnadshavare inte kan delta.
• Hårdvara. HSM-modell, serienummer och firmwareversion dokumenterad och bekräftad mot det erforderliga FIPS-valideringscertifikatet; manipuleringssäker försegling inspekterad; en testkörning utförd på icke-produktionshårdvara för att upptäcka kommandofel innan de inträffar.
• Dokumentation. Ceremonimanuset färdigställt och godkänt i förväg, tomma loggsidor förberedda, media märkt och klart, och signeringsrader tillräckligt specifika för att registrera exakta förvaringsplatser och serienummer snarare än "säkert lagrade".

Regeln som är värd att internalisera: om det inte står i manuset så har det inte hänt, åtminstone inte vad gäller en revisor. Att skriva manuset i efterhand, eller att improvisera ett steg eftersom den första provkörningen hoppades över, är den enskilt vanligaste källan till granskningsresultat vid annars väl genomförda ceremonier.

Hur ser detta ut i praktiken?

Fyra scenarier täcker det mesta av vad organisationer faktiskt anordnar ceremonier för:

• Generering av offentlig rot-CA. En WebTrust-granskad CA genererar en ny rotnyckel. Förvänta dig ett dedikerat valv, fem eller fler deltagare i rollerna ovan, en oberoende granskare, notariebekräftad dokumentation och kontinuerlig video från det ögonblick valvet öppnas till det ögonblick det stängs.
• Stand-up CA för företag på mellannivå. Ett internt PKI-team sätter en ny utfärdande CA online under en befintlig offline-rot. Ceremonin är fortfarande skriptad och bevittnad, men omfattningen är mindre: vanligtvis två kryptoansvariga, ett vittne och en ceremoniadministratör, körs i ett säkert datacenter snarare än i ett valv.
• Uppgradering eller migrering av HSM-firmware. Att byta till ny hårdvara (till exempel återupprätta en Entrust nShield Security World på uppgraderade enheter, eller migrera mellan Thales Luna-partitioner) kräver att klienter registreras om och anslutningen testas på nytt innan någon produktionsnyckelåtgärd återupptas, under samma kvorumkontroller som användes vid den ursprungliga genereringen.
• Återställning efter katastrofåterställning. Efter ett hårdvarufel eller en platsförlust återställer förvaltare kvorumet och återställer rot- eller mellannyckeln från dess krypterade säkerhetskopia till ersättningshårdvara, en inövad, inte improviserad, procedur med dubbel kontroll.

Vad går fel, och hur förhindrar man det?

Tre fellägen står för de flesta ceremoniproblem som uppstår vid revisioner eller incidentgranskningar:

• Skriptavvikelse. Ett steg hoppas över, ändras ordning eller improviseras eftersom testkörningen inte gjordes eller skriptet inte var tillräckligt detaljerat för att täcka ett edge-fall. Mildrande åtgärder: en obligatorisk testkörning på icke-produktionshårdvara, ett låst och förhandsgodkänt skript och en regel om att alla avvikelser pausas, dokumenteras och godkänns på nytt innan de fortsätter snarare än att arbeta runt dem i tysthet.
• Bevittna eller granska luckor. Ett vittne träder fram, även om det bara är kort, och den luckan i den kontinuerliga bestyrkandet blir ett fynd senare, eller så rekonstrueras loggen i realtid från minnet i efterhand istället för att skrivas live. Mildrande åtgärder: kontinuerlig vittnesbevakning med dokumenterade byten om någon måste lämna, liveloggning allt eftersom varje handling sker och videoinspelning som en backstop till den skriftliga loggen.
• HSM-misslyckande mitt i ceremonin. Hårdvarufel innan säkerhetskopieringssteget är slutfört, och teamet måste bestämma om de ska starta om och varifrån. Åtgärder: verifiera att den krypterade säkerhetskopian slutförs och validerar innan sessionen förklaras avslutad, ha en reservvaliderad HSM till hands för viktiga rotceremonier och skripta avbrotts-/återupptagningsproceduren i förväg istället för att bestämma att den ska vara live.

Var och en av dessa kan förebyggas med planering gjord innan rummet låses, inte under själva ceremonin.

Vilken typ av ceremoni behöver du?

Ceremonityp	Typiskt användningsfall	Noggrannhet / vittnen	Frekvens
Generering av rot-CA-nyckel	Etablera en ny rot av förtroende, offentligt eller företag	Högst: 5+ deltagare, ofta en extern revisor, video, offline-valv	En gång vid hierarkiskapandet, sedan sällan
Generering av mellanliggande/utfärdande CA-nyckel	Skapa en ny underordnad CA under en befintlig rot	Måttlig: kryptoansvariga plus internt vittne	Vartannat år, eller per ny CA
Nyckelrotation / förnyelse	Byta ut en nyckel innan certifikatet har löpt ut	Måttlig, följer det ursprungliga godkända manuset	Schemalagd enligt certifikatpolicy
Återställning av katastrofåterställning	Återuppbygga en CA eller HSM efter hårdvarufel eller platsförlust	Hög: återställning med dubbel kontroll från krypterad säkerhetskopia	Vid behov; repeteras regelbundet
HSM-avveckling / nyckelförstöring	Ta ut hårdvara eller förstöra en komprometterad eller utgången nyckel	Hög: bevittnad nollställning, revisionsgodkännande	Slut på hårdvarans eller nyckelns livscykel

Begränsningar

Det här inlägget beskriver allmänt accepterad praxis för nyckelceremonier på utövarnivå. Det ersätter inte din organisations godkända certifikatpolicy/certifieringspraxis (CP/CPS), en specifik HSM-leverantörs officiella ceremonidokumentation eller de granskade krav som en offentligt betrodd certifikatutfärdare måste uppfylla enligt WebTrust eller ETSI. Exakt skriptstruktur, kortmekanik och terminologi (Security World och RFS för Entrust nShield; PED-autentiserade kontra lösenordsautentiserade partitioner för Thales Luna; molnbaserade HSM-konsolarbetsflöden för AWS CloudHSM, Azure Managed HSM eller Google Cloud HSM) varierar beroende på leverantör och distributionsmodell, och tillämpliga myndighetskrav varierar beroende på jurisdiktion och bransch. Betrakta detta som ramverket att planera mot, och validera sedan detaljerna mot din CPS och din HSM-leverantörs aktuella dokumentation före ceremonidagen.

Vad skulle krypteringskonsulter rekommendera?

Att genomföra en väl genomförd nyckelceremoni kräver mer än att samla människor i ett säkert rum och generera nycklar. Det kräver validerade procedurer, strikt rolluppdelning och dokumentation som är utformad för att överleva en revision flera år senare. Våra PKI-tjänster och HSM-tjänster stöder ceremonier från början till slut:

• Utformning av ceremoniförfarandet. Steg-för-steg-skript utformade för era efterlevnadskrav, WebTrust, PCI DSS, FIPS 140-2/3och din organisations egen CP/CPS.
• Omfattande dokumentation. Skapa böcker, checklistor före ceremonin, manus till ceremonin och rapporter efter ceremonin som håller för granskning.
• Support för firmware och konfiguration. Uppgraderingar av HSM-firmware, initiering av hårdvara och konfiguration av Security World eller partitioner, så att ceremonin börjar på validerade grunder.
• Genomförande och facilitering av ceremoni. Vi kan fungera som ceremoniadministratör, vaktmästare eller oberoende vittnen, säkerställa att kvorum är tillåtet och logga varje handling.
• Utbildning och kunskapsöverföring. Vi ger ert interna team förståelsen för att leda framtida ceremonier på egen hand, med självförtroende.
• Försäkran efter ceremonin. Färdigställd dokumentation, revisionsvalidering och rekommendationer för löpande nyckelhantering och säkerhetskopieringstestning.

För organisationer som vill ha nyckelskydd av hårdvaruklass utan att själva äga och driva HSM-infrastrukturen, ger HSM-as-a-Service validerad, högtillgänglig HSM-kapacitet samma noggrannhet som beskrivs här, utan bördan av att skaffa och underhålla hårdvaran.

Vanliga frågor om partihandel med mat och dryck

Hur lång tid tar en nyckelceremoni?
En rot-CA-ceremoni varar vanligtvis en hel dag då du inkluderar installation, verifiering, generering, säkerhetskopiering, dokumentation och försegling. Mellanliggande CA-ceremonier är vanligtvis kortare, ofta några timmar, eftersom kraven på fysisk säkerhet och vittnesbevisningar är lättare.

Vem ska vara i rummet för en viktig ceremoni?
Minst en ceremoniadministratör, kryptotjänstemän som innehar kvorumandelar, en HSM-operatör och minst ett oberoende vittne. Offentligt betrodda rotceremonier lägger vanligtvis till en extern revisor och ytterligare vittnen för att uppfylla WebTrust- eller ETSI-krav.

Vad är den verkliga skillnaden mellan en rot-CA-ceremoni och en mellanliggande CA-ceremoni?
Att roten komprometteras är katastrofalt och påverkar alla certifikat som hierarkin någonsin har utfärdat, så rotceremonier får högsta möjliga noggrannhet: offline-valv, fler vittnen, videoinspelning och ofta notariebekräftelse. Mellanliggande ceremonier använder fortfarande kvorum och dubbel kontroll men skalar ner den fysiska säkerheten eftersom en komprometterad mellanliggande aktör är innesluten och kan återställas.

Kan en nyckelceremoni genomföras på distans?
Vissa organisationer genomför ceremonier med lägre risk, som att rotera en intern mellanliggande nyckel, med distansdeltagare under video- och skärmdelningskontroller. Rot-CA-ceremonier för offentligt betrodda hierarkier genomförs nästan alltid personligen, eftersom distansdeltagande försvagar de fysiska bevis för spårbarhetskedjan som revisorer kräver.

Vad händer om HSM misslyckas under ceremonin?
En välskriven ceremoni tar hänsyn till detta innan det händer: skriptet anger om det ska avbrytas och startas om från det senast slutförda steget eller fortsätta på en validerad reserv-HSM, och ingen säkerhetskopia anses vara klar, och sessionen avslutas inte förrän den krypterade säkerhetskopian har genererats och verifierats.

Slutsats

En nyckelceremoni är en av de mest betydelsefulla händelserna i en PKI:s livscykel. Den kombinerar rollseparation, M-of-N-kvorum, delad kunskap och en HSM:s FIPS-validerade gräns till en enda, granskningsbar procedur som ger alla nedströms, granskare, förlitande parter och organisationen själv, ett verifierbart svar på "hur vet vi att den här nyckeln är pålitlig?". Få rätt topologi (offline-root, online-mellanled), skripta varje steg i förväg, säkerhetskopiera under samma dubbla kontroll som används för att generera och öva på fellägena innan de dyker upp objudna, och ceremonin gör exakt vad den är utformad för att göra: skapa en rot av förtroende som ingen behöver ta på sig.

Med expertvägledning från en partner som har drivit den här processen inom både offentliga och stora företagshierarkier behöver du inte planera din första, eller din femtionde, ceremoni ensam.

Referensprojekt

• WebTrust-principer och kriterier för certifieringsmyndigheter, CPA Kanada
• CA/Browser Forum Baskrav för utfärdande och hantering av offentligt betrodda TLS-certifikat
• NIST SP 800-57 Del 1 Revision 5, Rekommendation för nyckelhantering
• FIPS 140-3, Säkerhetskrav för kryptografiska moduler, NIST
• FIPS 140-3-övergångsinsats, NIST CSRC
• Operatörskortsuppsättningar (OCS), Entrust nShield-dokumentation