CSR (Certificate Signing Request)

general

Définition

Une CSR (Certificate Signing Request — Demande de Signature de Certificat) est un message formaté contenant une clé publique et des informations d'identification (nom du domaine, organisation, localisation) qu'une entité soumet à une Autorité de Certification (CA) pour obtenir un certificat numérique. La CSR prouve que le demandeur possède la clé privée correspondante à la clé publique incluse dans la demande. Le processus d'obtention d'un certificat suit trois étapes. Génération de la paire de clés : l'entité génère une paire de clés cryptographiques (RSA-2048/4096 ou ECDSA P-256/P-384). La clé privée reste secrète et ne quitte jamais le système. Création de la CSR : l'entité génère une CSR qui contient la clé publique et le Subject (CN=www.example.com, O=Example Corp, C=FR) et la signe avec sa clé privée — prouvant la possession de la clé privée. Soumission et signature CA : la CA vérifie les informations de la CSR (vérification du contrôle du domaine pour les certificats DV, vérification de l'organisation pour les OV/EV), signe la clé publique avec sa propre clé privée, et retourne le certificat X.509 signé. La CSR est encodée en format PEM (Privacy Enhanced Mail) avec les en-têtes `-----BEGIN CERTIFICATE REQUEST-----` et `-----END CERTIFICATE REQUEST-----`. Le format DER est l'équivalent binaire. La commande OpenSSL pour générer une paire de clés et une CSR est : `openssl req -new -newkey rsa:2048 -keyout private.key -out request.csr -subj "/CN=www.example.com/O=Example Corp/C=FR"`. Un aspect critique des CSR est la sécurité de la clé privée générée. La clé privée doit être générée sur le système qui utilisera le certificat — pas sur un système tiers qui la transmettrait ensuite. Envoyer sa clé privée à un tiers (même à la CA) est une erreur de sécurité fondamentale. La CA signe uniquement la clé publique de la CSR — la clé privée n'est jamais partagée dans le processus légitime d'obtention d'un certificat.

SAN — Subject Alternative Names dans les CSR modernes

Les certificats modernes incluent des Subject Alternative Names (SAN) plutôt que de se baser uniquement sur le Common Name (CN). Les navigateurs Chrome et Firefox ignorent le CN pour la validation et exigent des SANs. Une CSR avec SANs multiples (certificat multi-domaines ou wildcard) permet de couvrir plusieurs noms de domaine avec un seul certificat : `openssl req -new -newkey rsa:2048 -keyout private.key -out request.csr -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN] subjectAltName=DNS:www.example.com,DNS:api.example.com,DNS:mail.example.com"))`. Les certificats wildcard (*.example.com) couvrent tous les sous-domaines de premier niveau mais ne couvrent pas les sous-domaines de niveau 2 (app.dev.example.com). Pour les infrastructures complexes, les certificats multi-SANs sont préférables aux wildcards pour une meilleure granularité de révocation.

Renouvellement de certificat — garder ou générer une nouvelle clé

Lors du renouvellement d'un certificat expirant, deux approches sont possibles. Réutiliser la même paire de clés : générer une nouvelle CSR avec la clé privée existante, soumettre à la CA, recevoir un nouveau certificat. Avantage : pas de déploiement de nouvelle clé privée, pratique pour les environnements avec Certificate Pinning. Inconvénient : si la clé privée a été compromise entre-temps, le nouveau certificat est aussi compromis. Générer une nouvelle paire de clés : générer une nouvelle clé privée et une nouvelle CSR, obtenir un nouveau certificat avec la nouvelle clé. Recommandé : une rotation des clés périodique (idéalement à chaque renouvellement) est une bonne pratique de sécurité. La rotation automatique via ACME (Let's Encrypt/Certbot) génère systématiquement de nouvelles clés à chaque renouvellement.

HSM pour la génération de clés — sécurité maximale

Pour les certificats de haute sensibilité (certificats Code Signing pour les logiciels publiés, certificats Root CA, certificats d'infrastructure critique), la génération de la clé privée dans un HSM (Hardware Security Module) garantit que la clé privée ne peut jamais être extraite du matériel. Les HSM certifiés FIPS 140-2 Level 3 (comme Thales Luna, Gemalto SafeNet, AWS CloudHSM, Azure Dedicated HSM) génèrent la paire de clés en interne et exposent des APIs cryptographiques (PKCS#11, CNG) pour signer les CSR — la clé privée ne quitte jamais le HSM. Certains fournisseurs de certificats de code signing (DigiCert, Sectigo EV Code Signing) exigent désormais que la clé privée soit stockée sur un token matériel (Yubikey 5 Series ou équivalent FIPS) — depuis les abus de certificats de code signing volés pour signer des malwares.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis