Keychain Access este încă prezent pe fiecare Mac, iar Certificate Assistant al său continuă să genereze cereri de semnare a certificatelor. Dacă acea cerere este utilă pentru semnarea codului depinde în întregime de certificatul pe care îl comandați. Pentru un certificat Apple Developer ID, cel care vă permite să distribuiți software pentru Mac în afara Mac App Store, Keychain Access este instrumentul corect, iar pașii de mai jos sunt actuali. Pentru un certificat comercial de semnare a codului emis de o Autoritate de Certificare publică, tipul folosit pentru semnarea executabilelor Windows, a programelor de instalare, a driverelor și a aplicațiilor Java, o cerere generată în Keychain Access nu mai este acceptată din 1 iunie 2023, deoarece cheia privată trebuie acum creată pe hardware.
Stabiliți mai întâi de care dintre cele două aveți nevoie, apoi urmați secțiunea corespunzătoare.
Ce certificat de semnare a codului obțineți de fapt?
Ambele produse sunt numite certificate de semnare a codului și ambele dovedesc cine a publicat o anumită aplicație software, dar provin de la emitenți diferiți și respectă reguli diferite. Cititorii ajung pe această pagină deoarece Apple și Autoritățile de Certificare publice folosesc aceiași termeni pentru două lucruri diferite.
- Certificatul Apple Developer ID. Emis de Apple, sub propria sa Autoritate de Certificare Developer ID, pentru membrii Apple Developer Program. Semnează aplicații Mac, pluginuri și pachete de instalare pe care le distribuiți dvs. înșivă, astfel încât macOS Gatekeeper vă recunoaște ca dezvoltator identificat. Perechea de chei este generată pe Mac-ul dvs. și rămâne în breloc de chei (keychain) de conectare, iar cererea o creați în Keychain Access.
- Certificatul de semnare a codului de încredere publică. Cumpărat de la o Autoritate de Certificare publică precum Sectigo, DigiCert sau GlobalSign. Semnează executabile Windows, programe de instalare MSI, drivere, scripturi PowerShell și aplicații Java. Este reglementat de Cerințele de Bază pentru Semnarea Codului ale CA/Browser Forum, care impun ca cheia privată să fie generată și să rămână pe hardware certificat, astfel încât Keychain Access nu are nimic de făcut.
Regula scurtă de decizie: dacă software-ul pe care îl semnați rulează pe macOS și îl distribuiți în afara Mac App Store, aveți nevoie de un certificat Developer ID. Dacă semnați orice pentru Windows, sau o aplicație Java, aveți nevoie de un certificat comercial de semnare a codului, chiar dacă îl construiți pe un Mac. Niciunul dintre acestea nu este un certificat SSL/TLS. Dacă de fapt doriți HTTPS pe un server Mac, urmați ghidul cum să generați un CSR pe servere macOS.
Ruta comercială: de ce metoda Keychain nu mai este valabilă
Din 1 iunie 2023, Cerințele de Bază pentru Semnarea Codului ale CA/Browser Forum impun ca cheia privată pentru fiecare certificat de semnare a codului de încredere publică, atât standard (OV), cât și Extended Validation (EV), să fie generată și stocată într-un modul criptografic hardware care îndeplinește standardul FIPS 140-2 Level 2, Common Criteria EAL4+ sau un standard echivalent, și să fie ne-exportabilă. Semnarea codului EV a necesitat întotdeauna hardware; modificarea din 2023 a extins aceeași regulă la certificatele standard.
O cheie creată de Certificate Assistant nu trece acest test prin însăși construcția sa, din trei motive separate:
- Cheia este material de cheie software exportabil. Este scrisă în brelocul de chei de conectare, iar dvs. o puteți selecta și exporta ca fișier .p12. Această portabilitate este convenabilă pentru dezvoltarea Apple și este exact proprietatea pe care cerința hardware urmărește să o elimine.
- Dimensiunea cheii nu se potrivește. Cerințele de Bază stabilesc un minim de RSA 3072 biți pentru semnarea codului, iar meniul Key Size din Certificate Assistant nu are opțiunea 3072.
- Cererea conține aproape nicio informație de identitate. Certificate Assistant solicită doar un Nume Comun (Common Name) și adrese de email. Nu există unde să introduceți detalii precum organizația, localitatea, statul sau țara, pe care o Autoritate de Certificare le validează pentru un certificat de semnare a codului validat la nivel de organizație.
Rămân două moduri valide de a obține un certificat de semnare a codului de încredere publică, iar cel pe care îl folosiți se decide la comandă:
- Token plus livrare. Autoritatea de Certificare generează perechea de chei și cererea pe un token USB certificat, pe partea sa, încarcă certificatul emis pe el și vă trimite tokenul prin poștă. Nu există niciun CSR pe care să îl creați sau să îl lipiți undeva. Consultați ce metodă de livrare a certificatului de semnare a codului să alegeți.
- Propriul token hardware, HSM sau HSM în cloud, cu atestare. Generați cheia în interiorul dispozitivului, produceți cererea acolo și trimiteți un fișier de atestare care dovedește că cheia a fost creată pe hardware conform și nu poate fi exportată. Urmați ghidul generarea CSR și atestarea YubiKey 5 FIPS sau ghidul CSR și atestarea Luna Network Attached HSM v7.x, sau documentația proprie a furnizorului dvs. de HSM.
Încă o schimbare care a intrat deja în vigoare: votul CSC-31 a redus valabilitatea maximă a certificatelor de semnare a codului de încredere publică de la 39 de luni la 460 de zile pentru certificatele emise începând cu 1 martie 2026, astfel încât reînnoirile revin acum aproximativ la fiecare 15 luni. Pentru o imagine de ansamblu mai largă, consultați cum să generați un CSR pentru un certificat de semnare a codului și versiunea OpenSSL a aceluiași ghid.
Generați CSR-ul în Keychain Access pentru un certificat Apple Developer ID
Dacă ați salvat deja un fișier .certSigningRequest, treceți direct la trimiterea acestuia în contul dvs. de dezvoltator.
Două lucruri de verificat înainte de a începe. Aveți nevoie de o calitate de membru Apple Developer Program, iar Apple impune rolul de Account Holder pentru a crea un certificat Developer ID. De asemenea, vi se permit până la cinci certificate Developer ID Application și cinci certificate Developer ID Installer per echipă. Portalul vă cere să încărcați o cerere de fiecare dată când creați un certificat, așa că parcurgeți acest proces o dată pentru fiecare certificat.
Pasul 1: Deschideți Keychain Access și inițiați cererea
Keychain Access nu se mai află unde spun majoritatea tutorialelor. Până la macOS Sonoma se afla în Applications > Utilities. Începând cu macOS Sequoia, Apple l-a mutat în /System/Library/CoreServices/Applications/, un folder de sistem pe care Finder nu îl afișează atunci când parcurgeți Applications, astfel încât căutarea în Utilities nu mai returnează nimic. Cele mai rapide moduri de a-l deschide sunt Spotlight (apăsați Command-Space și tastați Keychain Access), sau o singură comandă în Terminal:
open "/System/Library/CoreServices/Applications/Keychain Access.app"Cu aplicația deschisă, alegeți Keychain Access > Certificate Assistant > Request a Certificate From a Certificate Authority din bara de meniu.
Înainte de a face acest lucru, faceți clic pe o zonă goală a listei de elemente, astfel încât nimic să nu fie selectat. Dacă o cheie sau un certificat este evidențiat, elementul de meniu se schimbă în Request a Certificate From a Certificate Authority With, urmat de numele acelui element, iar cererea se construiește în jurul cheii existente, în loc să creeze o pereche nouă. Acest lucru este util atunci când doriți în mod deliberat să reutilizați o cheie și confuz atunci când nu doriți.
Pasul 2: Completați fereastra Certificate Information
Certificate Assistant se deschide pe un panou intitulat Certificate Information. Solicită foarte puține informații:
- User Email Address: adresa de email din contul dvs. Apple Developer.
- Common Name: o etichetă pentru perechea de chei, de exemplu Developer ID Application Key. Acesta nu este numele care va apărea în certificat. Apple construiește subiectul certificatului emis pe baza echipei dvs., sub forma Developer ID Application: Numele Echipei Dvs. (TEAMID), așa că tratați acest câmp ca pe o referință proprie.
- CA Email Address: lăsați gol. Este folosit doar de cealaltă opțiune de livrare.
- Request is: selectați Saved to disk, nu Emailed to the CA. Portalul de dezvoltatori Apple preia un fișier încărcat.
Dacă doriți și să alegeți dimensiunea sau algoritmul cheii, bifați Let me specify key pair information aici. Apoi faceți clic pe Continue.
Pasul 3: Alegeți setările perechii de chei, dacă este necesar
Acest panou apare doar dacă ați bifat caseta la pasul 2, iar pentru un certificat Developer ID puteți de obicei să îl omiteți. Valorile implicite sunt RSA la 2048 biți, ceea ce folosesc și instrucțiunile proprii ale Apple. Cu RSA selectat, meniul Key Size oferă 2048, 4096 și 8192 biți. Meniul Algorithm oferă RSA și ECC, iar trecerea la ECC înlocuiește acele dimensiuni cu 256, 384 și 521 biți. Lăsați algoritmul pe RSA, cu excepția cazului în care serviciul la care vă înscrieți solicită în mod specific o cheie cu curbă eliptică.
Versiunile anterioare ale acestui ghid vă spuneau să selectați cel puțin 3072 de biți în acest punct. Acea valoare este minimul CA/Browser Forum pentru certificatele comerciale de semnare a codului. Nu se aplică certificatelor Developer ID și nu este oferită în acest meniu, așa că nu aveți ce selecta. Faceți clic pe Continue.
Pasul 4: Salvați cererea și verificați ce conține
Alegeți unde să salvați fișierul și faceți clic pe Save. Veți obține un fișier cu extensia .certSigningRequest, iar Certificate Assistant plasează și perechea de chei corespunzătoare în brelocul de chei de conectare. Fișierul în sine este text PEM obișnuit, așa că îl puteți deschide în TextEdit și citi, deși blocul codificat nu vă va spune prea multe de unul singur.
Pentru a confirma detaliile înainte de a-l încărca, decodificați cererea în Terminal. Acest lucru funcționează cu comanda openssl deja prezentă pe macOS, care este de fapt LibreSSL și nu OpenSSL propriu-zis, așa că nu aveți nimic de instalat:
openssl req -noout -text -in CertificateSigningRequest.certSigningRequestVerificați trei lucruri în rezultat: linia Subject afișează Numele Comun și adresa de email pe care le-ați introdus, linia cheii publice raportează 2048 bit (sau orice dimensiune ați ales), iar algoritmul de semnătură este SHA-256. Dacă preferați să nu folosiți Terminal, lipiți conținutul fișierului în decodorul nostru de CSR pentru a citi aceleași câmpuri.
Pasul 5: Trimiteți cererea și instalați certificatul
Conectați-vă la contul dvs. Apple Developer și deschideți Certificates, Identifiers & Profiles. Faceți clic pe Certificates în bara laterală, apoi pe butonul de adăugare, iar la Software selectați Developer ID. Alegeți tipul de care aveți nevoie:
- Developer ID Application semnează o aplicație, un plugin sau un pachet Mac.
- Developer ID Installer semnează un pachet de instalare Mac care conține aplicația dvs. semnată.
Faceți clic pe Continue, apoi pe Choose File, selectați fișierul dvs. .certSigningRequest, faceți din nou clic pe Continue și apoi pe Download. Apple returnează un fișier de certificat cu extensia .cer. Faceți dublu clic pe el pentru a-l instala, iar acesta va apărea în Keychain Access sub My Certificates, asociat cu cheia privată creată la pasul 4.
Semnarea cu certificatul este doar jumătate din ceea ce verifică macOS. Gatekeeper se așteaptă ca software-ul descărcat din afara Mac App Store să fie semnat cu un certificat Developer ID și notarizat de Apple, așa că trimiteți versiunea semnată pentru notarizare înainte de a o distribui. Notarizarea nu înlocuiește semnătura, ci se aplică peste aceasta.
Găsiți cheia privată și faceți o copie de rezervă
Certificatul nu are nicio valoare fără cheia privată generată de Certificate Assistant, iar acea cheie există într-un singur loc până când o copiați. Pentru a o găsi, deschideți Keychain Access, selectați brelocul de chei login, apoi categoria Keys, și căutați Numele Comun pe care l-ați introdus la pasul 2. Veți vedea două intrări sub acel nume, o cheie publică și o cheie privată. Rețineți că cheia publică nu este CSR-ul dvs.: CSR-ul este fișierul .certSigningRequest pe care l-ați salvat pe disc.
Odată ce fișierul .cer este instalat, căutați în schimb sub My Certificates. Acolo, certificatul și cheia sa privată apar ca o singură intrare, care reprezintă identitatea de semnare folosită de codesign, Xcode și scripturile dvs. de build. Pentru a muta acea identitate pe un alt Mac sau pe un server de build, faceți clic dreapta pe intrare și alegeți Export, ceea ce produce un fișier .p12 protejat de o parolă pe care o stabiliți. Stocați acel fișier la fel cum ați stoca orice cheie de semnare, deoarece oricine îl deține, împreună cu parola, poate semna software în numele dvs.
Faceți o copie de rezervă înainte de a avea nevoie de ea. Certificatele Developer ID sunt valabile timp de cinci ani și nu pot fi reînnoite: când unul expiră, creați un înlocuitor. Dacă pierdeți cheia privată, certificatul nu mai poate fi folosit niciodată și trebuie să creați altul, ceea ce consumă unul dintre cele cinci sloturi Developer ID Application sau cele cinci sloturi Developer ID Installer. Rezistați tentației de a revoca certificatul devenit inutilizabil pentru a face ordine. Apple este explicit că o aplicație semnată cu un certificat Developer ID revocat nu se va instala și nu se va lansa pentru un utilizator care o are deja, așa că revocarea ar strica fiecare copie deja existentă. Revocați doar dacă cheia a fost efectiv furată, și pregătiți-vă pentru această întrerupere.
O mențiune organizatorică pentru cei care au ajuns aici pentru un certificat comercial: dacă ați generat deja o pereche de chei în Keychain Access pentru o comandă la o Autoritate de Certificare publică, aceasta nu poate fi folosită și nicio CA nu o va accepta. Nimic nu se strică dacă o lăsați acolo, dar există puține motive să păstrați material de cheie de semnare exportabil într-un breloc de chei. Selectați atât cheia publică, cât și cea privată sub Keys și ștergeți-le, apoi comandați printr-un token sau un HSM.
Întrebări frecvente
Pentru un certificat Apple Developer ID, da, și este metoda documentată de Apple. Pentru un certificat de semnare a codului de încredere publică emis de o Autoritate de Certificare comercială, nu. Din 1 iunie 2023, acele chei private trebuie generate și stocate pe un modul criptografic hardware care îndeplinește standardul FIPS 140-2 Level 2, Common Criteria EAL4+ sau un standard echivalent, iar o cheie creată în Keychain Access este material de cheie software exportabil.
În /System/Library/CoreServices/Applications/. Apple l-a mutat acolo în macOS Sequoia, deci nu se mai află în Applications > Utilities și nu apare atunci când parcurgeți Applications în Finder. Deschideți-l cu Spotlight, sau rulați open "/System/Library/CoreServices/Applications/Keychain Access.app" în Terminal. Aplicația separată Passwords, introdusă alături de acesta, gestionează doar parole, nu certificate și chei.
RSA 2048 biți pentru un certificat Developer ID, care este valoarea implicită, așa că puteți lăsa nebifat Let me specify key pair information. Cu RSA selectat, meniul Key Size oferă 2048, 4096 și 8192 biți, iar trecerea la ECC le înlocuiește cu 256, 384 și 521 biți. La nicio setare nu se oferă 3072 biți, care este minimul CA/Browser Forum pentru certificatele comerciale de semnare a codului, și acesta este unul dintre mai multe motive pentru care această rută nu se potrivește unei comenzi comerciale.
Deoarece cererea pe care o construiește conține doar un Nume Comun și adrese de email. Apple nu are nevoie de mai mult: completează subiectul unui certificat Developer ID pe baza contului dvs. de dezvoltator. O Autoritate de Certificare comercială are nevoie de detalii despre organizație și le validează în raport cu evidențele publice, ceea ce reprezintă un alt motiv pentru care o cerere Keychain nu este potrivită pentru acea comandă.
Nu. Regula hardware a CA/Browser Forum se aplică certificatelor de semnare a codului de încredere publică emise de Autorități de Certificare comerciale. Certificatele Developer ID sunt emise de propria autoritate de certificare a Apple pentru membrii Apple Developer Program, iar cheia este generată în brelocul dvs. de chei de conectare de către Certificate Assistant, exact așa cum este descris mai sus.
Generați câte unul pentru fiecare. Portalul de dezvoltatori vă cere să încărcați o cerere de semnare a certificatului la fiecare creare de certificat, iar atribuirea unei perechi de chei proprii fiecărei identități înseamnă că înlocuirea sau revocarea uneia dintre ele lasă neafectat software-ul semnat cu cealaltă. Dați fiecărei cereri un Nume Comun pe care să îl puteți distinge ulterior în Keychain Access.
Verificați categoria Keys din brelocul de chei login, căutând Numele Comun pe care l-ați introdus, nu numele fișierului. Dacă lipsește într-adevăr, cauzele obișnuite sunt că perechea de chei a fost creată pe un alt Mac sau sub un alt cont de utilizator, că elementul din breloc a fost șters, sau că cererea a fost construită pe baza unei chei existente cu varianta de meniu Request a Certificate From a Certificate Authority With. Fără cheia privată, cererea nu poate fi folosită, așa că generați una nouă.
Certificatele de semnare a codului de încredere publică emise începând cu 1 martie 2026 sunt limitate la 460 de zile, reduse de la 39 de luni prin votul CSC-31 al CA/Browser Forum. Certificatele Apple Developer ID sunt valabile timp de cinci ani și sunt înlocuite, nu reînnoite. În ambele cazuri, software-ul semnat cât timp certificatul era valabil continuă să funcționeze după expirarea acestuia, cu condiția ca semnătura să fi fost marcată temporal (timestamped). Apple aplică o excepție: verifică certificatul Developer ID Installer în momentul în care rulează un pachet de instalare, astfel încât un .pkg trebuie resemnat după expirarea acelui certificat, deși aplicația din interiorul acestuia nu este afectată.
Pentru lecturi conexe, consultați tutorialele noastre de semnare a codului, celelalte moduri de a genera un CSR și cum să semnați un fișier EXE folosind un certificat de semnare a codului.
Economisește 10% la certificatele SSL în momentul plasării comenzii!
Eliberare rapidă, criptare puternică, încredere în browser de 99,99%, suport dedicat și garanție de returnare a banilor în 25 de zile. Codul cuponului: SAVE10
