Certificats serveur TLS
Sécurisez le trafic web à grande échelle
Inventaire des certificats
Découvrez et suivez tous vos certificats
Certificats DevOps
Automatisez pour les pipelines CI/CD
Chiffrement d'e-mails
S/MIME pour la messagerie d'entreprise
Directive NIS2
Obligations européennes en cybersécurité
DORA
Résilience opérationnelle numérique
eIDAS 2.0
Identification électronique et services de confiance
RGPD
Protection des données et vie privée
Cyber Resilience Act
Règlement européen sur la sécurité des produits
Un Certificate Signing Request (CSR) est la première étape pour obtenir un certificat numérique. Il contient votre clé publique et vos informations d'identité, signées avec votre clé privée. Ce guide explique ce qu'est un CSR, ce qu'il contient, comment en générer un et les erreurs courantes à éviter.
Un Certificate Signing Request (CSR) est un bloc de données encodées que vous envoyez à une autorité de certification (CA) lorsque vous demandez un certificat numérique. Le CSR contient votre clé publique ainsi que des informations d'identification sur votre organisation, et il est signé avec la clé privée correspondante pour prouver que vous la possédez.
Le format du CSR est défini par la norme PKCS#10 (RFC 2986). Lorsqu'une CA reçoit votre CSR, elle vérifie la signature, valide votre identité (selon le type de certificat), puis émet un certificat signé contenant votre clé publique et vos informations d'identité, lié par la signature numérique de la CA.
Considérez un CSR comme une demande formelle : vous renseignez vos informations, vous prouvez votre identité, et la CA y appose son autorité. La clé privée ne quitte jamais votre système ; seules la clé publique et les métadonnées sont transmises à la CA.
Créez une clé privée RSA de 2048 bits (ou utilisez ECDSA pour de meilleures performances) :
Générez le CSR à l'aide de la clé privée. Incluez les SAN directement sur la ligne de commande :
Avant de soumettre, vérifiez que le contenu du CSR est correct :
Soumettez le fichier server.csr à votre autorité de certification. La CA valide la demande et renvoie un certificat signé. Conservez server.key en sécurité et ne le partagez jamais.
Le nom de domaine principal ou le nom d'entité que le certificat protégera.
Le nom légalement enregistré de votre organisation. Utilisé dans les certificats OV et EV.
Un service ou une division. Ce champ est désormais déprécié par de nombreuses CA et peut être laissé vide.
Code pays ISO 3166-1 à deux lettres correspondant au lieu d'enregistrement légal de l'organisation.
La clé publique qui sera intégrée au certificat. Typiquement RSA 2048/4096 bits ou ECDSA P-256/P-384.
Le CSR est signé avec la clé privée correspondant à la clé publique, prouvant à la CA la possession de la clé.
Définir le CN avec le nom de l'organisation au lieu du nom de domaine. Pour les certificats TLS, le CN doit être le FQDN principal (par exemple, www.example.com), et non Example Inc.
Générer un CSR sans l'extension Subject Alternative Name. Les navigateurs ignorent le champ CN pour la correspondance d'identité depuis Chrome 58. Un certificat sans SAN déclenchera ERR_CERT_COMMON_NAME_INVALID.
Utiliser des clés RSA de 1024 bits, qui ne sont plus acceptées par aucune CA sérieuse. La plupart des CA exigent au minimum du RSA 2048 bits ou de l'ECDSA 256 bits. Consultez les exigences de votre CA avant de générer le CSR.
Générer un CSR puis perdre, supprimer ou écraser la clé privée. Sans la clé privée correspondante, le certificat émis est inutilisable. La seule solution est de générer une nouvelle paire de clés et de soumettre un nouveau CSR. Sauvegardez toujours la clé privée de manière sécurisée avant de soumettre le CSR.
# RSA 2048-bit key
openssl genrsa -out server.key 2048
# Or ECDSA P-256 key (recommended)
openssl ecparam -genkey -name prime256v1 -out server.key openssl req -new -key server.key -out server.csr \
-subj "/CN=www.example.com/O=Example Inc/C=US" \
-addext "subjectAltName=DNS:www.example.com,DNS:example.com" openssl req -in server.csr -noout -text -verify
# Check: subject, public key algorithm, key size, SANs, signature keytool -genkeypair -alias server -keyalg RSA -keysize 2048 \
-keystore keystore.jks -dname "CN=www.example.com,O=Example Inc,C=US"
keytool -certreq -alias server -keystore keystore.jks -file server.csr openssl req -in server.csr -noout -text
Certificate Request:
Data:
Version: 1 (0x0)
Subject: CN=www.example.com, O=Example Inc, C=US
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Attributes:
Requested Extensions:
X509v3 Subject Alternative Name:
DNS:www.example.com, DNS:example.com
Signature Algorithm: sha256WithRSAEncryption
[signature bytes...] Validation et politique des CSR — Evertrust PKI valide chaque CSR au regard des politiques de votre organisation avant d'émettre un certificat. Rejetez automatiquement les CSR avec clés faibles, sujets incorrects ou SAN non autorisés.
Éliminer les workflows manuels de CSR — Grâce à l'enrôlement via ACME et API REST, Evertrust CLM automatise l'intégralité du processus, de la génération de clé à l'installation du certificat. Plus besoin d'envoyer des fichiers CSR par e-mail ou de les coller dans des formulaires web.
Décoder et inspecter — Utilisez l'outil gratuit Crypto Decoder pour analyser n'importe quel CSR et en inspecter visuellement le contenu : sujet, SAN, algorithme de clé et signature.