Rappels sur les certificats
Les certficats sont des composants essentiels aux infrastructures informatiques de confiance car il servent soit pour authentifier des services ou soit pour établir une communication chiffrée. On parle souvent de cycle de vie d'un certificat SSL, depuis sa création jusqu'à sa révocation.
Introduction
Principe de fonctionnement, quelques concepts et définitions
- La cryptographie :
La cryptographie permet de de chiffrer une information en clair au moyen d'une clé. Le fait de détenir cette clé permet de déchiffrer l'information. La cryptographie peut être symétrique (1 clé) ou asymétrique (1 clé publique distribuable et 1 clé privée non distribuable).
La cryptographie asymétrique sé gère souvent par une infrastructure de clés, IGC ou Public Key Infrastructure (PKI).
Dans notre cas de cahier de laboratoire électronique, il est possible :
- soit d'auto-générer toute la chaîne de certification (y compris la CA) pour la communication sécurisée entre les machines virtuelles eLabFTW et MysQL; ce sera le cas des TPs sur la mise en place desmachines virtuelles;
- ou soit de faire générer la CA par une autorité de cratification reconnue (SECTIGO, DIGICERT, HARICA);
- ou soit d'utiliser son infrastructure interne de certificats PKI.
- L'infrastructure de certificats (PKI)
Une infrastructure à clés publiques (PKI) permet d'établir la confiance sur des infrastructures informatiques et comporte plusieurs éléments :
1. une autorité de Certification ou Certificate Authority (CA) qui est une entité qui signe et qui valide les certificats;
2. un certificat serveur qui est installé pour une application ou serveur en identifiant le serveur et permettant le chiffrement TLS;
3. un certificat client (optionnel mais recommandé pour l’authentification mutuelle) qui est installé sur l’application frontale.
4. une chaîne de confiance constituée des certificats serveur et client qui sont signés par la même CA.
Dans notre cas du CLE,
il est possible soit de s'adresser à une infrastructure de clés (SECTIGO, DIGICERT, HARICA) et CA ou soit de créer une CA interne avec des tunnels chiffrés entre l'application frontend eLabFTW et la baes de données MySQL. IL s'agit de créer un niveau et une zone de confiance. Le certificat venant d'une infrastructure de clés est authentique car il devient non falsifiable. En revanche, si le certificat auto-signé alors il est non vérifiable. Le client eLabFTW sait vraiment qu’il parle au bon serveur de base de données MySQL. Mais les certificats peuvent être également différents pour chaque service (client/serveur). Le frontend eLabFTW et la base de données font confiance à la même CA. Le client eLabFTW reçoit le certificat de la CA (ca-cert.pem ou .crt), et pas celui du serveur de la base de données.
- Un certifictat TLS/SSL :
La fonction de base d'un certificat est de distribuer une clé publique. Un certificat contient 2 informations : 1 clé publique à distribuer et son nom associé FQDN reposant sur ce certificat.
SSL (Secure Sockets Layer) est un protocole de chiffrement des sessions TCP. Le client récupère la clé publique du service ou de l'application communiquant en SSL. Une fois récupérée cela va servir pour chiffrer une communication avec le service SSL; c'est le principe de la crypto asymétrique. La clé publique sert uniquement à chiffrer un échange afin d'obtenir une clé pour la session.
Selon DIGICERT,
- les certificats SSL, aussi appelés certificats numériques, établissent une connexion chiffrée entre un navigateur ou l'ordinateur d'un utilisateur et un serveur ou un site web.
- le SSL est une technologie standard de sécurisation des connexions Internet par le chiffrement des données transitant entre un navigateur et un site web (ou entre deux serveurs). Pendant le transfert les données sont ainsi protégées des hackers qui ne peuvent ni les voir ni les détourner.
- le TLS (Transport Layer Security) est un terme associé car étant une version plus récente et plus sécurisée du SSL.
- Lorsqu'un site web est sécurisé par un certificat TLS/SSL, son URL commence par la mention HTTPS (preprésenté par le cadenas dans la barre d'adresse du navigateur).
Dans notre cas du CLE, nous allons certifier le serveur MySQL afin de communiquer avec lui en HTTPS (HTTP sur SSL).
- Un certificat X.509 et sa finalité :
C'est un format standard pour les certificats numériques et utilisé souvent dans les infrastructures à clé publique. Les certificats X.509 possèdent une structure hiérarchique : une autorité de certification racine qui émet des certificats aux autorités de certification intermédiaires et qui peuvent émettent également des certificats à des entités finales. Les certificats X.509 contiennent divers champs comme le nom de l’objet ou de l’émetteur, la période de validité, la clé publique.
Un certificat est normalisé par X.509 ou est un document numérique normalisé (selon la norme ITU-T X.509) permettant de lier une identité comme un nom de domaine ou une organisation/personne à une clé publique.
Le principe est que le certificat contient la clé publique, le propriétaire garde et ne commuique jamais la clé privée et secrète. La CA signe le certificat avec sa propre clé privée et les clients vérifient cette signature avec la clé publique de la CA.
Un certificat X.509 sert à sécuriser des communications par : - le chiffrement qui permet d'établir une connexion chiffrée (SSL/TLS), comme par exemple avec HTTPS, des connexions chiffrées entre services ou serveurs; - l'authentification permettant d'identifier de manière sûre; dans le cas du CLE, l'accès aux services eLabFTW et MySQL se font de façon sûre; - et par la signature numérique qui permet de vérifier la non altération des données et donc leur intégrité.
Les certificats X.509 utilisent généralement plusieurs types d’algorithmes :
- des clés asymétriques (clé publique/privée) : signature et authentification (courbes elliptiques, RSA, ...))
- des fonctions de hachage : vérification d’intégrité du certificat (SHA-256, ...)
- des clés symétriques (sessions TLS) : chiffrement des données lors des échanges (AES, ...).
- Une infrastructure de clés :
Les différents éléments et composants d'un certificat x509:
Version : version du standard (actuellement v3)
Numéro de série : identifiant unique du certificat
Sujet (Subject) : l’entité d'appartenance du certificat (exemple CN=cle.univ.com)
Émetteur (Issuer): l’autorité de certification (CA) qui a signé le certificat (exemple SECTIGO)
Clé publique (Public Key): la clé utilisée pour le chiffrement ou la vérification de signature (RSA 2048 bits)
Période de validité : date de début et date d’expiration (exemple 2025-12-04 à 2026-12-03)
Extensions X.509v3 : des champs additionnels comme les noms alternatifs,...
Signature : signature numérique de l’autorité de certification sur le contenu (exemple SHA25 6with RSA)
Un point de situation avec Let's Encrypt (non recommandé)
Let's Encrypt est une Autorité de Certification (CA) qui a ouvert son service au grand public en avril 2016. Depuis il a rendu de nombreux services et la part du traffic web n'a cessé d'augmenter pour plus de 90% du traffic total entre 2016 et 2022.
Cependant, face à la facilité d'obention de certificats TLS, des menaces de cyberattaques existent sur la confidentialité et l'intégrité des données. C'est pour cela qu'il fortement recommandé d'utiliser soit propre autorité de certification PKI, ou alors de faire à une autorité de certfication reconnue.