CSR et émission d'un certificat

Portail > Cycle de vie

L'émission d'un certificat part d'une demande de signature (CSR, Certificate Signing Request) produite par le futur titulaire, puis signée par une autorité de certification. Cette page décrit la CSR et le déroulé de l'émission.

La CSR (PKCS#10)

Une CSR est une structure (format PKCS#10) générée par le demandeur, contenant :

• le sujet souhaité (DN) ;
• la clé publique du demandeur ;
• éventuellement des extensions souhaitées (SAN…) ;
• une signature de la CSR par la clé privée du demandeur.

Cette auto-signature constitue une preuve de possession : elle démontre que le demandeur détient bien la clé privée associée à la clé publique présentée. La clé privée ne quitte jamais le demandeur — la CSR ne la contient pas.

# Générer une clé puis une CSR
openssl req -new -newkey rsa:3072 -nodes \
  -keyout clipsy.key -out clipsy.csr \
  -subj "/C=FR/O=Nexiat/CN=clipsy.tech" \
  -addext "subjectAltName=DNS:clipsy.tech,DNS:www.clipsy.tech"

# Inspecter une CSR
openssl req -in clipsy.csr -noout -text -verify

Déroulé de l'émission

1. Génération de clé : le demandeur crée sa paire de clés (idéalement dans un HSM/TPM pour les usages sensibles).
2. Création de la CSR : sujet + clé publique + extensions souhaitées, auto-signée.
3. Soumission à la CA (ou à l'autorité d'enregistrement).
4. Vérification : la RA/CA contrôle l'identité et le droit du demandeur sur les noms réclamés.
5. Application de la politique : la CA décide des champs et extensions effectifs — validité, Key Usage, EKU, contraintes. Elle peut ignorer ou remplacer ce que demandait la CSR.
6. Signature : la CA signe le TBSCertificate avec sa clé privée (Signatures numériques et fonctions de hachage).
7. Délivrance : le certificat est remis, accompagné de sa chaîne d'intermédiaires.

<mermaid> flowchart LR

   K[Paire de clés] --> CSR[CSR auto-signée]
   CSR --> RA[Vérification RA/CA]
   RA --> POL[Politique + extensions]
   POL --> SIGN[Signature par la CA]
   SIGN --> CERT[Certificat + chaîne]

</mermaid>

(Schéma en Mermaid.)

Point important : la CSR ne décide pas

La CSR propose ; la CA dispose. Les extensions finales (validité, EKU, Basic Constraints, Name Constraints) sont fixées par la CA selon son profil/politique. Ne pas supposer qu'un champ présent dans la CSR se retrouvera tel quel dans le certificat émis.

Automatisation

Dans les environnements modernes, ce cycle est automatisé :

• ACME (Let's Encrypt et autres) : génération de CSR, validation de contrôle du domaine et émission sans intervention.
• cert-manager (Kubernetes) : objets CertificateRequest portant la CSR, émis par un Issuer/ClusterIssuer (ACME, CA interne, Vault…).
• Vault PKI : la CA est un moteur de secrets ; les rôles définissent la politique d'émission (noms autorisés, TTL, usages).

Points clés à retenir

• La CSR contient sujet + clé publique + preuve de possession (auto-signature) ; jamais la clé privée.
• La CA vérifie, applique sa politique, puis signe : c'est elle qui fixe les extensions finales.
• Le résultat est le certificat plus sa chaîne d'intermédiaires.
• ACME/cert-manager/Vault automatisent tout le cycle.

Voir aussi

• Cycle de vie d'un certificat
• Structure d'un certificat X.509
• Autorités de certification