Cum se instalează un certificat SSL pe serverul JBoss

Acest tutorial vă arată cum să instalați un certificat SSL pe JBoss EAP și WildFly folosind keytool și subsistemul de securitate Elytron. Dacă nu aveți încă fișierele certificatului, prima secțiune acoperă generarea unui CSR.

Notă despre versiuni: JBoss EAP modern (7.1 și versiunile ulterioare, inclusiv EAP 8) și versiunile recente de WildFly configurează HTTPS prin subsistemul elytron conectat la https-listener-ul Undertow. Vechea metodă security-realm și conectorii vechi Tomcat sau Jetty sunt depreciați, așa că acest ghid folosește abordarea actuală.

Am înregistrat, de asemenea, un videoclip care vă ghidează prin întregul proces. Puteți urmări videoclipul, citi instrucțiunile sau ambele. Puteți urmări videoclipul mai jos.

Generați un cod CSR pe JBoss

Un CSR (Certificate Signing Request) este un bloc de text codificat pe care îl trimiteți Autorității de Certificare (CA) atunci când comandați un certificat. Acesta conține detaliile domeniului și organizației dumneavoastră, pe care CA le folosește pentru a valida cererea. Generarea CSR-ului creează și cheia privată corespunzătoare, care rămâne pe serverul dumneavoastră și este necesară în timpul instalării.

Aveți două opțiuni:

• Folosiți Generatorul nostru de CSR pentru a crea CSR-ul automat.
• Urmați tutorialul nostru pas cu pas despre cum să generați un CSR pe JBoss.

Pe JBoss, CSR-ul este generat cu keytool dintr-un keystore .jks sau .p12. Notați alias-ul și numele keystore-ului ales acum: veți importa certificatul semnat înapoi în acel alias exact mai târziu. Trimiteți CSR-ul către CA în timpul comenzii, iar odată ce certificatul este emis, continuați cu instalarea de mai jos.

Instalați un certificat SSL pe serverul JBoss

Pasul 1: Pregătiți fișierele certificatului

După validare, CA vă trimite prin e-mail fișierele certificatului, de obicei într-o arhivă ZIP. Extrageți-o. Ar trebui să aveți:

• Certificatul principal (un fișier .crt, .cer sau .pem).
• Certificatele intermediare, adesea livrate ca fișier .ca-bundle (pachetul CA). Unele CA includ și rădăcina.
• Keystore-ul (.jks sau .p12) creat împreună cu CSR-ul, care deține cheia privată sub aliasul ales la generarea CSR-ului.

Păstrați aceste fișiere împreună și copiați-le pe server, de exemplu în directorul de configurare JBoss ($JBOSS_HOME/standalone/configuration/). Dacă un fișier se deschide ca text, puteți confirma că acesta conține liniile așteptate BEGIN CERTIFICATE și END CERTIFICATE.

Pasul 2: Importați lanțul CA în keystore

Importați mai întâi certificatele intermediare (și rădăcina, dacă este furnizată), astfel încât keytool să poată construi un lanț complet de încredere. Folosiți același keystore care conține cheia privată și dați fiecărui certificat CA propriul alias:

keytool -import -trustcacerts -alias root -file root.crt -keystore your_keystore.jks

keytool -import -trustcacerts -alias intermediate -file intermediate.crt -keystore your_keystore.jks

Dacă CA v-a trimis un singur fișier .ca-bundle, importați-l sub un singur alias (de exemplu -alias intermediate). Când vi se solicită, introduceți parola keystore-ului și confirmați încrederea. Aceste intrări sunt intrări de certificat de încredere, nu intrări de cheie, deci nu afectează cheia privată.

Pasul 3: Importați certificatul semnat în aliasul cheii dumneavoastră

Acum importați certificatul semnat (răspunsul de la CA) în exact aliasul folosit la generarea CSR-ului. Deoarece acel alias deține deja cheia privată, keytool tratează aceasta ca pe un răspuns de certificat și înlocuiește certificatul auto-semnat temporar cu lanțul semnat de CA, păstrând cheia intactă:

keytool -import -trustcacerts -alias your_csr_alias -file your_domain.crt -keystore your_keystore.jks

Înlocuiți your_csr_alias cu aliasul folosit la generarea CSR-ului și your_keystore.jks cu keystore-ul dumneavoastră. La succes, keytool afișează Certificate reply was installed in keystore.

Important: nu inventați un alias nou aici. Importarea răspunsului sub un alias nou creează o intrare de certificat de încredere fără cheie privată, lanțul se pierde, iar serverul nu poate finaliza handshake-ul TLS. Dacă vedeți Failed to establish chain from reply, înseamnă că certificatul intermediar sau rădăcină din Pasul 2 lipsește din keystore.

Puteți verifica rezultatul, aliasul ar trebui acum să arate un lanț de certificate cu lungimea mai mare de 1:

keytool -list -v -alias your_csr_alias -keystore your_keystore.jks

Pasul 4: Configurați HTTPS în subsistemul Elytron

Plasați keystore-ul în $JBOSS_HOME/standalone/configuration/, apoi definiți un key-store, key-manager și server-ssl-context Elytron. Cea mai rapidă metodă este CLI-ul de management. Porniți serverul, conectați-vă cu jboss-cli.sh --connect și rulați un batch pentru ca modificările să se aplice împreună:

batch

/subsystem=elytron/key-store=httpsKS:add(path=your_keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=your_keystore_password}, type=JKS)

/subsystem=elytron/key-manager=httpsKM:add(key-store=httpsKS, credential-reference={clear-text=your_keystore_password})

/subsystem=elytron/server-ssl-context=httpsSSC:add(key-manager=httpsKM, protocols=["TLSv1.3","TLSv1.2"])

run-batch

În continuare, direcționați https-listener-ul Undertow către noul ssl-context. Undertow nu poate face referire simultan la un security-realm vechi și la un ssl-context Elytron, așa că eliminați referința veche și setați-o pe cea nouă într-un singur batch:

batch

/subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)

/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=httpsSSC)

run-batch

Dacă preferați să editați direct standalone.xml (cu serverul oprit), configurația echivalentă arată astfel în subsistemul elytron:

<tls>
    <key-stores>
        <key-store name="httpsKS">
            <credential-reference clear-text="your_keystore_password"/>
            <implementation type="JKS"/>
            <file path="your_keystore.jks" relative-to="jboss.server.config.dir"/>
        </key-store>
    </key-stores>
    <key-managers>
        <key-manager name="httpsKM" key-store="httpsKS">
            <credential-reference clear-text="your_keystore_password"/>
        </key-manager>
    </key-managers>
    <server-ssl-contexts>
        <server-ssl-context name="httpsSSC" key-manager="httpsKM" protocols="TLSv1.3 TLSv1.2"/>
    </server-ssl-contexts>
</tls>

Iar listener-ul corespunzător din subsistemul undertow face referire la acel ssl-context:

<https-listener name="https" socket-binding="https" ssl-context="httpsSSC" enable-http2="true"/>

Limitarea protocols la TLS 1.3 și TLS 1.2 dezactivează versiunile obsolete TLS 1.0 și 1.1. Portul HTTPS implicit este 8443; mapați-l la 443 cu un load balancer sau o redirecționare de port dacă aveți nevoie de portul standard.

Pasul 5: Reporniți JBoss

Dacă ați editat manual standalone.xml, reporniți serverul pentru ca acesta să încarce noua configurație. Dacă ați folosit batch-urile CLI de mai sus, modificările se aplică imediat, dar o reîncărcare confirmă o pornire curată:

jboss-cli.sh --connect --command=:reload

Urmăriți jurnalul serverului pentru erori SSL sau Elytron în timpul pornirii. Odată ce pornește curat, certificatul dumneavoastră SSL este instalat pe JBoss.

Testați instalarea SSL

După instalare, confirmați că certificatul și lanțul sunt oferite corect. Deschideți site-ul dumneavoastră prin HTTPS (de exemplu https://www.yourdomain.com:8443) și verificați lacătul, sau rulați o scanare externă cu SSL Checker pentru un raport complet despre certificat, lanț și suportul de protocoale. Puteți verifica și din linia de comandă:

echo | openssl s_client -connect yourdomain.com:8443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -issuer -dates

Aceasta afișează emitentul și datele de valabilitate ale certificatului pe care JBoss îl oferă. Dacă emitentul este CA-ul dumneavoastră (nu o intrare auto-semnată), răspunsul a fost importat corect.

Întrebări frecvente