Qu'est-ce qu'une CSR - Certificate Signing Request expliqué

Une CSR (Certificate Signing Request) est un fichier standardisé qu'un demandeur envoie à une autorité de certification (CA) pour demander un certificat numérique. Elle contient la clé publique de l'entité, ses métadonnées (domaine, organisation), et est signée par la clé privée correspondante pour prouver la possession. Le concept est vieux de 30 ans (PKCS#10 défini par RSA Laboratories en 1993), mais reste central en 2026 : TLS, mTLS, VPN, code signing, PKI interne. Ce guide explique ce qu'est exactement une CSR, son contenu, comment la générer (OpenSSL, cfssl, step, cert-manager), comment les CAs la valident, les pièges classiques, et l'évolution vers l'automatisation ACME qui la rend largement invisible.

1. Définition précise

1.1 Le mot et la fonction

• Certificate Signing Request : demande de signature de certificat.
• Format standard : PKCS#10 (Public Key Cryptography Standard #10), RFC 2986.
• Contenu : une clé publique + des métadonnées + une signature par la clé privée correspondante.
• Destinataire : une autorité de certification (CA) qui, après validation, émet un certificat X.509.

1.2 Ce que la CSR N'EST PAS

• Pas la clé privée : la clé privée reste strictement chez le demandeur. Si la clé privée voyage, c'est un bug.
• Pas le certificat : le certificat est émis par la CA en réponse à la CSR.
• Pas directement utilisable : une CSR seule ne sert qu'à obtenir un certificat.

1.3 Le cycle de vie simplifié

1. Demandeur génère : clé privée + clé publique
2. Demandeur crée une CSR (contient clé publique + metadata + signature)
3. Demandeur envoie la CSR à la CA
4. CA valide (ex. propriété du domaine pour Let's Encrypt)
5. CA émet un certificat signé par sa propre clé privée
6. Demandeur utilise : certificat + clé privée privée pour TLS

2. Ce que contient une CSR

2.1 Structure PKCS#10

Une CSR est un objet ASN.1 structuré comprenant :

• Version : typiquement 0 (PKCS#10 v1.0).
• Subject : informations sur le demandeur.
• Subject Public Key Info : la clé publique + l'algorithme (RSA, ECDSA, Ed25519).
• Attributes : extensions (SAN, key usage, extended key usage, etc.).
• Signature Algorithm : ex. sha256WithRSAEncryption.
• Signature : signature de tout ce qui précède, avec la clé privée.

2.2 Subject - les champs classiques

Le Subject est au format Distinguished Name (DN), notation LDAP :

Exemple :

CN=api.example.com
O=Example Corp
OU=Platform Engineering
C=FR
ST=Ile-de-France
L=Paris
emailAddress=ops@example.com

2.3 Subject Alternative Names (SAN) - essentiel en 2026

SAN est une extension qui liste les domaines couverts par le certificat. Elle remplace le CN pour la validation TLS depuis RFC 2818 (2011), Chrome l'exige depuis 2017.

Exemples :

DNS:api.example.com
DNS:www.api.example.com
DNS:admin.api.example.com
IP:192.168.1.1
email:contact@example.com
URI:https://example.com

Règle 2026 : toujours mettre les domaines dans le SAN, même si un seul. CN peut être omis ou dupliquer le premier SAN.

2.4 Key Usage et Extended Key Usage

Extensions qui précisent l'usage du certificat :

Key Usage :

• digitalSignature : signature de données.
• keyEncipherment : chiffrement de clé (RSA legacy).
• keyAgreement : échange de clé (ECDH).
• keyCertSign : seulement pour les CAs.
• cRLSign : seulement pour les CAs.

Extended Key Usage :

• serverAuth : auth serveur TLS.
• clientAuth : auth client mTLS.
• codeSigning : signature de code.
• emailProtection : S/MIME.
• OCSPSigning : réponses OCSP.

Une CSR pour un serveur web inclut typiquement digitalSignature + keyEncipherment + serverAuth.

Une CSR pour un client mTLS inclut digitalSignature + clientAuth.

2.5 La signature de la CSR

La CSR est auto-signée par le demandeur avec sa propre clé privée. Pourquoi ?

• Prouve au CA que le demandeur possède bien la clé privée associée à la clé publique.
• Empêche qu'un attaquant qui intercepte la CSR la modifie en transit sans invalider la signature.

Important : cette auto-signature ne vérifie pas l'identité (un attaquant peut générer une CSR pour n'importe quel CN). Seul le CA, via sa validation métier, établit l'identité.

3. CSR vs certificat vs clé privée - la confusion classique

3.1 Les trois fichiers du monde PKI

3.2 Piège : ne jamais envoyer la clé privée

Certaines plateformes de gestion de certificat proposent "pour vous simplifier la vie, téléchargez la clé privée et le CSR pré-généré" en envoyant les deux en clair. Mauvaise pratique :

• La clé privée doit être générée chez le propriétaire final.
• Elle ne devrait jamais transiter par le CA ou un tiers.
• Si une interface propose de générer la clé privée pour toi, vérifier qu'elle reste chez toi (ex. key generation côté client en JS, ou génération locale avec CLI).

3.3 Formats PEM et DER

• PEM (Privacy Enhanced Mail) : encodage Base64 avec headers -----BEGIN...----- / -----END...-----. Lisible en texte, format le plus courant.
• DER (Distinguished Encoding Rules) : encodage binaire. Plus compact, moins utilisé en admin système.

Les deux représentent exactement la même chose, convertibles l'un vers l'autre.

Exemple CSR au format PEM :

-----BEGIN CERTIFICATE REQUEST-----
MIICijCCAXICAQAwRTELMAkGA1UEBhMCRlIxETAPBgNVBAoTCE15IENvcnAxEDAO
BgNVBAsTB0RldiBPcHMxEDAOBgNVBAMTB2FwaS1kZXYwggEiMA0GCSqGSIb3DQEB
...
-----END CERTIFICATE REQUEST-----

4. Générer une CSR en pratique

4.1 OpenSSL - classique

Étape 1 - Générer une clé privée (Ed25519 recommandé 2026) :

openssl genpkey -algorithm Ed25519 -out server.key

Alternative RSA (interop plus large) :

openssl genpkey -algorithm RSA -out server.key \
  -pkeyopt rsa_keygen_bits:2048

Protéger la clé privée : permissions 600, stockage sécurisé.

Étape 2 - Créer un fichier de configuration CSR :

# csr.conf
[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[dn]
C = FR
ST = Ile-de-France
L = Paris
O = Example Corp
OU = Platform Engineering
CN = api.example.com

[req_ext]
subjectAltName = @alt_names
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[alt_names]
DNS.1 = api.example.com
DNS.2 = www.api.example.com
DNS.3 = admin.api.example.com

Étape 3 - Générer la CSR :

openssl req -new -key server.key -out server.csr -config csr.conf

Étape 4 - Vérifier le contenu :

openssl req -in server.csr -noout -text

Affiche Subject, SAN, Key Usage, signature algorithm. Important pour détecter les erreurs avant envoi au CA.

4.2 cfssl - approche JSON

cfssl (CloudFlare) utilise du JSON et est plus pratique pour l'automation.

Fichier de config JSON :

{
  "CN": "api.example.com",
  "key": { "algo": "ecdsa", "size": 256 },
  "names": [{
    "C": "FR",
    "ST": "Ile-de-France",
    "L": "Paris",
    "O": "Example Corp"
  }],
  "hosts": [
    "api.example.com",
    "www.api.example.com"
  ]
}

Génération :

cfssl genkey csr.json | cfssljson -bare server

Produit server-key.pem et server.csr.

4.3 Smallstep step CLI - moderne

step (smallstep) simplifie le workflow :

step certificate create api.example.com \
  server.crt server.key \
  --csr \
  --profile leaf \
  --not-after 8760h

Génère clé privée, CSR, et même le cert si auto-signé. Excellent pour PKI interne.

4.4 cert-manager (Kubernetes)

Pour Kubernetes, cert-manager génère les CSRs automatiquement à partir d'une ressource Certificate :

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-tls
  namespace: default
spec:
  secretName: api-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - api.example.com
    - www.api.example.com
  privateKey:
    algorithm: ECDSA
    size: 256

cert-manager génère la clé privée, crée la CSR, résout le challenge ACME, et stocke le certificat émis dans un Secret Kubernetes. Workflow complet automatisé.

4.5 Automation ACME - la CSR invisible

Avec Let's Encrypt et le protocole ACME (RFC 8555), la CSR devient quasi invisible pour l'utilisateur :

• Certbot, acme.sh, lego, cert-manager : génèrent la clé privée, la CSR, résolvent les challenges, récupèrent et renouvellent le certificat.
• L'utilisateur voit juste "certificat émis".
• Rotation automatique tous les 60-90 jours.

C'est la raison pour laquelle HTTPS est passé de 50 % à 95+ % du web en 10 ans.

5. Ce que fait le CA avec la CSR

5.1 Vérifications techniques

• La signature de la CSR est valide avec la clé publique fournie (preuve de possession).
• Le format est conforme.
• Les algorithmes demandés sont supportés.
• Les extensions sont acceptables.

5.2 Vérifications métier - niveaux de validation

Trois niveaux de certificats TLS publiquement de confiance :

En 2026 :

• DV dominant grâce à Let's Encrypt (gratuit, automatisé).
• OV et EV en déclin : les navigateurs n'affichent plus de différence visuelle depuis 2019, leur valeur marketing s'est érodée.
• Exceptions : secteurs très réglementés (banque, santé, institutions) qui restent sur OV/EV.

5.3 Challenge ACME - DV automatisé

Let's Encrypt et la plupart des CAs modernes utilisent ACME :

• HTTP-01 : demandeur publie un fichier à un chemin spécifique sur son domaine. CA vérifie en HTTP.
• DNS-01 : demandeur ajoute un enregistrement TXT dans son DNS. CA vérifie la résolution.
• TLS-ALPN-01 : demandeur répond via handshake TLS avec un certificat auto-signé spécial. CA vérifie.

Une fois le challenge passé, la CSR est signée et le certificat émis.

6. CSR pour cas d'usage spécifiques

6.1 CSR pour mTLS (client certificate)

Différences avec un CSR serveur :

• Extended Key Usage : clientAuth au lieu de serverAuth.
• CN : généralement un identifiant de service ou user (service-payments, bob@example.com).
• SAN : peut inclure des URIs ou emails selon les besoins.

Exemple de config OpenSSL pour CSR client :

[req_ext]
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
subjectAltName = @alt_names

[alt_names]
URI.1 = spiffe://example.com/service/payments
email.1 = payments@example.com

Usage typique : authentification mutuelle service-to-service, VPN, systèmes enterprise avec CA interne.

6.2 CSR pour code signing

• Extended Key Usage : codeSigning.
• Subject : nom officiel de l'éditeur (vérifié par le CA).
• CA : DigiCert, Sectigo, Entrust, Certum pour Microsoft Authenticode. Apple Developer pour macOS/iOS.

6.3 CSR pour PKI interne

Beaucoup d'organisations opèrent leur propre CA interne pour signer des certificats non-publics :

• Certificats pour services internes (ex. api.internal.example.com).
• Certificats mTLS pour workloads.
• Certificats de VPN clients.

Outils : smallstep CA, HashiCorp Vault PKI, Boulder (impl. Let's Encrypt open-source), step-ca, AWS Private CA, Google Cloud CA Service, Azure Private CA.

Les CSRs sont signées par le CA interne. Les clients internes font confiance au CA root interne, pas aux CAs publics.

6.4 CSR pour certificats multi-domaines (SAN / wildcard)

SAN multi-domaines : un certificat couvre plusieurs domaines listés.

Wildcard : un certificat couvre *.example.com (tous les sous-domaines directs).

Attention :

• Wildcard ne couvre qu'un niveau : *.example.com ne couvre pas api.v1.example.com.
• Wildcard combine pratique + risque : compromission = impact large sur tous les sous-domaines.
• Let's Encrypt supporte wildcard uniquement via DNS-01 challenge.

7. Inspecter une CSR

7.1 Avec OpenSSL

openssl req -in server.csr -noout -text -verify

Sortie détaillée : Subject, Public Key, SAN, Extensions, signature verification.

Important : le flag -verify vérifie que la signature est valide. Une CSR dont la signature ne vérifie pas n'est pas utilisable.

7.2 Décoder un champ spécifique

# Afficher seulement le Subject
openssl req -in server.csr -noout -subject
 
# Afficher la clé publique
openssl req -in server.csr -noout -pubkey
 
# Afficher les extensions (SAN)
openssl req -in server.csr -noout -text | grep -A1 "Subject Alternative Name"

7.3 Outils en ligne

• SSL Shopper CSR Decoder : affichage web, utile pour checks visuels.
• CertLogik : décodeur de CSR, cert, CRL.

Attention : ne jamais coller la clé privée dans ces outils. La CSR seule est publique (elle ne contient rien de secret), mais préférer les outils locaux pour tout ce qui touche les clés.

7.4 Script de validation en CI

Validation automatique avant soumission à un CA :

#!/bin/bash
# Verifier que la CSR contient les bonnes SANs
openssl req -in server.csr -noout -text | grep "DNS:api.example.com" || exit 1
# Vérifier l'algorithme
openssl req -in server.csr -noout -text | grep "Signature Algorithm" | grep -v "md5\|sha1" || exit 1
# Vérifier la taille de clé (RSA min 2048)
openssl req -in server.csr -noout -text | grep "Public-Key" | awk '{print $2}' | grep -E "2048|3072|4096|256|384|521" || exit 1

8. Erreurs fréquentes

8.1 CSR sans SAN

Générer une CSR avec seulement le CN rempli, sans SAN. Les navigateurs modernes (Chrome, Firefox) rejetent ces certificats depuis 2017. Toujours inclure au moins un DNS dans SAN.

8.2 Clé privée faible

Utiliser RSA 1024 bits (interdit depuis 2014). Minimum 2048 bits pour RSA. Préférer ECDSA P-256 ou Ed25519 en 2026.

8.3 Signature algorithm faible

CSR signée avec md5WithRSAEncryption ou sha1WithRSAEncryption. Refusée par les CAs modernes. Utiliser SHA-256 ou mieux.

8.4 Informations incorrectes ou incohérentes

• CN avec typo (api.exampel.com au lieu de api.example.com).
• SAN qui ne couvre pas tous les domaines réellement utilisés.
• O, OU, C incohérents avec les records d'organisation.

Toujours review la CSR avec openssl req -text avant soumission.

8.5 Clé privée envoyée au CA

Certaines plateformes de gestion proposent de générer la paire de clés "chez elles". Ne jamais accepter que la clé privée transite par un tiers. Générer toujours localement.

8.6 Ne pas roter la clé privée

Utiliser la même clé privée pendant 5-10 ans en renouvelant juste le certificat. Mauvaise pratique : si la clé privée fuite, tous les anciens enregistrements chiffrés sont compromis. Bonne pratique : nouvelle clé privée à chaque renouvellement (cert-manager le fait par défaut).

8.7 Oublier les certificats intermédiaires

Une fois le certificat reçu du CA, il faut aussi la chaîne de certificats (intermediate + root) pour que les clients puissent vérifier. Serveurs TLS doivent présenter la chaîne complète, pas juste le cert final.

8.8 Certificat expiré

Domaines down suite à oubli de renouvellement. Incidents historiques chez grands acteurs (Microsoft Teams, Cisco, Equifax). Mitigation : ACME automation, monitoring expiration, alertes 30 jours et 7 jours avant.

9. Post-quantum et CSRs

9.1 Impact des standards NIST 2024

Avec la publication FIPS 203-205, les algorithmes post-quantum entrent dans le paysage PKI :

• ML-DSA (Dilithium) : signature PQ, FIPS 204.
• SLH-DSA (SPHINCS+) : signature PQ hash-based, FIPS 205.

Les CSRs post-quantum incluront des clés publiques ML-DSA beaucoup plus grandes (plusieurs KB vs 64 octets pour Ed25519).

9.2 Certificats hybrides

Approche de transition : CSR avec deux clés et deux signatures :

• Une paire classique (Ed25519, ECDSA).
• Une paire post-quantum (ML-DSA).

Le certificat émis est utilisable par clients classiques ET post-quantum. Stratégie recommandée par la NSA CNSA 2.0.

9.3 Quand migrer

Pour la majorité des applications en 2026-2027 : pas d'urgence. Observer les standards se stabiliser, outils atteindre maturité (OpenSSL 3.4+ support PQ hybride). Commencer par l'inventaire de l'usage crypto et la crypto agility.

Pour les systèmes à haute valeur long terme : commencer l'expérimentation dès 2026.

10. Checklist CSR

Avant de générer et soumettre une CSR, vérifier :

Génération de clé privée

• Algorithme moderne (Ed25519 recommandé, ECDSA P-256 ou RSA 2048+ acceptable)
• Génération locale sur la machine cible
• Stockage sécurisé (permissions 600, HSM/KMS pour les critiques)
• Jamais committée en Git

Contenu de la CSR

• CN cohérent avec le premier SAN
• SAN contient tous les domaines à couvrir
• Pas de typo dans les noms de domaine
• Key Usage et Extended Key Usage adaptés (serverAuth, clientAuth, codeSigning)
• Subject (O, OU, C) cohérent avec l'organisation

Signature et format

• Algorithme de signature moderne (SHA-256 minimum, pas MD5 ni SHA-1)
• Format PEM pour interop
• Vérification préalable avec openssl req -text -verify

Validation avant envoi

• Review visuelle du contenu
• Script de validation en CI si workflow récurrent
• Test sur environnement dev avant production

Après émission du certificat

• Chaîne complète (intermediate + root) présentée par le serveur
• Monitoring d'expiration configuré
• Alerte 30 jours et 7 jours avant expiration
• Renouvellement automatisé si possible

Rotation

• Nouvelle clé privée à chaque renouvellement
• Plan de rotation documenté
• Break-glass process en cas d'oubli

11. Outils récapitulatifs

12. Verdict et posture Zeroday

La CSR est une brique technique qui n'a pas changé fondamentalement depuis 30 ans, mais dont l'usage a été profondément automatisé ces 10 dernières années. En 2026 :

• Pour les certificats TLS publics : ACME + automation (cert-manager, certbot, Caddy) rend la CSR invisible à l'utilisateur. Devenu la norme.
• Pour la PKI interne et les certs spéciaux : génération manuelle reste nécessaire mais encadrée par des outils modernes (step, cfssl).
• Pour le futur post-quantum : la CSR reste la primitive, seuls les algorithmes changent.

Pour un développeur : savoir générer une CSR avec OpenSSL et la décoder est une compétence transférable, utile en troubleshooting, en audit, en PKI interne. Pas besoin de le faire au quotidien, mais indispensable en contexte spécial.

Pour un AppSec : auditer les pratiques CSR d'une équipe (algorithmes, rotation, stockage clé privée, cert expiration monitoring) révèle rapidement la maturité de leur PKI. Des signes de maturité : ACME automation partout, rotation des clés à chaque renouvellement, cert-manager ou équivalent en K8s.

Pour une organisation : standardiser sur un outil unique (cert-manager, step-ca, HashiCorp Vault PKI) et éliminer les processus manuels produit les gains les plus durables. Les incidents TLS (certificats expirés, chaînes incomplètes, clés faibles) sont quasi tous des erreurs opérationnelles évitables par outillage.

Pour approfondir : qu'est-ce que la cryptographie pour le contexte PKI, différence hash/HMAC/signature pour comprendre la signature qui sous-tend les certificats, sécurité REST : les bases pour l'articulation TLS côté API, service accounts : risques et bonnes pratiques pour mTLS et workload identity.