OpenSSL: подпрограммы PEM: PEM_read_bio: без начальной строки: pem_lib.c: 703: Ожидается: ДОВЕРЕННЫЙ СЕРТИФИКАТ

Мне нужно хеш-имя файла для публикации в каталоге CApath Stunnel. У меня есть сертификаты в этом каталоге, и они работают хорошо. Также у меня есть серверный sert и серверный ключ:

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

Когда я пытаюсь вычислить хэш моего нового сертификата, я получаю сообщение об ошибке:

/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

Насколько я понимаю, я должен подписать свой сертификат, но не понимаю, как я могу это сделать. Пожалуйста, дайте решение.

P.S.:

Сообщение

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

windows certificate openssl trusted
person lsv    schedule 30.12.2013    source источник
comment
Может помочь кому-то другому. Я получил эту ошибку, когда ошибочно поменял местами файлы key и cert в https объекте конфигурации, предоставленном webpack.config devServer.   -  person tao    schedule 30.04.2020

Ответы (7)


arrow_upward
46
arrow_downward

  1. Поскольку вы работаете в Windows, убедитесь, что ваш сертификат в Windows «совместим», и самое главное, чтобы в конце каждой строки не было ^M.

    Если открыть его, это будет выглядеть так:

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

    Чтобы решить "это", откройте его с помощью Write или Notepad ++ и попросите преобразовать его в "стиль" Windows.

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

person Noam Rathaus    schedule 30.12.2013
comment
Попробуй запустить openssl x509 -hash -noout -in, он извлекает хеш, посмотри, поможет ли? - person Noam Rathaus; 30.12.2013
comment
это полезно. Спасибо. Но в журнале 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, когда пытаюсь установить соединение - person lsv; 30.12.2013
comment
Это означает совсем другое, это означает, что обе стороны не используют одинаковый ca для своего сертификата CA - person Noam Rathaus; 30.12.2013
comment
Спасибо, openssl x509 -text -inform DER -in server_cert.pem преобразовал мой p7b закодированный (?) Сертификат во что-то пригодное для использования. - person Koen.; 03.02.2014
comment
Моя проблема заключалась не в окончании строк CRLF, как описано здесь, но этого предложения было достаточно, чтобы я встал на путь. Моя проблема заключалась в том, что мой файл был сохранен в двухбайтовом Unicode с спецификацией, и openssl для Windows не мог с этим справиться. Я пересохранил как ascii, и это сработало. - person Elroy Flynn; 15.08.2014
comment
Спасибо @ElroyFlynn, это тоже была моя проблема - у openssl в Linux такая же проблема, если в начале файла есть спецификация. - person natevw; 13.09.2016
comment
+1. В моем случае проблема (как только я внимательно посмотрел) заключалась в том, что у меня действительно был сертификат request (-----BEGIN CERTIFICATE REQUEST-----), а не сертификат (-----BEGIN CERTIFICATE-----). Я смог проверить это, используя openssl req ..., а не openssl x509 .... - person ruakh; 30.12.2016
comment
Для всех, у кого есть эта ошибка, моя проблема заключалась в том, что я запускал команду для преобразования .p7b в .cer как openssl pkcs7 -in pkcs7.p7b -print_certs > pem.cer, решение заключалось в использовании -out вместо >, поэтому openssl pkcs7 -in pkcs7.p7b -print_certs -out pem.cer - person iMassakre; 25.07.2019
comment
Нет необходимости в параметре -text - person Borzh; 06.07.2021

arrow_upward
43
arrow_downward

Другая возможная причина этого - попытка использовать; x509; модуль на то, что не является X.509.

Сертификат сервера имеет формат X.509, но закрытый ключ - RSA.

So:

openssl rsa -noout -text -in privkey.pem
openssl x509 -noout -text -in servercert.pem
person Rondo    schedule 14.07.2017

arrow_upward
19
arrow_downward

Моя ошибка заключалась в том, что я просто использовал файл CSR вместо файла CERT.

person SpiRail    schedule 02.03.2018
comment
по крайней мере, я не единственный, кто допустил эту ошибку ... я удивлен, что модуль не предупреждает нас об этом. - person edwardsmarkf; 13.09.2019
comment
на это у меня ушло несколько часов. Все начинается с загадочной ошибки из xmlsec1, key is not found - person Amichai Schreiber; 06.10.2019

arrow_upward
15
arrow_downward

Моя ситуация была немного другой. Решение заключалось в том, чтобы удалить .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-----
person Gustavo da Silva Serra    schedule 20.05.2015
comment
M kinda noob, пожалуйста, посоветуйте мне .. Как отредактировать этот файл на Mac - person shubhamkes; 31.01.2017
comment
У меня была аналогичная ошибка. У меня сработало изменение порядка. - person Jonathon Richardson; 11.05.2017
comment
Мои ключи пришли в отдельных файлах, которые мне понадобились для создания нового файла: cat $SOURCE/privkey.pem $SOURCE/fullchain.pem > server.pem - person ErichBSchulz; 15.03.2018

arrow_upward
12
arrow_downward

У меня была такая же проблема с Windows, которую можно было исправить, открыв ее в Notepad ++ и изменив кодировку с «UCS-2 LE BOM» на «UTF-8».

person peter n    schedule 30.12.2015

arrow_upward
8
arrow_downward

Измените кодировку в блокноте ++ UTF-8 с спецификацией. Вот как это сработало для меня

person Yoda Zemichael    schedule 30.09.2017
comment
Да! Это сработало для меня. Обратите внимание, что сертификаты PEM, экспортированные из утилиты Apple Keychain, не имеют спецификации, и это нарушает работу некоторых программ. - person HughHughTeotl; 17.04.2019

arrow_upward
5
arrow_downward

Вы можете получить эту вводящую в заблуждение ошибку, если наивно попытаетесь сделать это:

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

Шифрование данных с помощью закрытого ключа запрещено по дизайну.

Из параметров командной строки для open ssl видно, что единственные параметры encrypt -> decrypt go в одном направлении 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

Примечание: мое описание является упрощением для ясности. Прочтите этот ответ для получения дополнительной информации.

person TrophyGeek    schedule 23.05.2017