Cum să generați un CSR pentru un certificat de semnare a codului

Un certificat de semnare a codului dovedește cine a publicat o aplicație software și arată că codul nu a fost modificat de la semnare. Pentru a comanda unul, creați un CSR (Certificate Signing Request), blocul de text codat pe care Autoritatea de Certificare (CA) îl folosește pentru a vă identifica și a emite certificatul. CSR-urile pentru semnarea codului respectă reguli diferite față de CSR-urile create pentru un site web, iar aceste reguli s-au schimbat în 2023. Acest ghid explică procesul actual și metodele care încă se aplică.

Cheia privată trebuie să existe pe hardware

Începând cu 1 iunie 2023, Cerințele de Bază pentru Semnarea Codului ale CA/Browser Forum au impus ca cheia privată pentru fiecare certificat de semnare a codului de încredere publică să fie generată și stocată pe un dispozitiv hardware care respectă standardul FIPS 140-2 Level 2, Common Criteria EAL4+, sau un standard echivalent. Acest lucru se aplică atât certificatelor standard (Validare Organizație și Validare Individuală), cât și certificatelor Extended Validation (EV). Semnarea codului EV necesita deja hardware înainte de această dată; modificarea din 2023 a extins aceeași regulă și la certificatele standard.

Consecința practică este importantă: o cheie privată și un CSR generate exclusiv în software, într-un browser, sau într-un fișier obișnuit pe un laptop sau server, nu mai sunt acceptate pentru un certificat de semnare a codului de încredere publică. CA-urile au oprit suportul pentru generarea cheilor în browser și livrarea unui fișier .pfx descărcabil pentru aceste produse. Cheia trebuie să fie generată pe un dispozitiv conform și să rămână pe acesta. Rămân două căi valide:

• Un token hardware preconfigurat de către CA. CA generează perechea de chei și CSR-ul direct pe un token USB certificat, instalează certificatul emis pe acesta și vă trimite tokenul prin poștă. Semnați cu tokenul conectat. Cu această metodă, nu generați CSR-ul dumneavoastră înșivă.
• Propriul dvs. HSM sau HSM cloud, cu atestare a cheii. Dacă aveți deja un Modul de Securitate Hardware conform (sau un HSM cloud precum AWS CloudHSM, Azure Dedicated HSM sau Google Cloud HSM), generați cheia și CSR-ul pe acel dispozitiv și furnizați un fișier de atestare care dovedește CA-ului că cheia a fost creată pe hardware conform și nu poate fi exportată de pe acesta.

Ruta pe care o alegeți este stabilită la momentul comenzii. Pentru o comparație directă, consultați metodele de livrare a certificatelor de semnare a codului.

Opțiunea 1: token plus livrare prin poștă (CA creează CSR-ul)

Aceasta este ruta pe care o aleg majoritatea persoanelor și echipelor mici, pentru că nu necesită hardware propriu. Când selectați token plus livrare prin poștă la finalizarea comenzii, CA se ocupă de generarea cheii și crearea CSR-ului pe un token certificat de partea sa, apoi vă trimite prin poștă tokenul cu certificatul deja încărcat. Nu există un CSR pe care să îl lipiți într-un formular de comandă.

Ce faceți în schimb:

• Completați pașii de validare cerute de CA (verificarea organizației sau a identității).
• Așteptați ca tokenul fizic să ajungă.
• Instalați driverele tokenului (de obicei SafeNet Authentication Client) și semnați aplicația software cu tokenul conectat.

Opțiunea 2: generați CSR-ul pe propriul dvs. HSM sau token

Dacă aveți deja hardware conform, generați perechea de chei și CSR-ul pe acel dispozitiv și furnizați o atestare corespunzătoare. Pașii exacți depind de hardware, așa că urmați ghidul pentru dispozitivul dumneavoastră sau documentația proprie a furnizorului:

• YubiKey 5 FIPS: generarea CSR-ului și atestarea
• Luna Network Attached HSM v7.x: ghid de CSR și atestare

Pentru HSM-uri cloud (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM), generați cheia în interiorul HSM-ului, exportați CSR-ul și fișierul de atestare produs de platformă, și trimiteți-le pe amândouă CA-ului dumneavoastră în timpul comenzii.

Câteva detalii se aplică tuturor CSR-urilor bazate pe hardware:

• Utilizați o cheie RSA de cel puțin 3072 de biți, sau o cheie ECDSA echivalentă, conform specificațiilor Cerințelor de Bază.
• Marcați cheia ca neexportabilă, astfel încât să nu poată părăsi dispozitivul.
• Generați atestarea în același timp cu cheia. Un CSR fără atestare validă va fi respins.

Unde se încadrează acum metodele OpenSSL, Java Keytool, MMC, CertReq și Keychain

Este posibil să fi văzut instrucțiuni mai vechi care creează un CSR de semnare a codului cu OpenSSL, utilitarul Java keytool, Microsoft Management Console (MMC), comanda Windows certreq, sau Keychain Access pe macOS. Folosite de sine stătător, aceste instrumente generează cheia în software, așa că un CSR produs astfel nu este valid astăzi pentru un certificat de semnare a codului de încredere publică.

Ele mai au totuși un rol atunci când sunt direcționate către hardware conform, în loc de un depozit de chei software. De exemplu, OpenSSL poate crea un CSR pentru un HSM printr-un modul PKCS#11, iar CertReq sau MMC pot construi o cerere care utilizează un furnizor hardware de stocare a cheilor. Utilizați aceste referințe doar în acest context și asociați întotdeauna cererea cu atestarea de la dispozitiv:

• Generați un CSR de semnare a codului cu OpenSSL
• Generați un CSR de semnare a codului cu Java Keystore
• Generați un CSR de semnare a codului cu CertReq
• Generați un CSR de semnare a codului cu Microsoft Management Console
• Generați un CSR de semnare a codului cu macOS Keychain Access

Verificați conținutul CSR-ului dumneavoastră

Înainte de a trimite un CSR, confirmați că detaliile subiectului sunt corecte. Dacă aveți OpenSSL disponibil, decodați local cererea și citiți-o în text simplu:

openssl req -noout -text -in codesigning.csr

Verificați organizația sau numele comun și dimensiunea cheii în rezultat. Un verificator standard de CSR pentru site-uri web nu este instrumentul potrivit aici, pentru că un CSR de semnare a codului este legat de hardware și este validat prin atestare, nu printr-o scanare HTTPS publică.

Întrebări frecvente