OpenSSL: PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE

Question

I need a hash-name for file for posting in Stunnel's CApath directory. I have got some certs in this directory and they are working well. Also, I have a server sert and server key:

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

When I try to calculate a hash of my new cert, I get an error:

/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

As I understand I must sign my cert, but I don't understand how I can do that. Please, provide the solution.

P.S.:

The message

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

posted when I made c_hash for cert.pem This is not server_cert.pem, this is Root_CA and it is content something like

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

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

When I write

openssl x509 -noout -text -in cert.pem

In console panel I see this info:

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

Solution 1

1. Since you are on Windows, make sure that your certificate in Windows "compatible", most importantly that it doesn't have ^M in the end of each line

   If you open it it will look like this:

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

   To solve "this" open it with Write or Notepad++ and have it convert it to Windows "style"

2. Try to run openssl x509 -text -inform DER -in server_cert.pem and see what the output is, it is unlikely that a private/secret key would be untrusted, trust only is needed if you exported the key from a keystore, did you?

Solution 2

Another possible cause of this is trying to use the ;x509; module on something that is not X.509.

The server certificate is X.509 format, but the private key is RSA.

So:

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

Solution 3

My mistake was simply using the CSR file instead of the CERT file.

Solution 4

My situation was a little different. The solution was to strip the .pem from everything outside of the CERTIFICATE and PRIVATE KEY sections and to invert the order which they appeared. After converting from pfx to pem file, the certificate looked like this:

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

After correcting the file, it was just:

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

Solution 5

I had the same issue using Windows, got if fixed by opening it in Notepad++ and changing the encoding from "UCS-2 LE BOM" to "UTF-8".

View more solutions

Comments

[Noam Rathaus]

Try to run this openssl x509 -hash -noout -in it does hash extraction, see if it helps?

[lsv]

that's useful. Thanks. But in STunnel log I see the error 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 when I try ro make connection

[Noam Rathaus]

That means something else altogether, it means that both sides are not using the same ca for their CA certificate

[Koen.]

Thanks, openssl x509 -text -inform DER -in server_cert.pem converted my p7b encoded(?) certificate to something usable.

[Elroy Flynn]

My problem wasn't CRLF line endings as described here, but this suggestion was enough to get me on track. My problem was the my file was saved double-byte Unicode with a BOM, and openssl for windows couldn't deal with that. I resaved as ascii and it worked.

[natevw]

Thanks @ElroyFlynn, that was my problem too — openssl on Linux has the same trouble if there's a BOM at the beginning of the file.

[ruakh]

+1. In my case, the problem (once I looked carefully) was that I actually had a certificate request (-----BEGIN CERTIFICATE REQUEST-----) rather than a certificate (-----BEGIN CERTIFICATE-----). I was able to inspect it by using openssl req ... rather than openssl x509 ....

[shubhamkes]

M kinda noob, pls suggest me..How to edit this file in mac

[Jonathon Richardson]

I had a similar error. Inverting the order worked for me.

[ErichBSchulz]

My keys came in seperate files I needed to create a new file: cat $SOURCE/privkey.pem $SOURCE/fullchain.pem > server.pem

[HughHughTeotl]

Yes! This worked for me. Note PEM certificates exported from Apple's Keychain utility don't have the BOM and this upsets some programs.

[secondbreakfast]

For anyone else who has this error, my problem was that I was running the command to convert .p7b to .cer as openssl pkcs7 -in pkcs7.p7b -print_certs > pem.cer, the solution was to use -out instead of >, so openssl pkcs7 -in pkcs7.p7b -print_certs -out pem.cer

[edwardsmarkf]

at least i am not the only one who made this mistake... i am surprised the module does not alert us to this.

[Amichai Schreiber]

this took me hours to work out. All starting with a cryptic error from xmlsec1, key is not found

[Borzh]

No need for -text parameter