wake-up-neo.net

SSL: Fehler: 0B080074: X509-Zertifikatroutinen: X509_check_private_key: Nicht übereinstimmende Schlüsselwerte

Ich kann kein SSL einrichten. Ich habe gegoogelt und ein paar Lösungen gefunden, aber keine davon hat für mich funktioniert. Ich brauche Hilfe, bitte ...

Hier ist der Fehler, den ich bekomme, wenn ich versuche, nginx neu zu starten:

[email protected]:~# 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

Mein Zertifikat stammt von StartSSL und ist ein Jahr gültig.

Folgendes habe ich getestet:

  • Das Zertifikat und der private Schlüssel haben keine Leerzeichen.
  • Ich verwende nicht die Standardserver.key-Datei.
  • Ich habe überprüft, dass die Anweisungen nginx.conf und auf den richtigen privaten Schlüssel und das richtige Zertifikat zeigen.

Ich habe auch den Modul geprüft und erhalte einen unterschiedlichen Modul für Schlüssel und Zertifikat.

Danke für deine Hilfe. :)

sslnginxopensslcertificatekey
69
Galou

Ich habe einen MD5-Hash mit unterschiedlichen Ergebnissen für Schlüssel und Zertifikat erhalten.

Das sagt alles. Sie haben keine Übereinstimmung zwischen Ihrem Schlüssel und dem Zertifikat.

Der Modul sollte übereinstimmen. Stellen Sie sicher, dass Sie den richtigen Schlüssel haben.

29
dev0z

Wenn Sie festgestellt haben, dass sie nicht übereinstimmen, haben Sie immer noch ein Problem - was Sie dagegen tun können. Oft wird das Zertifikat nur falsch zusammengestellt. Wenn eine Zertifizierungsstelle Ihr Zertifikat signiert, sendet sie Ihnen einen Block, der ungefähr so ​​aussieht 

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

sie senden Ihnen auch ein Bündel (oft zwei Zertifikate), das ihre Befugnis zur Erteilung eines Zertifikats darstellt. Das wird ungefähr so ​​aussehen 

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

abgesehen davon werden sie leider nicht so eindeutig gekennzeichnet. 

daher ist es üblich, diese in einer Datei zu bündeln - Ihrem Zertifikat und dann den signierenden Zertifikaten. Da sie jedoch nicht leicht unterschieden werden können, passiert es manchmal, dass jemand sie versehentlich in die andere Reihenfolge bringt - Signierzertifikate und dann das endgültige Zertifikat - ohne es zu merken. In diesem Fall stimmt Ihr Zertifikat nicht mit Ihrem Schlüssel überein. 

Sie können testen, um zu sehen, was das Zertifizierungssystem für es hält, indem Sie es ausführen

openssl x509 -noout -text -in yourcert.cert

Oben sollten Sie "Betreff:" und dann Dinge sehen, die wie Ihre Daten aussehen. Wenn es stattdessen wie Ihre Zertifizierungsstelle aussieht, ist Ihr Paket wahrscheinlich in der falschen Reihenfolge. Sie können versuchen, ein Backup zu erstellen und dann das letzte Zertifikat an den Anfang zu verschieben, in der Hoffnung, dass dies das ist, das Ihr Zertifikat ist.

Wenn dies nicht funktioniert, müssen Sie möglicherweise das Zertifikat erneut ausstellen lassen. Wenn ich eine CSR mache, benenne ich gerne eindeutig, für welchen Server (statt nur ssl.key oder server.key) und mache eine Kopie davon mit dem Datum im Namen, wie z. B. mydomain.20150306.key usw. Es ist unwahrscheinlich, dass die privaten und öffentlichen Schlüsselpaare mit einem anderen Satz verwechselt werden. 

143
Vynce
  1. Stellen Sie sicher, dass Ihr Zertifikat und Ihr Schlüssel das PEM-Format haben. Wenn nicht, dann konvertieren Sie sie mit dem Befehl openssl

  2. Überprüfen Sie einen MD5-Hash des öffentlichen Schlüssels, um sicherzustellen, dass er mit dem in einem privaten Schlüssel enthaltenen übereinstimmt

    openssl x509 -noout -modulus -in certificate.crt | openssl md5

    openssl rsa -noout -modulus -in privateKey.key | openssl md5

57
dev0z

Ich hatte dieses Problem, weil ich Bündel und Zertifikat in falscher Reihenfolge hinzugefügt habe. Vielleicht könnte dies jemand anderem helfen.

Vorher (was falsch ist):

cat ca_bundle.crt certificate.crt > bundle_chained.crt

Nach (was richtig ist)

cat certificate.crt ca_bundle.crt > bundle_chained.crt

Und bitte vergessen Sie nicht, das entsprechende conf (ssl_certificate muss jetzt auf den verketteten crt zeigen) zu aktualisieren

server {
    listen              443 ssl;
    server_name         www.example.com;
    ssl_certificate     bundle_chained.crt;
    ssl_certificate_key www.example.com.key;
    ...
}

Aus der nginx-Manpage :

Wenn das Serverzertifikat und das Bundle in der falschen Reihenfolge verkettet wurden, wird nginx startet nicht und zeigt die Fehlermeldung an:

SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed
   (SSL: error:0B080074:x509 certificate routines:
    X509_check_private_key:key values mismatch)
12
Mandeep Gill

Wenn dies der Fall ist und Sie Let's Encrypt/certbot verwenden, ist es wahrscheinlich, dass Sie chain.pem statt fullchain.pem verwendet haben.

Es sollte ungefähr so ​​sein:

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

Siehe certbot docs "Wo sind meine Zertifikate?"

8
Marian

Ich hatte das gleiche Problem und löste es schließlich durch Ändern der Reihenfolge der Pem-Blöcke in der Zertifikatsdatei.

Der cert-Block sollte am Anfang der Datei stehen, dann Zwischenblöcke und dann Root-Block.

Ich habe dieses Problem erkannt, indem ich eine problematische Zertifikatdatei mit einer funktionierenden Zertifikatdatei verglichen habe.

3
fuweichin

Meine 5 Cent zum Thema:

Ich hatte das gleiche Problem. Nach ungefähr 1 Stunde habe ich festgestellt, dass ich das Zertifikat falsch eingefügt habe.

Wenn Sie einen solchen Fehler haben, überprüfen Sie bitte Ihr Zertifikat.

1
Nick

In meinem Fall wollte ich das SSL-Zertifikat ändern, da ich meinen Server geändert habe, sodass ich mit diesem Befehl einen neuen CSR erstellen musste:

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

Ich habe die mysite.csr -Datei an den ssl-Anbieter der Firma gesendet und nachdem ich das Zertifikat crt erhalten habe, habe ich nginx neu gestartet und ich habe diesen Fehler erhalten 

(SSL: Fehler: 0B080074: X509-Zertifikatroutinen: X509_check_private_key: Nicht übereinstimmende Schlüsselwerte)

Nach langen Untersuchungen bestand der Fehler darin, dass das Modul aus der Schlüsseldatei nicht mit dem aus der CRT-Datei identisch war

Damit es funktioniert, habe ich eine neue CSR-Datei erstellt, aber ich habe den Namen der Datei mit diesem Befehl geändert

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

Dann hatte ich eine neue CRT-Datei vom Firmenanbieter erhalten, nginx neu gestartet und es funktionierte. 

1
lemon fish

Es ist mir passiert, als ich bundle.crt und main cert kombiniert habe. Der Grund war, dass ich das Hauptzertifikat unterhalb der bundle.crt kopiert habe. Es sollte umgekehrt sein

1/Hauptzertifikat 2/Bundle.crt

0
Krishna

In meinem Fall bestand das Problem darin, dass ich Sertifikate abrite, ohne Daten in die CLI-Schnittstelle einzugeben. Wenn ich Zertifikate neu erstellt habe und alle Felder eingebe: Stadt, Bundesland usw., wurde alles in Ordnung.

 Sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt
0
Viktor Kruglikov

Dies kann auch passieren, wenn Ihre Zertifizierungsstelle ein Zwischenzertifikat ausstellt

Ich bin mit nginx (zweimal) auf dieses Problem gestoßen, und keine der Lösungen in diesem Beitrag erklärte das Problem. Der Blogbeitrag eines netten Gentlemans namens Marco hat es auf den Punkt gebracht, und ich füge es hier für jeden ein, der auch auf das trifft, was ich sah. https://medium.com/@mrkdsgn/steps-to-install-a-go-daddy-ssl-certificate-on-nginx-on-ubuntu-14-04-ff942b9fd7ff

In meinem Fall war go-daddy die CA und dies ist spezifisch für die Herausgabe des cert und der intermediären cert-Pakete.

Hier ist ein Auszug aus Marco's Blogpost

Wenn Ihre Zertifizierungsstelle ein Zwischenzertifikat enthielt, müssen Sie mit Nginx eine einzige verkettete Zertifikatsdatei erstellen, die Ihr Zertifikat und die Zwischenzertifikate der Zertifizierungsstelle enthält.

Mit diesem Befehl können Sie eine kombinierte Datei mit dem Namen example.com.chained.crt erstellen:

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

0
Shyam Habarakada

Für Nginx;

1- openssl req -newkey rsa: 2048 -nodes -keyout domain.com.key -out domain.com.csr

2- SSL-Datei "domain_com.crt" und "domain_com.ca-bundle" -Dateien Kopieren Sie die neue Datei in "paste.com.com.chained.crt"

3- Fügen Sie Nginx-Dateien hinzu: ein. ssl_certificate /home/user/domain_ssl/domain.com.chained.crt; b. ssl_certificate_key /home/user/domain_ssl/domain.com.key;

Lats startet Nginx neu

0
electrocoder