Cum se generează un CSR pe Android

Acest tutorial vă arată cum să generați un CSR (Certificate Signing Request) pentru Android cu utilitarul Java keytool.

Android nu generează CSR-uri TLS de CA publică direct pe telefon: un certificat de CA publică este emis pentru un server (sau un dispozitiv controlat de utilizator), iar aplicațiile și browserele Android îl consumă. Fluxul keytool de mai jos produce o cerere PKCS #10 dintr-un keystore Java, care este calea corectă atunci când aveți nevoie de un certificat TLS pe care o aplicație Android sau un site web destinat mobilului îl va accepta ca de încredere.

Alegeți procedura corectă pentru cazul dumneavoastră

„CSR pentru Android” poate însemna trei lucruri diferite. Asigurați-vă că sunteți pe pagina corectă înainte de a rula orice comandă:

• Un certificat TLS pentru un server cu care clienții Android vor comunica. Acesta este cel mai comun caz, iar restul acestei pagini îl acoperă. Folosiți keytool (mai jos) sau generați CSR-ul în afara serverului cu Generatorul nostru de CSR, apoi instalați certificatul emis pe serverul web, gateway-ul API sau brokerul MQTT pe care aplicația dumneavoastră îl accesează.
• O cheie de semnare pentru un APK sau AAB. Semnarea aplicațiilor Android folosește o cheie RSA sau EC auto-semnată într-un keystore Java: nu este implicată nicio CA publică și nu există niciun CSR de trimis. Generați cheia cu keytool din asistentul Build > Generate Signed Bundle / APK al Android Studio (sau rulați keytool manual), apoi înregistrați cheia cu Google Play App Signing. Nu comandați un certificat public pentru acest lucru.
• Un certificat de dispozitiv furnizat de un MDM sau EMM. Android Enterprise emite certificate client către dispozitivele gestionate prin SCEP, EST sau API-ul Managed Configurations. CSR-ul este generat, iar certificatul instalat automat de către MDM. Nu există niciun pas manual keytool.

Dacă situația dumneavoastră este prima, continuați. Fluxul are două părți: creați un keystore PKCS12 care conține cheia privată, apoi exportați CSR-ul din acel keystore.

Ce veți avea nevoie

• O instalare Java (JDK sau JRE) astfel încât comanda keytool să fie disponibilă în PATH. Confirmați cu keytool -help. Pe Windows, folderul bin al Java trebuie să fie în PATH, sau puteți rula keytool direct din directorul bin al JDK-ului.
• Numele de domeniu complet calificat (FQDN) exact pe care doriți să-l securizați (de exemplu www.yoursite.com), plus orice alte nume de gazdă pe care le doriți pe același certificat (pentru lista Subject Alternative Name).
• Detaliile legale ale organizației dumneavoastră (țară, stat, oraș, numele organizației) pentru Distinguished Name. Folosiți valorile exact așa cum apar în registrele publice ale companiei: CA va respinge nepotrivirile.

Pasul 1: Creați keystore-ul și cheia privată

Dacă ați generat deja CSR-ul, treceți direct la trimiterea CSR-ului și apoi la instrucțiunile de instalare SSL pentru Android.

Deschideți un terminal (sau Command Prompt pe Windows) și rulați comanda keytool de mai jos. Aceasta creează un nou keystore în format PKCS12, generează o pereche de chei RSA de 2048 de biți în interiorul acestuia și stochează cheia sub aliasul pe care îl alegeți. PKCS12 este formatul implicit de keystore începând cu JDK 9; formatul mai vechi JKS este depreciat și trebuie evitat pentru chei noi.

keytool -genkeypair 
  -alias myalias 
  -keyalg RSA -keysize 2048 
  -storetype PKCS12 
  -keystore yoursite.p12 
  -validity 825

Pe Windows, aceeași comandă pe o singură linie arată astfel (rețineți calea absolută pentru a putea găsi din nou fișierul):

keytool -genkeypair -alias myalias -keyalg RSA -keysize 2048 -storetype PKCS12 -keystore C:certsyoursite.p12 -validity 825

Ce fac aceste opțiuni:

• -alias myalias: numele intrării din keystore. Alegeți o etichetă pe care o veți recunoaște și notați-o. Trebuie să reutilizați exact acest alias atunci când exportați CSR-ul și din nou atunci când importați certificatul semnat.
• -keyalg RSA -keysize 2048: o cheie RSA de 2048 de biți este minimul public actual acceptat de fiecare CA. Folosiți 3072 de biți pentru o cheie cu durată de viață mai lungă, sau generați o cheie ECDSA cu -keyalg EC -groupname secp256r1 pentru o cheie mai mică și mai rapidă (fiecare CA modernă emite certificate pentru ECDSA P-256 și P-384).
• -storetype PKCS12: forțează keystore-ul modern PKCS12. Extensia corespunzătoare este .p12 (sau .pfx).
• -keystore yoursite.p12: fișierul keystore de creat. Înlocuiți numele cu ceva pe care îl veți reține și păstrați fișierul în siguranță: acesta conține cheia dumneavoastră privată.
• -validity 825: cât timp este valid certificatul de tip placeholder auto-semnat din interiorul keystore-ului. Certificatul semnat de CA îl va înlocui ulterior, deci această valoare nu afectează durata de viață în producție.

keytool va solicita apoi o parolă de keystore. Alegeți o parolă puternică și stocați-o în managerul dumneavoastră de secrete. Veți avea nevoie de ea pentru fiecare comandă keytool ulterioară și pentru orice server care consumă keystore-ul. Cu keystore-urile PKCS12, parola cheii este egală cu parola keystore-ului, deci există o singură parolă de reținut.

Pasul 2: Introduceți detaliile organizației dumneavoastră (DN)

keytool solicită acum Distinguished Name (DN): câmpurile de identitate care vor apărea în CSR. Răspundeți la fiecare solicitare cu valoarea legală exactă pentru organizația dumneavoastră. Folosiți doar caractere ASCII standard: literele non-latine strică cererea. Punctuația contează, de asemenea, întrucât CA compară valorile dumneavoastră cu registrele publice ale companiei.

• Care este numele și prenumele dumneavoastră? Aceasta este formularea keytool pentru Common Name (CN). Introduceți FQDN-ul exact pe care doriți să-l securizați (de exemplu www.yoursite.com), sau un wildcard precum *.yoursite.com. Nu introduceți numele unei persoane.
• Care este numele unității organizaționale dumneavoastră? CA/Browser Forum a retras atributul organizationalUnitName la 01.09.2022, iar CA-urile publice îl elimină din certificatele emise. Rețineți că apăsarea tastei Enter nu lasă câmpul gol: keytool substituie propria valoare implicită, astfel încât DN-ul ajunge să conțină OU=Unknown, iar această valoare ajunge în CSR. Pentru a omite efectiv atributul, săriți peste solicitări și transmiteți DN-ul inline cu -dname, lăsând OU în afara șirului.
• Care este numele organizației dumneavoastră? Introduceți numele legal complet al companiei dumneavoastră, exact așa cum este înregistrat (de exemplu Your Company LLC). Este obligatoriu pentru certificatele OV și EV; pentru certificatele Domain Validation (DV), valoarea este ignorată, deci funcționează orice placeholder scurt.
• Care este numele orașului sau localității dumneavoastră? Scrieți numele complet al orașului în care este înregistrată compania dumneavoastră (de exemplu Seattle, nu SEA).
• Care este numele statului sau provinciei dumneavoastră? Introduceți numele complet al statului sau provinciei (de exemplu California, nu CA).
• Care este codul de țară din două litere pentru această unitate? Introduceți codul ISO 3166-1 alpha-2 din două litere (de exemplu US, GB, DE). Consultați lista oficială ISO dacă nu sunteți sigur.

keytool afișează DN-ul asamblat și întreabă Is CN=…, OU=…, O=…, L=…, ST=…, C=… correct? Introduceți yes și apăsați Enter pentru a confirma. Dacă observați o greșeală de tastare, introduceți no, iar keytool reia solicitările.

Pasul 3: Exportați CSR-ul cu un Subject Alternative Name

Acum exportați CSR-ul cu keytool -certreq. Fiecare CA publică validează numele de gazdă în raport cu extensia Subject Alternative Name (SAN), nu cu Common Name (browserele și bibliotecile TLS moderne au încetat să mai verifice CN-ul de ani buni), așa că includeți un SAN chiar și pentru un singur nume de gazdă. Folosiți același alias setat la Pasul 1:

keytool -certreq 
  -alias myalias 
  -file certreq.csr 
  -keystore yoursite.p12 
  -ext SAN=DNS:www.yoursite.com,DNS:yoursite.com

Pe Windows, aceeași comandă pe o singură linie:

keytool -certreq -alias myalias -file certreq.csr -keystore C:certsyoursite.p12 -ext SAN=DNS:www.yoursite.com,DNS:yoursite.com

Adăugați câte o intrare DNS: pentru fiecare nume de gazdă pentru un certificat multi-domeniu (separați-le cu virgule, fără spații). Pentru un wildcard, folosiți DNS:*.yoursite.com. keytool solicită parola keystore-ului, apoi scrie CSR-ul în fișierul certreq.csr din directorul curent.

Pasul 4: Deschideți CSR-ul și trimiteți-l către CA

Deschideți certreq.csr în orice editor de text (Notepad, TextEdit, nano, vim). De asemenea, îl puteți afișa în terminal:

cat certreq.csr

În Command Prompt pe Windows:

type certreq.csr

Veți vedea un bloc care arată astfel:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIDXjCCAkYCAQAwgZQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
... (many lines of base64) ...
-----END NEW CERTIFICATE REQUEST-----

Selectați întregul bloc, inclusiv liniile BEGIN NEW CERTIFICATE REQUEST și END NEW CERTIFICATE REQUEST (unele CA-uri le etichetează BEGIN CERTIFICATE REQUEST / END CERTIFICATE REQUEST: ambele etichete sunt acceptate). Copiați-l și lipiți-l în câmpul CSR din formularul dumneavoastră de comandă.

Verificați CSR-ul înainte de a-l trimite (opțional)

Merită să confirmați Common Name, intrările SAN și dimensiunea cheii înainte de a trimite cererea către CA. keytool afișează aceleași informații pentru intrarea din keystore:

keytool -printcertreq -file certreq.csr

Preferați un instrument online? Lipiți conținutul cererii în Decodorul de CSR al SSL Dragon pentru a citi subiectul, lista SAN și parametrii cheii publice. Confirmați că Common Name se potrivește cu numele de gazdă pe care îl vor folosi clienții și că fiecare nume necesar apare în lista Subject Alternative Name.

Va avea Android încredere în certificatul emis?

Da, pentru orice certificat semnat de o CA de încredere publică. Android livrează un depozit de sistem de certificate rădăcină care reflectă listele de încredere ale principalelor browsere, astfel încât un certificat emis sub una dintre acele rădăcini este de încredere pentru Chrome, WebView și orice aplicație care folosește depozitul de încredere al sistemului, fără nicio configurare suplimentară.

Două avertismente demne de reținut dacă instalați și certificatul (sau o rădăcină de CA privată) direct pe dispozitiv:

• CA-urile instalate de utilizator sunt ignorate de aplicații pe Android 7 și versiuni ulterioare. Începând cu Android 7 (Nougat), doar depozitul de sistem este de încredere pentru traficul aplicațiilor în mod implicit, iar Google Chrome ignoră, de asemenea, CA-urile instalate de utilizator. Dacă aplicația dumneavoastră trebuie să aibă încredere într-o CA privată, dezvoltatorul trebuie să opteze explicit printr-o configurație de securitate a rețelei care include <certificates src="user" />. Certificatele de CA publică nu au nevoie de acest lucru: ele se află deja în depozitul de sistem.
• Fixați-vă (pin) pe un identificator stabil, nu pe un singur certificat. Dacă implementați certificate pinning în aplicația dumneavoastră, fixați-vă pe hash-ul SPKI al cheii publice sau pe CA-ul emitent, nu pe un certificat leaf specific. Altfel, următoarea reînnoire va bloca utilizatorii.

Pașii următori

După ce CA validează CSR-ul și emite certificatul dumneavoastră, importați certificatul emis înapoi în același keystore (sub același alias), apoi implementați keystore-ul pe serverul pe care clienții Android îl vor accesa. Consultați ghidul nostru de instalare SSL pentru Android pentru pașii de instalare de pe dispozitiv, sau ghidurile de instalare specifice platformei din cum se instalează un certificat SSL dacă back-end-ul dumneavoastră rulează pe Tomcat, JBoss, Nginx sau alt server.