(Italiano) HTTPS Java Client e Certificati SSL

Sorry, this entry is only available in Italian. For the sake of viewer convenience, the content is shown below in the alternative language. You may click the link to switch the active language.

Questo breve post nasce come risposta a un quesito posto da lettore sull’articolo Importazione Certificati SSL sul Java Keystore (JKS) di qualche anno addietro e pubblicato sul mio blog. In quell’articolo era discussa la gestione dei Certificati Digitali sulla piattaforma Java e in particolare i repository key store e trust store.

La domanda posta ieri era la seguente:

Ciao Antonio,
ho un problema con i certificati e vedo che hai una risposta per tutto, ti è mai capitato di dover usare più certificati? …ma non appena riconfiguro le property di sistema per il secondo certificato ed invoco il secondo servizio va in eccezione (Connection has been shutdown: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target).

Certamente è possibile utilizzare più certificati che possono risiedere all’interno dello stesso trust store. Questo tipo di errore è classico, accade quando non è stato possibile eseguire la validazione della catena di certificazione (Certificate Chain). E’ possibile incappare in errori del genere quando per esempio si tenta di accedere a servizi che espongono un certificato non rilasciato da una Certification Authority o CA valida o comunque riconosciuta. Classico esempio sono i certificati rilasciati da CA interne a un’organizzazione.

La soluzione al problema è abbastanza semplice, occorre aggiungere al repository dei certificati tutta la catena di certificazione che ha firmato il certificato esposto dal servizio cui desiderate accedere. Solitamente, quando la locazione del trust store non è specificata, l’implementazione di  SunJSSE esegue la ricerca nelle seguenti directory:

  1. $JAVA_HOME/lib/security/jssecacerts
  2. $JAVA_HOME/lib/security/cacerts

Per aggiungere uno o più certificati al proprio repository si procede sempre con il tool keytool o altrimenti è anche possibile utilizzare tool di terze parti come per esempio KeyStore Explorer.  

Per l’occasione , ho realizzato un semplice client HTTPS che tenta di accedere a tre  risorse di cui una è “fake SSL”, ovvero, dispone di un certificato di tipo self-signed. L’accesso a quest’ultima risorsa sarà quindi negativo, fino a quando, in maniera esplicita, non aggiungeremo il certificato al nostro trust store.

Le risorse cui tenteremo di accedere sono quindi:

  • https://www.goodreads.com/book/show/18734728-enterprise-integration-with-wso2-esb?from_search=true (Risorsa con SSL OK)
  • https://www.liferay.com/it/products/liferay-portal/overview (Risorsa con SSL OK)
  • https://crm-shiruslabs.dontesta.it:8443/SugarEnt-Full-7.1.0 (Risorsa con SSL FAKE)

La prima esecuzione del programma java, quindi, senza nessun intervento sul trust store, darà esito positivo (accesso alla risorsa) per i primi e negativo per l’ultima. Nel Listato 1 è mostrato proprio ciò che accade con evidenza dell’errore per l’accesso all’ultima risorsa.

Dal log del Listato 1 è possibile vedere le informazioni sulla catena di certificazione per ogni risorsa a cui si sta facendo accesso. Sempre dal Listato 1 notare l’errore che si ottiene accedendo all’ultima risorsa: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.

Aggiungendo quindi il certificato (che ricordo essere di tipo self-signed) al nostro trust store, ci saranno poi le condizioni per accedere alla risorsa senza alcun problema. Questa volta ho utilizzato il tool KeyStore Explorer per aggiungere il certificato tra quelli trust. In Figura 1 è mostrato il dettaglio del certificato con CN (Common Name) crm-shiruslabs.dontesta.it che sarà poi aggiunto al trust strore così come mostrato in Figura 2.

Figura 1 - Certificato Self-Signed da aggiungere al trust store.

Figura 1 – Certificato Self-Signed da aggiungere al trust store.

Figura 2 - Aggiunta del certificato al trust store.

Figura 2 – Aggiunta del certificato al trust store.

Una volta aggiunto il nuovo certificato al trust store, possiamo nuovamente eseguire il programma java e verificare che tutto vada a buon fine. Il Listato 2, mostra questa volta come l’accesso alla risorsa sia avvenuto in modo corretto.

Notare dal Listato 2 come non esiste una catena di certificazione per l’ultimo servizio, al contrario dei primi due, questo perchè si tratta di un certificato di tipo self-signed. Il programma di test realizzato per il post, più il JKS del trust store sono disponibili sul mio repository GitHub all’indirizzo HTTPS Java Client Example. Se avete la voglia e la fantasia di fare un test, il tutto è molto semplice, basta seguire le indicazioni riportate al Listato 3.

Da un commento a un articolo!

Antonio Musarra

I began my journey into the world of computing from an Olivetti M24 PC (http://it.wikipedia.org/wiki/Olivetti_M24) bought by my father for his work. Day after day, quickly taking control until … Now doing business consulting for projects in the enterprise application development using web-oriented technologies such as J2EE, Web Services, ESB, TIBCO, PHP.

You may also like...

Cos'è il progetto CIE/CNS Apache Docker - Developers Italia

In questo video https://youtu.be/TcAzn1POhsM introdurrò il progetto CIE/CNS Apache Docker di Developers Italia (https://developers.italia.it/it/cie/#resourcecontent-3) nato circa due anni fa.

L'obiettivo di questo progetto è quello di fornire un template pronto all'uso che realizza un sistema di autenticazione tramite la Smart Card TS-CNS (o CNS) e la CIE (Carta d'Identità Elettronica) basato su Apache HTTP. Ognuno può poi modificare o specializzare questo progetto sulla base delle proprie esigenze Si tratta di un progetto docker per la creazione di un container che implementa un sistema di mutua autenticazione o autenticazione bilaterale SSL/TLS.

Questo meccanismo di autenticazione richiede anche il certificato digitale da parte del client, certificato che in questo caso risiede all'interno della TS-CNS o della CIE. La particolarità del sistema implementato (attraverso questo container) è quella di consentire l'autenticazione tramite:

  • La TS-CNS (Tessera Sanitaria - Carta Nazionale Servizi), rilasciata dalla regione di appartenenza;
  • La CIE (Carta d'Identità Elettronica), rilasciata dal comune di residenza.

Nella versione 2.0.0 il progetto è stato aggiornato per essere uniforme alle linee guida di Bootstrap Italia. A seguire alcune risorse che possono essere utili.

  • Cos’è il progetto CIE/CNS Apache Docker (http://bit.ly/3aJ5Gbl)
  • CIE Carta d'Identità Elettronica (https://developers.italia.it/it/cie/)
  • Carta Nazionale dei Servizi (https://www.agid.gov.it/it/piattaforme/carta-nazionale-servizi)
  • Raspberry Pi – Un esempio di applicazione della TS-CNS (https://bit.ly/3hkJ8Aj)
  • Pubblicare il servizio CIE/CNS Apache Docker su Azure Cloud (http://bit.ly/3aPoq8V)
  • Come accedere al portale VETINFO tramite TS-CNS e Mac OS (http://bit.ly/2VFMKq7)