01
Vérifier le conteneur PEM
Collez un seul bloc CERTIFICATE REQUEST ou choisissez un fichier .csr local. Un certificat ou une clé privée ne sera pas interprété comme une demande.
Demandes de certificat
Décoder un CSR et générer un essai
Examinez d’abord une demande existante ; passez volontairement à la génération de test si une nouvelle paire de clés est nécessaire.
décoder un CSR
Entrée CSR PEM
Demande décodée
Collez un CSR ou chargez l’exemple.
Le décodage reste dans ce navigateur ; la clé de test est produite dans un cadre isolé.
Options de saisie
Le fichier est lu localement ; son remplacement demande confirmation. Une demande PEM, 256 Kio maximum.
Collez un CSR ou chargez l’exemple.
Avant un dépôt auprès de l’AC, décoder un CSR révèle un SAN manquant, un CN mal saisi ou une signature altérée. Le rapport distingue les noms demandés de la vérification cryptographique des octets signés. Le décodeur CSR présente les champs sans les confondre avec un certificat délivré.
Pourquoi décoder un CSR ici
Lire la demande et laisser toute clé privée produite dans un environnement séparé.
Sujet et noms demandés distincts
Décoder un CSR affiche séparément sujet, SAN DNS et IP, algorithme de clé et état de la signature. Vérifiez les hôtes avant toute délivrance.
Créer une clé hors de la page principale
Décoder un CSR se fait sur la page normale ; la génération de test tourne dans un cadre isolé. La clé privée ne se télécharge que depuis ce cadre.
Trois points à vérifier avant dépôt
Un bloc PEM lisible peut tout de même avoir une signature invalide.
02
Lire le verdict de signature
Décoder un CSR vérifie l’autosignature indépendamment des champs. Un succès prouve l’intégrité de la demande, pas la maîtrise du domaine.
03
Sauver la nouvelle clé
Le générateur de test ajoute le CN au SAN DNS. Téléchargez la clé privée avant de quitter le mode ou de recharger ; aucune copie durable n’est conservée.
Ce que le rapport établit réellement
Les vérifications portent sur les octets de la demande, sans contacter une autorité.
Noms et identité demandés
Décoder un CSR sépare le CN et les autres champs du sujet des SAN DNS et IP contenus dans extensionRequest.
Autosignature vérifiée
Décoder un CSR vérifie la signature avec la clé publique intégrée et distingue un échec d’un algorithme non vérifiable.
Paire de clés pour essai
Décoder un CSR partage cette URL avec un générateur manuel RSA 2048 ou EC P-256, tous deux en SHA-256.
Limites de la demande
- Aucun verdict de confiance
- Décoder un CSR ne vérifie ni l’émetteur, ni la durée de validité, ni la révocation : ces propriétés concernent un certificat délivré.
- Une seule demande
- Décoder un CSR accepte un bloc PEM de 256 Kio au plus. Tout bloc supplémentaire, Base64 incorrect ou dépassement est rejeté.
- Clé de test non protégée
- La clé PKCS#8 exportée dans le cadre isolé n’est pas chiffrée. Aucune clé existante n’est importée, sauvegardée ou envoyée à une AC.
Questions sur décoder un CSR
Pourquoi faut-il vérifier un CSR avant de le soumettre ?
Vérifier un CSR avant le dépôt permet de contrôler sujet, SAN et clé publique. Le rapport ne garantit pas l’acceptation par votre AC.
Comment lire les noms SAN d'un CSR ?
Les SAN se lisent dans les extensions demandées. Si la liste est vide, il faut générer une autre demande avec les noms nécessaires.
Peut-on modifier un CSR déjà signé ?
Non. Modifier les octets du sujet ou des SAN invalide la signature ; il faut créer et signer une nouvelle demande.
La signature du CSR est-elle vérifiée ?
Oui. Décoder un CSR vérifie l’autosignature avec la clé publique du bloc. Un algorithme non pris en charge reste « non vérifié ».
Quelle différence entre un CSR et un certificat ?
Un CSR demande un certificat ; il ne possède encore ni émetteur, ni numéro de série, ni date de fin de validité.
Un cas de CSR mérite-t-il une meilleure prise en charge ?
Décoder un CSR avant de l’envoyer
Vérifiez les noms demandés et la signature, puis enregistrez le rapport ou générez une clé de test dans le cadre isolé.