OpenSSL: Підпрограми PEM: PEM_read_bio: немає початкової лінії: pem_lib.c: 703: Очікуємо: довірений сертифікат [закрито]


100

Мені потрібне хеш-ім'я для файлу для публікації в каталозі Stunnel's CApath. У мене в цьому каталозі є декілька сертифікатів, і вони працюють добре. Також у мене є серверний сервер і ключ сервера:

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

Коли я намагаюся обчислити хеш моєї нової cert, я отримую помилку:

/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

Як я розумію, я повинен підписати свою серт, але я не розумію, як я можу це зробити. Будь ласка, надайте рішення.

PS:

Повідомлення

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

Опубліковано, коли я робив c_hash для cert.pem Це не server_cert.pem, це Root_CA, і він вміщує щось подібне

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

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

Коли я пишу

openssl x509 -noout -text -in cert.pem

На панелі консолі я бачу цю інформацію:

    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
Може допомогти комусь іншому, я отримав цю помилку, коли я неправильно поміняв файли keyта certфайли в httpsконфігураційному об’єкті, наданому webpack.config's devServer.
дао

Відповіді:


43
  1. Оскільки ви перебуваєте в Windows, переконайтеся, що ваш сертифікат в Windows "сумісний", головне, щоб його не було ^Mв кінці кожного рядка

    Якщо ви відкриєте його, це буде виглядати приблизно так:

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

    Щоб вирішити "це", відкрийте його за допомогою " WriteNotepad ++" і перетворіть його в "стиль" Windows "

  2. Спробуйте запустити openssl x509 -text -inform DER -in server_cert.pemі побачити, що таке вихід, навряд чи приватний / секретний ключ не буде довіряти, довіра потрібна лише в тому випадку, якщо ви експортували ключ з магазину ключів, чи не так?


2
Спробуйте запустити це, openssl x509 -hash -noout -inце робить видобуток хешу, подивіться, чи це допомагає?
Ноам Ратхаус

це корисно. Дякую. Але в журналі журналу STunnel я бачу помилку, 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 socketколи я намагаюся встановити з'єднання
lsv

Це означає щось інше, це означає, що обидві сторони не використовують те саме caдля свого сертифіката CA
Ноам Ратхаус

1
Дякую, openssl x509 -text -inform DER -in server_cert.pemперетворив мій p7bзакодований (?) Сертифікат на щось корисне.
Коен.

3
Моєю проблемою були не закінчення рядків CRLF, як описано тут, але цієї пропозиції було достатньо, щоб привести мене в шлях. Моя проблема полягала в тому, що мій файл був збережений двобайтовим Unicode з BOM, і openssl для Windows не міг із цим впоратися. Я врятувався як ascii, і це спрацювало.
Елрой Флінн

35

Іншою можливою причиною цього є намагання використовувати модуль x509 на чомусь не x509

Сертифікат сервера формату x509, але приватний ключ - rsa

Так,

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

14

Моя ситуація була дещо іншою. Рішення полягало в тому, щоб зняти .pem з усього, що не належить до розділу CERTIFICATE і PRIVATE KEY, і перевернути порядок, який вони з’явилися. Після перетворення з pfx у файл pem сертифікат виглядав так:

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

Після виправлення файлу було просто:

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

M kinda noob, pls запропонуйте мені ... Як відредагувати цей файл у mac
shubhamkes

У мене була подібна помилка. Інвертування замовлення працювало на мене.
Джон Річардсон

Мої ключі надходили в окремі файли, мені потрібно було створити новий файл:cat $SOURCE/privkey.pem $SOURCE/fullchain.pem > server.pem
ErichBSchulz

14

Моєю помилкою було просто використання файлу CSR замість файлу CERT.


2
принаймні, я не єдиний, хто допустив цю помилку ... я здивований, що модуль не попереджає нас про це.
edwardsmarkf

1
це потребувало у мене годин на роботу. Все починається з криптографічної помилки з xmlsec1,key is not found
Amichai Schreiber

8

У мене була та сама проблема з Windows, яку виправили, якщо її виправили, відкривши її в Notepad ++ та змінивши кодування з "UCS-2 LE BOM" на "UTF-8".


6

Змініть кодування в блокноті ++ UTF-8 за допомогою BOM . Ось як це працювало для мене


1
Так! Це працювало для мене. Зверніть увагу, що сертифікати PEM, експортовані з утиліти Keychain Apple, не мають BOM, і це засмучує деякі програми.
HughHughTeotl

5

Ви можете отримати цю оманливу помилку, якщо наївно спробуєте це зробити:

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

Зашифрування даних за допомогою приватного ключа дизайном заборонено .

З параметрів командного рядка для відкритого ssl видно, що єдині варіанти encrypt -> decryptйти в одному напрямку public -> private.

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

Інший напрямок навмисно перешкоджає тому, що відкриті ключі в основному "можна здогадатися". Отже, шифрування приватним ключем означає, що єдине, що ви отримуєте, - це перевірити, чи має автор доступ до приватного ключа.

private key encrypt -> public key decryptНапрямок називається «підписання» , щоб відрізнити його від того , щоб метод , який може на самому справі захисту даних.

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

Примітка: мій опис - це спрощення для ясності. Прочитайте цю відповідь для отримання додаткової інформації .

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.