probar - SSL: error: 0B080074: rutinas de certificado x509: X509_check_private_key: valores clave no coinciden

verificar certificado digicert (8)

Obtuve un hash MD5 con diferentes resultados para clave y certificado.

Esto lo dice todo. Usted tiene un desajuste entre su clave y certificado.

El módulo debe coincidir. Asegúrate de tener la clave correcta.

No puedo configurar SSL. Busqué en Google y encontré algunas soluciones, pero ninguna de ellas me funcionó. Necesito ayuda por favor...

Este es el error que recibo cuando intento reiniciar 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

Mi certificado es de StartSSL y es válido por 1 año.

Esto es lo que probé:

El certificado y la clave privada no tienen espacios finales.
No estoy usando el archivo server.key predeterminado.
Comprobé el nginx.conf y las directivas apuntan a la clave privada y el certificado correctos.

También verifiqué el módulo y obtuve un módulo diferente para la clave y el certificado.

Gracias por tu ayuda. :)

Esto también puede suceder cuando su CA emite un certificado intermedio

Me encontré con este problema (dos veces) con nginx y ninguna de las soluciones en esta publicación explicó el problema. La entrada del blog aquí, escrita por un buen caballero llamado Marco, fue clave y la estoy pegando aquí para cualquiera que también se encuentre con lo que estaba viendo. https://medium.com/@mrkdsgn/steps-to-install-a-go-daddy-ssl-certificate-on-nginx-on-ubuntu-14-04-ff942b9fd7ff

En mi caso, go-daddy fue la CA y esto es específico de cómo emiten el certificado y los paquetes intermedios de certificados.

Aquí está el extracto de la publicación de blog de Marco

Con Nginx, si su CA incluye un certificado intermedio, debe crear un solo archivo de certificado encadenado que contenga su certificado y los certificados intermedios de la CA.

Puede usar este comando para crear un archivo combinado llamado example.com.chained.crt:

cat example.com.crt intermediate.crt > example.com.chained.crt

Asegúrese de que su certificado y clave sean en formato PEM. Si no, conviértelos usando el comando openssl
Compruebe un hash MD5 de la clave pública para asegurarse de que coincida con lo que está en una clave privada
openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in privateKey.key | openssl md5

En mi caso, he querido cambiar el certificado ssl, porque he cambiado mi servidor, así que tuve que crear un nuevo csr con este comando:

$ openssl req -new -newkey rsa: 2048 -nodes -keyout mysite.key -out mysite.csr

He enviado el archivo mysite.csr al proveedor de la compañía ssl y luego de haber recibido el crt del certificado y luego he reiniciado nginx, y tengo este error

(SSL: error: 0B080074: rutinas de certificado x509: X509_check_private_key: valores clave no coinciden)

Después de mucha investigación, el error fue que el módulo del archivo de clave no era el mismo que el del archivo crt

Entonces, para hacer que funcione, he creado un nuevo archivo csr pero he cambiado el nombre del archivo con este comando

$ openssl req -new -newkey rsa: 2048 -nodes -keyout mysite_new.key -out mysite_new.csr

Luego recibí un nuevo archivo crt del proveedor de la compañía, reinicié nginx y funcionó.

Mis 5 centavos sobre el tema:

Tuve el mismo problema Después de aproximadamente 1 hora de cuidarlo, descubrí que pegué el certificado incorrectamente.

Si tiene un error como este, verifique su certificado.

Si esto sucede y está utilizando Let''s Encrypt / certbot, la razón es más probable que haya utilizado chain.pem lugar de fullchain.pem .

Debería ser algo como esto:

ssl_certificate /etc/certbot/live/example.com/fullchain.pem; ssl_certificate_key /etc/certbot/live/example.com/privkey.pem;

Ver certbot docs "¿Dónde están mis certificados?"

Tuve el mismo problema y finalmente lo resolví cambiando el orden de los bloques de pem en el archivo de certificado.

El bloque de cert debe ponerse al principio del archivo, luego en bloques intermedios, luego en el bloque de raíz.

Me di cuenta de este problema comparando un archivo de certificado problemático con un archivo de certificado en funcionamiento.

Una vez que haya establecido que no coinciden, todavía tiene un problema: qué hacer al respecto. A menudo, el certificado puede simplemente ensamblarse incorrectamente. Cuando un CA firma su certificado, le envían un bloque que se parece a algo

-----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-----

también le enviarán un paquete (a menudo dos certificados) que representan su autoridad para otorgarle un certificado. esto se verá algo así como

excepto que, lamentablemente, no estarán tan claramente etiquetados.

una práctica común, entonces, es agrupar todo esto en un solo archivo: su certificado y luego los certificados de firma. Pero como no se distinguen fácilmente, a veces sucede que alguien accidentalmente los coloca en el otro orden, firmando certificados, luego el certificado final, sin darse cuenta. En ese caso, su certificado no coincidirá con su clave.

Puede probar para ver qué cree el certificado que representa ejecutando

openssl x509 -noout -text -in yourcert.cert

Cerca de la parte superior, debería ver "Asunto:" y luego cosas que se parecen a sus datos. Si, en cambio, se parece a su CA, su paquete probablemente esté en el orden incorrecto; puede intentar hacer una copia de seguridad y luego mover el último certificado al principio, esperando que ese sea su certificado.

Si esto no funciona, puede que tenga que volver a emitir el certificado. Cuando hago una CSR, me gusta marcar claramente para qué servidor es (en lugar de solo ssl.key o server.key) y hacer una copia con la fecha en el nombre, como mydomain.20150306.key etc. de esa manera es poco probable que los pares de claves privadas y públicas se mezclen con otro conjunto.