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 :
- Génération de clefs sur le serveur, fichier ".key", contient la clef privée, à protéger sur le serveur, ne pas le communiquer.
- Génération d'une demande de certificat, fichier ".csr", à transmettre à l'autorité de certification.
- 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 :
- openssl genrsa -des3 -out NomDeLaClef.key 2048
- 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 :
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 :
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 :
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 :
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.
Concernant la "Communication SSL avec Java", en complément de ce billet je vous propose ce document :
[Outil] Récupération de certificat SSL et inscription dans le magasin des certificats
Alerte de sécurité concernant SSL découverte le 8 avril 2014 :
Heartbleed
ou "CVE-2014-0160"http://heartbleed.com/
Renseignez-vous afin de vérifier la sécurité de vos systèmes informatiques et les corriger le cas échéant.
Bonjour Ronan,
Pour être au top, il va être temps de parler TLS (plutôt que SSL) et de dire "chiffrer" à la place de "crypter"
Pour finir de pinailler, on aurait pu dire que même avec openSSL, on n'est pas obligé de passer par une CA externe.
Enfin, pour vérifier la vulnérabilité de ses serveurs web à heartbleed si on a la flemme de rechercher sa version de openSSL (attention, il n'y a pas que le serveurs webs qui sont vulnérables) : http://filippo.io/Heartbleed/
Bonjour Ronan,
Pour rappel, la vuln est relative à un dépassement mémoire permettant de récupérer dans un shunk de 64k ce qui est en mémoire à ce moment là sur le composant concerné login et mdp bien sûr mais aussi certificat clefs publiques et privéees.
donc la logique consiste à tester, patcher, tester à nouveau puis changer login/mdp et certificats avec leurs clefs privées.
Pour aller dans le sens du précédent post de Laurent, la terminologie devient plus importante aujourd hui qu'avant et la précision est souvent indispensable: SSL vs TLS v1.1 vs 1.2 vs 1.3 Une autre vul "SSL beast" révèle en effet des vulnérabilités sur les ciphers (par block) à ne pas/plus utiliser. Il serait bon d'avoir des préconisations de la part de Jalios sur le volet sécurité quand des composants de son packaging sont potentiellement vulnérable.(ce qui commence à être partiellement fait avec les alertes sécu).
bien sur Jcms n'est pas nécessairement concerné lorsque cela se fait depuis l'exterieur (où un LB ou proxy va "gérer" le point), mais une attention plus particulière devra être apportée sur le volet interne; et là jalios pourrait faire des reco.
Je pense qu'il serait bien que Jalios publie la liste et versions des packages opensource utilisés, pour chacune des versions produit.
Comme nous l'indiquons en introduction :
Il est donc normal que nous n'entrons pas dans les détails.
Pour répondre point par point à vos remarques :
SSL/TLS
pour éviter la confusion.Merci Laurent Marot et Philippe Provost pour vos remarques.
Information :
Google (Chrome) a décidé de considérer que les sites dont le certificat est encrypté avec l'algorithme
SHA-1
ne seront plus suffisemment de confiance à partir de janvier 2017. (source : http://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html )Si vous disposez d'un certificat encrypté avec SHA-1, et valide jusqu'à une date en 2017 ou ultérieur, alors la dernière version de Chrome (41) retourne une alerte (un avertissement mineur est déjà affiché depuis la version 39 de Chrome).
Les navigateurs étant de plus en plus strict sur la sécurité, si vous souhaitez utiliser un certificat autosigné pour vos test, assurez vous de le générer en suivant la procédure comme s'il s'agissait d'un site de production.
Créez votre certificat racine puis générez vos certificats de tests via le fichier 'csr' que vous certifiez via votre certificat racine autosigné. Pour être valide, le niveau de chiffrement doit être
sha256
et le certificat doit définir lessubjectAltName
correspondant au nom DNS du site.Enfin, enregistrez votre certificat racine dans les autorités de confiance de votre système et de votre navigateur.
Exemples de procédures à combiner :
Sécurité des communications SSL
Apache préconise (ainsi que d'autres acteurs) qu'à partir de fin 2016 seules les communications en TLS 1.2 soient utilisées (où plus récent mais le TLS 1.3 n'est actuellement pas encore proposé). Que les protocoles précédents soient refusés.
Les navigateurs récents supportent tous ce protocole, ainsi la communication est généralement correctement sécurisée, ce n'est en revanche pas le cas des applications .net 4.0, c'est pourquoi nous sortons désormais nos nouvelles application en compatibilité .net 4.5.
Ainsi vous pourrez désormais configurer vos serveurs en mode "TLS 1.2 Only".
Exemple extrait de la configuration d'Apache 2.4 :
Petite veille autour de SSL/TLS qui peut expliquer pourquoi un certificat "officiel" peut être rejeté par Chrome :
Bonjour,
OpenSSL a sorti sa version 1.1.1 (version LTS : Long term Support, donc avec un support au moins pendant les 5 prochaines années) : https://www.openssl.org/blog/blog/2018/09/11/release111/
Cette version OpenSLL 1.1.1 permet de faire du TLS 1.3
Merci, c'est effectivement une bonne nouvelle, reste encore quelque temps avant que tous les acteurs se mettent à jour pour proposer la version TLS 1.3 officielle et rendre ce protocole utilisable, à défaut fallback vers TLS 1.2.