Tutoriale despre Certificatele Code Signing

Un certificat de semnare a codului nu se instalează în același mod ca un certificat SSL. Nu există niciun fișier de plasat pe un server. Cheia privată trebuie creată în interiorul unui echipament hardware certificat și trebuie să rămână acolo pe toată durata de viață a certificatului, ceea ce schimbă ordinea fiecărui pas care urmează: ce alegeți la finalizarea comenzii, ce trebuie să trimiteți Autorității de Certificare, ce primiți la finalul validării și ce introduceți atunci când, în cele din urmă, semnați ceva.

Aceste tutoriale acoperă fiecare dintre aceste etape pentru certificatele vândute de SSL Dragon. Folosiți această pagină pentru a determina în ce etapă vă aflați și pentru a verifica regulile care se aplică indiferent de Autoritatea de Certificare sau de dispozitivul utilizat.

Navigare rapidă

• Ce metodă de livrare a certificatului de semnare a codului să alegeți?
• Generarea CSR și atestarea pe YubiKey 5 FIPS
• Luna Network HSM 7: ghid pentru CSR și atestare
• Cum să validați certificatele de semnare a codului Sectigo și Comodo
• Cum să validați certificatele de semnare a codului DigiCert și GoGetSSL
• Cum să configurați un certificat de semnare a codului EV pe un token expediat prin poștă
• Instalarea certificatului de semnare a codului pe YubiKey 5 FIPS
• Cum să semnați un fișier EXE folosind un certificat de semnare a codului

Ce reglementează astăzi fiecare comandă de certificat de semnare a codului

Trei schimbări la nivel de industrie stau la baza celor opt ghiduri de mai jos. Citirea lor mai întâi explică de ce procesul se prezintă în felul acesta și vă scutește de a urma instrucțiuni mai vechi care încă circulă pe scară largă.

Cheia privată trebuie generată și păstrată într-un echipament hardware certificat

Începând cu 1 iunie 2023, Cerințele de Bază pentru Semnarea Codului ale CA/Browser Forum au impus ca cheia privată să fie protejată de un modul criptografic certificat la un nivel de cel puțin FIPS 140-2 Level 2 sau Common Criteria EAL 4+. Autoritățile de Certificare nu mai pot permite generarea unei chei într-un browser sau pe un laptop și descărcarea ulterioară a unui fișier PFX.

Totul derivă din această unică regulă. De aici vine faptul că formularul de comandă vă cere să alegeți o metodă de livrare, faptul că există un fișier de atestare (acesta fiind modul în care demonstrați CA-ului că o cheie pe care nu a văzut-o niciodată creându-se a fost, într-adevăr, creată în interiorul unui echipament hardware conform), și faptul că instalarea certificatului înseamnă introducerea acestuia într-un slot al unui dispozitiv, nu importarea lui pe un server.

Certificatele sunt valabile acum câteva luni, nu ani

Rezoluția CA/Browser Forum CSC-31, adoptată pe 17 noiembrie 2025 ca versiunea 3.10.0 a Cerințelor de Bază pentru Semnarea Codului, a redus valabilitatea maximă a unui certificat de semnare a codului de încredere publică de la 39 de luni la 460 de zile pentru certificatele emise la sau după 1 martie 2026. Se aplică deopotrivă certificatelor standard și celor cu Validare Extinsă.

Ambele CA-uri au acționat din timp și amândouă s-au stabilit la 459 de zile, aproximativ cincisprezece luni: Sectigo de la 23 februarie 2026 și DigiCert de la 24 februarie 2026. DigiCert a eliminat, în același timp, opțiunile de doi și trei ani. Orice ghid, inclusiv versiunile mai vechi ale acestor pagini, care vă oferă un certificat de semnare a codului valabil trei ani descrie un produs care nu mai există. Achizițiile multianuale înseamnă acum acoperire multianuală prin reemitere, nu un singur certificat de lungă durată. Durata de viață mai scurtă este și motivul pentru care marcarea temporală (timestamping) a fiecărei semnături nu mai este opțională, întrucât o marcă temporală este ceea ce menține valabil un software deja livrat după expirarea certificatului.

Validarea Extinsă nu mai depășește SmartScreen

Certificatele de semnare a codului EV omiteau anterior avertismentul Microsoft Defender SmartScreen pentru o aplicație complet nouă. Acest comportament a fost eliminat în august 2024, când identificatorii de obiect pentru semnarea codului EV au fost eliminați din rădăcinile din Programul Microsoft Trusted Root. Windows tratează acum toate certificatele de semnare a codului în același mod, iar un fișier semnat EV își construiește reputația exact la fel ca unul semnat OV.

EV înseamnă totuși o verificare mai strictă a organizației dumneavoastră, iar unele reguli de achiziții corporative încă îl solicită, așa că nu a devenit inutil. Simplu spus, nu mai oferă imediat încrederea Windows, și nicio procedură de semnare din aceste pagini nu va schimba acest lucru.

Etapa 1: Alegeți sau confirmați metoda de livrare

Aceasta este prima decizie și singura pe care nu o puteți relua. Determină dacă CA vă trimite un echipament hardware sau se așteaptă să furnizați propriul dispozitiv, și decide, prin urmare, care dintre ghidurile de mai jos se aplică situației dumneavoastră.

Ce metodă de livrare a certificatului de semnare a codului să alegeți?

Compară cele două opțiuni din formularul de comandă, un token pre-încărcat și expediat de CA versus un echipament hardware pe care îl dețineți deja, cu costurile actuale de expediere pentru fiecare CA, dispozitivele acceptate în prezent de Sectigo și DigiCert, ce diferă la serviciile de semnare în cloud operate de CA, și de ce alegerea este blocată la finalizarea comenzii. Citiți-l înainte de a plasa comanda: enumeră și întrebările pe care merită să le clarificați dinainte, cum ar fi dacă dispozitivul dumneavoastră se află pe lista suportată de CA-ul dumneavoastră și dacă poate produce efectiv o atestare. Dacă comanda a fost deja plasată, stabilește ce se poate și ce nu se poate schimba în acel moment.

Etapa 2: Generați cheia și CSR-ul în propriul echipament hardware

Ignorați această etapă dacă CA vă expediază un token pre-încărcat, întrucât cheia este generată pentru dumneavoastră înainte ca dispozitivul să fie trimis prin poștă. Se aplică doar dacă ați ales să folosiți un echipament hardware pe care îl dețineți deja, caz în care CA nu poate emite nimic până când nu trimiteți un CSR generat pe acel dispozitiv, plus un pachet de atestare care dovedește că cheia a fost creată acolo și nu poate fi exportată.

Un avertisment înainte de a începe pe un YubiKey: interfața grafică YubiKey Manager GUI pe care se bazează instrucțiunile mai vechi a atins finalul ciclului de viață pe 19 februarie 2026. Instrumentul din linia de comandă ykman și Yubico Authenticator nu sunt afectate și sunt cele folosite în ghidurile de mai jos.

Generarea CSR și atestarea pe YubiKey 5 FIPS

Întregul traseu ykman pe un YubiKey 5 FIPS: mai întâi trecerea tokenului în modul aprobat FIPS (altfel refuză să genereze o cheie), alegerea slotului și a algoritmului de cheie, producerea perechii de chei și a CSR-ului, exportarea certificatului de atestare și a intermediarului Yubico, și combinarea acestora într-un singur fișier PEM așa cum se așteaptă CA-ul. Se acoperă și capcana de codare din PowerShell care face ca un fișier de atestare altfel corect să fie respins.

Luna Network HSM 7: ghid pentru CSR și atestare

Aceeași operațiune pe un Thales Luna Network HSM, folosind utilitarul autonom cmu din Luna HSM Client: generarea perechii de chei RSA cu atributele de care depinde atestarea, citirea handle-urilor de obiect, construirea CSR-ului cu algoritmul de semnătură corect, și producerea confirmării cheii publice pe care CA o verifică. Merită citit chiar dacă ați mai rulat aceste comenzi înainte, întrucât versiunea publicată la nivelul industriei produce un CSR semnat SHA-1 dacă nu adăugați o opțiune.

Etapa 3: Treceți de validare

Validarea are legătură cu identitatea dumneavoastră, nu cu echipamentul hardware, așa că se desfășoară în paralel cu etapele 1 și 2, nu după acestea. CA confirmă că entitatea numită în certificat există legal, că poate fi contactată la o adresă și un număr de telefon sau o adresă de e-mail pe care le poate verifica dintr-o sursă diferită de formularul dumneavoastră de comandă, și că persoana care a aprobat cererea era autorizată să o facă. Aici se blochează aproape toate comenzile întârziate, și este singura etapă pe care nu o puteți accelera lucrând mai rapid.

Cele două CA-uri desfășoară procese diferite, așa că alegeți ghidul care corespunde certificatului dumneavoastră.

Cum să validați certificatele de semnare a codului Sectigo și Comodo

Ce verifică Sectigo și în ce ordine, pentru Validarea Organizației, pentru dezvoltatori individuali fără companie, și pentru Validarea Extinsă: verificarea în registru a denumirii dumneavoastră legale, sesiunea automatizată Video ID, verificarea adresei și a datelor de contact, Acordul cu Abonatul, apelul de confirmare care finalizează comanda, și pașii adiționali de verificare a existenței operaționale și de a doua revizuire pe care EV îi adaugă. De asemenea, explică de ce apare documentație cu marca Comodo pe o comandă Sectigo și ce trebuie făcut atunci când doar registrul guvernamental nu este suficient.

Cum să validați certificatele de semnare a codului DigiCert și GoGetSSL

Procesul DigiCert pentru CS și EV CS, inclusiv aspectul care blochează majoritatea comenzilor: două lucruri separate trebuie finalizate, organizația trebuie validată pentru semnarea codului, și un contact verificat marcat pentru acel tip de certificat trebuie să aprobe cererea, iar comanda rămâne în așteptare până ce ambele sunt îndeplinite. Acoperă verificarea organizației, a adresei și a telefonului, apelul de confirmare, traseul individual pentru dezvoltatorii fără companie înregistrată, și ce trebuie făcut atunci când o comandă se blochează.

Etapa 4: Instalați certificatul pe echipamentul dumneavoastră hardware

După trecerea validării, certificatul este emis. Ce se întâmplă în continuare depinde de metoda de livrare aleasă la etapa 1. Fie ajunge prin poștă un token cu cheia și certificatul deja instalate pe el, fie primiți un fișier de certificat pentru a-l importa în dispozitivul care a generat CSR-ul dumneavoastră.

Cum să configurați un certificat de semnare a codului EV pe un token expediat prin poștă

Traseul pentru un token expediat de CA, mod în care sunt livrate de obicei comenzile EV. Acoperă instalarea SafeNet Authentication Client, ordinea în care trebuie conectate clientul și tokenul, înlocuirea parolei inițiale a tokenului trimise prin e-mail de CA, confirmarea că certificatul este vizibil pentru Windows, și găsirea amprentei digitale (thumbprint) de care va avea nevoie instrumentul dumneavoastră de semnare. Citiți secțiunea despre blocare înainte de a introduce parola: tokenul se blochează după un număr redus de încercări greșite, iar parola de administrator care l-ar debloca rămâne la CA.

Instalarea certificatului de semnare a codului pe YubiKey 5 FIPS

Importarea certificatului emis în slotul YubiKey a cărui pereche de chei a produs CSR-ul dumneavoastră, fie prin ykman, fie prin Yubico Authenticator, plus cum se verifică rezultatul și ce trebuie făcut atunci când CA trimite un fișier PKCS#7 pe care instrumentul nu îl poate citi. De asemenea, clarifică două aspecte pe care ghidurile mai vechi le prezintă greșit: care acreditare este de fapt solicitată la import și unde trebuie să se afle cu adevărat intermediarul Sectigo pentru ca semnăturile dumneavoastră să formeze corect lanțul de încredere.

Etapa 5: Semnați codul și verificați-l

Ultima etapă este cea pe care o veți repeta la fiecare lansare, așa că merită să obțineți comanda corectă o dată și să o transformați într-un script.

Cum să semnați un fișier EXE folosind un certificat de semnare a codului

Găsirea SignTool în Windows SDK fără a ghici un număr de versiune, comanda de semnare cu un digest SHA-256 și o marcă temporală RFC 3161, selectarea certificatului corect pe o mașină care deține mai multe, verificarea canonică și de ce aceasta eșuează fără comutatorul corect, și cum să semnați dintr-o cheie în cloud sau dintr-un pipeline CI/CD. Se acoperă și opțiunea fără token pe care Microsoft o recomandă acum pentru distribuția în afara Store-ului, precum și ce face și ce nu face semnarea în privința SmartScreen.