PKI - Certificate Signing Request

1. Génération de la paire de clés

Le client génère localement une paire de clés asymétriques :

• Clé privée : conservée localement (jamais transmise)
• Clé publique : sera envoyée à la CA

openssl genpkey -algorithm RSA -out ma_cle_privee.pem -pkeyopt rsa_keygen_bits:2048

2. Création de la CSR (Certificate Signing Request)

Le client crée une CSR contenant sa clé publique et ses informations d'identité. Cette CSR est signée avec sa clé privée pour prouver sa possession.

openssl req -new -key ma_cle_privee.pem -out ma_demande.csr -subj "/CN=client.exemple.com/O=MonOrganisation"

3. Envoi de la CSR à la CA

Le client envoie la CSR à la CA via un canal sécurisé (HTTPS, ACME, SCEP, EST...).

4. Vérification et signature par la CA

La CA :

• Vérifie la signature de la CSR (preuve de possession de la clé privée)
• Vérifie l'identité (selon politique)
• Signe la CSR avec sa clé privée pour émettre un certificat X.509

5. Réception du certificat par le client

La CA renvoie un certificat signé. Le client peut l'utiliser avec sa clé privée locale pour s'authentifier ou chiffrer.

Diagramme du processus

[Client]                                   [CA]
   |                                          |
   |-- Génère clé privée/publique ----------->|
   |-- Crée CSR signée (clé publique) ------->|
   |                                          |
   |<-- Certificat signé (X.509) -------------|
   |                                          |

Exemple de signature côté CA

openssl x509 -req -in ma_demande.csr -CA ca-cert.pem -CAkey ca-key.pem \
    -CAcreateserial -out cert_client.pem -days 365 -sha256

Avantages

• ✅ Clé privée jamais transmise
• ✅ Sécurité maximale
• ✅ Conformité avec les standards (X.509, RFC, ANSSI, ISO)

Protocoles d’enrôlement compatibles

• ACME – Automatisation (ex: Let's Encrypt)
• EST – Enrôlement sécurisé pour entreprise
• SCEP – Appareils réseau / IoT
• CMP / CMC – PKI avancées

Validation de la légitimité de la CSR

🔐 1. Domain Validation (DV) – Validation du domaine

Pour les certificats les plus basiques (DV), la CA vérifie que le demandeur contrôle le domaine. Cela peut se faire par plusieurs moyens :

• Email : Un email est envoyé à une adresse standard (ex. admin@domaine.com, webmaster@domaine.com) avec un lien à cliquer pour prouver le contrôle.
• DNS : Le demandeur doit créer un enregistrement DNS spécifique (souvent un TXT record) fourni par la CA.
• Fichier HTTP : La CA demande au client d’héberger un fichier spécifique à une URL bien définie (ex : http://domaine.com/.well-known/...).

👉 Ces méthodes permettent à la CA de vérifier que la personne qui fait la demande contrôle bien le domaine. Mais aucune vérification d'identité de l'entreprise ou de la personne n’est faite.

🏢 2. Organization Validation (OV) – Validation de l'organisation

La CA vérifie en plus que :

• Le nom de l'organisation dans la CSR correspond à une entité légale enregistrée.
• L'entité existe réellement (vérification via des bases de données officielles, comme celles des chambres de commerce).
• Le demandeur a l'autorité pour représenter cette organisation.

Des échanges de documents ou appels téléphoniques sont parfois nécessaires.

🧾 3. Extended Validation (EV) – Validation étendue

C’est la validation la plus stricte, notamment pour les certificats HTTPS à haut niveau de confiance (ex : banques, grandes entreprises). Tous les éléments de la validation OV s'appliquent.

En plus, la CA doit vérifier l'identité de la personne faisant la demande (pièce d'identité, fonction dans l'entreprise). Vérification de l'autorité du signataire de la CSR.