Błąd SSL - nie można odczytać certyfikatu serwera z pliku

Skonfigurowałem dziś protokół SSL dla mojej domeny i napotkałem inny problem - miałem nadzieję, że ktoś rzuci trochę światła na ...

Ciągle otrzymuję następujące komunikaty o błędach:

[błąd] Init: Nie można odczytać certyfikatu serwera z pliku /etc/apache2/domain.com.ssl/domain.com.crt/domain.com.crt
[błąd] Błąd biblioteki SSL: 218529960 błąd: 0D0680A8: procedury kodowania asn1: ASN1_CHECK_TLEN: zły tag
[błąd] Błąd biblioteki SSL: 218595386 błąd: 0D07803A: procedury kodowania asn1: ASN1_ITEM_EX_D2I: zagnieżdżony błąd asn1

Korzystam z Apache 2.2.16 i Ubuntu 10.10. Mój plik .crt ma znaczniki Begin i End i został skopiowany dokładnie z e-maila z potwierdzeniem, który otrzymałem, bardzo frustrujące!

Twoje zdrowie!

Edytuj >> Podczas próby sprawdzenia .crt Wygląda na to, że nie działa:

>> openssl x509 -noout -text -in domain.com.crt 
nie można załadować certyfikatu
16851: błąd: 0906D06C: Procedury PEM: PEM_read_bio: brak wiersza początkowego: pem_lib.c: 650: Oczekiwanie: ZAUFANY CERTYFIKAT

Również >>

>> openssl x509 -tekst -inform PEM -w domenie.com.crt
nie można załadować certyfikatu
21321: błąd: 0906D06C: Procedury PEM: PEM_read_bio: brak linii początkowej: pem_lib.c: 650: Oczekiwanie: ZAUFANY CERTYFIKAT

>> openssl x509 -tekst -inform DER -w domenie.com.crt
nie można załadować certyfikatu
21325: błąd: 0D0680A8: Procedury kodowania asn1: ASN1_CHECK_TLEN: zły tag: tasn_dec.c: 1316:
21325: błąd: 0D07803A: Procedury kodowania asn1: ASN1_ITEM_EX_D2I: zagnieżdżony błąd asn1: tasn_dec.c: 380: Type = X509

Edytuj >> (Przy okazji, okrzyki pomocy)

>> grep '^ -----' domain.com.crt
----- ROZPOCZNIJ CERTYFIKAT -----
----- KONIEC CERTYFIKATU -----

Właśnie wysłałem e-mail do firmy dostarczającej certyfikat, odpowiedzieli>

Sprawdziłem podany plik CSR i zapewniam, że został on poprawnie wygenerowany. Występujący obecnie błąd jest spowodowany, ponieważ używasz niewłaściwego wiersza polecenia do zainstalowania CSR. Konieczne będzie zmodyfikowanie tej domeny.com.crt z wiersza polecenia zgodnie z odpowiednią nazwą domeny.

• obecnie konfiguracja crt to mysite.com.crt - jako przykład użyłem domain.com.crt

Czy to możliwe, że linie są zakończone ^ M? Jest to potencjalny problem podczas przenoszenia plików z systemu Windows na systemy UNIX. Jednym łatwym sposobem sprawdzenia jest użycie viw trybie „pokaż mi plik binarny” vi -b /etc/apache2/domain.ssl/domain.ssl.crt/domain.com.crt.

Jeśli każda linia kończy się klawiszem sterującym-M, to tak

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

masz plik w formacie Windows zakończonym wierszem, a apache go nie lubi.

Dostępne opcje obejmują przeniesienie pliku ponownie, zwracając większą uwagę; lub za pomocą dos2unixpolecenia, aby je usunąć; możesz również usunąć je w vi, jeśli jesteś ostrożny.

Edycja : dzięki @ dave_thompson_085, który zwraca uwagę, że ta odpowiedź nie ma już zastosowania w 2019 r. Oznacza to, że Apache / OpenSSL są teraz tolerancyjne wobec linii zakończonych ^ M, więc nie powodują problemów. To powiedziawszy, inne błędy formatowania, których kilka różnych przykładów pojawiają się w komentarzach, mogą nadal powodować problemy; sprawdź je dokładnie, czy certyfikat został przeniesiony między systemami.

Dla każdego, kto dotrze na tę stronę z podobnym błędem podczas próby odczytania Żądania podpisania certyfikatu (CSR) (zauważ, że OP czyta certyfikat): upewnij się, że używasz właściwej komendy OpenSSL. x509dotyczy certyfikatów i reqCSR:

openssl req -in server.csr -text -noout

vs

openssl x509 -in server.crt -text -noout

Po prostu krążyłem w kółko w tej sprawie i okazało się, że mam certyfikaty w niewłaściwy sposób - np

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

zamiast:

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

Coś do sprawdzenia, czy pojawia się ten błąd.

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

Podejrzewam, że masz problem z formatem certyfikatu.

Uruchom oba następujące polecenia i przekaż nam dane wyjściowe:

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

W moim przypadku mój certyfikat miał różne znaki „-”. Musiał to być problem kopiowania / wklejania przez administratora, który umieścił certyfikat na serwerze, z zastąpieniem edytora tekstu - po drodze specjalnym znakiem Unicode.

Diagnozowanie zajęło wiele godzin, w końcu po prostu zgadłem i edytowałem certyfikat w vi, usunąłem istniejące znaki „-” i przepisałem je ponownie.

Mam nadzieję, że to komuś pomoże.

W moim przypadku napotkałem błędy OP, ponieważ ktokolwiek stworzył dla mnie plik .crt, naprawdę stworzył plik w formacie .PEM i nazwał go .crt.

Odkryłem to, uruchamiając następujący pomocny przewodnik: https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-cer-vs-pem-certificates-and-how -to-przekonwertować je

wszystko, co musiałem zrobić, to zmienić nazwę mojego .crt na .pem i skończyłem! Przewodnik wskazał, że błędy w pytaniu PO oznaczają, że plik wejściowy jest już sformatowany w formacie PEM, więc próba konwersji go do formatu .pem z formatu DER nie jest możliwa i jest w rzeczywistości niepotrzebna.

Upewnij się, że w pliku certyfikatu nie ma spacji końcowych ani początkowych. Ostrożnie upewnij się, że w pliku certyfikatu nie ma spacji ani pustych miejsc, zaznaczając cały tekst i szukając pustych miejsc w edytorze tekstowym.

Sprawdź także, czy rzeczywiście wszystkie skonfigurowane pliki istnieją i są poprawne.

Np .: w innym poście mówisz, że plik .key nazywa się moja domena.com.crt, podczas gdy w konfiguracji hosta masz domenę.com.com.crt

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

Sprawdź ponownie, czy wszystkie powyższe pliki naprawdę istnieją i są prawidłowe.

Jeśli ktoś napotka ten problem, a dzienniki błędów apache mówią coś takiego:

Init: Nie można odczytać certyfikatu serwera z pliku /etc/apache2/domain.com.ssl/domain.com.crt/domain.com.crt

Upewnij się, że nie zamieniłeś plików kluczy i certyfikatów w deklaracjach w konfiguracji apache. Wskazałem klucz na mój plik certyfikatu, a certyfikat na mój plik klucza. Ten post pomógł mi zrozumieć problem, ale chciałem go wskazać jako kolejny potencjalny problem / rozwiązanie.

Mój problem (ten sam błąd podczas instalowania nowego serwera z Apache 2.4) polegał na tym, że Apache (2.4) nie mógł odczytać binarnego pliku .crt. Zaimportowałem go do mojego osobistego magazynu certyfikatów (z mmc) i wyeksportowałem jako X.509 (.cer) w formacie base-64. Zmieniłem nazwę eksportowanego pliku na tę samą nazwę (.crt) (użytą w moim httpd-ssl.conf) i zadziałało ponownie! Ten sam certyfikat działał na moim starym serwerze, może Apache 2.4 jest bardziej rygorystyczny niż 2.2? Powodzenia.

W moim przypadku ma to związek z obecnością BOM w pliku. Można to rozebrać tak:

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

Nie jestem pewien, czy zawsze zajmuje 3 bajty, więc lepszym sposobem musi być:

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

Wystąpił ten sam błąd, ponieważ zmieniłem .key z nazwami plików .crt

Miałem podobny problem, gdy przypadkowo użyłem dostarczonego przez klienta certyfikatu P7b typu IIS w konfiguracji apache. Konwersja certyfikatu do formatu x509 naprawiła błąd. Oba typy wyglądają tak samo na powierzchni, ale najwyraźniej różnią się od wewnątrz.

Miałem ten problem, ponieważ przesłano mi zawartość pliku .p7b w stylu IIS wklejonego do wiadomości e-mail. Posiada znaczniki „----- ROZPOCZNIJ CERTYFIKAT -----” i „----- ZAKOŃCZ CERTYFIKAT -----”, podobnie jak .pem, a treść używa podobnie wyglądającego kodowania base64. Przekształciłem go w plik * .pem w następujący sposób:

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

Po tym Apache 2.2 był szczęśliwy.

Ostatnio miałem problem z używaniem Lets Encrypt (letsencrypt) w systemie Windows. Cert wrócił zakodowany jako UTF-16LE. Konwersja go do UTF-8 (przy użyciu dos2unix) rozwiązała problem.

W moim przypadku były tylko puste linie. Kiedy wkleiłem plik CRT z ntepad lub notatnika ++ w nano, zawsze miałem coś podobnego

sdgrgrgr rgregegreg rgrgreg
rgregreg rggregregr rgregrg

usunięcie pustych spacji i umieszczenie wszystkich w linii rozwiązało problem Np .:

sdgrgrgr
rgregegreg
rgrgreg
rgregreg
rggregregr
rgregrg