CSR - Certificate Signing Request, génération 2026

Le CSR (Certificate Signing Request) est le format de demande de certificat soumis à une Autorité de Certification (CA) pour obtenir un certificat X.509 signé. C'est la première étape obligatoire du cycle de vie d'un certificat : tu génères une paire de clés (privée + publique), tu encapsules la clé publique + des métadonnées (Subject, SANs, extensions) dans un CSR signé par ta clé privée, tu envoies à la CA qui vérifie l'identité et émet le certificat. Le format est standardisé par PKCS#10 (Public-Key Cryptography Standards #10) publié par RSA Labs en 1998 et formalisé par IETF RFC 2986 en novembre 2000, encodage PEM (RFC 7468 avril 2015) dominant en pratique. En 2026, le CSR est largement automatisé sous le capot par ACME (RFC 8555 mars 2019), cert-manager (CNCF Graduated 2024) et les services cloud managed (AWS ACM, Azure App Service Managed Cert, GCP Certificate Manager), l'ingénieur ne le manipule manuellement que dans 4-5 cas spécifiques : Private PKI mTLS avec workflow approval, EV/OV Web PKI exigeant Subject custom, code signing (Apple/Microsoft/Sigstore), Certificate Re-key Application (CRA), Hardware tokens/HSM où la clé ne peut pas quitter le device. Le CN (Common Name) est déprécié depuis 2017 par les Baseline Requirements CA/Browser Forum, Subject Alternative Names (SANs) sont obligatoires pour tous certs Web PKI 2026. Comprendre l'anatomie PKCS#10, la génération concrète (OpenSSL / cfssl Cloudflare / step Smallstep), la validation, les algorithmes 2026 (ECDSA P-256 préféré, RSA 2048-3072 legacy, Ed25519 émergent, ML-DSA post-quantum), et les anti-patterns est non-négociable pour tout ingénieur sécurité ou DevSecOps 2026.

Pour le contexte adjacent : voir PKI - Public Key Infrastructure pour l'umbrella infrastructure dont le CSR est la première étape.

1. Anatomie PKCS#10 et structure CSR

Un CSR PKCS#10 (RFC 2986) est une structure ASN.1 DER, généralement encodée en PEM (Base64 + headers -----BEGIN CERTIFICATE REQUEST-----).

1.1 Distinguished Name (DN) - Subject

Le DN identifie le demandeur. Composants standards :

Position tranchée 2026 : pour DV (Domain Validation) certs publics, un CN suffit + SANs. Pour OV/EV, ajouter O + C uniquement. Ne jamais utiliser OU depuis le ballot 2022 du CA/Browser Forum.

1.2 Subject Alternative Names (SANs) - obligatoire 2026

Les SANs étendent le DN avec une liste de noms d'identité. Types supportés :

Chrome 58 a refusé en mai 2017 les certs sans SANs. Depuis, toutes les CAs publiques refusent les CSR sans SAN. Anti-pattern absolu en 2026.

2. Génération de CSR avec OpenSSL en 2026

2.1 Pattern recommandé : config file + ECDSA P-256

# 1. Créer le fichier de configuration OpenSSL avec SANs
cat > csr.cnf <<'EOF'
[ req ]
default_bits       = 2048
default_md         = sha256
distinguished_name = req_distinguished_name
req_extensions     = v3_req
prompt             = no
 
[ req_distinguished_name ]
CN = app.example.com
O  = Acme Corp
C  = FR
 
[ v3_req ]
subjectAltName = @alt_names
keyUsage       = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
 
[ alt_names ]
DNS.1 = app.example.com
DNS.2 = www.example.com
DNS.3 = api.example.com
EOF
 
# 2. Générer la clé privée ECDSA P-256 (recommandé 2026)
openssl ecparam -name prime256v1 -genkey -noout -out app.key
 
# 3. Générer le CSR avec config
openssl req -new \
  -key app.key \
  -out app.csr \
  -config csr.cnf
 
# 4. Vérifier le CSR généré
openssl req -text -noout -verify -in app.csr
 
# Output attendu :
# Certificate Request:
#     Data:
#         Version: 1 (0x0)
#         Subject: CN=app.example.com, O=Acme Corp, C=FR
#         Subject Public Key Info:
#             Public Key Algorithm: id-ecPublicKey
#                 Public-Key: (256 bit)
#                 ASN1 OID: prime256v1
#                 NIST CURVE: P-256
#         Requested Extensions:
#             X509v3 Subject Alternative Name:
#                 DNS:app.example.com, DNS:www.example.com, DNS:api.example.com
#             X509v3 Key Usage: critical
#                 Digital Signature, Key Encipherment
#             X509v3 Extended Key Usage:
#                 TLS Web Server Authentication, TLS Web Client Authentication
#     Signature Algorithm: ecdsa-with-SHA256

2.2 Pattern one-liner avec -addext (OpenSSL 1.1.1+)

# Génération clé + CSR en une commande (utile en automation)
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout app.key -out app.csr \
  -subj "/CN=app.example.com/O=Acme Corp/C=FR" \
  -addext "subjectAltName=DNS:app.example.com,DNS:www.example.com,DNS:api.example.com" \
  -addext "keyUsage=critical,digitalSignature,keyEncipherment" \
  -addext "extendedKeyUsage=serverAuth,clientAuth"
 
# RSA 3072 alternative (si compliance exige RSA)
openssl req -new -newkey rsa:3072 -nodes \
  -keyout app.key -out app.csr \
  -subj "/CN=app.example.com" \
  -addext "subjectAltName=DNS:app.example.com,DNS:www.example.com"

2.3 Pattern cfssl (Cloudflare) - JSON déclaratif

# Install cfssl
go install github.com/cloudflare/cfssl/cmd/cfssl@latest
go install github.com/cloudflare/cfssl/cmd/cfssljson@latest
 
# Config JSON
cat > csr-config.json <<'EOF'
{
  "CN": "app.example.com",
  "key": {
    "algo": "ecdsa",
    "size": 256
  },
  "names": [
    {
      "O": "Acme Corp",
      "C": "FR"
    }
  ],
  "hosts": [
    "app.example.com",
    "www.example.com",
    "api.example.com",
    "10.0.1.42"
  ]
}
EOF
 
# Générer clé + CSR
cfssl genkey csr-config.json | cfssljson -bare app
 
# Output : app.csr + app-key.pem

2.4 Pattern step (Smallstep) - le plus ergonomique 2026

# Install step CLI
brew install step  # macOS
# OR
curl -sLO https://github.com/smallstep/cli/releases/latest/download/step_linux_amd64.tar.gz
 
# Génération en une commande avec SANs et KU/EKU
step certificate create app.example.com app.csr app.key \
  --csr \
  --san www.example.com \
  --san api.example.com \
  --san IP:10.0.1.42 \
  --kty EC \
  --crv P-256 \
  --not-after 2160h  # Validity hint (90 jours, peut être ignoré par CA)
 
# Vérification
step certificate inspect app.csr

3. Validation d'un CSR

Avant de soumettre à une CA, toujours valider le CSR :

# Validation OpenSSL standard
openssl req -text -noout -verify -in app.csr
 
# Vérifications critiques :
# 1. Signature valide ? Output: "verify OK" requis
# 2. Subject correct ?
# 3. SANs présents et corrects ?
# 4. Public Key algorithm + size adéquats ?
# 5. KeyUsage et ExtendedKeyUsage corrects ?
 
# Comparer hash clé privée vs CSR (s'assurer que CSR est signé par la bonne clé)
openssl pkey -in app.key -pubout -outform DER | sha256sum
openssl req -in app.csr -pubkey -noout -outform DER 2>/dev/null | sha256sum
# Les deux hash doivent être identiques
 
# Outils online (utiliser uniquement pour CSR non-sensibles, jamais en prod)
# - DigiCert SSL Tools : https://ssltools.digicert.com/checker/views/csrCheck.jsp
# - SSL Shopper : https://www.sslshopper.com/csr-decoder.html

4. Algorithmes et tailles de clé recommandés 2026

Position tranchée 2026 : pour Web PKI public et mTLS service-to-service, ECDSA P-256 est la recommandation par défaut, équivalent sécurité RSA 3072, signature 5-10× plus rapide, certificat 50 % plus petit (~500 bytes vs ~1.5 KB), bandwidth économisé en TLS handshake. RSA 3072 acceptable si compliance gov/banking exige explicitement RSA. Éviter RSA 2048 pour nouveaux certs longue durée (post-quantum risk).

5. Algorithmes de signature CSR

L'algo de signature du CSR doit être au moins équivalent à la clé. Standard 2026 :

Anti-pattern : CSR signé en SHA-1 → refus immédiat de toute CA publique depuis 2017. Toujours -sha256 minimum dans OpenSSL.

6. Stack outillage CSR moderne 2026

6.1 Comparaison outils

6.2 Pattern moderne : cert-manager Kubernetes auto-CSR

Configuration cert-manager (CNCF Graduated 2024) où le CSR est généré automatiquement :

# Aucun CSR à manipuler manuellement - cert-manager fait tout
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: app-tls
  namespace: production
spec:
  secretName: app-tls-secret
  duration: 2160h        # 90 jours
  renewBefore: 720h       # Renew 30 jours avant
  subject:
    organizations:
      - Acme Corp
  privateKey:
    algorithm: ECDSA
    size: 256
    rotationPolicy: Always   # Nouvelle clé à chaque renew
  dnsNames:
    - app.example.com
    - www.example.com
    - api.example.com
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
    group: cert-manager.io

cert-manager génère automatiquement la clé ECDSA P-256, construit le CSR avec SANs, soumet via ACME à Let's Encrypt, stocke le cert dans Secret Kubernetes. Zero CSR manuel, automation totale. C'est le pattern 2026 dominant en production K8s.

7. Cas d'usage où CSR manuel reste obligatoire en 2026

Malgré l'automation ACME + cert-manager, 5 cas nécessitent CSR manuel 2026 :

8. Erreurs fréquentes CSR et anti-patterns

9. Workflow CSR + ACME + automation 2026

Pipeline mature 2026 pour Web PKI public sur Kubernetes :

[Application]
    │
    ▼
[cert-manager Certificate resource]
    │
    │ génère automatiquement :
    ├─► clé privée ECDSA P-256
    ├─► CSR PKCS#10 avec SANs + KU + EKU
    └─► soumission ACME challenge
        │
        ▼
[Let's Encrypt CA via ACME RFC 8555]
    │
    ├─► HTTP-01 challenge (TLS-ALPN-01 ou DNS-01 selon)
    ├─► validation domaine
    └─► émission cert signé
        │
        ▼
[Kubernetes Secret tls-secret]
    │
    │ contient :
    ├─► tls.crt (cert signed)
    └─► tls.key (private key)
        │
        ▼
[Ingress / Gateway] mount le Secret pour TLS termination
    │
    ▼
[Trafic HTTPS production]
    │
    │ 30 jours avant expiration :
    ▼
[cert-manager re-génère NEW key + CSR + cert]
    │
    │ rotation transparente
    ▼
[Application restart automatique ou hot-reload]

Position tranchée 2026 : ce pattern automation totale est devenu le défaut Kubernetes, aucun CSR manuel sur le chemin production. L'ingénieur ne touche au CSR que pour debugging ou cas spéciaux.

10. Mapping CSR vers compliance frameworks 2026

11. Pour aller plus loin

• PKI - Public Key Infrastructure, l'umbrella infrastructure cryptographique dont le CSR est la première étape.
• IAM - Identity and Access Management, couche identity dans laquelle les certs client jouent un rôle.
• Zero Trust - Architecture et ZTNA, stratégie qui repose sur mTLS pervasif.
• RBAC - Role-Based Access Control, modèle d'autorisation post-authentication par cert.
• ABAC - Attribute-Based Access Control, autorisation contextuelle.
• Bootcamp DevSecOps, formation 12 semaines couvrant CSR, PKI, mTLS.
• Hub catégorie Glossaire cyber, autres définitions de référence Zeroday.
• RFC 2986 (PKCS#10) : https://datatracker.ietf.org/doc/html/rfc2986.
• RFC 7468 (PEM encoding) : https://datatracker.ietf.org/doc/html/rfc7468.
• CA/Browser Forum Baseline Requirements : https://cabforum.org/baseline-requirements-documents/.
• OpenSSL req documentation : https://docs.openssl.org/master/man1/openssl-req/.
• cfssl (Cloudflare) : https://github.com/cloudflare/cfssl.
• step CLI (Smallstep) : https://smallstep.com/docs/step-cli/.
• cert-manager (CNCF) : https://cert-manager.io/.
• Sigstore Cosign : https://docs.sigstore.dev/cosign/.
• NIST FIPS 204 ML-DSA : https://csrc.nist.gov/pubs/fips/204/final.

12. Points clés à retenir

• CSR = Certificate Signing Request, format PKCS#10 standardisé par RSA Labs 1998 + IETF RFC 2986 novembre 2000, encodage PEM (RFC 7468 avril 2015).
• Anatomie : Subject (DN) + Public Key + SANs + Extensions + Signature par clé privée du demandeur.
• CN seul déprécié depuis 2017 (CA/B Forum + Chrome 58 mai 2017). SANs obligatoires pour tous certs Web PKI 2026.
• OU déprécié depuis ballot CA/B Forum 2022, ne plus utiliser dans Subject.
• Algorithmes 2026 : ECDSA P-256 recommandé par défaut, RSA 2048-3072 acceptable, Ed25519 émergent, ML-DSA (FIPS 204 août 2024) en pilote post-quantum.
• Algorithmes signature 2026 : SHA-256+ obligatoire. SHA-1 et MD5 interdits depuis 2014-2017. ML-DSA pour PQC.
• Outils 2026 : OpenSSL (référence), cfssl (Cloudflare, JSON), step (Smallstep, ergonomie maximale), HashiCorp Vault PKI, AWS Private CA, Azure Key Vault.
• Automation totale via ACME (RFC 8555 mars 2019) + cert-manager (CNCF Graduated 2024), CSR généré sous le capot, zero manipulation manuelle en pattern Kubernetes moderne.
• 5 cas où CSR manuel reste obligatoire 2026 : EV/OV Web PKI, code signing (Apple, Microsoft), Sigstore Cosign, HSM-bound keys, CRA (rekey).
• Sigstore Cosign = modèle keyless signing CNCF Graduated 2024, certs éphémères 10 min via Fulcio + Rekor transparency log, recommandé CI/CD container signing.
• Validation systématique avant submit : openssl req -text -noout -verify -in csr.pem. Vérifier signature, Subject, SANs, KU/EKU, Public Key adéquats.
• Anti-pattern n°1 : utiliser un outil online qui stocke la clé privée → compromission garantie. Toujours générer en local.
• Anti-pattern n°2 : CSR avec CN seul sans SAN → refus toutes CAs publiques depuis 2017.
• Compliance : CSR mappe CA/Browser Forum Baseline Requirements (SAN obligatoire, OU déprécié, validity 90j émergent), NIST FIPS 203/204/205, NIST SP 800-57 + 800-131A, PCI-DSS v4.0 Req 4, NIS2 article 21, DORA article 9, ISO 27001:2022 A.8.24, eIDAS 2.0.