Pourquoi utiliser cet analyseur ?
Validez ce qui figurera sur votre certificat avant de l'envoyer à une autorité de certification (AC). Détectez un SAN manquant, une clé trop courte, un algorithme faible ou un encodage IDN douteux. Gagnez du temps lors d'un onboarding ou d'un renouvellement en lisant tout de suite les champs utiles.
Qu'est-ce qu'un CSR ?
Un Certificate Signing Request est un fichier texte au format PEM qui contient :
- Votre clé publique (RSA ou EC)
- Des informations d'identité : sujet (CN, O, OU, L, ST, C) et SAN
- Une signature faite avec votre clé privée pour prouver la possession
Le CSR est transmis à une AC (Let's Encrypt, DigiCert, GlobalSign, Sectigo...) qui délivre le certificat si la vérification passe (DV, OV ou EV).
Quand générer un CSR ?
| Cas d'usage | Description |
|---|---|
| Nouveau certificat | Création d'un certificat TLS pour serveur web, API, MTA |
| Renouvellement | Renouveler un certificat existant avec une nouvelle paire de clés |
| Ajout de SAN | Ajouter un nouveau sous-domaine ou FQDN au certificat |
| Migration RSA vers EC | Passer à une clé EC pour de meilleures performances |
| Normalisation | Harmoniser les champs d'un parc hétérogène |
Ce que doit contenir un bon CSR
Champs obligatoires
- SAN (Subject Alternative Names) : liste de tous les noms couverts, y compris le domaine nu si nécessaire. Sans SAN, beaucoup d'AC refusent.
- Clé publique : RSA 2048 bits minimum (idéal 3072) ou EC P-256/P-384
- Signature : SHA-256 recommandé (SHA-1 refusé)
Champs optionnels
- Subject CN : souvent ignoré par les AC modernes, mais gardez-le par compatibilité
- O, OU, L, ST, C : utiles pour OV/EV, inutiles pour DV
- Key Usage / Extended Key Usage : selon vos besoins spécifiques
Important : Un CN seul ne suffit plus. Les SAN sont obligatoires pour la plupart des AC.
Exemples OpenSSL
CSR RSA 3072 avec SAN
Fichier san.cnf :
[ req ]
prompt = no
distinguished_name = dn
req_extensions = v3_req
[ dn ]
CN = www.exemple.com
[ v3_req ]
subjectAltName = @alt
[ alt ]
DNS.1 = www.exemple.com
DNS.2 = exemple.com
Commande :
openssl req -new -newkey rsa:3072 -nodes -keyout site.key -out site.csr -config san.cnf
CSR EC P-256 avec SAN
openssl ecparam -name prime256v1 -genkey -noout -out site.key
openssl req -new -key site.key -out site.csr -config san.cnf
Domaines internationalisés (IDN)
Utilisez le punycode (xn--...) dans les SAN pour éviter les surprises d'encodage.
Erreurs fréquentes
| Erreur | Impact | Solution |
|---|---|---|
| SAN manquants | Certificat couvre moins de noms que prévu | Ajouter tous les domaines dans la section [alt] |
| RSA 1024 ou SHA-1 | Refus probable par l'AC | Utiliser RSA 2048+ et SHA-256 |
| Clé privée exposée | Compromission de sécurité | Ne jamais coller la clé privée en ligne |
| IDN mal encodé | Domaine non reconnu | Utiliser le punycode exact |
| Wildcard sans domaine nu | *.exemple.com ne couvre pas exemple.com | Ajouter les deux dans les SAN |
Bonnes pratiques
- Générer la paire de clés côté serveur et garder la clé privée hors de tout partage
- Préférer EC P-256/P-384 ou RSA 3072+ pour les nouveaux déploiements
- Limiter la liste des SAN à ce qui est réellement utile
- Conserver un journal : date, sujet, SAN, taille de clé, responsable
- Tester le CSR après génération pour éviter un aller-retour avec l'AC
Confidentialité
Votre CSR est envoyé à l'API CaptainDNS uniquement pour être décodé et affiché. Le contenu n'est pas conservé. Aucun champ n'est journalisé en clair. Seules des métriques techniques anonymes sont enregistrées (durée de traitement, taille, type de clé, algorithme) pour le suivi de disponibilité.