Cum se generează un CSR pentru un certificat Code Signing prin MMC

Componenta Certificates din Microsoft Management Console (MMC) poate construi o cerere de certificat PKCS #10 pe un calculator Windows fără niciun software suplimentar. Acest ghid parcurge acel asistent ecran cu ecran pentru un certificat de semnare a codului și începe cu partea pe care majoritatea instrucțiunilor mai vechi o omit: regulile pentru cheile private de semnare a codului s-au schimbat la 1 iunie 2023, iar acestea decid dacă o cerere MMC este utilizabilă sau nu.

Citiți această cerință înainte de a deschide asistentul. Restul ghidului presupune că știți deja ce traseu urmează comanda dumneavoastră.

Cheile de semnare a codului trebuie generate pe hardware

Conform Cerințelor de bază pentru semnarea codului ale CA/Browser Forum, în vigoare din 1 iunie 2023, cheia privată pentru fiecare certificat de semnare a codului de încredere publică trebuie generată, stocată și utilizată într-un modul criptografic hardware certificat cel puțin la nivelul FIPS 140-2 Level 2, Common Criteria EAL 4+, sau un standard echivalent. Aceasta acoperă atât certificatele standard (Organization Validation și Individual Validation), cât și cele Extended Validation. Certificatele EV de semnare a codului funcționau deja astfel; schimbarea din 2023 a extins aceeași regulă și la produsele standard.

Cerințele stabilesc și parametrii cheii în sine. Cheile RSA trebuie să aibă cel puțin 3072 de biți, cheile ECDSA trebuie să folosească curbele NIST P-256, P-384 sau P-521, iar SHA-1 nu este permis pentru certificatele de semnare a codului.

La fel de important, Autoritatea de Certificare trebuie să dovedească faptul că cheia se află într-adevăr pe hardware, folosind una dintre metodele enumerate în cerințe. În practică, acestea sunt cele pe care le veți întâlni:

• CA vă trimite un token hardware care deține deja o pereche de chei generată de CA pe acel dispozitiv.
• Contrasemnați cererea cu un certificat al producătorului, ceea ce înseamnă de fapt atestarea cheii: dovada că cheia a fost creată într-un mod neexportabil în interiorul unui dispozitiv conform.
• Folosiți o combinație de bibliotecă criptografică și modul hardware prescrisă de CA.
• Furnizați un audit IT, un raport de la un serviciu de protecție a cheilor în cloud, sau un acord pe care îl semnați printr-un serviciu de semnare conform.

Niciuna dintre aceste condiții nu este îndeplinită de o cerere pe care MMC o construiește folosind Microsoft Software Key Storage Provider. Acest furnizor creează cheia în stocarea software a Windows, astfel încât cererea rezultată va fi respinsă pentru un certificat de semnare a codului de încredere publică, indiferent cum este completat restul asistentului. Autoritățile de Certificare au încetat de asemenea, în același timp, să mai ofere generarea cheii în browser și livrarea .pfx descărcabilă pentru aceste produse.

Dacă obiectivul dumneavoastră este un certificat de încredere publică, traseul se decide în momentul comenzii. Fie CA generează cheia pe un token și v-o trimite prin poștă, caz în care nu există niciun CSR pe care trebuie să îl creați, fie generați cheia pe un dispozitiv hardware pe care îl dețineți deja și trimiteți o atestare împreună cu cererea. Ghidul metodele de livrare a certificatelor de semnare a codului compară cele două variante, iar pașii specifici dispozitivelor se găsesc aici:

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

Unde este încă potrivit MMC

Asistentul nu este depășit. Furnizorul pe care îl alegeți în cadrul lui este cel care decide unde ia naștere cheia, iar există trei situații în care rămâne instrumentul potrivit.

O cerere susținută de un furnizor hardware. Lista Cryptographic Service Provider din asistent arată toți furnizorii instalați pe calculator, nu doar cei software ai Microsoft. Odată ce driverul unui token sau minidriverul unui smart card este instalat, furnizorul său apare și el acolo. Diferența constă în locul unde ia naștere perechea de chei: un furnizor software o generează pe calculatorul dumneavoastră, în timp ce un furnizor bazat pe hardware, precum un smart card sau un furnizor de token, instruiește dispozitivul să genereze perechea, iar dispozitivul reține apoi cheia privată și controlează accesul la aceasta. Selectați un furnizor hardware, iar MMC produce o cerere pentru o cheie care nu a existat niciodată în software.

Două avertismente înainte să vă bazați pe aceasta. MMC produce o cerere PKCS #10 și nimic altceva, deci nu generează fișierul de atestare a cheii pe care majoritatea Autorităților de Certificare îl doresc alături de aceasta. Acesta provine din instrumentele proprii ale dispozitivului. Iar CA decide ce metodă de verificare va accepta, multe prescriindu-și propriul utilitar pentru această sarcină. Întrebați-vă CA ce traseu susține înainte să generați ceva, deoarece o cheie creată cu instrumentul greșit nu poate fi mutată ulterior.

O CA internă sau la nivel de întreprindere. Cerințele de bază guvernează certificatele de încredere publică. Un certificat emis de propriul dvs. CA Active Directory Certificate Services pentru semnare internă se află în afara acestui domeniu, astfel încât propria dumneavoastră politică decide cum este stocată cheia, iar un furnizor software este o alegere legitimă. Rețineți ce obțineți: codul semnat astfel este de încredere doar pe calculatoarele care au deja încredere în rădăcina dumneavoastră internă, iar oriunde altundeva Windows va trata în continuare editorul ca fiind necunoscut.

Semnare de test și pregătire. O cerere software este potrivită pentru un certificat de test și pentru stabilirea valorilor exacte ale subiectului pe care le veți reutiliza atunci când veți genera cererea reală pe hardware.

Pasul 1: Deschideți componenta Certificates

Apăsați tasta Windows + R, tastați mmc și apăsați Enter. Puteți de asemenea să tastați mmc în caseta de căutare din bara de sarcini și să îl deschideți de acolo. Acceptați solicitarea Controlului de cont utilizator. Se deschide o fereastră Console1 goală.

Faceți clic pe File, apoi pe Add/Remove Snap-in. În lista Available snap-ins selectați Certificates și faceți clic pe Add.

Windows vă întreabă acum ce magazin de certificate ar trebui să gestioneze componenta: My user account, Service account sau Computer account. Această alegere contează mai mult pentru un certificat de semnare a codului decât pentru un certificat de server web, deoarece decide unde locuiește cheia și în ce magazin caută instrumentul dumneavoastră de semnare:

• My user account plasează cheia în magazinul personal al utilizatorului conectat. Aceasta este alegerea obișnuită atunci când un dezvoltator semnează interactiv, deoarece signtool al Microsoft deschide implicit magazinul My al utilizatorului curent.
• Computer account plasează cheia în magazinul calculatorului, ceea ce se potrivește unui server de build unde semnarea rulează sub un cont de serviciu. Instrumentele de semnare trebuie instruite să caute acolo: signtool folosește comutatorul /sm pentru magazinul calculatorului.

Dacă alegeți My user account, faceți clic pe Finish. Dacă alegeți Computer account, faceți clic pe Next, lăsați selectat Local computer (the computer this console is running on) și faceți clic pe Finish. Indiferent de opțiune, faceți clic pe OK pentru a închide fereastra Add or Remove Snap-ins.

Există două scurtături care sar peste pasul de adăugare a componentei atunci când nu aveți nevoie de o consolă salvată: certmgr.msc deschide direct magazinele de certificate ale utilizatorului curent, iar certlm.msc deschide magazinele calculatorului local. Dacă ați construit consola manual și intenționați să reveniți la ea, folosiți File, apoi Save pentru a o păstra.

Pasul 2: Începeți o cerere personalizată

În arborele consolei, extindeți Certificates și faceți clic dreapta pe folderul Personal (sau pe folderul Certificates de sub el, dacă magazinul conține deja certificate). Alegeți All Tasks, apoi Advanced Operations, apoi Create Custom Request. Aceleași comenzi se află și în meniul Action, dacă preferați această variantă.

Asistentul Certificate Enrollment se deschide la Before You Begin. Faceți clic pe Next.

La Select Certificate Enrollment Policy, uitați-vă sub titlul Custom Request și selectați Proceed without enrollment policy, apoi faceți clic pe Next. Aceasta îi spune Windows-ului să construiască o cerere de sine stătătoare pentru o CA externă, în loc să se înscrie folosind un șablon Active Directory.

Pagina Custom request are trei setări:

• Template. Alegeți (No template) CNG key. Aceasta folosește un Key Storage Provider, care este modul în care se înregistrează furnizorii hardware moderni. (No template) Legacy key folosește furnizorii CryptoAPI mai vechi și este necesar doar atunci când un dispozitiv sau o aplicație specifică îl solicită.
• Suppress default extensions. Lăsați-o nebifată, cu excepția cazului în care intenționați să trimiteți doar extensiile stabilite manual.
• Request format. Selectați PKCS #10. Fiecare CA îl acceptă. CMC este destinat cererilor adresate sistemelor care îl solicită în mod specific.

Faceți clic pe Next. Pe pagina Certificate Information veți vedea un singur rând etichetat Custom request cu starea Available. Faceți clic pe săgeata Details din dreapta rândului respectiv pentru a-l extinde, apoi faceți clic pe butonul Properties care apare. Se deschide caseta de dialog Certificate Properties cu patru file: General, Subject, Extensions și Private Key.

Pasul 3: Introduceți detaliile subiectului

Pe fila General, tastați un Friendly name și, dacă doriți, o Description. Ambele sunt etichete locale care vă ajută să găsiți ulterior certificatul în magazin. Niciuna nu face parte din cerere și niciuna nu este validată.

Treceți la fila Subject. Aici este asamblată identitatea care va apărea drept editor al software-ului. Sub Subject name, alegeți o intrare din meniul derulant Type, tastați textul corespunzător în caseta Value și faceți clic pe Add >. Fiecare intrare se mută în lista din dreapta, unde Windows o afișează în formă scurtă (CN=, O=, OU=, L=, S=, C=). Repetați pentru fiecare dintre următoarele:

• Common name (CN): numele înregistrat al organizației dumneavoastră, sau numele legal complet al persoanei pentru un certificat individual. Aceasta este identitatea pe care o văd utilizatorii atunci când Windows numește editorul.
• Organization (O): numele organizației înregistrate căreia îi aparține certificatul. Dacă numele conține un simbol precum ampersand-ul, scrieți-l în cuvinte sau eliminați-l, deoarece aceste caractere nu sunt acceptate în câmp. „AB & C Corporation” devine „AB and C Corporation” sau „ABC Corporation”.
• Organizational unit (OU): departamentul care gestionează înscrierea, de exemplu IT. Opțional.
• Locality (L): orașul unde este înregistrată organizația.
• State (S): statul sau provincia, scrisă în întregime. Folosiți Florida, nu FL.
• Country (C): codul de țară ISO din două litere al locului unde este înregistrată organizația, de exemplu US.

Introduceți detalii care se potrivesc exact cu evidențele dumneavoastră legale, deoarece CA le validează în raport cu surse publice și oficiale înainte de a emite orice. O nepotrivire este cel mai frecvent motiv pentru care o comandă de semnare a codului rămâne blocată.

Lăsați caseta Alternative name goală. Numele alternative ale subiectului identifică serverele după numele gazdei, iar un certificat de semnare a codului identifică un editor, nu un calculator, astfel încât nu conține intrări DNS.

Pasul 4: Alegeți furnizorul, dimensiunea cheii și hash-ul

Deschideți fila Private Key. Aceasta conține mai multe grupuri restrângibile: Cryptographic Service Provider, Key options, Select Hash Algorithm, Select Signature Format și Key permissions. Faceți clic pe un titlu pentru a-l extinde.

Extindeți mai întâi Cryptographic Service Provider, deoarece aceasta este setarea pe care o activează Cerințele de bază. Lista arată toți furnizorii instalați pe calculator, fiecare cu o casetă de bifare. Asigurați-vă că singurul bifat este furnizorul pe care îl doriți cu adevărat:

• Pentru un certificat de semnare a codului de încredere publică, selectați furnizorul care aparține token-ului sau HSM-ului dumneavoastră. Acesta apare în această listă doar după ce driverul sau minidriverul dispozitivului este instalat, așa că introduceți mai întâi dispozitivul și instalați-i software-ul.
• RSA, Microsoft Software Key Storage Provider este opțiunea software. Folosiți-o doar pentru o CA internă sau un certificat de test.
• Lista conține și intrări ECDSA precum ECDSA_P256, Microsoft Software Key Storage Provider. Confirmați că CA dumneavoastră susține ECDSA pentru semnarea codului înainte de a alege una, deoarece nu toate produsele o fac.

Extindeți Key options. Setați Key size la 3072 sau 4096. RSA 3072 este pragul minim pentru semnarea codului, iar o cerere construită cu 2048 va fi refuzată. Dacă meniul derulant nu oferă 3072 pentru furnizorul ales, folosiți 4096.

În același grup, lăsați nebifat Make private key exportable. Aceasta este cea mai importantă corecție unică a instrucțiunilor MMC mai vechi. O cheie exportabilă poate fi copiată de pe calculator sub forma unui fișier .pfx, ceea ce este exact ceea ce cerința hardware urmărește să prevină, iar traseul de atestare certifică în mod explicit că cheia a fost creată într-un mod neexportabil. Singurul caz în care se bifează este o configurație de semnare internă în care trebuie să mutați certificatul și cheia pe un alt calculator, și chiar și atunci acest lucru slăbește cheia. Lăsați de asemenea nebifat Allow private key to be archived. Strong private key protection este opțional și face ca Windows să solicite confirmare de fiecare dată când cheia este utilizată, ceea ce este rezonabil pentru o cheie de semnare pe o stație de lucru partajată.

Extindeți Select Hash Algorithm și setați Hash Algorithm la sha256. SHA-1 nu este permis pentru certificatele de semnare a codului.

Fila Extensions merită analizată dacă vă înscrieți la o CA internă. Extindeți Key usage și adăugați Digital signature, apoi extindeți Extended Key Usage (application policies) și adăugați Code Signing. O CA publică construiește certificatul pornind de la produsul comandat, nu de la extensiile din cererea dumneavoastră, deci pentru o comandă publică această filă nu schimbă nimic. O CA internă poate să o respecte.

Faceți clic pe OK pentru a închide Certificate Properties, apoi pe Next.

Pasul 5: Salvați cererea

Asistentul întreabă Where do you want to save the offline request? Faceți clic pe Browse, alegeți un folder pe care îl controlați, dați fișierului un nume precum codesigning.req și confirmați. Navigați întotdeauna către un folder în loc să tastați un simplu nume de fișier: fără o cale, cererea ajunge în orice folder din care rulează consola, ceea ce rareori este locul dorit și este greu de găsit ulterior.

Sub File format, lăsați selectat Base 64. Aceasta este forma text pe care CA o inserează într-o casetă de înscriere. Binary scrie DER brut, pe care majoritatea formularelor de comandă îl resping. Faceți clic pe Finish.

Deschideți fișierul într-un editor de text simplu, precum Notepad, și copiați întregul bloc, inclusiv primul și ultimul rând:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEbDCCA1QCAQAwZDELMAkGA1UEBhMCVVMx...
...base64 encoded request...
-----END NEW CERTIFICATE REQUEST-----

Instrumentele de înscriere Windows scriu de obicei formularea mai lungă de mai sus, cu cuvântul NEW în liniile de marcaj, în timp ce OpenSSL scrie BEGIN CERTIFICATE REQUEST și END CERTIFICATE REQUEST. Dacă fișierul dumneavoastră folosește forma mai scurtă, nimic nu este greșit: conținutul este aceeași cerere PKCS #10, iar Autoritățile de Certificare acceptă ambele variante. Copiați exact ce vedeți și nu rescrieți liniile de marcaj.

Un lucru pe care asistentul nu îl produce este un fișier cu cheia privată pe care să îl puteți salva sau copia, iar ghidurile mai vechi care vă spun să păstrați în siguranță fișierele cu cheia publică și cea privată descriu un alt instrument. MMC păstrează noua cheie privată în magazinul de chei Windows, sub contul selectat la pasul 1, doar pe acel calculator. Cererea în așteptare apare de obicei în componentă sub Certificate Enrollment Requests. Rezultă trei consecințe:

• Nu ștergeți cererea în așteptare cât timp așteptați emiterea. Ștergerea ei elimină cheia, iar certificatul emis va deveni astfel inutilizabil.
• Finalizați comanda pe același calculator, în același context de cont. O cerere generată în magazinul utilizatorului nu poate fi finalizată în magazinul calculatorului, sau invers.
• Nu reconstruiți și nu reimaginați calculatorul între generarea cererii și instalarea certificatului.

Pasul 6: Verificați cererea înainte de a o trimite

O cerere nu poate fi editată după ce a fost creată, așa că verificați-o acum, nu descoperiți o greșeală de tastare după ce validarea a început. Windows o poate citi înapoi fără niciun software suplimentar. Deschideți un Command Prompt în folderul care conține fișierul și executați:

certutil -dump codesigning.req

Dacă OpenSSL este instalat, aceasta citește același fișier și verifică și semnătura cererii:

openssl req -noout -text -verify -in codesigning.req

Confirmați patru lucruri în rezultat: subiectul enumeră țara, statul, localitatea, organizația și numele comun exact așa cum intenționați; cheia publică are 3072 de biți sau mai mult, sau o curbă ECDSA aprobată; algoritmul de semnătură este SHA-256; și, cu comanda OpenSSL, apare linia verify OK, care confirmă că cererea a fost semnată de cheia sa privată corespunzătoare. Puteți de asemenea să lipiți blocul în decodorul CSR pentru a-l citi într-un browser.

Dacă ceva nu este corect, generați o cerere nouă începând de la pasul 2. Pentru a vedea ce furnizori sunt disponibili pe calculator, inclusiv orice furnizori hardware pe care i-ați instalat, executați:

certutil -csplist

Pasul 7: Instalați certificatul emis pe același calculator

Trimiteți blocul Base 64 în timpul comenzii certificatului, finalizați validarea solicitată de CA și descărcați certificatul emis atunci când sosește. Deoarece cheia privată a rămas în magazinul de chei Windows, certificatul trebuie să revină în același magazin pentru a fi utilizabil.

În aceeași componentă, faceți clic dreapta pe Personal, alegeți All Tasks, apoi Import, și îndreptați asistentul către fișier. Windows potrivește certificatul cu cheia păstrată din cerere, iar intrarea în așteptare de sub Certificate Enrollment Requests dispare. Deschideți certificatul ulterior și verificați că fila General arată că aveți o cheie privată care corespunde acestui certificat. Dacă acea linie lipsește, asocierea nu s-a produs și o puteți relega folosind numărul de serie al certificatului:

certutil -repairstore My <serial-number>

Adăugați comutatorul -user dacă certificatul aparține utilizatorului curent, nu calculatorului:

certutil -user -repairstore My <serial-number>

De aici, instrumentul dumneavoastră de semnare preia certificatul din magazin. Rețineți magazinul ales la pasul 1: signtool citește magazinul My al utilizatorului curent, cu excepția cazului în care transmiteți /sm pentru magazinul calculatorului.

Alte moduri de a crea aceeași cerere sunt prezentate în ghidurile CertReq, OpenSSL, Java Keystore și macOS Keychain Access. Puteți consulta de asemenea și tutorialele mai ample despre semnarea codului sau alte modalități de a genera un CSR.

Întrebări frecvente