SSL-Fehler - Serverzertifikat kann nicht aus Datei gelesen werden

Ich habe heute SSL für meine Domain eingerichtet und ein anderes Problem festgestellt - ich hatte gehofft, jemand könnte etwas Licht ins Dunkel bringen.

Ich erhalte weiterhin die folgenden Fehlermeldungen:

[Fehler] Init: Das Serverzertifikat kann nicht aus der Datei /etc/apache2/domain.com.ssl/domain.com.crt/domain.com.crt gelesen werden
[Fehler] SSL-Bibliotheksfehler: 218529960 Fehler: 0D0680A8: asn1-Codierungsroutinen: ASN1_CHECK_TLEN: falsches Tag
[Fehler] SSL-Bibliotheksfehler: 218595386 Fehler: 0D07803A: asn1-Codierungsroutinen: ASN1_ITEM_EX_D2I: verschachtelter asn1-Fehler

Ich verwende Apache 2.2.16 und Ubuntu 10.10. Meine .crt-Datei enthält die Start- und End-Tags und wurde genau aus der Bestätigungs-E-Mail kopiert, die ich erhalten habe. Sehr frustrierend!

Prost!

Bearbeiten >> Beim Versuch, die .crt-Datei zu verifizieren, scheint Folgendes nicht zu funktionieren:

>> openssl x509 -noout -text -in domain.com.crt 
Zertifikat kann nicht geladen werden
16851: Fehler: 0906D06C: PEM-Routinen: PEM_read_bio: Keine Startzeile: pem_lib.c: 650: Erwarten: VERTRAUENES ZERTIFIKAT

Auch >>

>> openssl x509 -text -inform PEM -in domain.com.crt
Zertifikat kann nicht geladen werden
21321: Fehler: 0906D06C: PEM-Routinen: PEM_read_bio: Keine Startzeile: pem_lib.c: 650: Erwarten: VERTRAUENES ZERTIFIKAT

>> openssl x509 -text -inform DER -in domain.com.crt
Zertifikat kann nicht geladen werden
21325: Fehler: 0D0680A8: asn1-Codierungsroutinen: ASN1_CHECK_TLEN: falsches Tag: tasn_dec.c: 1316:
21325: Fehler: 0D07803A: asn1-Codierungsroutinen: ASN1_ITEM_EX_D2I: verschachtelter asn1-Fehler: tasn_dec.c: 380: Typ = X509

Bearbeiten >> (Danke übrigens für die Hilfe)

>> grep '^ -----' domain.com.crt
----- ZERTIFIKAT BEGINNEN -----
----- ZERTIFIKAT BEENDEN -----

Sie haben dem Unternehmen, das das Zertifikat bereitgestellt hat, eine E-Mail gesendet und darauf geantwortet

Ich habe die von Ihnen bereitgestellte CSR-Datei überprüft und kann versichern, dass diese korrekt generiert wurde. Der Fehler, auf den Sie derzeit stoßen, wird dadurch verursacht, dass Sie für die Installation des CSR eine falsche Befehlszeile verwenden. Sie müssen diese domain.com.crt in Ihrer Befehlszeile mit dem entsprechenden Namen Ihrer Domain ändern.

• Derzeit ist der CRT auf mysite.com.crt eingestellt. Ich habe domain.com.crt als Beispiel verwendet

Ist es möglich, dass die Leitungen ^ M-terminiert sind? Dies ist ein potenzielles Problem beim Verschieben von Dateien von Windows auf UNIX-Systeme. Eine einfache Möglichkeit, dies zu überprüfen, ist die Verwendung vides Modus "Zeigen Sie mir die Binärdatei" mit vi -b /etc/apache2/domain.ssl/domain.ssl.crt/domain.com.crt.

Wenn jede Zeile mit einem Strg-M endet, so

-----BEGIN CERTIFICATE-----^M
MIIDITCCAoqgAwIBAgIQL9+89q6RUm0PmqPfQDQ+mjANBgkqhkiG9w0BAQUFADBM^M
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg^M
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0x^M

Sie haben eine Datei im Windows-Format mit Zeilenende, und Apache liebt diese nicht.

Zu Ihren Optionen gehört das erneute Verschieben der Datei, wobei Sie mehr Sorgfalt walten lassen. oder mit dem dos2unixBefehl, um diese zu entfernen; Sie können sie auch in vi entfernen, wenn Sie vorsichtig sind.

Bearbeiten : Dank an @ dave_thompson_085, der darauf hinweist, dass diese Antwort 2019 nicht mehr gilt. Das heißt, Apache / OpenSSL tolerieren jetzt ^ M-terminierte Zeilen, sodass sie keine Probleme verursachen. Andere Formatierungsfehler, von denen verschiedene Beispiele in den Kommentaren aufgeführt sind, können jedoch weiterhin Probleme verursachen. Prüfen Sie sorgfältig, ob das Zertifikat systemübergreifend übertragen wurde.

Wenn Sie auf dieser Seite mit einem ähnlichen Fehler versuchen, eine Certificate Signing Request (CSR) zu lesen (beachten Sie, dass OP ein Zertifikat liest), stellen Sie sicher, dass Sie den richtigen OpenSSL-Befehl verwenden. x509ist für Zertifikate und reqist für CSRs:

openssl req -in server.csr -text -noout

vs

openssl x509 -in server.crt -text -noout

Ging einfach im Kreis herum und es stellte sich heraus, dass ich die Zertifikate falsch herum hatte - zB

SSLCertificateFile    /etc/apache2/ssl/server.key
SSLCertificateKeyFile /etc/apache2/ssl/server.crt

anstatt:

SSLCertificateFile    /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key

Überprüfen Sie, ob dieser Fehler angezeigt wird.

>> openssl x509 -noout -text -in domain.com.crt 
unable to load certificate
16851:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:650:Expecting: TRUSTED CERTIFICATE

Ich vermute, dass Sie ein Problem mit dem Format des Zertifikats haben.

Führen Sie die beiden folgenden Befehle aus und geben Sie die Ausgabe aus:

openssl x509 -text -inform DER -in domain.com.crt 
openssl x509 -text -inform PEM -in domain.com.crt 

In meinem Fall stellte ich fest, dass mein Zertifikat unterschiedliche "-" Zeichen hatte. Es muss ein Copy / Paste-Problem des Administrators gewesen sein, der das Zertifikat auf den Server gestellt hat, wobei der Texteditor ersetzt wurde - mit einem speziellen Unicode-Zeichen auf dem Weg.

Die Diagnose dauerte Stunden, und am Ende habe ich es nur erraten und das Zertifikat in vi bearbeitet und die vorhandenen "-" Zeichen gelöscht und erneut getippt.

Hoffe das hilft jemandem.

In meinem Fall bin ich auf die Fehler des OP gestoßen, weil derjenige, der die CRT-Datei für mich erstellt hat, tatsächlich eine PEM- formatierte Datei erstellt und sie CRT genannt hat.

Ich habe dies festgestellt, indem ich auf die folgende hilfreiche Anleitung gestoßen bin: https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-cer-vs-pem-certificates-and-how -zu-konvertieren-sie

Alles was ich tun musste war, meine .crt in eine .pem umzubenennen und ich war fertig! Der Leitfaden wies darauf hin, dass die Fehler in der Frage des OP darauf hindeuten, dass die Eingabedatei bereits PEM-formatiert ist. Daher kann der Versuch, sie aus einem DER-Format in .pem zu konvertieren, nicht durchgeführt werden und ist in der Tat unnötig.

Stellen Sie sicher, dass Ihre Datei keine nachgestellten oder führenden Leerzeichen in der Zertifikatdatei enthält. Stellen Sie sicher, dass Ihre Zertifikatdatei keine Leerzeichen enthält, indem Sie den gesamten Text auswählen und in einem Nur-Text-Editor nach Leerzeichen suchen.

Überprüfen Sie auch, ob tatsächlich alle konfigurierten Dateien vorhanden und korrekt sind.

Beispiel: In Ihrem anderen Beitrag sagen Sie, dass Ihre .key-Datei my domain.com.crt heißt, während Sie in der vhost-Konfiguration domain.com.crt haben

SSLCertificateFile /etc/apache2/domain.ssl/domain.ssl.crt/domain.com.crt
SSLCertificateKeyFile /etc/apache2/domain.ssl/domain.ssl.key/domain.com.key
SSLCertificateChainFile /etc/apache2/domain.ssl/ca.crt
SSLCACertificateFile /etc/apache2/domain.ssl/gs_intermediate_ca.crt

Überprüfen Sie erneut, ob alle oben genannten Dateien tatsächlich vorhanden und gültig sind.

Sollte jemand anderes auf dieses Problem stoßen und Ihre Apache-Fehlerprotokolle sagen etwas wie:

Init: Serverzertifikat aus Datei /etc/apache2/domain.com.ssl/domain.com.crt/domain.com.crt kann nicht gelesen werden

Stellen Sie sicher, dass Sie Ihre Schlüssel- und Zertifikatsdateien nicht in den Deklarationen in der Apache-Konfiguration vertauscht haben. Ich hatte den Schlüssel zu meiner Zertifikatsdatei und das Zertifikat zu meiner Schlüsseldatei gezeigt. Dieser Beitrag hat mir geholfen, das Problem herauszufinden, aber ich wollte es als ein weiteres mögliches Problem / eine mögliche Lösung herausstellen.

Mein Problem (der gleiche Fehler bei der Installation eines neuen Servers mit Apache 2.4) war, dass Apache (2.4) die binäre CRT-Datei nicht lesen konnte. Ich habe es in meinen persönlichen Zertifikatspeicher (mit mmc) importiert und als Base-64-codiertes X.509 (.cer) exportiert. Die exportierte Datei wurde in denselben Namen (.crt) umbenannt (in meiner httpd-ssl.conf verwendet) und es funktionierte wieder! Dasselbe Zertifikat hat auf meinem alten Server funktioniert. Vielleicht ist Apache 2.4 strenger als 2.2? Viel Glück.

In meinem Fall hat dies damit zu tun, dass die Stückliste in der Datei vorhanden ist. Man könnte es so ausziehen:

tail -c +4 ssl.crt > ssl2.crt

Ich bin mir nicht sicher, ob es immer 3 Bytes dauert. Der bessere Weg muss also sein:

vi -c 'se nobomb' -c wq ssl.crt

Ich habe den gleichen Fehler erhalten, weil ich den .key mit den .crt- Dateinamen getauscht habe

Ich hatte ein ähnliches Problem, als ich versehentlich ein vom Kunden bereitgestelltes IIS-Zertifikat vom Typ p7b in der Apache-Konfiguration verwendet habe. Das Konvertieren des Zertifikats in das x509-Format behebt den Fehler. Beide Typen sehen auf der Oberfläche gleich aus, unterscheiden sich jedoch anscheinend auf der Innenseite.

Ich hatte dieses Problem, weil mir der Inhalt einer .p7b-Datei im IIS-Stil gesendet wurde, die in eine E-Mail eingefügt wurde. Es hat die Tags "----- BEGIN CERTIFICATE -----" und "----- END CERTIFICATE -----", genau wie .pem, und der Inhalt verwendet eine ähnlich aussehende Base64-Codierung. Ich habe es in eine * .pem-Datei wie folgt konvertiert:

openssl pkcs7 -print_certs -in cert.p7b -out cert.cer

Danach war Apache 2.2 glücklich.

Ich hatte vor kurzem dieses Problem mit Lets Encrypt (Letsencrypt) unter Windows. Das Zertifikat wurde als UTF-16LE zurückgegeben. Durch Konvertieren in UTF-8 (mit dos2unix) wurde das Problem behoben.

In meinem Fall handelte es sich nur um leere Zeilen. Als ich die CRT-Datei von NTEPAD oder Notepad ++ in Nano eingefügt habe, bekam ich immer etwas wie

sdgrgrgr rgregegreg rgrgreg
rgregreg rggregregr rgregrg

das Entfernen der Leerzeichen und das Setzen aller in einer Linie löste das Problem zB:

sdgrgrgr
rgregegreg
rgrgreg
rgregreg
rggregregr
rgregrg