Problème d'installation SSL - "incompatibilité valeur-clé" (mais ils correspondent?)
J'ai donc reçu un nouveau certificat public à installer sur un serveur (fichier .crt). Terminé. Redémarrez Apache - "ECHEC".
Message d'erreur:
[Tue Jan 11 12:51:37 2011] [error] Unable to configure RSA server private key
[Tue Jan 11 12:51:37 2011] [error] SSL Library Error: 185073780 error:0B080074:
x509 certificate routines:X509_check_private_key:key values mismatch
J'ai vérifié les valeurs clés:
openssl rsa -noout -modulus -in server.key | openssl md5
openssl x509 -noout -modulus -in server.crt | openssl md5
et ils correspondent.
J'ai vérifié les chemins dans mon fichier ssl.conf, et ils pointent vers les fichiers corrects.
Si je rétablis l'ancien fichier de certificat (expiré), Apache démarre correctement et n'aime donc absolument pas le nouveau.
C'est un GeoTrust QuickSSL, et il est venu avec un "intermediate.crt" que je suis censé utiliser à la place du fichier "ca-bundle.crt" que j'utilisais auparavant
SSLCertificateFile /etc/pki/tls/certs/www.domain.com.crt
SSLCertificateKeyFile /etc/pki/tls/private/www.domain.com.key
SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt
Des idées que je pourrais faire mal? Plus d'infos dont vous avez besoin?
Merci!
J'ai aussi rencontré la même erreur. Dans mon cas, je devais fournir des certificats CA supplémentaires dans la chaîne de vérification. Et au lieu de fournir le certificat et la clé dans des fichiers séparés, je les ai combinés dans un fichier .pem.
Toutefois, dans ce cas, l’ordre de la clé et du certificat, ainsi que le ou les intermédiaires, est important. Le bon ordre:
your private key
your certificate
(intermediate) CA certificate lowest in the hierarchy
other CA certificates higher in the hierarchy...
(intermediate) CA certificate highest in the hierarchy
Lors de la réémission de mon certificat Rapid SSL (acheté via Namecheap) pour traiter le bogue Heartbeat, le nouveau certificat était toujours émis avec la clé privée utilisée pour la précédente demande de CSR. Après environ la cinquième réédition, le jumelage avec la clé privée utilisée lors de la quatrième tentative de réémission a permis de résoudre le problème.
Pour quiconque est aux prises avec ce problème ...
J'ai eu le même problème récemment sur l'un de mes serveurs CentOS 6.5 et c'était au moment où j'ai généré la clé et la CSR.
J'ai trois sites fonctionnant sur ce serveur dans virtualhosts, tous avec des adresses IP dédiées et chaque site a son propre certificat SSL.
Lorsque je changeais rapidement l'un des certificats, je suivais stupidement le guide des fournisseurs de certificats pour obtenir le CSR et l'installer dans Apache. On m'a alors demandé d'utiliser la commande suivante:
openssl req -new -newkey rsa:2048 -nodes -keyout domain-name-here.key -out domain-name-here.csr
Après avoir installé le nouveau certificat, je devais également faire face à Apache et ne pas démarrer avec les mêmes erreurs dans /var/log/httpd/ssl_error_log:
[error] SSL Library Error: 185073780 error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch
[error] Unable to configure RSA server private key
Maintenant, ce que j’aurais vraiment dû faire, c’était de vérifier mes fichiers .bash_history, comme j’ai réussi à le faire plusieurs fois auparavant dans CentOS.
J'aurais dû exécuter ces deux commandes à la place:
openssl genrsa -des3 -out domain-name-here.co.uk.key 2048
openssl req -new -key domain-name-here.co.uk.key -out domain-name-here.co.uk.csr
Cela a ensuite généré avec succès la CSR et la KEY. J'ai redemandé le certificat en utilisant la CSR récemment acquise, puis j'ai appliqué le nouveau certificat et ajouté le nouveau fichier de clé. Apache a finalement démarré proprement.
Aussi, juste pour noter qu'après une petite configuration, nous marquons maintenant A + dans un test de laboratoire SSL.
assurez-vous que tous les fichiers de cert sont encodés en utilisant ANSI, pas UTF-8.
Pour moi, tous les tests ont dit: key, crt et csr correspondent, mais les journaux ont indiqué X509_check_private_key:key values mismatch jusqu'à ce que je voie qu'un des fichiers était encodé en UTF-8.
Dans mon cas, j'avais deux sites et deux clés privées différentes:
nginx: [emerg] SSL_CTX_use_PrivateKey_file("/some/path/server.key") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)
Après avoir résolu ce problème, le message d'erreur a été modifié pour mentionner /some/path/server.pem. Notez les différentes clés privées, qui ne diffèrent que par l’extension du fichier. J'avais 2 sites différents chiffrés avec des clés différentes (ce qui signifie que j'avais corrigé le premier site, mais que je devais maintenant réparer le deuxième site). Veillez donc à lire attentivement le message d'erreur!
Dynadot semble avoir les mêmes problèmes avec les certificats RapidSSL qu’ils réémettent. Je viens juste de recevoir un certificat qui ne fonctionnait pas, ce qui a ensuite déclenché un autre problème avec Apache. Lorsque ce problème a été résolu, j'ai trouvé cette question et je répondais ici pour le problème initial, merci pour l'information fournie à tous. Je vais éliminer le certificat RapidSSL car j’ai quand même quelques problèmes de compatibilité avec le client et en acheter un nouveau chez AlphaSSL à la place.
Selon la FAQ du site Web Apache, le module et l'exposant public du cert et de la clé doivent correspondre, ce qui constitue un contrôle valide.
http://httpd.Apache.org/docs/2.0/ssl/ssl_faq.html#verify
Comme vous et d'autres l'avez déjà indiqué, travaillez avec l'émetteur de certificats
La partie la plus délicate dans mon cas est la configuration de la SSLCACertificateFile. Une fois que la société de certification a délivré notre certificat, nous avons également reçu deux certificats supplémentaires: un certificat intermédiaire et un certificat racine. Lequel utiliser pour SSLCACertificateFile? Tous les deux..
Voici à quoi ressemble ma chaîne de certificats:
Et pour la SSLCACertificateFile je dois concaténer digicert_sha2_high_assurance_server_ca.crt et digicert.crt dans un fichier dans l’ordre indiqué.
Nous avions également un problème avec NameCheap: le certificat émis correspondait au CSR utilisé pour générer le CERT précédent. Nous leur avons fait savoir via leur page de support, et ils ont dit qu'ils étaient déjà au courant du problème.