Certificat SSL
Introduction
Pour ce post je vais vous partager ce qui s'est produit assez récemment sur une de nos applications web dont nous avons la charge.
Contexte
J'etais en charge d'une application web permettant à des systèmes de mesure de remonter des données de monitoring. par exemple un statut d'état de fonctionnement du système. Cette connexion devant être sécurisée elle passe par une connection HTTPS.
Cela signifie que le serveur web doit avoir ce que l'on appelle un certificat SSL.
Qu'est ce qu'un certificat SSL si je reprends la definition fournie par digicert:
Les certificats Secure Sockets Layer (SSL), appelés parfois certificats numériques, sont utilisés pour établir une connexion cryptée entre le navigateur ou l'ordinateur d'un utilisateur et un serveur ou un site Internet. La connexion SSL empêche les données sensibles échangées lors de chaque visite, appelée session, comme les informations de carte de crédit, d'être interceptées par des parties non autorisées.
Les certificats SSL sont visibles lorsque l'on clique sur le cadenas de sécurité présent dans votre navigateur lorsque l'on visite un site https.
Lorsque l'on veut mettre en place un certificat sur un site nous enregistrons notre nom de domaine auprés de fournisseurs SSL étant capables de nous fournir ce cerificat (let's encrypte, GeoTrust,Digicert,GlobalSign,Entrust Datacard,GoDaddy,RapidSSL,SSL.com)
Ce qu'il faut savoir aussi et que j'ai appris durant le probléme c'est que ces fournisseurs utilisent deux types de certificat pour pouvoir générer notre certificat:
Certificat root :
Pour résumer les certificats root permettent d'authentifier les CA (certificate authority) qui sont les autorités autorisées à émettre des certificats SSL (GlobalSign, Comodo, Geotrust…). Sans ces certificats les navigateurs n'auraient aucune manière de vérifier la validité du certificat.
Pour les internautes ce fonctionnement est totalement transparent et pris en charge par le navigateur
Certificat intermédiaire :
Vous avez donc compris que le certificat root est essentiel puisqu'il permet d'identifier l'organisme ayant certifier le site. Si jamais ce certificat root est compromis cela veut dire que tous les sites certifiés par l'organisme sont donc compromis. Pour éviter cela les certificats root ne sont pas utilisés pour signer les certificats mais les certificats intermédiaires.
Le problème rencontré:
Nous utilisons let's encrypte comme certificat authority et ce qu'il s'est passé est que courant septembre let's encrypte a modifié son certificat root :
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
Ce changement est assez transparent pour les utilisations standard de site web et en effet aucun de nos clients n'a rencontré de problème de connexion sur notre site. Par contre ce qui est indiqué à la fin du post de let's encrypt c'est que pour les clients qui utilisent le certificat via une API il faut utiliser la librairie OpenSSL, en version 1.1.0 ou supérieure. Et donc ce changement anodin a eu un impact dévastateur puisque toute notre flotte de système (environ 1500) utilise une version d'openssl inférieure à 1.1.0 donc suite au changement de certificat root plus aucune connexion de système.
Comment a-t-on solutionné le problème
Notre première idée la plus simple était de mettre à jour OpenSSL sur notre flotte. Mais bon problème majeur comme vous pouvez l'imaginer la mise à jour de 1500 systèmes ne se fait pas du jour au lendemain et en attendant nos systèmes ne sont plus opérationnels ce qui n'est donc pas imaginable. Il faut donc travailler sur le certificat.
Let's encrytpe solution
En regardant de plus prés la documentation de let's encrypt nous nous sommes aperçus de la mise à disposition de deux certificats root: le R3 qui vient de changer mais aussi de E1 qui est plus limité mais permet de garder l'ancien fonctionnement parfait pour notre cas. Il ne reste plus qu'a générer une certification en utilisant ECDSA et non RSA.
Certbot update
Pour automatiser la génération de nos certificats nous utilisons le logiciel certbot. En regardant de plus près la documentation de certbot nous nous sommes aperçus d'une nouvelle option disponible depuis la version 1.10 --key-type qui permet de faire le choix entre RSA et ECDSA*. Malheureusement pour nous nos serveurs utilisent une version inférieure de certbot. Il suffit donc de mettre à jour certbot d'ajouter le paramètre et le tour est joué.
Dernier problème.
Pour la mise à jour de certbot une nouvelle difficulté arrive. La version 1.10 n'est distribuée qu'en passant par une installation snap. Mais notre serveur trop ancien n'accepte pas l'installation de l'outil snap; nous sommes donc bloqués et tous nos systèmes toujours bloqués.
Docker le sauveur. Nous avons docker tournant sur nos serveurs et nous avons réussi à trouver un container certbot à jour. La génération du certificat peut donc se faire au travers de ce docker en indiquant les paramètres de certbot. Et voilà après la génération de ce nouveau certificat nos systèmes arrivent enfin à se connecter au serveur central.
Ce que l'on a appris de ce problème.
1- Faire une meilleure veille. Nous avons subi les conséquences de ce changement alors que let's encrypter avait communiqué en avance sur ce changement .
2- Mettre à jour les systèmes plus régulièrement. Le fond du problème c'est que nos systèmes ne sont pas à jour; il faut donc prévoir un plan de mise à jour pour éviter d'avoir à subir des obsolescences.
3-La force de docker. La solution est donc venue d'un conteneur docker ce qui nous a grandement aidé. Docker est devenu un indispensable dans la vie de tous les jours. Un prochain poste sur docker verra prochainement le jour.
4- Une super re-activité de l’équipe. Nous avons eu un downtime à cause de ce problème d’environ 4 heures; ce qui au vue des difficultés rencontrées est un petit miracle donc un grand merci à eux.
Lien
Si vous souhaitez approfondir le sujet sur les certificat voici des liens que je troube interessant