KeyStore con certificati pkcs12: come viene scelto il certificato da usare?

[Tiziano Lattisi]

Ciao a tutti.

Sto impazzendo dietro ad un keystore con dei certificati pkcs12, ognuno protetto con una password diversa, ma con lo stesso alias.

Ho creato il keystore e vi ho importato i 3 certificati .p12., modificando di volta in volta l'alias, e cambiando la password perché fosse la stessa del keystore.

# keytool -importkeystore -srckeystore cert1.p12 -srcstoretype pkcs12 -destkeystore ks.jks -deststoretype JKS

# keytool -changealias -keystore ks.jks -alias samealias -destalias alias1

# keytool -keypasswd -keystore ks.jks -alias alias1

Creo un ContextSSL utilizzando questo keystore, e proposta a collegarmi ai tre service che mi permettono di autenticarmi con i tre certificati (sono sullo stesso endpoint, facendo una sorta di routing sulla base di un parametro passato nella chiamata soap).

Noto che me ne funziona solo uno. Il secondo per la precisione.

Allora provo a rimuovere il secondo certificato:

# keytool -delete -alias alias2 -keystore ks.jks

A questo punto il servizio relativo al secondo certificato ovviamente non funziona più. Ora mi funziona il servizio del certificato 3, e non quello del certificato 1.

Come è possibile intuire, se rimuovo anche il certificato 3, allora riesco ad accedere al servizio 1.

Sembra che cerchi di utilizzare sempre il primo certificato che trova (chissà poi con che ordine), ma non mi è chiaro sulla base di cosa potrebbe essere in grado di scegliere il certificato corretto...

Qualche idea? Oppure devo rassegnarmi a tirare su e distruggere contesti ssl diversi per ogni certificato?

ciao!

T

[Mario Alexandro Santini]

2018-02-22 15:42 GMT+01:00 Tiziano Lattisi <tiziano...@gmail.com>:

Ciao a tutti.

Ciao Tiziano,

 

Creo un ContextSSL utilizzando questo keystore, e proposta a collegarmi ai tre service che mi permettono di autenticarmi con i tre certificati (sono sullo stesso endpoint, facendo una sorta di routing sulla base di un parametro passato nella chiamata soap).

Penso che la scelta del certificato da usare sia legata alla PKI chain, ovvero se trova un certificato che condivide una CA con quella del server allora usa quello.

In automatico, penso non faccia distinzione su quale utilizzare se non il primo che fa il match.

 

Qualche idea? Oppure devo rassegnarmi a tirare su e distruggere contesti ssl diversi per ogni certificato?

ciao! 

T

Per determinare il certificato da usare devi implementarti un tuo X509KeyManager da pilotare a seconda delle tue esigenze e che poi passi all'SSLContext.

Qui c'è un esempio:

https://stackoverflow.com/a/15202608/6452829

--

 Mario

[Tiziano Lattisi]

Grazie Mario,

c'hai preso in pieno!

Nel mio caso il certificato da utilizzare è legato al tenant (ha l'alias uguale al tenant id), quindi l'ho collegato così.

Ciao!

T

--
You received this message because you are subscribed to the Google Groups "JUG Trentino Alto Adige Suedtirol" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jugtaa+unsubscribe@googlegroups.com.
To post to this group, send email to jug...@googlegroups.com.
Visit this group at https://groups.google.com/group/jugtaa.
For more options, visit https://groups.google.com/d/optout.

[Mario Alexandro Santini]

2018-02-22 19:12 GMT+01:00 Tiziano Lattisi <tiziano...@gmail.com>:

Nel mio caso il certificato da utilizzare è legato al tenant (ha l'alias uguale al tenant id), quindi l'ho collegato così.

Ciao!

T

Immaginavo qualcosa del genere.

Ma devi gestire un client che si comporta come n-tenant o si tratta solo di test?

--

 Mario

[Tiziano Lattisi]

Ho un client n-tenant che deve collegarsi allo stesso service, con certificati diversi dipendentemente dal tenant.

Avevo una soluzione che prevedeva diversi contesti ssl (ognuno con il suo certificato). Funzionante ma poco pratica.

Ora sto lavorando sul tuo spunto: keystore unico, contesti su tenant-scope.

T

[Andrea Bertagnolli]

Forse poco pratica nel tuo caso, ma nel nostro caso è stata reputata la migliore. 

Siamo in una situazione dove i tenant possono essere creati e aggiornati dagli utenti del servizio tecnico tramite un'interfaccia web,

e la gestione di un keystore "multichiave" lato codice non è proprio il massimo, così salviamo i certificati su un database e creiamo un ssl context per ognuno di questi, 

in base ad un identificativo che rappresenta il servizio che va poi interrogato.

Il giorno venerdì 23 febbraio 2018 09:12:45 UTC+1, Tiziano Lattisi ha scritto:

Ho un client n-tenant che deve collegarsi allo stesso service, con certificati diversi dipendentemente dal tenant.

Avevo una soluzione che prevedeva diversi contesti ssl (ognuno con il suo certificato). Funzionante ma poco pratica.

Ora sto lavorando sul tuo spunto: keystore unico, contesti su tenant-scope.

T

2018-02-22 20:14 GMT+01:00 Mario Alexandro Santini <alexm...@gmail.com>:

2018-02-22 19:12 GMT+01:00 Tiziano Lattisi <tiziano...@gmail.com>:

Nel mio caso il certificato da utilizzare è legato al tenant (ha l'alias uguale al tenant id), quindi l'ho collegato così.

Ciao!

T

Immaginavo qualcosa del genere.

Ma devi gestire un client che si comporta come n-tenant o si tratta solo di test?

--

 Mario

--
You received this message because you are subscribed to the Google Groups "JUG Trentino Alto Adige Suedtirol" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jugtaa+un...@googlegroups.com.

[Tiziano Lattisi]

La vostra soluzione è in effetti simile alla mia attuale.

L'aggiunta di nuovi tenant per me non è così "snella", visto che si tira dietro un overhead di attivazione che va avanti mesi.

Non sono ancora convinto al 100% di quale strada seguire. Per ora cerco di capire per bene come funziona.

Tra l'altro, con un unico context ssl c'è il problema di invalidarlo al momento del cambio di tenant, in modo che riesegua chooseClientAlias.

T

To unsubscribe from this group and stop receiving emails from it, send an email to jugtaa+unsubscribe@googlegroups.com.