OpenSSL: procedury PEM: PEM_read_bio: brak linii startowej: pem_lib.c: 703: Oczekiwanie: TRUSTED CERTIFICATE [zamknięte]


100

Potrzebuję nazwy skrótu dla pliku do umieszczenia w katalogu CApath programu Stunnel. Mam kilka certyfikatów w tym katalogu i działają dobrze. Mam również serwer serwera i klucz serwera:

cert = c:\Program Files (x86)\stunnel\server_cert.pem 
key = c:\Program> Files (x86)\stunnel\private\server_key.pem

Kiedy próbuję obliczyć skrót mojego nowego certyfikatu, pojawia się błąd:

/etc/pki/tls/misc/c_hash cert.pem

unable to load certificate 140603809879880:error:0906D06C:PEM
routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE

Jak rozumiem, muszę podpisać swój certyfikat, ale nie rozumiem, jak mogę to zrobić. Proszę podać rozwiązanie.

PS:

Wiadomość

unable to load certificate 140603809879880:error:0906D06C:PEM
routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE:

opublikowane, kiedy zrobiłem c_hash dla cert.pem To nie jest server_cert.pem, to jest Root_CA i jest to coś w rodzaju

-----BEGIN CERTIFICATE-----  
...6UXBNSDVg5rSx60=.. 

-----END CERTIFICATE-----

Kiedy piszę

openssl x509 -noout -text -in cert.pem

W panelu konsoli widzę te informacje:

    Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=BE, ST=BB, L=BB, O=BANKSYS NV, OU=SCY, CN=TEST Root CA
        Validity
            Not Before: May 31 08:06:40 2005 GMT
            Not After : May 31 08:06:40 2020 GMT
        Subject: C=BE, ST=BB, L=BB, O=BB NV, OU=SCY, CN=TEST Root CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:82:c8:58:1e:e5:7a:b2:63:a6:15:bd:f9:bb:1f:
............
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Subject Key Identifier:
                76:70:AB:92:9B:B1:26:CE:9E:93:D8:77:4F:78:0D:B8:D4:6C:DA:C6
    Signature Algorithm: sha1WithRSAEncryption
         2c:7e:bd:3f:da:48:a4:df:8d:7c:96:58:f7:87:bd:e7:16:24:
...............

1
Może pomóc ktoś inny, mam ten błąd, kiedy niewłaściwie zamienione keyi certpliki znajdujące się w httpsobiekcie konfiguracyjnym dostarczone webpack.config„s devServer.
tao

Odpowiedzi:


43
  1. Ponieważ korzystasz z systemu Windows, upewnij się, że Twój certyfikat w systemie Windows jest „zgodny”, a co najważniejsze, że nie ma ^Mna końcu każdej linii

    Jeśli go otworzysz, będzie wyglądać tak:

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

    Aby rozwiązać ten problem, otwórz go za pomocą Writelub Notepad ++ i przekonwertuj na „styl” systemu Windows

  2. Spróbuj uruchomić openssl x509 -text -inform DER -in server_cert.pemi zobacz, jakie są wyniki, jest mało prawdopodobne, że klucz prywatny / tajny nie będzie zaufany, zaufanie jest potrzebne tylko wtedy, gdy wyeksportowałeś klucz z magazynu kluczy, prawda?


2
Spróbuj to uruchomić openssl x509 -hash -noout -in, wyciąga hash, zobacz, czy to pomaga?
Noam Rathaus

to jest przydatne. Dzięki. Ale w dzienniku STunnel widzę błąd, SSL_accept: 14094418: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socketgdy próbuję nawiązać połączenie
lsv

Oznacza to coś zupełnie innego, oznacza to, że obie strony nie używają tego samego cadla swojego certyfikatu CA
Noam Rathaus

1
Dzięki, openssl x509 -text -inform DER -in server_cert.pemprzekonwertowałem mój p7bzakodowany (?) Certyfikat na nadający się do użytku.
Koen.

3
Moim problemem nie były zakończenia linii CRLF, jak opisano tutaj, ale ta sugestia wystarczyła, aby wprowadzić mnie na właściwe tory. Mój problem polegał na tym, że mój plik został zapisany w dwubajtowym formacie Unicode z BOM, a openssl dla Windows nie mógł sobie z tym poradzić. Zapisałem się ponownie jako ascii i zadziałało.
Elroy Flynn

35

Inną możliwą przyczyną jest próba użycia modułu x509 na czymś innym niż x509

Certyfikat serwera ma format x509, ale klucz prywatny to rsa

Więc,

openssl rsa -noout -text -in privkey.pem
openssl x509 -noout -text -in servercert.pem

14

Moja sytuacja była trochę inna. Rozwiązaniem było usunięcie .pem ze wszystkiego poza sekcjami CERTIFICATE i PRIVATE KEY i odwrócenie kolejności, w jakiej się pojawiały. Po konwersji z pliku pfx do pem certyfikat wyglądał następująco:

Bag Attributes
localKeyID: ...
issuer=...
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
Bag Attributes
more garbage...
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----

Po poprawieniu pliku po prostu:

-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

M trochę noobem, pls sugerują me..How edytować tego pliku w Mac
shubhamkes

Miałem podobny błąd. Odwrócenie kolejności działało dla mnie.
Jon Richardson

Moje klucze przyszły w osobnych plikach, których potrzebowałem, aby utworzyć nowy plik:cat $SOURCE/privkey.pem $SOURCE/fullchain.pem > server.pem
ErichBSchulz

14

Moim błędem było po prostu użycie pliku CSR zamiast pliku CERT.


2
przynajmniej nie jestem jedynym, który popełnił ten błąd ... Dziwię się, że moduł nas o tym nie ostrzega.
edwardsmarkf

1
to zajęło mi wiele godzin. Wszystko zaczyna się od tajemniczego błędu z xmlsec1,key is not found
Schreiber

8

Miałem ten sam problem z systemem Windows, który został rozwiązany, otwierając go w Notepad ++ i zmieniając kodowanie z „UCS-2 LE BOM” na „UTF-8”.


6

Zmień kodowanie w notatniku ++ UTF-8 z BOM . Tak to u mnie zadziałało


1
Tak! To zadziałało dla mnie. Uwaga Certyfikaty PEM wyeksportowane z narzędzia Keychain firmy Apple nie mają BOM, co zakłóca działanie niektórych programów.
HughHughTeotl

5

Możesz otrzymać ten mylący błąd, jeśli spróbujesz to zrobić naiwnie :

[clear] -> Private Key Encrypt -> [encrypted] -> Public Key Decrypt -> [clear]

Szyfrowanie danych przy użyciu klucza prywatnego jest niedozwolone z założenia .

Możesz zobaczyć z opcji wiersza poleceń dla otwartego ssl, że jedyne opcje encrypt -> decryptidą w jednym kierunku public -> private.

  -encrypt        encrypt with public key
  -decrypt        decrypt with private key

Drugi kierunek jest celowo zabroniony, ponieważ klucze publiczne w zasadzie „można odgadnąć”. Zatem szyfrowanie za pomocą klucza prywatnego oznacza, że ​​jedyną rzeczą, jaką zyskujesz, jest weryfikacja, czy autor ma dostęp do klucza prywatnego.

private key encrypt -> public key decryptKierunek jest nazywany „podpisywania”, aby odróżnić ją od bycia technika, która może rzeczywiście bezpieczne dane.

  -sign           sign with private key
  -verify         verify with public key

Uwaga: mój opis jest uproszczeniem dla większej przejrzystości. Przeczytaj tę odpowiedź, aby uzyskać więcej informacji .

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.