Certificats + Truststore Java + Apache

Bonjour,

je me lance dans la compréhension des certificats et les communications sécurisé SSL.

Je vais aborder tout le périmètre du problème afin que quelqu'un puisse m'expliquer le fonctionnement que je remercie par avance.

Alors voilà mon problème:

Sur un serveur apache j'ai bien définit la configuration SSL(port:443) du virtualhost comme ceci pour une aplication [App_A]:

Code:

---

1 2 3 4 5 6 7 8

SSLEngine on SSLCipherSuite HIGH:MEDIUM:LOW SSLProtocol -ALL +SSLv3 +TLSv1   SSLCertificateFile /etc/ssl/certs/<nom_du_domaine>/2014/wildcard.e-server-name.crt SSLCertificateKeyFile /etc/ssl/certs/<nom_du_domaine>/2013/wildcard.e-server-name.key SSLCertificateChainFile /etc/ssl/certs/<nom_du_domaine>/2014/wildcard.e-server-name.chain

---

J'ai une autre application (App_B) qui tourne sur un autre serveur et qui contacte par webservice App_A, hors si le fichier:

Code:

---

SSLCertificateFile /etc/ssl/certs/<nom_du_domaine>/2014/wildcard.e-server-name.crt

---

change (mis à jour car la date est arrivée à expiration), j'ai une exception de type:

Code:

---

1 2 3 4 5

Exception in thread "main" 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 .... Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target .... Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

---

ok pas de souci, je récupère le certificat à laide de la commande:

Code:

---

1 2 3

echo | openssl s_client -connect server_name:443 2> /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > server_name.crt

---

je vérifie ça validité:

Code:

---

openssl x509 -noout -dates -in server_name.crt

---

je peut maintenant l'ajouter(le fichier server_name.crt) au 'fameux' truststore de $JAVA_HOME/lib/security/cacerts avec la commande

Code:

---

1 2 3

cd $JAVA_HOME/lib/security/cacerts keytool -import -keystore cacerts -file server_name.crt

---

la password par défaut est: Changeit

et voilà la connexion et rétabli, l'exception à disparu.


En local j'ai la même aplication que celle du serveur App_B (ou tester avec SoapUI), mais je n'ai pas eu besoin d'ajouter le certificat au truststore de java.

Je crois comprendre que mon application(mon client en local), lui ne sollicite pas une authentification de la part du serveur.

Tout le problème est là.

Est-ce possible qu'un client demande une authentification ou c'est le fait d'avoir une entré dans le truststore de java qui implique que la communication entre les deux machine est le même certificat(clé publique).

Merci par avance.

Bonjour,

Apparemment, il s'agit du premier cas de figure décrit ici. Pour visualiser le déroulement de l'authentification dans le fichier log, vous pouvez ajouter l'instruction

Citation:

---

-Djavax.net.debug=ssl:handshake

---

à la configuration de la JVM qui tourne en local.

Merci pour votre réponse,

Ce que je ne comprend toujours pas , c'est qu'il me manque toujours un maillon en local pour que je puisse dialoguer avec le serveur en https, en local je n 'ai pas ajouter le certificat au truststore et pourtant je n'ai pas d'exception.

J'ai ajouté

Code:

---

-Djavax.net.debug=ssl:handshake

---

je ne par pas de https donc je ne me identifie pas, je ne vérifie pas le certifica du serveur, alors que ceux qui parte de ssl, eux demande à identifier le serveur, je me trompe?

C'est beau comme interface utilisateur, un grand merci!

Veuillez m'en excuser @Snyper ...

Si je comprends bien, votre authentification via certificats ne passe pas par le protocole https? Comment est-ce possible?
Avez vous bien lu le fichier log après l'exécution de l'application? Ca fait un certain temps que je n'ai plus essayé ce truc
mais normalement il devrait y avoir des "server says ceci et cela" et de(s) affichages de(s) certificat(s) et toute une cohorte
d'informations échangées entre le serveur et le client...

Mais si je suis dans un cap ou en local je suis tout simplement en http, ma requête soap part vers de l'https, si je comprend bien l’authentification mutuelle ne fonctionne pas dans ce cas?


Client et serveur s'authentifie mutuelle que si nous somme dans un cas de https <=> https?


Merci par avance.

Citation:

---

Envoyé par Snyper

Mais si je suis dans un cap ou en local je suis tout simplement en http, ma requête soap part vers de l'https, si je comprend bien l’authentification mutuelle ne fonctionne pas dans ce cas?

---

J'ignore comment les deux applications sont conçues mais je ne vois pas l'intérêt de sécuriser juste un bout de la connexion s'il y a un transfert de données.

Citation:

---

Envoyé par Snyper

Client et serveur s'authentifie mutuelle que si nous somme dans un cas de https <=> https?

---

En tout cas, c'est comme ça que je l'ai fait car pas trop le choix: une application "client" devait se connecter à une application "entreprise". Il y avait authentification
par login et mot de passe (crypté) mais je me suis dit que ça ne sert à rien de crypter le mot de passe pour l'envoyer par la suite "en clair" sur le réseau lors de
l'authentification ou dans l'en-tête d'une requête HTTP POST.

Tout dépend des besoins des applications mais je dirais qu'une connexion sécurisée d'un bout à l'autre n'est pas du luxe.

Très bien merci pour votre réponse.

Alors je vais sécurisé mon aplication en local, éditer un virtualHost sur le port 443 puis faire un proxy reverse qui pointe sur le server jetty.

Je vais faire c'est manipulation ensuite je reviendrais pour faire par des résultats.

Merci.