Visualiseur CSR

Le CSR Viewer analyse les Certificate Signing Requests (CSR) encodées en PEM et affiche toutes les informations qui apparaîtront dans le certificat résultant -- champs du sujet, SANs, détails de la clé publique et algorithme de signature -- afin que vous puissiez détecter les erreurs avant la soumission à une autorité de certification. Collez une CSR commençant par -----BEGIN CERTIFICATE REQUEST----- et visualisez instantanément chaque champ.

Comprendre les Certificate Signing Requests

Une Certificate Signing Request est la demande formelle que vous envoyez à une autorité de certification lorsque vous avez besoin d'un nouveau certificat. Elle contient vos informations d'identité (nom de domaine, détails de l'organisation), votre clé publique et une liste d'extensions demandées comme les Subject Alternative Names. La CSR est signée avec votre clé privée pour prouver que vous possédez la paire de clés correspondante. La CA examine ces informations, vérifie votre identité par validation de domaine ou validation d'organisation, et émet un certificat basé sur le contenu de la CSR.

Le point essentiel à comprendre est qu'une fois le certificat émis, corriger les erreurs coûte cher. Si vous avez soumis une CSR avec une faute de frappe dans le Common Name, une entrée SAN manquante ou le mauvais algorithme de clé, vous devrez générer une nouvelle CSR, la resoumettre et attendre que la CA la traite à nouveau. Pour les certificats Domain Validation via Let's Encrypt, c'est un inconvénient mineur. Pour les certificats Organization Validation ou Extended Validation auprès de CA commerciales, la réémission peut prendre des jours et peut entraîner des frais supplémentaires. Vérifier la CSR avant soumission vaut toujours les trente secondes nécessaires.

Ce visualiseur décode la CSR et présente chaque champ dans un format lisible. Vous pouvez vérifier que le Common Name correspond au domaine visé, que tous les Subject Alternative Names sont présents et correctement orthographiés, que l'algorithme et la taille de clé répondent à vos exigences, et que l'algorithme de signature est actuel. Le visualiseur signale également les problèmes potentiels comme les tailles de clé faibles, les algorithmes obsolètes ou les entrées SAN manquantes qui pourraient causer des problèmes lors de l'émission.

Comment visualiser une Certificate Signing Request

1. Collez votre CSR encodée en PEM (commençant par -----BEGIN CERTIFICATE REQUEST-----)
2. Le visualiseur extrait et affiche tous les champs de la CSR
3. Vérifiez les détails du sujet, les SANs, les informations de clé et les éventuels avertissements de validation
4. Confirmez l'exactitude avant de soumettre la CSR à votre CA

Exemple de sortie CSR

En collant une CSR multi-domaines typique :

Subject:
  Common Name (CN):  www.example.com
  Organization (O):  Example Inc.
  Locality (L):      San Francisco
  State (ST):        California
  Country (C):       US

Requested SANs:
  DNS: www.example.com
  DNS: example.com
  DNS: api.example.com
  DNS: cdn.example.com

Public Key:
  Algorithm:  RSA
  Key Size:   2048 bits

Signature:
  Algorithm:  SHA-256 with RSA

Vérifications de validation clés

Le visualiseur signale automatiquement les problèmes potentiels :

Quand utiliser cet outil

• Vérification avant soumission -- vérifiez une CSR avant de l'envoyer à une autorité de certification, en particulier pour les certificats coûteux EV (Extended Validation) ou OV (Organization Validation) où la réémission coûte du temps et de l'argent
• Audit automatisé de CSR -- vérifiez que les CSR générées par les clients ACME, Terraform, Ansible ou d'autres outils d'automatisation contiennent les bons domaines et détails d'organisation
• Débogage d'échecs d'émission de certificats -- lorsqu'une CA rejette une CSR, inspectez-la pour identifier les clés faibles, les champs manquants ou les problèmes de formatage
• Revue d'équipe -- auditez les CSR créées par d'autres membres de l'équipe avant leur soumission, en vous assurant que les conventions de nommage et la couverture des domaines sont correctes
• Comparaison CSR vs. certificat émis -- vérifiez que la CA a émis un certificat correspondant à ce qui a été demandé
• Vérification de l'algorithme de clé -- confirmez si une CSR utilise RSA ou ECDSA avant soumission, surtout lors d'une migration de type de clé

Comment fonctionnent les Certificate Signing Requests

Une CSR est un message envoyé par un demandeur à une autorité de certification pour demander un certificat d'identité numérique. La CSR contient :

1. Distinguished Name du sujet -- identifie le demandeur du certificat (champs CN, O, OU, L, ST, C)
2. Clé publique -- la clé publique du demandeur qui sera intégrée dans le certificat
3. Extensions demandées -- attributs supplémentaires comme les Subject Alternative Names
4. Signature -- la CSR est signée avec la clé privée du demandeur, prouvant qu'il possède la paire de clés correspondante

Générer une CSR avec OpenSSL

Une commande typique de génération de CSR :

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/C=US/ST=California/L=San Francisco/O=Example Inc./CN=www.example.com"

Pour les CSR avec SANs, vous avez besoin d'un fichier de configuration OpenSSL spécifiant l'extension subjectAltName, ou utilisez le flag -addext :

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/CN=www.example.com" \
  -addext "subjectAltName=DNS:www.example.com,DNS:example.com"

CSR vs. Certificat

Bonnes pratiques de revue de CSR

L'erreur de CSR la plus courante est d'oublier d'inclure le Common Name dans les Subject Alternative Names. Depuis Chrome 58 (sorti en 2017), les navigateurs ignorent entièrement le champ CN pour la validation des noms d'hôtes et ne vérifient que les SAN. Si votre CSR a CN=www.example.com mais pas d'entrée SAN DNS:www.example.com, le certificat émis produira des erreurs de non-correspondance de nom d'hôte dans tous les navigateurs modernes. Assurez-vous toujours que chaque domaine qui doit être couvert apparaît comme entrée SAN, y compris le CN lui-même.

Un autre problème fréquent est de générer une CSR avec une clé trop petite. Les CA n'émettront pas de certificats pour des clés RSA de moins de 2048 bits, et certains référentiels de conformité exigent RSA 4096 bits ou ECDSA P-384. Si vos outils d'automatisation ont des tailles de clé par défaut, vérifiez-les avant le déploiement en production. Régénérer une CSR avec une clé plus grande est simple ; découvrir le problème après que le certificat a été émis et déployé ne l'est pas.

Pour les équipes utilisant des outils d'infrastructure as code comme Terraform ou Ansible pour générer des CSR, intégrez une étape de vérification dans votre pipeline. Faites analyser et valider la CSR automatiquement avant qu'elle ne soit soumise à la CA. Cela détecte la dérive de configuration, les substitutions de variables incorrectes et les erreurs de template qui entraîneraient autrement des certificats avec de mauvais domaines ou des SAN manquants. Une simple vérification qui confirme que le CN et la liste SAN de la CSR correspondent aux valeurs attendues peut faire gagner des heures de dépannage.

Questions fréquentes

Une CA peut-elle modifier le contenu de ma CSR ? Oui. La CA contrôle ce qui figure dans le certificat final. Pour les certificats DV, les CA suppriment généralement les champs d'organisation et ne conservent que le CN et les SANs. Pour les certificats OV/EV, la CA vérifie et peut ajuster les détails de l'organisation. La CA définit toujours la période de validité, le numéro de série et les champs Issuer. Vérifier à la fois votre CSR et le certificat émis est une bonne pratique.

Pourquoi ma CSR affiche-t-elle SHA-256 with RSA alors que j'ai généré avec une clé ECDSA ? L'algorithme de signature dans la CSR reflète la façon dont la CSR elle-même a été signée, ce qui dépend du type de votre clé. Une clé ECDSA produit ecdsa-with-SHA256 ou similaire. Si vous voyez sha256WithRSAEncryption, votre clé est RSA. Vérifiez la section Public Key pour confirmer que l'algorithme et la taille de clé correspondent à vos attentes.

Dois-je inclure les SANs dans la CSR, ou la CA peut-elle les ajouter ? Cela dépend de la CA. La plupart des CA modernes vous permettent de spécifier les SANs lors du processus de commande, même s'ils ne sont pas dans la CSR. Cependant, inclure les SANs dans la CSR est une bonne pratique car cela documente votre intention et est exigé par certaines CA. Vérifiez toujours que le certificat émis inclut tous les SANs attendus.

Comment vérifier qu'une CSR et une clé privée correspondent ? Extrayez la clé publique de la CSR et de la clé privée, puis comparez-les. Avec OpenSSL : openssl req -in csr.pem -noout -pubkey et openssl pkey -in key.pem -pubout. Si la sortie est identique, la CSR a été générée avec cette clé privée. Le Public Key Extractor peut également aider avec cette comparaison.

Quelle est la différence entre PKCS#10 et une Certificate Signing Request ? C'est la même chose. PKCS#10 (RFC 2986) est le standard formel qui définit le format CSR. Lorsque les outils font référence à une « requête PKCS#10 » ou à une « CSR », ils désignent la même structure de données. L'en-tête PEM -----BEGIN CERTIFICATE REQUEST----- est utilisé pour les CSR PKCS#10.

Puis-je réutiliser une CSR après expiration du certificat ? Techniquement oui, si vous possédez toujours la clé privée correspondante. Cependant, la bonne pratique est de générer une nouvelle paire de clés et une nouvelle CSR pour chaque renouvellement. Cela limite la fenêtre d'exposition si la clé privée a été compromise à un moment donné pendant la durée de vie du certificat précédent.

Outils associés

• X.509 Certificate Viewer - Visualiser le certificat émis pour le comparer avec la CSR d'origine
• Public Key Extractor - Extraire la clé publique de la CSR et du certificat pour vérifier qu'elles correspondent
• SAN Extractor - Extraire les SANs du certificat émis pour confirmer que tous les domaines demandés sont couverts
• Certificate Fingerprint Generator - Générer les empreintes du certificat émis
• Certificate Expiry Checker - Vérifier la période de validité du certificat émis