53

I've been setting up SSL for my domain today, and have struck another issue - I was hoping someone could shed some light on..

I keep receiving the following error messages:

[error] Init: Unable to read server certificate from file /etc/apache2/domain.com.ssl/domain.com.crt/domain.com.crt
[error] SSL Library Error: 218529960 error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag
[error] SSL Library Error: 218595386 error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error

I'm running Apache 2.2.16 and Ubuntu 10.10. My .crt file has the Begin and End tags, and has been copied exactly from the confirmation email I received, very frustrating!

Cheers!

Edit >> When trying to verify the .crt It doesn't seem to work:

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

Also >>

>> openssl x509 -text -inform PEM -in domain.com.crt
unable to load certificate
21321:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:650:Expecting: TRUSTED CERTIFICATE
>> openssl x509 -text -inform DER -in domain.com.crt
unable to load certificate
21325:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1316:
21325:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:380:Type=X509

Edit>> (Cheers for the help by the way)

>> grep '^-----' domain.com.crt
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

Just emailed the company providing the Certificate, they responded>

I have checked the CSR file that you have provided and I can assure that this was correctly generated. The error that you are currently encountering is caused because you are using a wrong command line for installing the CSR. You will need to modify this domain.com.crt from your command line with the according name of your domain.

  • currently the crt is set up to mysite.com.crt - I've used domain.com.crt as an example
4
  • Could you please show us the output of grep '^-----' domain.com.crt?
    – quanta
    Sep 30, 2011 at 9:23
  • Williamsowen, the whole point of a certificate is to be shown to anyone who connects to your webserver; it's not a private thing. That given, would you consider attaching or posting the whole certificate here so we can look directly at it instead of having to guess?
    – MadHatter
    Sep 30, 2011 at 11:30
  • Hang on, I see you've just accepted my answer. Does that mean that it was terminal Windows linefeeds that were causing the problem?
    – MadHatter
    Sep 30, 2011 at 11:31
  • MadHatter - apologies! New to this, but I've just got it working, the formatting from the email I receieved was off, couldn't thank you guys enough! Sep 30, 2011 at 11:33

16 Answers 16

57

Is it possible that the lines are ^M-terminated? This is a potential issue when moving files from Windows to UNIX systems. One easy way to check is to use vi in "show me the binary" mode, with vi -b /etc/apache2/domain.ssl/domain.ssl.crt/domain.com.crt.

If each line ends with a control-M, like this

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

you've got a file in Windows line-terminated format, and apache doesn't love those.

Your options include moving the file over again, taking more care; or using the dos2unix command to strip those out; you can also remove them inside vi, if you're careful.


Edit: thanks to @dave_thompson_085, who points out that this answer no longer applies in 2019. That is, Apache/OpenSSL are now tolerant of ^M-terminated lines, so they don't cause problems. That said, other formatting errors, several different examples of which appear in the comments, can still cause problems; check carefully for these if the certificate has been moved across systems.

10
  • 4
    For me it was a copy&paste error, omitting the first couple of characters of the header -----BE... Thanks for the inspiration to double check!
    – cfi
    Nov 3, 2012 at 17:31
  • Thanks, this was my problem! In notepad++ in windows you can use the EDIT-EOL conversion dialog to change set the correct LF format. And you can use the View-Show Symbol menu to actually see the windows CR LF line endings.
    – Bjørn
    Nov 17, 2013 at 13:04
  • 1
    My certificate simply ended up being an empty file. Something got broke in the generation I guess. This answer encouraged me to open it up and see that.
    – flickerfly
    Feb 18, 2014 at 19:31
  • 1
    CRLF shouldn't matter; Apache uses OpenSSL and OpenSSL accepts and ignores CR in PEM on all systems even Unix. However, there is a different Windows-caused issue: many Windows programs like to put a Byte Order Mark, appropriately abbreviated BOM(b!), at the beginning of the file and thus the beginning of the first line, which OpenSSL does NOT accept. vi -b, or cat -v, should show this; I don't think dos2unix fixes it. Apr 3, 2019 at 19:34
  • 1
    @dave_thompson_085 fair enough, but others have reported otherwise in comments above, so I don't intend to further modify this answer.
    – MadHatter
    Apr 6, 2019 at 6:29
29

For anyone arriving at this page with a similar error when trying to read a Certificate Signing Request (CSR) (note that OP is reading a certificate): make sure to use the right OpenSSL command. x509 is for certificates and req is for CSRs:

openssl req -in server.csr -text -noout

vs

openssl x509 -in server.crt -text -noout
26
>> 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

I suspect that you have a problem with the format of the certificate.

Run both of two following commands and give us the output:

openssl x509 -text -inform DER -in domain.com.crt 
openssl x509 -text -inform PEM -in domain.com.crt 
2
  • 1
    Thanks for this answer. I was able to determine the format my SAs provided as ".cer" were already ".pem" incognito
    – javafueled
    Apr 5, 2012 at 15:15
  • This was helpful !!! actually a generated cer file in windows was actually a pem Apr 7, 2022 at 13:02
20

Just went round and round in circles on this, and it turned out I had the certificates around the wrong way - e.g.

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

instead of:

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

Something to check if you're getting this error.

0
12

In my case, I found my certificate had different "-" characters. Must have been a copy/paste issue from the admin that placed the cert onto the server, with the text editor replacing -- with a special unicode character along the way.

This took hours to diagnose, and in the end I just guessed at it, and edited the cert in vi and deleted the existing "-" characters, and retyped them.

Hope this helps someone.

1
  • slack did this to me! thanks
    – jnnnnn
    Sep 15, 2021 at 5:15
11

In my case, I encountered the OP's errors because whoever created the .crt file for me in the first place had really created a .PEM formatted file, and named it .crt.

I discovered this by running into the following helpful guide: https://web.archive.org/web/20200103195255/https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-cer-vs-pem-certificates-and-how-to-convert-them.

EDIT NOTE: The originally posted URL is no longer working but included for completeness: https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-cer-vs-pem-certificates-and-how-to-convert-them

all I had to do was rename my .crt to a .pem, and I was done! The guide indicated that the errors from the OP's question imply that the input file is PEM formatted already, so attempting to convert it to .pem from a DER format cannot be done, and is in fact unnecessary.

0
4

Make sure your file has no trailing or leading spaces within the certificate file. Carefully ensure there are no spaces or blanks within your certificate file, by selecting the entire text and looking for blank spaces on a text only editor.

Also check if indeed all the configured files exist and are correct.

Eg: on your other post you say that your .key file is named mydomain.com.crt while on the vhost configuration you have domain.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

Check again that all the above files really exist and are valid.

4
  • 3
    Also check that your dashes are dashes. Microsoftian text editors like to change -- into ; that was not a lot of fun to troubleshoot. Sep 29, 2011 at 17:10
  • yeap, since you're on Ubuntu, just open up a terminal and use nano for example. This way you'll be sure. Sep 29, 2011 at 17:16
  • Hi, thanks for your feed back - I've checked everything and all is good. I've tried to verify the crt file however I get: sudo 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 Sep 29, 2011 at 21:23
  • 1
    Does the first line of your domain.com.crt file begin with -----BEGIN CERTIFICATE----- and the last line ends with -----END CERTIFICATE-----? Sep 29, 2011 at 21:34
1

Should someone else run into this problem and your apache error logs say something like:

Init: Unable to read server certificate from file /etc/apache2/domain.com.ssl/domain.com.crt/domain.com.crt

Make sure you haven't swapped your key and certificate files in the declarations in the apache config. I had pointed the key to my certificate file and the certificate to my key file. This post helped me figure out the problem but I wanted to point it out as another potential problem/solution.

1

In my case, it has to do with BOM being present in the file. One could strip it like so:

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

Not sure if it always takes 3 bytes, so the better way must be:

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

I had this problem because I was sent the content of an IIS-style .p7b file pasted into an email. It has "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" tags, just like .pem, and the content uses a similar looking base64 encoding. I converted it to a *.pem file like so:

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

After that, Apache 2.2 was happy.

0

My problem (having the same error while installing a new server with Apache 2.4) was that Apache (2.4) couldn't read the binary .crt file. I imported it in my personal certificate store (with mmc) and exported it as base-64 encoded X.509 (.cer). Renamed the exported file to the same name (.crt) (used in my httpd-ssl.conf) and it worked again! The same certificate worked on my old server, maybe Apache 2.4 is more stringent then 2.2? Good luck.

0

I got the same error because I switched .key with .crt filenames

0

I had a similar problem when I accidentally used a customer-supplied p7b type IIS cert in the apache config. Converting the cert to x509 format fixed the error. Both types look the same on the surface but are apparently different on the inside.

0

I recently had this issue using Lets Encrypt (letsencrypt) on Windows. The cert came back encoded as UTF-16LE. Converting it to UTF-8 (using dos2unix) solved the problem.

0

In my case was just the empty lines. When i pasted the crt file from ntepad or notepad ++ in nano always got smth like

sdgrgrgr rgregegreg rgrgreg
rgregreg rggregregr rgregrg

removing the empty spaces and putig all in a line solved the problem Eg :

sdgrgrgr
rgregegreg
rgrgreg
rgregreg
rggregregr
rgregrg
0

In my case, the PEM file contained just the key, not the certificate.

Check the file contents, it must contain the line

-----BEGIN CERTIFICATE-----

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .