Pourquoi utiliser cet analyseur ?
Validez ce qui figurera sur votre certificat avant de l'envoyer à une autorité.
Détectez un SAN manquant, une clé trop courte, un algorithme faible, 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
- des informations d'identité sujet 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… qui délivre le certificat si la vérification passe DV, OV, EV.
Quand générer un CSR ?
- Création ou renouvellement d'un certificat TLS serveur web, API, MTA
- Ajout d'un SAN nouveau sous-domaine, nouveau FQDN
- Passage de RSA vers EC pour de meilleures performances
- Normalisation d'un parc hétérogène où les champs ne sont pas cohérents
Ce que doit contenir un bon CSR ?
- Subject CN parfois ignoré par les AC modernes, gardez-le mais ne comptez pas dessus seul
- SAN Subject Alternative Name la liste de tous les noms couverts, y compris le domaine nu si nécessaire
- Public Key type RSA 2048 min, idéal 3072 ou EC P-256/P-384
- Signature SHA-256 recommandé
- Éventuels Key Usage et Extended Key Usage selon vos besoins
Rappel
Sans SAN, beaucoup d'AC refusent. Un CN seul ne suffit plus.
Mode d'emploi
- Collez le CSR complet entre
-----BEGIN CERTIFICATE REQUEST-----et-----END CERTIFICATE REQUEST-----. - Cliquez Analyser le CSR.
- Lisez le résumé sujet, SAN, type et taille de clé, algorithme, empreintes.
- Corrigez et regénérez si un point bloque.
Exemples OpenSSL utiles
CSR RSA 3072 avec SAN
# 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
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
IDN
Utilisez le punycode xn--… dans les SAN pour éviter les surprises.
Dépannage et erreurs fréquentes
- SAN manquants le certificat couvrira moins de noms que prévu
- RSA 1024 ou SHA-1 refus probable
- Clé privée exposée ne collez jamais la clé privée ici ni dans un ticket
- Sélecteur de champs fantaisistes O, OU, L, ST, C inutiles en DV et sources d'incohérence en OV/EV
- IDN mal encodé passez par le punycode exact
- Wildcard *.exemple.com ajoutez aussi exemple.com si vous voulez couvrir le domaine nu
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é, personne à l'origine
- Tester la lecture du CSR après génération pour éviter un aller-retour avec l'AC
Engagement 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é et algorithme pour le suivi de disponibilité.