Certificats et PKI

L’article précédent laissait une question ouverte : quand un serveur me présente sa clé publique, comment savoir qu’elle est vraiment la sienne, et pas celle d’un attaquant placé au milieu ? La réponse d’Internet, c’est le certificat et la PKI (infrastructure à clés publiques) : un système de tiers de confiance qui se portent garants des clés.

Le certificat : une carte d’identité signée

Un certificat X.509 est un document qui dit, en substance : « cette clé publique appartient à www.exemple.fr », signé par une autorité de certification (AC) à laquelle on fait confiance.

Ce qu’il contient :

Champ	Contenu
Sujet	L’identité du titulaire
Subject Alternative Name (SAN)	Les noms couverts : exemple.fr, www.exemple.fr, *.exemple.fr…
Clé publique	La clé du titulaire
Émetteur	L’AC qui a signé
Validité	Date de début et de fin
Usages	Authentification serveur, client, signature de code…
Signature	La signature de l’AC sur tout ce qui précède

# Afficher le certificat d'un site
openssl s_client -connect www.exemple.fr:443 -servername www.exemple.fr </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

La chaîne de confiance

Les AC ne signent pas directement les certificats des sites avec leur clé la plus précieuse. Elles utilisent une chaîne :

AC racine           (auto-signée, préinstallée dans le système ou le navigateur, gardée hors ligne)
  └── AC intermédiaire   (signée par la racine, signe au quotidien)
        └── Certificat du serveur   (www.exemple.fr)

Quand un navigateur reçoit un certificat, il vérifie :

1. que chaque maillon est signé par le maillon du dessus, jusqu’à une racine de confiance ;
2. que chaque certificat est dans sa période de validité ;
3. que le nom demandé figure dans le champ SAN ;
4. que les usages sont corrects ;
5. que le certificat n’est pas révoqué.

Si une seule vérification échoue, il affiche une alerte.

DV, OV, EV

Niveau	Ce que l’AC vérifie	Exemple
DV (Domain Validation)	Que le demandeur contrôle le domaine (fichier sur le site, enregistrement DNS)	Let’s Encrypt, en quelques secondes
OV (Organization Validation)	En plus, l’existence de l’organisation	Certificats d’entreprise
EV (Extended Validation)	Vérifications juridiques poussées	Les navigateurs ne l’affichent plus de façon particulière

La révocation

Si une clé privée fuit, il faut révoquer le certificat avant sa date d’expiration.

Mécanisme	Principe	Limite
CRL	L’AC publie la liste des certificats révoqués	Listes parfois énormes, mises à jour périodiques
OCSP	Le client interroge l’AC en temps réel	Problèmes de vie privée et de disponibilité
OCSP stapling	Le serveur joint lui-même une réponse OCSP récente	Doit être activé sur le serveur

En pratique, la révocation fonctionne mal sur le web, ce qui explique la tendance aux certificats de courte durée : Let’s Encrypt délivre des certificats de 90 jours, et l’industrie s’est engagée à réduire progressivement la durée maximale des certificats publics.

Certificate Transparency

Depuis plusieurs années, les AC publiques doivent inscrire chaque certificat émis dans des journaux publics, en ajout seul : c’est Certificate Transparency (CT). Les navigateurs refusent les certificats qui n’y figurent pas.

Pour un défenseur, c’est une source précieuse :

• surveiller les certificats émis pour son propre domaine (un certificat inattendu peut signaler une erreur ou une attaque) ;
• découvrir des sous-domaines oubliés ;
• repérer des domaines qui imitent le sien, souvent préparés pour du phishing.

On interroge ces journaux, par exemple, sur crt.sh.

Les certificats auto-signés

Un certificat auto-signé est signé par sa propre clé, sans AC. Aucun navigateur ne lui fait confiance par défaut. On en trouve sur les interfaces d’administration d’équipements internes… et sur les serveurs de commande de nombreux malwares. Dans une analyse réseau, un certificat auto-signé avec des champs vides ou par défaut, vers une IP inconnue, est un indice à creuser.

La PKI d’entreprise

Beaucoup d’entreprises ont leur propre PKI, souvent ADCS (Active Directory Certificate Services) dans les environnements Windows. Elle délivre des certificats pour les serveurs internes, l’authentification des machines (802.1X, VPN), la connexion par carte à puce, ou la signature de documents.

Une PKI interne fait partie des systèmes les plus sensibles (niveau 0 dans le modèle de cloisonnement, voir la série Active Directory) : un certificat d’authentification délivré à tort peut permettre de s’authentifier comme un autre utilisateur, jusqu’à l’administrateur du domaine. Des modèles de certificats trop permissifs sont une cause connue de compromission de domaines, et l’audit de la configuration d’ADCS fait désormais partie des vérifications courantes.