La mise en place d'un certificat SSL/TLS n'est pas toujours si facile, que ce soit pour sécuriser l'accès à votre site ou pour faire communiquer votre serveur avec un autre de manière sécurisée...

Au service professionnel de Jalios, nous sommes souvent confronté à des questions de diverses natures concernant le SSL/TLS, et par divers profils (développeurs, services informatiques, chefs de projet, etc)

Voici une petite présentation sur les usages que l'on rencontre le plus fréquemment afin de permettre au plus grand nombre d'entre vous de s'y retrouver. Pour aller plus loin sur un sujet précis il existe de nombreuses documentations très complètes et des tutoriels que vous pouvez trouver sur le web. Vous pouvez aussi bien évidemment nous commander une prestation.

Voici les points que nous allons aborder :

• Génération d'un certificat
• Installation du certificat sur un serveur
• Le certificat côté client
• Usages et contraintes

Génération d'un certificat

Pour le développement local ou pour les tests

Dans ce cas, le plus simple est de générer un certificat auto-signé puis de l'enregistrer comme certificat de confiance dans son ordinateur.

De nombreux tutoriels existent sur le web, l'outil 'openssl' est souvent cité mais en son absence sachez que le JDK contient l'outil 'Keytool' qui permet aussi d'en générer simplement.

C:> cd jdk/bin
C:\jdk\bin> keytool.exe -genkey -alias tomcat -keyalg RSA -keystore "C:\tomcat\conf\tomcat-keystore"
  Tapez le mot de passe du Keystore :  changeit
  Ressaisissez le nouveau mot de passe : changeit
  Quels sont vos prénom et nom ?
    [Unknown] :  test.jalios.net
  Quel est le nom de votre unité organisationnelle ?
    [Unknown] :  Test
  Quelle est le nom de votre organisation ?
    [Unknown] :  Jalios
  Quel est le nom de votre ville de résidence ?
    [Unknown] :  Le Chesnay
  Quel est le nom de votre état ou province ?
    [Unknown] :  Yvelines
  Quel est le code de pays à deux lettres pour cette unité ?
    [Unknown] :  33
  Est-ce CN=test.jalios.net, OU=Test, O=Jalios, L=Le Chesnay, ST=Yvelines, C=33 ?
    [non] :  oui
  
  Spécifiez le mot de passe de la clé pour <tomcat>
          (appuyez sur Entrée s'il s'agit du mot de passe du Keystore) :

C:\jdk\bin> keytool.exe -export -alias tomcat -file "C:\tomcat\conf\tomcat-cert.crt" -keystore "C:\tomcat\conf\tomcat-keystore"
  Tapez le mot de passe du Keystore :  changeit
  Certificat enregistré dans le fichier <C:\tomcat\conf\tomcat-cert.crt>

 Si vous ne précisez pas le paramètre "keystore" le fichier par défaut se nomme ".keystore" à la racine de votre dossier utilisateur.

Pour la production

Dans le cas de la mise en place d'un SSL/TLS en production, la procédure est la suivante :

1. Génération de clefs sur le serveur, fichier ".key", contient la clef privée, à protéger sur le serveur, ne pas le communiquer.
2. Génération d'une demande de certificat, fichier ".csr", à transmettre à l'autorité de certification.
3. Génération du certificat par l'autorité de certification, fichier ".crt", c'est le certificat public.

Dans ce cas de figure vous utiliserez très certainement 'openssl'. Exemple d'utilisation :

1. openssl genrsa -des3 -out NomDeLaClef.key 2048
2. openssl req -new -key NomDeLaClef.key -out NomDeLaClef.csr

Si vous spécifiez une 'passphrase' pour sécuriser la clef, son utilisation sera plus complexe.

Informations complémentaires pour les utilisateurs Windows :

• Tutoriel d'installation d'openssl sous Windows 
• Téléchargement d'openssl pour Windows

Installation serveur

https par Apache

Dans la configuration d'apache :

• Installez/Activez le module ssl
• configurez le module pour utiliser le certificat souhaité (en fonction de votre serveur en configuration par défaut ou au sein d'un virtualhost)
• "Listen 443", "SSLEngine on", "SSLCertificateFile ...", "SSLCertificateKeyFile ..."
• Si votre clef est sécurisée par une passphrase ajoutez un script pour la renseigner automatiquement et pointez ce script via la directive "SSLPassPhraseDialog"

Pour plus de détails :

• Documentation SSL d'Apache

https par Tomcat

Cette configuration n'est pas celle recommandée, il vaut mieux passer par le protocole AJP et traiter le ssl sur le frontal. 

Si vous avez utilisé la procédure de génération de clef auto-signée avec Keytool vous disposez alors d'un fichier keystore contenant votre certificat, vous pouvez alors simplement configurer votre connecteur ainsi :

    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS" 
               keystoreFile="C:\tomcat\conf\tomcat-keystore"
               keystorePass="changeit" 
               URIEncoding="UTF-8"
               />

Par défaut Tomcat propose d'utiliser les ports http-8080 et https-8443, vous pouvez le configurer différemment (80 et 443) si vous rencontrez des problèmes ou si vous souhaitez vous rapprocher de la configuration de prod, N'oubliez pas de mettre à jour le paramètre "redirectPort" sur les connecteurs non-SSL.

Pour plus de détails :

• Documentation SSL de Tomcat

Installation client

Communication SSL/TLS avec Java

Lorsqu'une application Java (comme JCMS) communique avec un autre serveur via un canal sécurisé, si le certificat n'est pas autorisé par les autorités certifiées dans la JVM, alors la communication échoue. Dans ce cas, pour que la communication chiffrée avec le certificat soit autorisée dans l'application, il faut enregistrer le certificat (ou celui d'une autorité l'autorisant) dans l’entrepôt des clefs de sécurité de Java (appelé "cacerts").

Le fichier "cacerts" par défaut contient une liste de certificats racine standard, son mot de passe de protection est "changeit". Par mesure de sécurité l'administrateur devrait changer ce mot de passe et protéger l'écriture du fichier, certains suppriment même les clefs préenregistrées dedans afin de contrôler finement les certificats autorisés.

Afin d'ajouter un certificat "serverCert.crt" dans l'entrepôt, commencez par vérifier que la variable d'environnement "JAVA_HOME" pointe bien sur votre JDK servant à exécuter Tomcat, puis exécutez la commande suivante (en adaptant les paramètres "alias" et "file") :

• Windows : %JAVA_HOME%\bin\keytool.exe -import -alias serverCert -file serverCert.crt -keystore %JAVA_HOME%/jre/lib/security/cacerts
• Linux/Unix : $JAVA_HOME/bin/keytool -import -alias serverCert -file serverCert.crt -keystore $JAVA_HOME/jre/lib/security/cacerts

Vous pouvez vérifier la liste des certificats par la commande suivante :

• Windows : %JAVA_HOME%\bin\keytool.exe -list -keystore %JAVA_HOME%/jre/lib/security/cacerts
• Linux/Unix : $JAVA_HOME/bin/keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts

Pour plus de détails :

• Documentation de KeyTool

Inscription navigateur web

Si vos certificats sont correctement configurés coté serveur et ont été signé par une autorité de certification reconnue par votre navigateur, alors vous n'avez rien à faire, ça doit fonctionner sans aucun avertissement du navigateur.

Dans le cas où vous utilisez un certificat non accepté par votre navigateur il vous faut l'ajouter manuellement dans l'entrepôt local.

Etant donné que la procédure diverge selon le navigateur, l'os, et dans le temps, nous vous recommandons la recherche suivante : https://www.google.fr/search?q=ajouter+un+certificat+dans+le+navigateur

Usages et contraintes

Impact JCMS : L'impact sur JCMS est assez faible, si la configuration n'est pas parfaite les navigateurs récents vous indiquent précisément pourquoi l'accès est refusé. Veillez à ce que la configuration soit bien acceptée par les navigateurs sans quoi une application cliente telle que l'addin-office pourrait ne pas fonctionner correctement sans vous afficher précisément la raison.

Protection des formulaires : Dans JCMS vous avez la possibilité de forcer la soumission en SSL/TLS des formulaires d'authentification. La navigation est transparente, l'url reste en http, mais les formulaires concernés sont soumis sur l'adresse en https. Ceci permet d'éviter que vos mots de passe transitent en clair sur le réseau. Pour activer l'option allez dans les propriétés du site rubrique "accès".

Durée du certificat : N'oubliez pas que le certificat n'est valable que pour une certaine durée, il faut donc le renouveler régulièrement et s'y prendre à l'avance, par exemple déployer un nouveau certificat 2 à 3 semaines avant l'expiration.

Mutualisation de sites : Dans le cas d'un serveur hébergeant plusieurs sites avec un frontal web unique, si les sites ont des domaines divergents et nécessitent donc plusieurs certificats (pas de wildcard possible), alors des problèmes surviendront. En effet le protocole étant chiffré, le frontal fournit par défaut le premier certificat pour chiffrer la transaction. Des solutions existent pour les navigateurs récents (SNI), mais pour être compatible avec tous les navigateurs la seule solution efficace est de disposer d'autant d'adresse IP différente que de certificats à fournir. Pour plus d'informations sur cette problématique : Server Name Indication (wikipédia)

Reverse Proxy & Load Balancer : Dans le cas où un matériel en amont sert de Reverse Proxy ou de Load Balancer, celui-ci ne peut pas lire le contenu de la trame chiffrée.
Si besoin, il est souvent possible de lui fournir la clef privée pour permettre la lecture du contenu, cela est souvent utilisé pour le mode "bridge" du Load Balancer qui doit pouvoir maintenir une session sur un même réplica. 

Iframe : Dans le cas d'utilisation d'iframes, les navigateurs récents effectuent des contrôles de sécurité qui empêchent l'affichage d'un contenu non-SSL dans une page SSL.

Sécurité : Https ajoute de la sécurité mais elle est limitée comme l'indique M.Bortzmeyer dans sa présentation sur la sécurité à ParisWeb.