Certificats X.509 : expiration, auto-signature, wildcard et erreurs de validation

Les certificats X.509 sont le mécanisme qui permet à un client de vérifier l'identité du serveur auquel il se connecte. Un certificat associe une clé publique à une identité (nom de domaine) et est signé par une autorité de certification (CA) en qui le client fait confiance. Les faiblesses dans ce mécanisme permettent des attaques de type man-in-the-middle, où un attaquant intercepte et déchiffre les communications sans que le client s'en aperçoive.

Certificat auto-signé

Un certificat auto-signé n'est signé par aucune autorité de certification reconnue. N'importe qui peut créer un certificat auto-signé pour n'importe quel domaine. Les navigateurs et les clients affichent un avertissement, mais les utilisateurs ont tendance à les ignorer, surtout sur des interfaces internes ou de développement qui ont "toujours fonctionné comme ça".

Les certificats auto-signés sont acceptables en développement local. En production ou sur des interfaces internes accessibles, ils doivent être remplacés par des certificats émis par une CA reconnue. Let's Encrypt permet d'obtenir des certificats gratuits et automatiquement renouvelables pour tous les domaines accessibles depuis internet. Pour les domaines internes, déployer une CA interne.

Certificat expiré

Un certificat expiré génère des avertissements que les utilisateurs finissent par ignorer, ce qui les expose à accepter de futurs faux certificats. C'est ce qu'on appelle l'accoutumance aux avertissements : un utilisateur habitué à cliquer sur "Continuer quand même" le fera aussi pour un certificat frauduleux présenté par un attaquant. Au-delà de l'impact sécurité, un certificat expiré interrompt les connexions automatiques (APIs, services, scripts) qui n'ignorent pas les erreurs.

La solution : automatiser le renouvellement des certificats. Let's Encrypt avec Certbot ou ACME renouvelle automatiquement 30 jours avant expiration. Mettre en place une alerte de monitoring qui se déclenche à 30 jours, 14 jours et 7 jours avant expiration.

Certificat wildcard trop large

Un certificat wildcard (*.example.com) couvre tous les sous-domaines de premier niveau, mais pas les sous-sous-domaines. Le problème de sécurité : si un sous-domaine est compromis, l'attaquant peut utiliser la clé privée associée au wildcard pour présenter un certificat valide pour n'importe quel autre sous-domaine. Un certificat wildcard est une clé qui ouvre toutes les portes de votre domaine.

Préférer des certificats SAN (Subject Alternative Names) qui listent explicitement les domaines couverts. Réserver les wildcards aux cas où le nombre de sous-domaines est réellement variable et géré dynamiquement.

Clé publique trop courte

Les clés RSA inférieures à 2048 bits sont considérées comme insuffisantes. Les clés de 1024 bits sont cassables avec des ressources computationnelles modérées. Le standard actuel est RSA-2048 minimum, avec RSA-4096 ou les courbes elliptiques (ECDSA P-256 ou Ed25519) recommandées pour les nouvelles émissions. ECDSA P-256 offre une sécurité équivalente à RSA-3072 avec une clé beaucoup plus courte.

Validation de certificat incorrecte

La faille la plus grave n'est pas dans le certificat lui-même mais dans le code qui le valide. Des applications désactivent la vérification du certificat pour "simplifier" les connexions HTTPS, surtout en développement, et oublient de la réactiver en production. C'est particulièrement courant dans les applications mobiles et les scripts d'intégration.

Désactivation dangereuse de la validation (Python Requests)

# Dangereux : ignore les erreurs de certificat
response = requests.get(url, verify=False)

# Correct : validation complète
response = requests.get(url)  # verify=True par défaut

# Pour une CA interne :
response = requests.get(url, verify='/path/to/ca-bundle.crt')

Récapitulatif

1. Certificats signés par une CA reconnue : Let's Encrypt en production, CA interne pour les domaines internes
2. Automatiser le renouvellement : alerte à 30 jours, renouvellement automatique avec ACME/Certbot
3. Préférer les SAN aux wildcards : lister explicitement les domaines couverts
4. Clés RSA-2048 minimum : préférer ECDSA P-256 pour les nouvelles émissions
5. Ne jamais désactiver la validation : configurer correctement les CAs internes plutôt que de contourner la vérification