Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

X.509 Certificate

general

Définition

Un certificat X.509 est un document numérique standardisé qui lie une clé publique à une identité (personne, organisation, serveur, appareil), signé par une Autorité de Certification (CA) qui atteste de cette liaison. Ce format, défini par l'ITU-T et l'IETF (RFC 5280), constitue la base de la PKI et est utilisé pour HTTPS, les emails signés, le code signing, l'authentification mutuelle, et des centaines d'autres applications. Un certificat X.509 contient les informations suivantes : la version du certificat (v3 est standard), le numéro de série unique chez la CA émettrice, l'algorithme de signature utilisé, le Distinguished Name (DN) de l'émetteur (CA), la période de validité (dates de début et fin), le DN du sujet (propriétaire du certificat), la clé publique du sujet et son algorithme, les extensions (usages clés, noms alternatifs SANs, usage étendu, politique de certificat, Points de Distribution CRL, URL OCSP), et enfin la signature de la CA sur l'ensemble du contenu. Les extensions X.509 v3 sont cruciales pour la sécurité : Basic Constraints indique si le certificat peut être une CA (importante pour éviter les chaînes malveillantes), Key Usage définit les opérations autorisées (signature numérique, chiffrement de clé, signature de certificat), Extended Key Usage précise les applications (TLS serveur, TLS client, code signing, email, authentification smartcard), et Subject Alternative Names (SANs) listent les noms de domaines couverts. La durée de validité des certificats TLS publics est limitée à 13 mois maximum depuis 2020 (décision de l'Apple Root Program). Cette limitation réduit l'exposition en cas de compromission et encourage l'automatisation du renouvellement. Let's Encrypt émet des certificats valides 90 jours pour maximiser la rotation et la sécurité. La gestion du cycle de vie des certificats (CLM — Certificate Lifecycle Management) est un enjeu opérationnel majeur. Les organisations avec des milliers de certificats font face au risque d'expiration inattendue pouvant causer des interruptions de service. Des solutions de CLM automatisées (Venafi, AppViewX, CertManager pour Kubernetes, AWS ACM) inventorient, surveillent et renouvellent automatiquement les certificats, prévenant les pannes liées aux expirations et assurant la conformité des algorithmes.

Structure ASN.1 et encodage DER/PEM

Les certificats X.509 sont encodés en ASN.1 (Abstract Syntax Notation One) et sérialisés en format DER (Distinguished Encoding Rules, binaire) ou PEM (Privacy Enhanced Mail, base64 avec en-têtes -----BEGIN CERTIFICATE-----). Les formats courants incluent : .pem (certificat + chaîne), .crt ou .cer (certificat seul), .p7b/.p7c (PKCS#7, chaîne de certificats), .pfx/.p12 (PKCS#12, certificat + clé privée protégée par mot de passe). La commande openssl x509 -in cert.pem -text -noout affiche le contenu lisible d'un certificat pour diagnostic et vérification.

Certificats de code signing et intégrité logicielle

Les certificats de code signing lient l'identité d'un éditeur logiciel à son code. Windows SmartScreen, macOS Gatekeeper, et les app stores vérifient ces signatures. Un logiciel signé avec un certificat EV de code signing bénéficie d'une confiance immédiate dans Windows SmartScreen, sans période de "réputation building". La compromission d'un certificat de code signing (cas NotPetya initial, supply chain attacks) permet à un attaquant de distribuer des logiciels malveillants en apparence légitimes. Les solutions HSM cloud (Azure Dedicated HSM, AWS CloudHSM) pour stocker les clés de code signing réduisent ce risque en empêchant l'extraction de la clé privée.

Automatisation avec ACME et cert-manager

Le protocole ACME (Automatic Certificate Management Environment, RFC 8555), popularisé par Let's Encrypt, automatise entièrement le cycle de vie des certificats TLS. Les clients ACME (certbot, acme.sh, Caddy) obtiennent, renouvellent et révoquent automatiquement les certificats via des challenges de validation DNS-01 ou HTTP-01. Dans Kubernetes, cert-manager automatise les certificats pour les Ingress et les services, intégrant Let's Encrypt, HashiCorp Vault, et les CA internes. L'automatisation via ACME élimine le risque d'expiration non détectée et réduit drastiquement la charge opérationnelle de la gestion des certificats.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis