Un développeur qui configure pour la première fois un certificat TLS avec des options avancées tombe rapidement sur un vocabulaire dense : RSA, ECDSA, OCSP, CAA, souvent présentés côte à côte sans que leur rôle respectif soit clairement distingué. Certains de ces termes désignent des algorithmes de chiffrement, d’autres des mécanismes de vérification totalement indépendants — les confondre mène à des choix de configuration mal justifiés.
Ce glossaire ne revient pas sur l’installation pratique d’un certificat, déjà couverte ailleurs. Il définit chaque terme précisément, avec son impact concret sur un serveur WordPress, pour que ces choix de configuration reposent sur une compréhension réelle plutôt que sur une copie de configuration trouvée en ligne.
RSA, l’algorithme historique
RSA (Rivest-Shamir-Adleman, du nom de ses trois inventeurs) est l’algorithme de cryptographie asymétrique le plus ancien encore largement utilisé pour les certificats TLS. Sa sécurité repose sur la difficulté de factoriser de grands nombres premiers. Pour rester sûre face à la puissance de calcul actuelle, une clé RSA doit être longue : 2048 bits est le minimum recommandé aujourd’hui, 3072 ou 4096 bits pour une marge de sécurité renforcée.
Cette longueur a un coût de performance : chaque poignée de main TLS (handshake) avec une clé RSA de grande taille demande davantage de calcul processeur, un impact mesurable sur un serveur qui gère un volume important de nouvelles connexions chiffrées par seconde.
ECDSA, une sécurité équivalente avec une clé plus courte
ECDSA (Elliptic Curve Digital Signature Algorithm) repose sur les mathématiques des courbes elliptiques plutôt que sur la factorisation de grands nombres. Sa propriété intéressante pour un serveur en production : une clé ECDSA de 256 bits offre un niveau de sécurité comparable à une clé RSA de 3072 bits, tout en étant nettement plus rapide à traiter lors du handshake TLS.
RSA et ECDSA ne sont donc pas deux niveaux de sécurité différents, l’un « meilleur » que l’autre : ce sont deux familles d’algorithmes aux propriétés mathématiques distinctes, ECDSA étant simplement plus efficace en termes de rapport performance/sécurité sur les serveurs modernes. Certbot permet de générer un certificat ECDSA explicitement avec l’option --key-type ecdsa, à condition que l’autorité de certification choisie le supporte, ce qui est désormais le cas de Let’s Encrypt.
OCSP, vérifier qu’un certificat n’a pas été révoqué
Le protocole OCSP (Online Certificate Status Protocol) répond à une question distincte de celle du chiffrement lui-même : un certificat, une fois émis, peut-il avoir été révoqué entre-temps par son autorité de certification, par exemple parce que sa clé privée a fuité ? OCSP permet à un client (ou, en pratique, plus souvent au serveur lui-même via le mécanisme dit d’OCSP stapling) de vérifier ce statut sans interroger systématiquement l’autorité de certification à chaque connexion.
L’OCSP stapling, activable dans Nginx via la directive ssl_stapling on; combinée à ssl_stapling_verify on;, permet au serveur de joindre lui-même une preuve de non-révocation récente à chaque handshake, évitant au navigateur du visiteur une requête réseau supplémentaire vers l’autorité de certification, ce qui accélère la connexion initiale.
CAA, contrôler qui peut émettre un certificat pour un domaine
L’enregistrement DNS CAA (Certification Authority Authorization) répond à une troisième question, indépendante des deux précédentes : quelles autorités de certification sont explicitement autorisées à émettre un certificat pour ce domaine ? Sans enregistrement CAA, n’importe quelle autorité de certification reconnue peut théoriquement émettre un certificat valide pour un domaine donné, ce qui laisse une porte ouverte en cas de compromission d’une autorité tierce peu rigoureuse.
exemple.fr. IN CAA 0 issue "letsencrypt.org"
exemple.fr. IN CAA 0 issuewild "letsencrypt.org"
exemple.fr. IN CAA 0 iodef "mailto:securite@exemple.fr"Cet enregistrement restreint explicitement l’émission de certificats pour exemple.fr à Let’s Encrypt, avec une entrée distincte pour les certificats wildcard, et notifie une adresse email en cas de tentative d’émission non conforme par une autre autorité.
Comment ces quatre notions se combinent
| Notion | Catégorie | Répond à la question |
|---|---|---|
| RSA | Algorithme de clé | Comment la clé chiffre-t-elle les données ? |
| ECDSA | Algorithme de clé | Comment la clé chiffre-t-elle, plus efficacement ? |
| OCSP | Vérification de statut | Ce certificat est-il toujours valide aujourd’hui ? |
| CAA | Contrôle d’émission | Qui a le droit d’émettre un certificat pour ce domaine ? |
Ces quatre notions ne s’opposent jamais entre elles : un même serveur peut parfaitement utiliser une clé ECDSA, activer l’OCSP stapling, et restreindre son domaine avec un enregistrement CAA, les trois se renforçant mutuellement.
En résumé
RSA et ECDSA choisissent la façon dont la clé chiffre. OCSP vérifie que le certificat émis reste valide dans le temps. CAA contrôle en amont qui a le droit de l’émettre. Comprendre cette distinction évite de copier une configuration TLS sans en maîtriser réellement chaque paramètre. La documentation Mozilla sur la configuration TLS recommandée reste une référence solide pour combiner ces réglages correctement : developer.mozilla.org.
