Cum se generează un CSR pe serverele JBoss

Acest tutorial vă arată cum să generați un CSR (Certificate Signing Request) pe JBoss EAP și WildFly folosind utilitarul Java keytool. Fluxul constă în două comenzi: mai întâi keytool -genkeypair creează un keystore și o cheie privată sub un alias ales, apoi keytool -certreq exportă CSR-ul corespunzător cu Subject Alternative Names pe care CA-ul le va emite. Același alias este reutilizat mai târziu când importați certificatul semnat, astfel încât cheia, CSR-ul și certificatul final se află toate în același loc.

Notă despre versiuni: JBoss modern este Red Hat JBoss Enterprise Application Platform (EAP) 8, lansat în februarie 2024 și bazat pe proiectul din amonte WildFly (WildFly 41, lansat în iulie 2026, este versiunea comunitară curentă). Ambele configurează HTTPS prin subsistemul elytron și https-listener-ul Undertow; configurația conectorului mai vechi Tomcat sau Jetty prezentată în ghidurile vechi nu se mai aplică. Totuși, pasul CSR în sine este identic în toate versiunile recente, deoarece este o simplă operațiune Java keytool.

De ce veți avea nevoie

• O instalare Java (JDK sau JRE) astfel încât comanda keytool să fie disponibilă. JBoss EAP 8.0 rulează pe Java 11 (depreciat) sau 17, EAP 8.1 adaugă Java 21, iar WildFly 41 rulează pe Java 17, 21 sau 25 (Java 11 nu mai este acceptat în amonte). Confirmați cu keytool -help.
• Acces shell sau terminal pe serverul JBoss care va găzdui cheia privată. Cheia privată trebuie să rămână pe acest server.
• Numele de domeniu complet calificat (FQDN) exact pe care doriți să-l securizați, de exemplu www.domeniulvostru.com, plus orice alte nume de gazdă pe care doriți să le acoperiți în câmpul SAN.
• Detaliile legale ale organizației dvs. (țară, stat, localitate, denumirea organizației) pentru Distinguished Name din CSR.

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

Dacă v-ați generat deja CSR-ul, treceți direct la trimiterea CSR-ului și apoi la instalarea certificatului SSL pe JBoss.

Deschideți un terminal pe serverul JBoss și creați un keystore nou în format PKCS12. PKCS12 este standardul modern, portabil (RFC 7292) și este formatul implicit de keystore în Java începând cu JDK 9; formatul proprietar mai vechi JKS este depreciat. Executați:

keytool -genkeypair 
  -alias jboss 
  -keyalg RSA -keysize 2048 
  -storetype PKCS12 
  -keystore yourdomain.p12 
  -validity 825

Ce înseamnă opțiunile:

• -alias jboss: numele intrării din keystore. Alegeți o etichetă pe care o veți recunoaște (adesea jboss, server sau domeniul dvs.). Notați-l. Trebuie să reutilizați exact acest alias atunci când generați CSR-ul și din nou atunci când importați certificatul semnat. Utilizarea unui alias diferit la import este cea mai frecventă greșeală keytool.
• -keyalg RSA -keysize 2048: o cheie RSA de 2048 de biți este minimul public actual. Pentru keystore-uri noi pe care intenționați să le păstrați mai mulți ani, 3072 de biți reprezintă o actualizare rezonabilă. Majoritatea CA-urilor publice acceptă și ECDSA (-keyalg EC -groupname secp256r1) dacă preferați o cheie mai mică și mai rapidă. Opțiunea -groupname necesită JDK 13 sau o versiune ulterioară; pe Java 11 folosiți în schimb -keyalg EC -keysize 256, care selectează aceeași curbă secp256r1. keytool respinge ambele opțiuni în aceeași comandă.
• -storetype PKCS12: forțează keystore-ul modern PKCS12. Extensia corespunzătoare este .p12 (sau .pfx).
• -keystore yourdomain.p12: fișierul keystore de creat. Înlocuiți numele cu ceva pe care îl veți recunoaște și păstrați acest fișier în siguranță; el conține cheia dvs. privată.
• -validity 825: durata de valabilitate a certificatului de rezervă autosemnat din interiorul keystore-ului. Certificatul semnat de CA îl va înlocui ulterior, astfel încât valoarea exactă nu afectează durata de viață în producție.

keytool vă va solicita apoi o parolă a keystore-ului. Alegeți o parolă puternică și stocați-o în managerul dvs. de secrete: veți avea nevoie de ea pentru fiecare comandă keytool ulterioară și pentru credential-reference-ul Elytron pe care îl veți configura în JBoss. La keystore-urile PKCS12, parola cheii este egală cu parola keystore-ului, astfel încât există o singură parolă de reținut.

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

keytool vă solicită acum Distinguished Name (DN): câmpurile de identitate care intră în CSR. Răspundeți la fiecare solicitare cu valoarea exactă, legală, pentru organizația dvs. Punctuația și acuratețea contează, deoarece un CA va respinge nepotrivirile față de registrele publice ale afacerii.

• Prenume și nume (CN): aceasta este formularea keytool, dar este de fapt câmpul Common Name. Introduceți FQDN-ul exact pe care îl securizați, de exemplu www.domeniulvostru.com, sau un wildcard precum *.domeniulvostru.com. Nu introduceți numele unei persoane.
• Unitate organizatorică (OU): acest câmp nu mai este emis de CA-urile publice și este cel mai bine să fie omis. Rețineți că apăsarea tastei Enter nu îl lasă gol: keytool substituie propria valoare implicită, astfel încât DN-ul ajunge să conțină OU=Unknown, care apoi ajunge în CSR. Pentru a omite efectiv câmpul, folosiți forma non-interactivă -dname de mai jos și lăsați OU în afara șirului.
• Organizație (O): numele legal complet al companiei dvs., de exemplu Your Company LLC. Certificatele OV și EV îl solicită; pentru certificatele DV, multe CA-uri îl acceptă ca fiind informativ, așa că este mai sigur să-l completați decât să-l lăsați gol.
• Oraș sau localitate (L): numele complet al orașului, de exemplu San Jose. Nu abreviați.
• Stat sau provincie (ST): numele complet al statului sau provinciei, de exemplu California. Nu folosiți un cod din două litere.
• Cod de țară (C): codul de țară ISO din două litere, de exemplu US, GB, DE.

După ultima solicitare, keytool afișează un rezumat precum CN=www.domeniulvostru.com, OU=Unknown, O=Your Company LLC, L=San Jose, ST=California, C=US. Tastați yes pentru a confirma. Fișierul keystore există acum cu o singură intrare: aliasul dvs., care conține cheia privată și un certificat de rezervă autosemnat.

Dacă preferați o comandă non-interactivă, transmiteți DN-ul inline și săriți peste solicitări:

keytool -genkeypair 
  -alias jboss 
  -keyalg RSA -keysize 2048 
  -storetype PKCS12 
  -keystore yourdomain.p12 
  -dname "CN=www.yourdomain.com, O=Your Company LLC, L=San Jose, ST=California, C=US" 
  -validity 825

Pasul 3: Generați CSR-ul cu SAN

Browserele moderne și clienții TLS validează certificatele față de extensia Subject Alternative Name (SAN), nu doar față de Common Name. Solicitați SAN-urile direct în CSR, astfel încât CA-ul să le includă în certificatul emis. Folosiți același alias și keystore din Pasul 1:

keytool -certreq 
  -alias jboss 
  -keystore yourdomain.p12 
  -file yourdomain.csr 
  -ext san=dns:yourdomain.com,dns:www.yourdomain.com

Ce înseamnă opțiunile:

• -alias jboss: trebuie să corespundă aliasului din Pasul 1. Acesta este aliasul a cărui cheie privată semnează cererea.
• -keystore yourdomain.p12: trebuie să corespundă keystore-ului din Pasul 1.
• -file yourdomain.csr: numele fișierului de ieșire pentru CSR.
• -ext san=dns:…: extensia Subject Alternative Name. Enumerați fiecare nume de gazdă pe care trebuie să-l acopere certificatul, inclusiv atât domeniul rădăcină (yourdomain.com), cât și subdomeniul www. Adăugați mai multe intrări separate prin virgulă, de exemplu dns:api.yourdomain.com.

keytool solicită parola keystore-ului și scrie CSR-ul în yourdomain.csr în directorul curent.

Esențial: păstrați aliasul și keystore-ul

Cea mai frecventă greșeală keytool pe JBoss este importul certificatului semnat sub un alias nou. Făcând acest lucru, certificatul este stocat ca intrare de încredere independentă, fără cheie privată atașată, iar key-manager-ul Elytron nu va reuși să pornească o sesiune TLS. Importați întotdeauna răspunsul semnat înapoi în același alias care conține cheia privată (aliasul din Pasul 1).

Notați acum aceste trei valori, înainte de a închide terminalul:

• Aliasul (în acest ghid, jboss).
• Calea fișierului keystore (de exemplu yourdomain.p12; pe JBoss aceasta se află de obicei în $JBOSS_HOME/standalone/configuration/).
• Parola keystore-ului.

Dacă nu sunteți sigur ce alias conține cheia dvs., listați conținutul keystore-ului și căutați intrarea al cărei tip este PrivateKeyEntry:

keytool -list -v -keystore yourdomain.p12

Pasul 4: Verificați CSR-ul înainte de a-l trimite

Depistați greșelile de scriere din DN sau SAN-urile lipsă înainte ca CA-ul să le valideze. Afișați CSR-ul cu keytool:

keytool -printcertreq -file yourdomain.csr

Sau, dacă OpenSSL este instalat, îl puteți folosi în schimb:

openssl req -noout -text -in yourdomain.csr

Confirmați trei lucruri în rezultat: Subject afișează DN-ul dvs. exact, Subject Alternative Name enumeră fiecare nume de gazdă de care aveți nevoie, iar dimensiunea Public-Key corespunde cu ceea ce ați solicitat (RSA de 2048 de biți sau orice altceva ați ales). Puteți, de asemenea, să lipiți CSR-ul în CSR Decoder-ul nostru pentru aceeași verificare într-un browser.

Pasul 5: Trimiteți CSR-ul către Autoritatea de Certificare

Deschideți yourdomain.csr în orice editor de text. Fișierul este text simplu, începând cu -----BEGIN NEW CERTIFICATE REQUEST----- și terminându-se cu -----END NEW CERTIFICATE REQUEST-----. Cuvântul NEW este scris de keytool și este normal: conținutul este o cerere PKCS#10 standard pe care orice CA o acceptă. Copiați întregul bloc, inclusiv acele linii de antet și subsol, și lipiți-l în câmpul CSR în timpul procesului de comandă la CA-ul dvs. Pe Windows, folosiți Ctrl + A apoi Ctrl + C pentru a prelua textul complet; pe macOS, folosiți Cmd + A apoi Cmd + C.

Realizați o copie de rezervă a fișierului keystore înainte de a face orice altceva. Dacă pierdeți yourdomain.p12, pierdeți și cheia privată, ceea ce înseamnă că certificatul semnat returnat de CA va fi inutilizabil și va trebui să reîncepeți totul cu un CSR nou.

După ce CA-ul vă validează cererea și emite certificatul, continuați cu cum să instalați certificatul SSL pe JBoss. Veți importa certificatul semnat înapoi în același alias din același keystore, apoi veți face referire la acel keystore dintr-un key-store, key-manager și server-ssl-context Elytron conectate la https-listener-ul Undertow.

Pot reutiliza un CSR pentru o reînnoire?

Puteți, dar cea mai bună practică de securitate este să generați un keystore nou, o cheie privată nouă și un CSR nou pentru fiecare certificat. O cheie nouă pentru fiecare reînnoire limitează impactul în cazul în care cheia veche este vreodată compromisă, iar procesul este același: rulați keytool -genkeypair și keytool -certreq pentru un fișier keystore nou. Duratele de valabilitate ale certificatelor TLS publice se reduc conform regulilor CA/Browser Forum (200 de zile începând cu 15 martie 2026, scăzând la 100 de zile în 2027 și 47 de zile în 2029), așa că planificați cicluri CSR mai frecvente sau automatizați emiterea prin ACME, acolo unde CA-ul dvs. o acceptă.