SSL: erreur:0B080074:certificat x509 routines:X509 vérification de la clé privée:clé incompatibilité de valeurs
Je ne peux pas configurer SSL. J'ai Googlé et j'ai trouvé quelques solutions, mais aucune n'a fonctionné pour moi. J'ai besoin d'aide s'il vous plaît...
Voici l'erreur que j'obtiens quand je tente de redémarrer nginx:
root@s17925268:~# service nginx restart
Restarting nginx: nginx: [emerg] SSL_CTX_use_PrivateKey_file("/etc/nginx/conf.d/ssl/ssl.key") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)
nginx: configuration file /etc/nginx/nginx.conf test failed
mon certificat est de StartSSL et est valide pour 1 an.
voici ce que j'ai testé:
- le certificat et la clé privée ne comportent pas d'espace de retrait.
- Je n'utilise pas le serveur par défaut.fichier de clé.
- j'ai vérifié le nginx.conf et le les directives pointent vers la clé privée et le certificat corrects.
j'ai aussi vérifié le module, et j'obtiens un module différent pour la clé et le certificat.
Merci pour votre aide. :)
10 réponses
j'ai eu un hachage MD5 avec des résultats différents pour la clé et le certificat.
ça dit tout. Vous avez un décalage entre votre clé et le certificat.
Le module doit correspondre. Assurez-vous que vous avez la bonne clé.
une Fois que vous avez établi qu'ils ne correspondent pas, vous avez encore un problème: que faire à ce sujet. Souvent, le certificat peut simplement être mal assemblé. Lorsqu'une AC signe votre certificat, elle vous envoie un bloc qui ressemble à
-----BEGIN CERTIFICATE-----
MIIAA-and-a-buncha-nonsense-that-is-your-certificate
-and-a-buncha-nonsense-that-is-your-certificate-and-
a-buncha-nonsense-that-is-your-certificate-and-a-bun
cha-nonsense-that-is-your-certificate-and-a-buncha-n
onsense-that-is-your-certificate-AA+
-----END CERTIFICATE-----
ils vous enverront aussi un paquet (souvent deux certificats) qui représente leur autorité pour vous accorder un certificat. cela ressemblera à quelque chose comme
-----BEGIN CERTIFICATE-----
MIICC-this-is-the-certificate-that-signed-your-request
-this-is-the-certificate-that-signed-your-request-this
-is-the-certificate-that-signed-your-request-this-is-t
he-certificate-that-signed-your-request-this-is-the-ce
rtificate-that-signed-your-request-A
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICC-this-is-the-certificate-that-signed-for-that-one
-this-is-the-certificate-that-signed-for-that-one-this
-is-the-certificate-that-signed-for-that-one-this-is-t
he-certificate-that-signed-for-that-one-this-is-the-ce
rtificate-that-signed-for-that-one-this-is-the-certifi
cate-that-signed-for-that-one-AA
-----END CERTIFICATE-----
sauf que malheureusement, ils ne seront pas clairement étiquetés.
une pratique courante consiste donc à regrouper tout cela en un seul fichier -- votre certificat, puis les certificats de signature. Mais comme ils ne sont pas faciles à distinguer, il arrive parfois que quelqu'un les mette accidentellement dans l'autre ordre -- signer des certs, puis le dernier cert -- sans s'en rendre compte. Dans ce cas, votre certificat ne correspondra pas à votre clé.
vous pouvez tester pour voir ce que le cert pense représente en exécutant
openssl x509 -noout -text -in yourcert.cert
Près du haut, vous devriez voir "Sujet:" et puis des trucs qui ressemble à vos données. Si au contraire il ressemble à votre CA, votre paquet est probablement dans le mauvais ordre; vous pourriez essayer de faire une sauvegarde, puis déplacer le dernier cert au début, en espérant que ce soit celui qui est votre cert.
si cela ne fonctionne pas, vous pourriez avoir juste à obtenir le cert ré-émis. Quand je fais un CSR, j'aime étiqueter clairement quel serveur c'est pour (au lieu de simplement ssl.clé ou d'un serveur.key) et faire une copie de celui-ci avec la date dans le nom, comme mydomain.20150306.clé etc. de cette façon, il est peu probable que les couples de clés privées et publiques se retrouvent avec un autre ensemble.
- assurez-vous que votre certificat et votre clé sont au format PEM. Si ce n'est pas le cas, convertissez-les en utilisant la commande openssl
-
vérifier un hachage MD5 de la clé publique pour s'assurer qu'il correspond à ce qui est dans une clé privée
openssl x509-noout-module-in certificate.crt / openssl md5
openssl RSA-noout-module-in privateKey.key / openssl md5
si cela se produit et que vous utilisez Let's Encrypt / certbot, la raison est très probablement que vous avez utilisé chain.pem
au lieu de fullchain.pem
.
ça devrait être quelque chose comme ça:
ssl_certificate /etc/certbot/live/example.com/fullchain.pem;
ssl_certificate_key /etc/certbot/live/example.com/privkey.pem;
j'ai eu le même problème et résolu en changeant l'ordre des pem blocs dans le fichier de certificat.
le bloc cert doit être mis au début du fichier, puis les blocs intermédiaires, puis le bloc root.
j'ai réalisé ce problème en comparant un fichier de certificat problématique avec un fichier de certificat de travail.
j'ai eu ce problème parce que j'ai ajouté le paquet et le certificat dans le mauvais ordre donc peut-être cela pourrait aider quelqu'un d'autre.
avant (qui est erroné) :
cat ca_bundle.crt certificate.crt > bundle.crt
après (ce qui est juste)
cat certificate.crt ca_bundle.crt > bundle.crt
De la nginx man :
si le certificat du serveur et le paquet ont été concaténées dans le mauvais ordre, nginx ne démarre pas et affiche le message d'erreur:
SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed
(SSL: error:0B080074:x509 certificate routines:
X509_check_private_key:key values mismatch)
dans mon cas, j'ai voulu changer le certificat ssl, parce que j'ai changé mon serveur, donc j'ai dû créer un nouveau csr avec cette commande:
$openssl req-new -newkey rsa:2048 -nœuds -keyout monsite.key-out monsite.la rse
j'ai envoyé mysite.csr fichier à la société fournisseur ssl et après que j'ai reçu le certificat crt et puis j'ai redémarré nginx , et j'ai cette erreur
(SSL: erreur: 0B080074: x509 routines de certificat: X509_check_private_key: décalage des valeurs clés)
après une longue enquête, l'erreur était que le module de key file n'était pas le même que celui du crt file
, afin de le faire fonctionner, j'ai créé un nouveau fichier csr mais j'ai changer le nom du fichier avec cette commande
$openssl req-new-newkey rsa:2048-nodes-keyout mysite_new.key-out mysite_new.la rse
alors j'ai eu reçu un nouveau fichier crt de la part du fournisseur de la compagnie, redémarrez nginx et cela a fonctionné.
Mes 5 cents sur la question:
j'ai eu le même problème. Après environ 1 heure de soins, je me suis rendu compte que j'avais mal collé le certificat.
si vous avez une erreur comme celle-ci, veuillez vérifier votre certificat.
cela peut aussi se produire lorsque votre AC émet un certificat intermédiaire
j'ai rencontré ce problème (deux fois) avec nginx et aucune des solutions dans ce post n'a expliqué le problème. Le billet de blog ici par un gentilhomme gentil nommé Marco cloué, et je le colle ici pour tous ceux qui court aussi dans ce que je voyais. https://medium.com/@mrkdsgn/steps-to-install-a-go-daddy-ssl-certificate-on-nginx-on-ubuntu-14-04-ff942b9fd7ff
dans mon cas, go-daddy était L'AC et ceci est spécifique à la façon dont ils émettent le cert et les faisceaux de cert intermédiaires.
Voici l'extrait du blog de Marco
avec Nginx, si votre AC incluait un certificat intermédiaire, vous devez créer un seul fichier de certificat enchaîné qui contient votre certificat et les certificats intermédiaires de l'AC.
Vous pouvez utiliser cette commande pour créer un fichier combiné appelé exemple.com.enchaîné.crt:
cat example.com.crt intermediate.crt > example.com.chained.crt
Pour Nginx;
1-openssl req-newkey rsa:2048-nodes-keyout domain.com.domaine key-out.com.csr
2-Fichier SSL domain_com.crt et domain_com.ca-bundle file copie le nouveau fichier dans le domaine paste.com.enchaîné.151910920"
3 - Ajouter des fichiers nginx: un. ssl_certificate /home/utilisateur/domain_ssl/domaine.com.enchaînés.crt; B. ssl_certificate_key/home/user/domain_ssl / domain.com.clé;
Lates restart Nginx