TLS consente una comunicazione sicura end-to-end su reti TCP/IP. Generalmente siamo abituati a situazioni in cui è l'applicazione client (ad esempio un Browser) a dover autenticare il server attraverso la verifica del certificato o la catena di certificati da esso ottenuti.
L'autenticazione può essere anche mutua, ciò significa che anche il server può richiedere al client di fornire un certificato. In questo articolo vedremo la configurazione per una mutua autenticazione TLS su server Wildfly utilizzando il nuovo unified security framework Elytron.
Keystores Client e Server
Partendo da un'installazione standalone di Wildfly portiamoci nella directory {jbossHomeName}/standalone/configuration e utilizziamo il keytool descritto negli articoli precedenti per creare un keystore per il certificato del server. Di seguito il comando di creazione e l'output prodotto:
Figura 1. Generazione keystore server
Creiamo poi un keystore per il client:
Figura 2. Generazione keystore client
Esportiamo quindi il certificato a chiave pubblica del client e importiamolo in un keystore che fungerà da truststore per il server. Il truststore consentirà al server di comprendere quali certificati client avranno diritto di accesso in fase di autenticazione:
Figura 3. Esportazione certificato client
Esportiamo infine il keystore del client nel formato PKCS12 che permette di salvare in modo criptato sia il certificato che la chiave privata. Questo formato consentirà l'importazione del keystore all'interno del browser per l'autenticazione del client.
Figura 4. Esportazione formato PKCS12
Configurazione Server
Una volta generati i keystore client/server avviamo la configurazione di un contesto SSL attraverso i comandi JBoss CLI. Spostiamoci nella directory {jbossHomeName}/bin e avviamo jboss-cli.sh o jboss-cli.bat a seconda del sistema in uso. Digitiamo il commando connect e inviamolo.
A questo punto siamo in grado di configurare Elytron per la mutua autenticazione. Inseriamo i seguenti comandi uno ad uno per aggiungere i keystore e creare un contesto SSL con utilizzo del protocollo TLS 1.2:
/subsystem=elytron/key-store=qsKeyStore:add(path=server.keystore,relative-to=jboss.server.config.dir,type=JKS,credential-reference={clear-text=server})
/subsystem=elytron/key-store=qsTrustStore:add(path=client.truststore,relative-to=jboss.server.config.dir,type=JKS,credential-reference={clear-text=client})
/subsystem=elytron/key-manager=qsKeyManager:add(key-store=qsKeyStore,credential-reference={clear-text=server})
/subsystem=elytron/trust-manager=qsTrustManager:add(key-store=qsTrustStore)
/subsystem=elytron/server-ssl-context=qsSSLContext:add(key-manager=qsKeyManager,trust-manager=qsTrustManager,protocols=[TLSv1.2],need-client-auth=true)Cambiamo inoltre la configurazione del sistema Undertow, Web server scritto in Java e integrato in Wildfly, per utilizzare il contesto SSL creato:
/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=qsSSLContext)Concludiamo digitando e inviando reload per caricare dinamicamente la configurazione modificata del server. Gli ultimi due comandi sul sistema Undertow potrebbero non concludersi correttamente, per risolvere il problema occorre editare manualmente il file standalone.xml in {jbossHomeName}/standalone/configuration e fare in modo che la linea https-listener del sistema Undertow referenzi il contesto SSL creato:
<https-listener name="https" socket-binding="https"
ssl-context="qsSSLContext" enable-http2="true" />Riavviamo il server e per testare il funzionamento della configurazione, colleghiamoci all'indirizzo
https://localhost:8443Si dovrebbe così visualizzare la richiesta del trust del certificato del server generato in precedenza come self-signded.
