Clé privée
C’est l’une des questions les plus fréquentes que nous recevons. Malheureusement, nous ne pouvons pas vous envoyer la clé privée, car elle est privée et nous ne la stockons nulle part dans notre système ou notre base de données. La clé privée est toujours confidentielle et vous êtes le seul à la détenir. Si nous devions posséder ou stocker votre clé privée, cela compromettrait la “sécurité” de votre certificat SSL.
Si vous avez utilisé le générateur de CS R sur notre site web pour générer votre code CSR, la CSR et la clé privée vous ont été présentées au cours du processus de génération de la CSR. Ils ont également été envoyés à votre adresse électronique au cas où vous l’auriez incluse dans le générateur de RSE. Le message qui a été envoyé à votre adresse électronique provient de [email protected] et a le sujet suivant : “Votre code CSR et votre clé privée”.
Si vous avez généré votre CSR sur votre serveur, votre code CSR et votre clé privée vous ont été fournis par votre serveur. Vous deviez les copier et les conserver en lieu sûr. Dans certains cas, certains serveurs peuvent afficher le code CSR et la clé privée, et en même temps stocker ces deux éléments de code pour vous sur le serveur. Dans d’autres cas, le serveur ne vous fournit que le code CSR et garde la clé privée cachée sur le serveur.
Ceci étant dit, veuillez rechercher la clé privée dans votre adresse e-mail ou sur votre serveur. Si vous ne le trouvez pas, vous devrez générer un nouveau code CSR sur votre serveur ou sur le générateur CSR sur notre site web. Le code CSR est accompagné d’une clé privée.
Une fois qu’un nouveau code CSR (et une nouvelle clé privée) ont été générés, vous devez vous rendre sur la page des détails du certificat SSL dans votre compte SSL Dragon, et cliquer sur le bouton “Rééditer le certificat” dans la barre latérale gauche de la page. Vous devrez à nouveau passer la validation du domaine, et une fois que vous l’aurez fait, le certificat SSL vous sera réémis sur la base du nouveau code CSR que vous avez saisi. En outre, le certificat SSL réémis sera associé à la clé privée qui accompagne le nouveau code CSR.
Si vous ne trouvez pas le Le bouton “Rééditer le certificat” sur la page des détails du certificat SSL dans votre compte SSL Dragon, puis envoyez-nous le nouveau code CSR via un ticket de support dans votre compte SSL Dragon, ou directement à [email protected] et nous générerons à nouveau le certificat SSL pour vous, en utilisant le nouveau code CSR. Ne nous envoyez pas votre clé privée car elle est confidentielle. Conservez-la en lieu sûr dans votre courrier électronique ou votre ordinateur, car vous en aurez besoin lors de l’installation de votre certificat SSL.
Copier le lien
Vous pouvez vérifier l’intégrité d’un certificat SSL et d’une paire de clés privées à l’aide de l’utilitaire
OpenSSL
et ses lignes de commande.
Le processus se déroule en quatre étapes :
- Vérifiez que la clé privée n’a pas été modifiée.
- Vérifier la correspondance entre la valeur du module, la clé privée et la paire de certificats SSL.
- Cryptage avec la clé publique du certificat et décryptage avec la clé privée.
- Confirmer l’intégrité du fichier, qui est signé avec la clé privée.
Vérifier l’intégrité de la clé privée
Exécutez la commande suivante : openssl rsa -in [key-file .key] -check -noout
Voici un exemple de clé privée corrompue :
D’autres erreurs résultant d’une clé altérée ou falsifiée sont énumérées ci-dessous :
- Erreur de clé RSA : p n’est pas premier
- Erreur de clé RSA : n n’est pas égal à p q
- Erreur de clé RSA : d e non congru à 1
- Erreur de clé RSA : dmp1 non congruent à d
- Erreur de clé RSA : iqmp n’est pas l’inverse de q
Si vous avez rencontré l’une des erreurs ci-dessus, votre clé privée a été altérée et peut ne pas fonctionner avec votre clé publique. Envisagez de créer une nouvelle clé privée et de demander un certificat de remplacement.
Voici un exemple de clé privée qui respecte l’intégrité :
Vérifier la correspondance entre la valeur du module, la clé privée et la paire de certificats SSL.
Remarque :
Le module de la clé privée et du certificat doit correspondre exactement.
Pour afficher le module du certificat, exécutez la commande suivante :
openssl x509 -noout -modulus -in [certificate-file .cer]
Pour afficher la clé privée Modulus, exécutez la commande :
openssl rsa -noout -modulus -in [key-file .key]
Cryptage avec la clé publique et décryptage avec la clé privée
1. Obtenez la clé publique du certificat:
openssl x509 -in [certificate-file .cer] -noout -pubkey > certificatefile.pub.cer
2. Chiffrer le contenu du fichier test.txt à l’aide de la clé publique
Créez un nouveau fichier appelé test.txt (vous pouvez utiliser le Bloc-notes) avec le contenu “message test”. Exécutez la commande suivante pour créer un message crypté dans le fichier cipher.txt.
openssl rsautl -encrypt -in test.txt -pubin -inkey certificatefile.pub.cer -out cipher.txt
3. Décryptage de cipher.txt à l’aide de la clé privée
Exécutez la commande suivante pour décrypter le contenu de cipher.txt.
openssl rsautl -decrypt -in cipher.txt -inkey [key-file .key]
Assurez-vous que vous pouvez déchiffrer le contenu de votre fichier cipher.txt sur votre terminal. La sortie du terminal doit correspondre au contenu du fichier test.txt.
Si le contenu ne correspond pas, la clé privée a été altérée et peut ne pas fonctionner avec votre clé publique. Envisagez de créer une nouvelle clé privée et de demander un certificat de remplacement. Voici un exemple de message décrypté :
4. Confirmer l’intégrité du fichier signé avec la clé privée
Exécutez la commande suivante pour signer les fichiers test.sig et test.txt avec votre clé privée :
openssl dgst -sha256 -sign [key-file .key] -out test.sig test.txt
Maintenant, vérifiez les fichiers signés avec votre clé publique extraite à l’étape 1.
openssl dgst -sha256 -verify certificatefile.pub.cer -signature test.sig test.txt
Assurez-vous que la sortie du terminal est exactement comme dans l’exemple ci-dessous :
Si votre clé privée est falsifiée, vous recevrez le message suivant :
Dans ce cas, vous devez créer une nouvelle clé privée et demander un certificat de remplacement.
Source : Base de connaissances de Digicert
Copier le lien
Il arrive que le certificat SSL qui vous a été délivré ne corresponde pas à la clé privée que vous essayez d’utiliser lors de l’installation de ce certificat SSL sur votre serveur. Il s’agit d’une erreur fréquente de l’utilisateur.
Si le système indique qu’il y a incompatibilité, vous devez revérifier la CSR et la clé privée que vous avez générées et qui ont été réunies. Vous devez vous assurer que vous avez utilisé cette CSR spécifique lorsque vous avez configuré votre certificat SSL. Lorsque le certificat SSL est émis, vous devez utiliser la clé privée associée à cette CSR spécifique.
Nous voyons des clients commettre l’erreur de générer une RSC et une clé privée, puis de configurer le certificat SSL avec une RSC différente générée par le serveur. Dans ce cas, le serveur a généré des paires CSR avec sa propre clé privée que vous ne possédez probablement pas.
La clé privée que vous possédez ne fonctionne qu’avec la CSR qui l’accompagne. En outre, la clé privée dont vous disposez ne fonctionne qu’avec le certificat SSL qui a été configuré à l’aide de la RSC associée à cette clé privée.
Solution
Pour résoudre ce problème, vous devez reconfigurer (réémettre) votre certificat SSL à l’aide d’un code CSR pour lequel vous disposez de la clé privée avec laquelle il est associé. Vous pouvez utiliser un code CSR fourni par votre serveur ou générer un nouveau code CSR et une nouvelle clé privée.
Copier le lien
À partir du 1er juin 2023, les normes industrielles imposent de stocker les clés privées des certificats de signature de code sur du matériel certifié FIPS 140 niveau 2, Common Criteria EAL 4+. Cette modification renforce la sécurité et s’aligne sur les normes de signature du code EV. Les autorités de certification ne peuvent plus prendre en charge la génération de clés par navigateur ou les installations sur ordinateur portable/serveur. Les clés privées doivent se trouver sur des tokens/HSM certifiés FIPS 140-2 niveau 2 ou Common Criteria EAL 4+. Pour signer le code, accédez au token/HSM et utilisez les informations d’identification du certificat stocké.
Conformément aux nouvelles lignes directrices, votre clé privée doit se trouver sur le jeton expédié par l’autorité de certification ou sur votre module de sécurité matériel.
Copier le lien