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
quelle
grep '^-----' domain.com.crt
?Antworten:
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
vi
des Modus "Zeigen Sie mir die Binärdatei" mitvi -b /etc/apache2/domain.ssl/domain.ssl.crt/domain.com.crt
.Wenn jede Zeile mit einem Strg-M endet, so
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
dos2unix
Befehl, 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.
quelle
-----BE
... Vielen Dank für die Inspiration zur Überprüfung!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.
x509
ist für Zertifikate undreq
ist für CSRs:vs
quelle
Ging einfach im Kreis herum und es stellte sich heraus, dass ich die Zertifikate falsch herum hatte - zB
anstatt:
Überprüfen Sie, ob dieser Fehler angezeigt wird.
quelle
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:
quelle
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.
quelle
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.
quelle
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
Überprüfen Sie erneut, ob alle oben genannten Dateien tatsächlich vorhanden und gültig sind.
quelle
--
in–
; Die Fehlersuche hat nicht viel Spaß gemacht.sudo 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
-----BEGIN CERTIFICATE-----
und endet die letzte Zeile mit-----END CERTIFICATE-----
?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.
quelle
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.
quelle
In meinem Fall hat dies damit zu tun, dass die Stückliste in der Datei vorhanden ist. Man könnte es so ausziehen:
Ich bin mir nicht sicher, ob es immer 3 Bytes dauert. Der bessere Weg muss also sein:
quelle
Ich habe den gleichen Fehler erhalten, weil ich den .key mit den .crt- Dateinamen getauscht habe
quelle
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.
quelle
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:
Danach war Apache 2.2 glücklich.
quelle
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.
quelle
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
das Entfernen der Leerzeichen und das Setzen aller in einer Linie löste das Problem zB:
quelle