Förstå och generera certifikatsigneringsförfrågningar (CSR) med Luna Cloud HSM – En omfattande guide

En certifikatsigneringsbegäran (CSR) är det meddelande som en server eller applikation skickar till en certifikatutfärdare (CA) för att begära ett SSL/TLS- eller kodsigneringscertifikat. Att generera den CSR:n med hjälp av Luna Cloud HSM ändrar var den privata nyckelhalvan av begäran finns: istället för att finnas i en programvarunyckellagring genereras och lagras den inuti en Thales-hanterad, FIPS 140-3-validerad hårdvarugräns. Den här guiden beskriver vad en CSR är, varför nyckelparet hör hemma i en HSM snarare än i programvara, och den fullständiga steg-för-steg-processen för att generera, signera och styra en CSR med hjälp av Luna Cloud HSM.

Publicerad: juni 2023. Uppdaterad: augusti 2026. Granskad av Encryption Consultings PKI- och HSM-tjänsteteam.

Vad är ett CSR och varför är det viktigt?

En CSR är ett block med kodat text som skickas till en certifikatutfärdare när ett certifikat begärs. Den genereras på, eller för, det system där certifikatet ska installeras, och den följer PKCS#10-syntaxen som definieras i RFC 2986. CSR:n innehåller den identifierande information som kommer att finnas i certifikatet, såsom organisationsnamn, gemensamt namn (domänen eller ämnet som certifikatet skyddar), ort och land, tillsammans med den publika nyckel som certifikatutfärdaren kommer att binda till den identiteten.

Att generera en CSR producerar två artefakter, inte en. Själva CSR:n innehåller den publika nyckeln och skickas till CA:n i det öppna. Den privata nyckeln genereras samtidigt och lämnar aldrig systemet, HSM:n eller nyckellagret som skapade den. CA:n ser aldrig den privata nyckeln och behöver inte göra det; den verifierar bara begäran och signerar den publika nyckeln i ett certifikat. Om den privata nyckeln någonsin exponeras, kopieras eller kan gissas, är certifikatet som byggts ovanpå den CSR:n inte längre tillförlitligt , oavsett hur korrekt själva CSR:n formaterades.

Varför generera CSR:ns nyckelpar inuti en HSM istället för i programvara?

En CSR som genereras med OpenSSL eller en Windows-certifikat-snap-in skapar den privata nyckeln i programvara, vanligtvis i en nyckelfil eller operativsystemets certifikatarkiv som endast skyddas av filbehörigheter och, i bästa fall, en lösenfras. Den nyckeln kan kopieras. Ett säkerhetskopieringsjobb, en felkonfigurerad delning, ett komprometterat administratörskonto eller en skadlig kod med lokal åtkomst kan bli av med den, och när den väl har kopierats finns det inget sätt att bevisa att den inte kopierades.

Att generera samma nyckelpar inuti Luna Cloud HSM ändrar den kalkylen. Den privata nyckeln skapas inuti en Thales HSM-partition och markeras som icke-exporterbar; varje signeringsoperation sker innanför modulgränsen, och själva nyckelmaterialet passerar aldrig in i serverminnet eller disken i användbar form. Detta är den praktiska skillnaden mellan "nyckeln är skyddad" och "nyckeln kan inte lämna", och det är anledningen till att HSM-baserad CSR-generering är standardförväntningen för offentliga CA-rot- och utfärdandenycklar, kodsigneringsnycklar och alla certifikat vars kompromettering skulle låta en angripare imitera organisationen. Det uppfyller också kraven på hårdvarunyckelskydd som finns i PCI DSS , och det är det som håller en Luna Cloud HSM-distribution inom en FIPS 140-3-validerad gräns snarare än en endast mjukvarubaserad.

Översikt över Luna Cloud HSM från Thales: Funktioner och fördelar

Luna Cloud HSM är en HSM -tjänst (Hardware Security Module) från Thales, levererad via Thales Data Protection on Demand (DPoD). Istället för att lagra och hantera fysiska HSM-enheter, etablerar en organisation en Luna Cloud HSM-tjänst och ansluter till den via internet som en partition. Det eliminerar hårdvaruanskaffning och datacenterkostnader för en traditionell HSM samtidigt som samma manipulationssäkra nyckelskydd bibehålls.

En HSM är en dedikerad enhet med specialiserade kryptografiska processorer byggda för att generera, lagra och använda krypteringsnycklar inom en isolerad, manipulationssäker gräns. Luna Cloud HSM ger det skyddet till en molnleveransmodell: samma nyckelisolering som en fysisk HSM, med skalbarheten och den lägre initiala kostnaden för en hanterad tjänst.

De viktigaste funktionerna i Luna Cloud HSM är:

1. Robust säkerhet

   Luna Cloud HSM utnyttjar Thales krypterings- och nyckelhanteringsfunktioner inom en FIPS 140-3-validerad, manipulationssäker gräns utformad för en hög nivå av molndataskydd.

2. Skalbarhet

   Allt eftersom kryptografiska behov växer skalar Luna Cloud HSM med dem. Det finns ingen ytterligare HSM-hårdvara att köpa eller installera.

3. Hög tillgänglighet

   Luna Cloud HSM stöder hög tillgänglighet och automatisk redundans för att upprätthålla affärskontinuitet, inklusive distribution i flera regioner för att minska lokala avbrott.

4. Compliance

   Luna Cloud HSM hjälper till att uppfylla myndighetskrav kopplade till kryptografiska operationer och nyckelhantering, inklusive PCI DSS , GDPR och HIPAA , med inbyggd granskning och loggning.

5. Interoperabilitet

   Luna Cloud HSM stöder en rad kryptografiska API:er och bibliotek, inklusive PKCS#11, Java (JCE), Microsoft CryptoAPI och Microsoft CNG, så det integreras med en bred uppsättning applikationer och tjänster.

Se hela listan över klientplattformar som stöds för Luna Cloud HSM på Thales dokumentationswebbplats . Nuvarande klientplattformsstöd inkluderar Red Hat Enterprise Linux 7/8 och CentOS 7/8 på Linux, och Windows Server 2012 R2 till Windows Server 2019 plus Windows 10 på Windows, anslutna via PKCS#11, Java Cryptography Architecture, OpenSSL, Microsoft CAPI eller Microsoft CNG.

Hur man genererar en CSR med Luna Cloud HSM: Steg-för-steg-process

Arbetsflödet nedan återspeglar hur CSR-generering mot en Windows-baserad CA vanligtvis körs mot en Luna Cloud HSM (DPoD)-tjänst: etablera en tjänstklient på DPoD-tjänsten, installera och registrera den på den begärande datorn, registrera SafeNet Key Storage Provider och skapa och skicka sedan CSR:n. Skärmbilderna nedan är från en live Thales DPoD-klient och en Microsoft ADCS-miljö; din konsolmärkning kan variera något beroende på DPoD-version.

Steg 1: Installera Luna Cloud HSM-tjänstklienten

• Gå till tjänstsidan och klicka på den tjänst eller det partitionsnamn som du vill generera en klient för.

  

• Klicka på Ny tjänsteklient så visas fönstret Skapa tjänsteklient.

  

• I fönstret Skapa tjänsteklient anger du ett klientnamn (till exempel Pega-makro) och väljer Skapa tjänsteklient.

  

Steg 2: Konfigurera den installerade tjänstklienten

• Ett nytt klientpaket (till exempel setup-PKI-Luna.zip) genereras och är tillgänglig för nedladdning och installation på klientdatorn.
• Klientpaketet är en zip-fil som innehåller det anslutningsmaterial som behövs för att nå HSM-partitionen. Se avsnittet Klientinnehåll i Thales-dokumentationen för en fullständig översikt över vad det innehåller.
• Överför klientpaketet till måldatorn med en godkänd metod som SCP, PSCP, WinSCP eller FTPS.
• Packa setup-PKI-Luna.zip med hjälp av Windows grafiska gränssnitt eller ett kommandoradsverktyg för att packa upp.
• Packa upp cvclient-min.zip-filen som den innehåller.
• Extrahera cvclient-min.zip från katalogen som skapades i föregående steg; den platsen krävs för setenv-kommandot nedan. Extrahera den inte till en ny underkatalog av typen cvclient-min.zip.

• Ställ in miljövariabeln. Öppna en kommandotolk för administratörer (högerklicka på Kommandotolken och välj Kör som administratör) och kör sedan kommandot setenv från den extraherade klientkatalogen:

  

Steg 3: Konfigurera SafeNet Key Storage Provider (KSP)

• Systemet behöver åtkomst till SafeNet Key Storage Provider (KSP). Kopiera SafeNetKSP.dll-filen från den nedladdade Luna Cloud HSM Service Client till C:\Windows\System32.

  Obs! Om filen SafeNetKSP.dll inte kopieras kommer SafeNet Key Storage Providers inte att vara tillgängliga under integrationen. Om du till exempel konfigurerar Microsoft Active Directory Certificate Services kommer SafeNet Key Storage Providers inte att visas som alternativ när du konfigurerar kryptografi för certifikatutfärdaren.

• Kör KspConfig.exe.
• Navigera till KSP-installationskatalogen.
• Dubbelklicka Registrera eller visa säkerhetsbiblioteket.

• Klicka på Bläddra . Välj filen cryptoki.dll från Luna Cloud HSM-tjänstklienten och klicka sedan på Registrera.

  

• När registreringen är lyckad visas meddelandet " Lyckades!" . Klicka på OK.

  

• Dubbelklicka på Registrera HSM-platser.

• Registrera HSM för administratörsanvändaren. Öppna rullgardinsmenyn Registrera för användare och välj Administratör, öppna rullgardinsmenyn Domän och välj domänen, öppna rullgardinsmenyn Tillgängliga platser och välj serviceetiketten, ange platslösenordet och klicka på Registrera plats.

  

• När registreringen har lyckats visas meddelandet " Lyckades!" . Klicka på OK.

  

• Registrera HSM för systemanvändaren. Öppna rullgardinsmenyn Registrera för användare och välj SYSTEM, öppna rullgardinsmenyn Domän och välj NT-AUTORITET, öppna rullgardinsmenyn Tillgängliga platser och välj serviceetiketten, ange platslösenordet och klicka på Registrera plats.

  

• När registreringen är lyckad visas meddelandet "Lyckades!". Klicka på OK.

  

Steg 4: Generera CSR:n i tjänsteklienten

• Skapa en fil med namnet request.inf och fyll i den för att generera en begäran om ett SSL-certifikat som är kopplat till en RSA- nyckel. Exempel på innehåll:

  [Version]
Signature = "$Windows NT$"
[NewRequest]
Subject = "C=US, S=Dallas, L=Texas, O=Encryption Consulting LLC, OU=Dev, [email protected], CN=ECIssued"
HashAlgorithm = SHA256
KeyAlgorithm = RSA
KeyLength =2048
ProviderName = "Safenet Key Storage Provider"
KeyUsage = 0xf0
MachineKeySet =True
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

  

  Obs: Ämnesnamnet (CN) ovan är ett exempelvärde och bör ersättas med det faktiska ämnet för det certifikat som begärs.

  Parametrarna är:

  • namnteckning

    ”$Windows NT$” anger att INF-filen är avsedd att användas med Windows NT och senare versioner av Windows.

  • Ämne

    • C är den tvåbokstäver långa landskoden för certifikatbegärans unika ämnesnamn (DN). Denna parameter ska finnas i ämnes-DN.
    • S är tillståndsnamnet för certifikatbegärans unika ämnesnamn (DN). Denna parameter ska finnas i ämnes-DN:et.
    • L är orten, vanligtvis staden, för det unika ämnesnamnet för certifikatbegäran. Denna parameter kan finnas i ämnes-DN.
    • O är organisationsnamnet för certifikatbegärans unika ämnesnamn (DN). Denna parameter ska finnas i ämnes-DN:et.
    • OU är organisationsenhetens namn för certifikatbegärans unika ämnesnamn (DN). Denna parameter kan finnas i ämnes-DN.
    • e är den kontakt-e-postadress som är kopplad till begäran.
    • CN är det gemensamma namnet för certifikatbegärans unika ämnesnamn (DN). Denna parameter ska finnas i ämnes-DN:et.

  • HashAlgoritm

    SHA256 ställer in hashalgoritmen till SHA-256, det nuvarande standardvalet.

  • Nyckelalgoritm

    RSA ställer in nyckelalgoritmen till RSA, en allmänt använd algoritm för offentlig nyckel.

  • Nyckellängd

    2048 ställer in nyckellängden till 2048 bitar, den nuvarande baslinjen för RSA-nycklar i offentliga TLS-certifikat.

  • Leverantörsnamn

    ”SafeNet Key Storage Provider” anger vilken kryptografisk tjänsteleverantör (CSP) som ska användas. CSP:n är det programbibliotek som implementerar de kryptografiska funktionerna; här dirigeras nyckelgenerering och signering till Luna Cloud HSM-partitionen via SafeNet KSP.

  • Nyckelanvändning

    0xf0 anger nyckelns syfte i certifikatet. I hexadecimalt format motsvarar 0xf0 binärt värde 11110000, vilket representerar nyckelanvändningar för digital signatur (0x80), nyckelchiffrering (0x20), datachiffrering (0x10) och nyckelavtal (0x08).

  • Maskinnyckeluppsättning

    True lagrar den privata nyckeln i den lokala datorns certifikatarkiv snarare än den aktuella användarens arkiv.

  • EnhancedKeyUsageExtension

    OID=1.3.6.1.5.5.7.3.1 anger den avsedda certifikatanvändningen. Denna OID representerar "Serverautentisering", vilket betyder att certifikatet är avsett för autentisering av servrar i SSL/TLS-kommunikation.

• Öppna ett nytt kommandotolksfönster som administratör.
• Navigera till sökvägen som innehåller request.inf och tryck på Enter.

• Generera certifikatbegäran med följande kommando:

  certreq -new request.inf request.req

  

  Detta kommando skapar en ny CSR-fil med namnet request.req baserat på konfigurationen i request.inf, med den privata nyckeln som genereras och lagras inuti Luna Cloud HSM-partitionen. Skicka request.req till certifikatutfärdaren för att begära certifikatet.

Hur får man CSR:n signerad och installerad?

När request.req finns måste det nå certifikatutfärdaren och komma tillbaka som ett installerat certifikat som fortfarande är bundet till den privata nyckeln som finns i HSM-partitionen. Det finns två vanliga sökvägar mot en Microsoft-certifikatutfärdare.

Väg A: Skicka in begäran direkt

• Överför CSR-filen till den utfärdande CA:n och kör:

  certreq -submit -attrib "CertificateTemplate:<Template Name>" "C:\MacroSign.csr"

  I det här exemplet är mallnamnet ”EncryptionConsuCodeSigning”.

  

• När du har valt certifikatutfärdaren från listan sparar du det resulterande certifikatet med ett lämpligt namn och filändelsen .crt eller .cer.

  

• Vid lyckad körning visas certifikatet i Utfärdade certifikat i certifikatutfärdaren.

  

• Bekräfta att ”Code Signing” (eller den förväntade användningen) visas i attributet Enhanced Key Usage för det nyligen utfärdade certifikatet.

  

Väg B: Inlämning via webbregistrering

• Granska de tillgängliga mallarna i certifikatutfärdaren.

  

• Öppna CA:s webbregistreringssida och välj lämplig mall, till exempel ”Kodsignering”.

  

• Välj Begär ett certifikat och sedan Avancerad certifikatbegäran.

  

• Klistra in innehållet i CSR:n i Sparad begäran , välj rätt certifikatmall och klicka på Skicka.

  

• Välj Ladda ner certifikatkedjan istället för det enskilda certifikatet och ladda ner det till det lokala systemet.

  

• Så här ser certifikatkedjan ut när den har laddats ner.

  

Binda certifikatet tillbaka till dess privata nyckel

• Acceptera och installera certifikatet så att det är tillgängligt i Windows-miljön.

  

• Lägg till certifikatet i den "Personliga" arkivet för Certifikat – Lokal dator med hjälp av:

  certutil -store MY "<thumbprint of the certificate>"

  

Vem äger den privata nyckeln som denna CSR genererar?

Den privata nyckeln som genereras tillsammans med en Luna Cloud HSM CSR tillhör den HSM-partition den skapades i, inte den person som körde certreq. I praktiken innebär det att tre roller måste tilldelas och hållas separerade: en partitionsägare (vanligtvis PKI- eller HSM-tjänsteteamet) som kontrollerar vilka applikationer och användare som kan nå partitionen; en applikations- eller tjänsteägare som använder det resulterande certifikatet och ansvarar för att förnya det innan det löper ut; och en HSM-administratör som hanterar partitionens kryptoansvariga och kryptoanvändarroller men inte nödvändigtvis har insyn i vilka certifikat partitionen används för. Dokumentera detta ägande i din CP/CPS eller nyckelhanteringspolicy innan du genererar produktionsnycklar, inte efter att en incident tvingar fram frågan.

När bör du rotera certifikatet som denna CSR producerar?

Rotera certifikatet och generera en ny CSR mot ett nytt nyckelpar, beroende på vilken av dessa utlösare som kommer först: CA/Browser Forums giltighetsgräns, en komprometterad eller misstänkt komprometterad nyckel eller system som det var bunden till, en ändring av ämnet som certifikatet identifierar (en omdöpt tjänst, en avaktiverad värd, en ändrad SAN-lista) eller en schemalagd kryptografisk uppdatering kopplad till algoritm- eller nyckellängdspolicy. Offentliga TLS-certifikat har en krympande giltighetsklocka enligt CA/Browser Forums omröstning SC-081v3 : maximal giltighet sjunker till 200 dagar från och med mars 2026, 100 dagar från och med mars 2027 och 47 dagar från och med mars 2029. Att manuellt köra igenom stegen ovan var 47:e dag är inte en plan; det är värt att automatisera förnyelse mot en Luna Cloud HSM-backad CA via PKI-as-a-Service snarare än att upprepa detta arbetsflöde manuellt vid varje cykel.

Vem bör tillåtas att utlösa CSR-generering?

CSR-generering mot en HSM-partition bör inte vara öppen för alla serveradministratörer som råkar ha nätverksåtkomst till DPoD-tjänstklienten. Begränsa det längs tre linjer: åtkomst på partitionsnivå, så att endast de tjänstkonton och namngivna administratörer som är registrerade mot den specifika HSM-platsen kan begära nyckelgenerering; rollseparation, så att den person som kan skapa en ny tjänstklient inte automatiskt är den person som kan godkänna den resulterande certifikatmallen på CA:n; och ändringskontroll, så att en ny CSR mot en produktionspartition går igenom samma godkännandeväg som alla andra begäranden om produktionsnyckelmaterial, inte ett ad hoc-ärende. Om certifikatet skyddar en rot- eller utfärdande CA-nyckel snarare än en slutenhetstjänst, behandla CSR-generering som en del av en formell nyckelceremoni med definierade vårdnadshavarroller, inte en rutinmässig administrativ uppgift.

Vilka revisionsbevis bör CSR-genereringen producera?

Eftersom CSR-generering mot Luna Cloud HSM skapar en ny privat nyckel inom en reglerad kryptografisk gräns, bör den lämna samma typ av bevisspår som en nyckelceremoni, skalad till risken för vad certifikatet skyddar. Som ett minimum ska DPoD-tjänstklientens skapandepost behållas, identiteten på vem som registrerade HSM-platsen och när, request.inf-innehållet som användes (med ämnes- och nyckelparametrarna som angavs), certreq-utdata och resulterande CSR-fil, CA:s beslut att utfärda mot en specifik mall och det slutliga certifikatets tumavtryck kopplat till utfärdandehändelsen. För allt som matar en SOC 2-, PCI DSS- eller ISO/IEC 27001-revision måste det spåret kunna hämtas på begäran och kopplas till en namngiven individ, inte bara "någon i PKI-teamet". Revisorer som granskar HSM-baserade nyckelmaterial frågar konsekvent efter denna kedja; saknade delar av den är ett av de vanligaste fynden i PKI-revisioner.

Programvarugenererad CSR kontra HSM-genererad CSR: Hur står de sig i jämförelse?

CSR-filen som kommer ut från endera sökvägen ser identisk ut med en CA; skillnaden ligger helt i var och hur den privata nyckeln finns före och efter att filen skapas.

Faktor	Programvarugenererad CSR	HSM-genererad CSR (Luna Cloud HSM)
Var den privata nyckeln finns	OS-nyckellager eller en fil på disk	Inuti en FIPS 140-3-validerad hårdvarupartition, ej exporterbar
Exponering för säkerhetskopior eller filkopieringsexfiltrering	Möjligt; nyckelfilen kan kopieras	Inte möjligt; nyckeln lämnar aldrig modulgränsen
Installationsarbete	Låg; ett enda OpenSSL- eller certreq-kommando	Högre; kräver en provisionerad HSM-partition, serviceklient och KSP-registrering
Typiskt användningsfall	Interna testcertifikat, kortlivade utvecklings-/test-TLS, interna tjänster med låg risk	Publika TLS på produktionsdomäner, kodsigneringsnycklar, CA-utgivning och rotnycklar, reglerade miljöer
Efterlevnadsanpassning	Sällan tillräckligt ensamt för PCI DSS-hårdvarunyckelskydd eller CA/Browser Forum-root-/utfärdande nyckelkrav	Uppfyller kraven för skydd av hårdvarunycklar enligt PCI DSS och CA/Browser Forums grundkrav för CA-nycklar.
Verifieringskedja	Begränsat till operativsystem- eller programloggar, om några	Partitionsnivåloggning kopplad till en namngiven tjänstklient och platsregistrering

Som en tumregel: om certifikatets kompromettering skulle låta någon utge sig för att vara din organisation, signera skadlig kod som du eller utfärda bedrägliga nedströmscertifikat, generera CSR:ns nyckelpar i en HSM. Om det är ett internt testcertifikat för engångsbruk som kommer att ersättas inom några dagar, är programvarugenerering en rimlig avvägning.

Vad händer om en CSR eller privat nyckel hanteras felaktigt?

En läckt CSR är i sig en mindre exponering; den innehåller endast offentlig information. En läckt, kopierad eller felaktigt exporterad privat nyckel har en annan allvarlighetsgrad, eftersom den låter någon annan presentera sig som certifikatets legitima innehavare. Om en privat nyckel kopplad till en CSR som genererats genom denna process misstänks vara exponering, följer svaret samma form som alla komprometterade nyckelringar: återkalla det associerade certifikatet hos CA omedelbart och begär att återkallningsstatusen publiceras (CRL/OCSP), rotera till ett nyligen genererat nyckelpar istället för att återanvända det komprometterade, granska HSM-partitionens åtkomst- och slotregistreringsloggar för att avgöra hur exponeringen inträffade och meddela alla nedströmssystem eller förlitande parter som litade på det återkallade certifikatet. Eftersom en HSM-genererad nyckel aldrig existerar utanför partitionen från första början, är det vanligaste verkliga "komprometterings"-scenariot för HSM-baserade certifikat inte nyckelstöld utan en felaktigt hanterad CSR-begäran, felaktig mallkonfiguration på CA eller en överbehörig tjänsteklient, vilket är anledningen till att åtkomstpolicyn och revisionsbeviskontrollerna ovan är lika viktiga som själva genereringssteget.

Begränsningar

Generering av Luna Cloud HSM CSR är inte en direkt ersättning för ett fem minuter långt OpenSSL-kommando. Det kräver en provisionerad DPoD-klient och partition, en korrekt installerad tjänstklient och KSP-registrering innan den första CSR:n kan genereras, vilket ger en real installationstid vid första omgången. Klientplattformsstödet är också begränsat än ett generellt OpenSSL-arbetsflöde: nuvarande Luna Cloud HSM-klienter riktar sig mot specifika Linux- och Windows Server-versioner snarare än varje operativsystem som ett certifikat kan behöva utfärdas från. Några praktiska problem dyker också upp tillräckligt ofta för att påpekas direkt:

• KSP-registrering misslyckas i Windows. Detta händer vanligtvis när Windows Update saknar ett steg som verifierar att SafeNet-DLL:erna är signerade av ett certifikat som kedjar tillbaka till en betrodd rot. Om Luna-klientvärden har internetåtkomst, uppdatera betroddarkivet manuellt med certutil, eller transportera det nödvändiga rotcertifikatet till en värd med air-gapped och lägg till det med certutil -addstore.
• Certifikatmallens ämne visas inte på det utfärdade certifikatet. Detta är vanligtvis ett konfigurationsproblem för CA-mall snarare än ett HSM-problem; duplicera den relevanta certifikatmallen på CA:n, ange Nyckelanvändning och Utökad Nyckelanvändning explicit under mallens flik Tillägg och utfärda mallen igen innan du begär igen.
• Den privata nyckeln visas inte bifogad certifikatet efter utfärdandet. Testa ett certutil repairstore-pass mot certifikatarkivet innan du antar att nyckeln har förlorats. I de flesta fall finns nyckeln fortfarande kvar i HSM-partitionen och det lokala certifikatarkivet har helt enkelt förlorat kopplingen.

Vad skulle krypteringskonsulter rekommendera?

Att manuellt gå igenom installation av tjänstklienter, KSP-registrering och request.inf-filer på varje värd är ett rimligt sätt att lära sig hur Luna Cloud HSM-baserad CSR-generering fungerar, men det skalar inte bortom ett fåtal certifikat, och det lägger de revisionsbevis som beskrivs ovan på enskilda administratörer att samla in och behålla manuellt. Två EC-tjänster täcker den luckan direkt. PKI-as-a-Service automatiserar certifikatregistrering, förnyelse och återkallelse mot en HSM-baserad CA, så den manuella CSR-sedan-certreq-cykeln ovan sker genom policydriven automatisering istället för att en person upprepar den var 47:e till 200:e dag allt eftersom giltighetstiderna krymper. HSM-as-a-Service hanterar partitionsprovisionering, konfiguration av hög tillgänglighet och nyckelförvaringskontroller som finns under Luna Cloud HSM, så det privata nyckelskydd som den här artikeln beskriver hanteras till ett definierat SLA snarare än att konfigureras en gång och lämnas orört. Båda stöds av EU-kommissionens ISO/IEC 27001:2022- och SOC 2-anpassade verksamhetspraxis, vilket är vad de flesta av revisionsfrågorna ovan egentligen efterfrågar från första början.

Om det omedelbara behovet är en engångs-CSR snarare än en fullständigt hanterad HSM, är EC:s kostnadsfria CSR Generator och OpenSSL CSR and Certificate Decoder bra utgångspunkter innan man bestämmer sig för ett HSM-baserat arbetsflöde.

Slutsats

En CSR är det som låter en certifikatutfärdare bygga ett certifikat kring din publika nyckel utan att någonsin röra din privata nyckel. Genom att generera den CSR:n med Luna Cloud HSM hålls den privata nyckeln inom en FIPS 140-3-validerad gräns från det ögonblick den skapas, vilket är anledningen till att HSM-baserad generering är den förväntade praxisen för publika TLS, kodsignering och CA-nycklar snarare än ett valfritt härdningssteg. Mekaniken, installationen av tjänsteklienten, KSP-registreringen, request.inf-konfigurationen och CA-inlämningen är bara halva bilden. Ägarskap, rotationskadens mot CA/Browser Forums krympande giltighetsschema, åtkomstkontroll över vem som kan utlösa generering och bevarande av revisionsbevis är det som förvandlar en engångs teknisk övning till ett certifikatprogram som överlever en revision och en incidentgranskning.

Vanliga frågor om partihandel med mat och dryck

Ser CA någonsin den privata nyckeln som genereras för en Luna Cloud HSM CSR?
Nej. Endast CSR:n, som innehåller den publika nyckeln och ämnesinformationen, skickas till CA:n. Den privata nyckeln genereras inuti HSM-partitionen och överförs, exporteras eller är aldrig synlig för CA:n under processens gång.

Kan Luna Cloud HSM generera CSR:er för andra algoritmer än RSA?
Ja. Arbetsflödet request.inf som visas ovan använder RSA eftersom det fortfarande är det vanligaste valet för TLS-servercertifikat, men Luna Cloud HSM-partitioner stöder även ECC-nyckelgenerering via samma PKCS#11-, KSP- eller JCE-gränssnitt, beroende på vad den begärande applikationen och CA-mallen accepterar.

Är Luna Cloud HSM samma sak som en fysisk Luna Network HSM?
Nej. Luna Network HSM är Thales lokala apparat; Luna Cloud HSM är motsvarande funktion som levereras som en tjänst via Thales Data Protection on Demand. Båda använder samma underliggande HSM-teknik och PKCS#11-gränssnitt, men Luna Cloud HSM eliminerar hårdvaruanskaffning och datacenterhantering.

Behöver jag en Luna Cloud HSM-partition för varje certifikat, inklusive interna testcertifikat?
Nej. HSM-baserad generering är värd installationskostnaden för certifikat vars kompromettering medför verkliga konsekvenser, såsom publik TLS, kodsignering och CA-nycklar. Interna testcertifikat med låg risk och kort livslängd genereras vanligtvis i programvara istället, vilket beskrivs i jämförelsetabellen ovan.

Vad händer med certifikat som redan utfärdats från en Luna Cloud HSM-nyckel när partitionen tas bort?
Om du tar bort HSM-partitionen tas den privata nyckeln bort, vilket gör alla certifikat som är kopplade till den nyckeln permanent oanvändbara för signering eller dekryptering när själva certifikatet har löpt ut eller återkallats. Säkerhetskopiera partitionsinnehållet enligt Thales dokumenterade säkerhetskopieringsprocedurer innan du tar bort eller migrerar en partition, och återkalla alla certifikat som fortfarande är beroende av nycklar i en partition som är schemalagd för borttagning.

Referensprojekt

• IETF, RFC 2986: PKCS #10 Syntaxspecifikation för certifieringsbegäran version 1.7
• Thales, Klientplattformar som stöds av Luna Cloud HSM-tjänsten
• CA/Webbläsarforum, Valomröstning SC-081v3: Schema för att minska giltigheten och återanvändningsperioder för data
• NIST CSRC, FIPS 140-3-övergångsinsats