Intégration de certificat Digicert

Bonjour,
je me permets de vous solliciter après avoir passé trois jours à me casser les dents sur un problème d'intégration de certificat Digicert dans le keystore de mon GlassFish.
Je précise que je débute en Java EE et GlassFish.
J'ai réussi à installer un serveur GlassFish 5 sur un Ubuntu 16.04 sans trop de problème. Ce dernier fonctionne parfaitement dans sa configuration d'origine. Je peux accéder à la console d'administration des domaines que je crée depuis l'extérieur via https. Là, je me rends compte que Glassfish utilise un certificat auto-signé, ce qui en soit est parfaitement normal. Cependant, mon navigateur Firefox ne me permettant plus d'enregistrer les exception de sécurité m'oblige à revalider l'exception levée par ce certificat à chaque nouvelle visite, ce qui est très pénible. Du coup, possédant plusieurs certificats SSL Classe 1, je me suis dits tiens, si je mettais mon certificat Digicert obtenu gratuitement auprès de mon fournisseur de nom One&One ? En effet, j'ai déjà mis en place ce certificat sur mon serveur Apache pour son protocole https, donc je dois aussi pouvoir l'utiliser avec GlassFish.
C'est là que ça se corse. Je n'ai pas trouvé le moyen d'intégrer ce certificat avec GlassFish.
D'après ce que j'ai compris, dans l'absolu, il me suffirait d'intégrer ma clé privée, mon certificat signé et mon certificat intermédiaire dans keystore.jks et cacerts.jks, mais je n'ai pas compris qui mettre dans keystore et qui mettre dans cacerts, et encore moins comment. Tous les exemples d'intégration que j'ai trouvé sur Internet concerne d'autre certificats qui ne se présentent pas avec le même jeu de fichiers, ils parlent de fichier CA, de fichier .p7b alors que moi j'ai un fichier .key et deux fichier .cer ?!
Bref, si quelqu'un parmi vous maîtrise bien cet aspect de Glassfish, je suis preneur de toutes explications qui me permettraient de réussir cette intégration.
Je précise aussi que mon interface One&One qui me permet de récupérer les fichiers de ce certificat me permet aussi de produire un fichier .pfx, mais je ne sais pas quoi en faire.
S'il vous faut plus de précision sur la nature exacte du certificat, je peux vous en communiquer tous les détails, mais je ne les ai pas encore récupéré pour l'instant.

4 pièce(s) jointe(s)

Solution trouvée !

Bon, j'ai enfin trouvé la solution pour intégrer mon certificat Digicert dans le keystore de Glassfish.
Si cela peut intéresser ceux qui m'ont lu, voilà une recette complète sur un domaine de test :

Première étape, en ligne de commande sur le serveur Glassfish via la commande asadmin, création d'un domaine Glassfish de test :

Code:

./asadmin --host nomDNS.du.serveur create-domain --admin_port xxxx DomainSSLTEST

Remplacez nomDNS.du.serveur par le nom DNS de votre serveur, et remplacez xxxx par le numéro de port de votre choix. Pour la suite des explications, je le fixe à 83.
Un nouveau domaine Glassfish nommé DomainSSLTEST est alors créé. Avant de mettre en place les éléments SSL, il nous faut positionner un mot de passe pour notre utilisateur admin, et activer l'usage de la sécurité SSL pour forcer l'accès à la console d'administration via HTTPS. C'est indispensable si l'on veut accéder à la console d'administration de notre serveur depuis Internet.
Procédons ainsi :
Code:

1 2 3 4 ./asadmin --host nomDNS.du.serveur start-domain DomainSSLTEST ./asadmin change-admin-password --domain_name DomainSSLTEST ./asadmin --host nomDNS.du.serveur --port 83 enable-secure-admin ./asadmin stop-domain DomainSSLTEST
ATTENTION ! Si vous avez opté pour un autre port lors de la création du domaine DomainSSLTEST, adaptez la valeur.
Dans cet exemple, j'ai conservé le nom de l'administrateur par défaut, admin.

Nous pouvons maintenant démarrer notre domaine dont la console d'administration sera alors accessible via HTTPS :

Code:

./asadmin --host nomDNS.du.serveur start-domain DomainSSLTEST

Nous sommes alors sensés obtenir le retour suivant :
Code:

1 2 3 4 5 6 Waiting for DomainSSLTEST to start ... Successfully started the domain : DomainSSLTEST domain Location: /usr/share/glassfish5/glassfish/domains/DomainSSLTEST Log File: /usr/share/glassfish5/glassfish/domains/DomainSSLTEST/logs/server.log Admin Port: 83 Command start-domain executed successfully.
On va maintenant se connecter à la console d'administration via l'URL : https://nomDNS.du.serveur:83

Pièce jointe 351746

J'ai mis en évidence ce qui a fait l'objet de ce post. On remarque effectivement que le certificat SSL utilisé par Glassfish est un certificat auto-signé, et comme je l'ai dit, ce n'est pas une critique, c'est normal. Mais, pour les raisons que je précise au début, je voulais remplacer ce certificat auto-signé par un "vrai" certificat, parfaitement vérifiable sur Internet. Pour ce faire, j'ai exploité un service fourni par mon hébergeur de nom DNS qui propose la création d'un certificat SSL Digicert gratuit. J'ai alors sauté sur l'occasion, et créé ce certificat en prenant soin de l'associer à nomDNS.du.serveur. A l'issu de la démarche réalisée sur l'interface de mon fournisseur de nom DNS, j'ai récupéré plusieurs fichiers, mais seuls deux d'entre-eux nous seront utiles :
nomDNS.du.serveur_ssl_certificate.cer
et
nomDNS.du.serveur_private_key.pfx
J'ai placé ces fichiers dans le dossier config du domaine DomainSSLTEST pour des raisons pratique, à l'issue, ils pourront être supprimés ou déplacés :

Code:

%glassfishHome%/glassfish/domains/DomainSSLTEST/config

Maintenant, on se place dans ce dossier config pour réaliser une suite de manipulations keytool qui vont nous permettre d'intégrer notre certificat et notre clé privée dans les magasins respectifs de certificats et de clés de glassfish, représentés respectivement par les fichiers cacerts.jks et keystore.jks.
Une précision sur l'outil keytool s'impose. En effet, dans mon cas, je travaille avec openjdk version "1.8.0_151", et il s'avère que ce dernier souffre d'un Bug pour ce qui concerne son outil keytool. Un Bug qui concerne la gestion charset et aboutit sans contremesure à une erreur de type MalformedString qui empêchera l'intégration de notre certificat. Pour contourner ce bug, il m'a fallu ajouter un paramètre particulier qui n'est pas forcément nécessaire dans tous les cas. Il s'agit du paramètre définissant la langue de l'environnement utilisateur. En effet, par défaut, keytool s'appuie sur la langue hôte alors qu'il faudrait s'appuyer sur la langue anglaise. Je dois donc ajouter le paramètre :

Code:

-J-Duser.language=en

dans la première des commandes keytool d'intégration du certificat et de la clé privée suivantes :
Code:

1 2 3 4 5 6 7 8 Import du certificat dans le fichier cacerts.jks de Glassfish keytool -J-Duser.language=en -import -trustcacerts -file nomDNS.du.serveur_ssl_certificate.cer -alias nomDNS.du.serveur -keystore cacerts.jks Import de la clé privée dans le fichier keystore.jks de Glassfish keytool -importkeystore -srckeystore nomDNS.du.serveur_private_key.pfx -srcstoretype pkcs12 -srcalias nomDNS.du.serveur -destkeystore keystore.jks -deststoretype jks -destalias nomDNS.du.serveur Il est nécessaire de redéfinir le format de notre keystore en pkcs12 keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12
Si comme moi, vous n'avez pas modifié le mot de passe du fichier keystore.jks, et que losrque vous avez récupéré le fichier pfx vous avez définit un autre mot de passe, la dernière commande de cette série n'aboutira pas et indiquera dans son message d'erreur cette différence de mot de passe. Il suffit alors d'ajouter à cette commande le paramètre :
Code:

1 2 3 4 -destkeypass m.d.p.DuKeyStore ce qui donne keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12 -destkeypass m.d.p.DuKeyStore
La dernière étape consiste à redémarrer le serveur depuis la console d'administration.
Pour l'instant, rien ne devrait avoir changé, le serveur utilise toujours le certificat auto-signé, mais il possède maintenant dans ses magasins un nouveau certificat dont l'alias est nomDNS.du.serveur. Pour tester le fonctionnement de ce nouveau certificat sans prendre le risque de perdre l'accès à notre console d'administration, nous allons modifier la configuration SSL de notre http-listener-2 comme le montre la figure suivante :

Pièce jointe 351771

Une fois cette modification en place, il ne reste plus qu'à redémarrer une dernière fois notre serveur. Rien n'a encore changé pour ce qui concerne la console d'administration qui continue d'utiliser le certificat auto-signé. Par contre, si tout c'est bien passé, en se rendant sur l'url de http-listener-2, on constate ce qui suit :

Pièce jointe 351788

Si vous voulez propager l'utilisation du certificat sur la console d'administration, il suffit d'éffectuer exacement la même modification sur le http-listeners nommé "admin-listener" et redémarrer le serveur. Vous obtiendrez alors :

Pièce jointe 351793

Configuration digicert sous glassfish

bonjour,

je suis là sur glassfish 5 sous windows server, en suivant vos instructions j'ai deux problèmes:

1/ asadmin --host DNS --port 82 enable-secure-admin

=> le https n'est pas en marche :calim2:

2/keytool -importkeystore -srckeystore dnsfilename.pem -srcstoretype pkcs12 -srcalias DNS -destkeystore keystore.jks -deststoretype jks -destalias DNS

=> j'ai renseigné le mdp destination, changeit, et le mot de passe source , de ma clé , mais ça affiche le msg d'erreur :
erreur keytool : java.io.IOException: toDerInputStream rejects tag type 45 :roll:

pourriez vous m'aider SVP.

Port 80 répond en HTTP

Bonjour,

J'ai suivi votre tuto, et cela marche sauf que le port 80 répond en http.
Comment redirigez les connexion http sur le listener-2 qui répond en https?