unable to load certificate with latest version

[j75]

Hello,

Testing my SMTP server with 4.11 version (from master) on a Debian 10 produces the following message:

unable to load certificate
140114474460288:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
unable to load certificate
139671307031680:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
unable to load certificate
139643736753280:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
unable to load certificate
140595073569920:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE

However, with an older version (3.30 from Ubuntu 18.04) it has no problem:

$ ssl-cert-check -x 8 -s mail.home.famion.eu -p 25

Host                                            Status       Expires      Days
----------------------------------------------- ------------ ------------ ----
mail.home.famion.eu:25                          Valid        Sep 12 2019  33     

Using openssl directly shows no error in certificate (and thus confirms that openssl is OK):

echo "" | openssl s_client -connect mail.home.famion.eu:25 -starttls smtp -showcerts | openssl x509 -text
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = home.famion.eu
verify return:1
...
        Validity
            Not Before: Jun 14 13:14:17 2019 GMT
            Not After : Sep 12 13:14:17 2019 GMT
...

Is there anything I can do?

[Glandos]

duplicate of #50 Fixed by a patch in #52

[j75]

No, it is not fixed; what this patch is doing is to add "${VERSION}" at the end of TLSFLAG variable, but this variable worth -tls1_1 and thus crashes on my server that does not support this old protocol version =>

CONNECTED(00000003)
139834287178816:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:../ssl/record/rec_layer_s3.c:1536:SSL alert number 70
---
no peer certificate available
---

Unfortunately, although in the (original) script the variable TLSFLAG is correctly set to -starttls smtp for the port 25, it is set again at line 661, hence my error message:

CONNECTED(00000003)
140192925803584:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:332:
---
no peer certificate available
---
No client certificate CA names sent

If it would have been added to the command, then the correct answer is obtained.

[kitserve]

I can verify this with an FTP server on port 21. Version 3.31 returns the following line of output:

example.com:21                                   Valid        Mar 3 2020   83                                 

Version 4.11 returns the following:

140261533037760:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
unable to load certificate
139775922095296:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
unable to load certificate
139842096620736:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
unable to load certificate
140636187006144:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
example.com:21                                   Expired                   -2458829                               

Server name redacted but can be supplied via PM if required for testing purposes.

[kbabioch]

Bisecting the master branch, identified ea7d5c2 as the culprit.

[Matty9191]

Thanks for the feedback everyone! I'm planning to get everything cleaned up and merged this weekend. It's been a crazy past couple of months so my apologies for not getting to this sooner.

[kbabioch]

Debugging this further:

In the working commit, the OpenSSL command line that is eventually triggered is this:

openssl s_client -connect mail.home.famion.eu:25 -starttls smtp

After the update, OpenSSL is invoked in this way:

openssl s_client -crlf -connect mail.home.famion.eu:25 -servername mail.home.famion.eu

As you can see the -starttls smtp is missing, leading to this error message:

140015268316416:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:331:

So essentially it comes down to openssl s_client being invoked in the wrong way.

[sdellenb]

Looking at the mentioned ea7d5c2, it's because this code: https://github.com/Matty9191/ssl-cert-check/blob/f3fc941bfaef7eb7b022e26c2dde99e323fc5e53/ssl-cert-check#L660-L664 overrides everything previously set in https://github.com/Matty9191/ssl-cert-check/blob/f3fc941bfaef7eb7b022e26c2dde99e323fc5e53/ssl-cert-check#L646-L658 so the -starttls flags get lost.

[Matty9191]

Can you try version 4.12? I just uploaded a new version with a ton of fixes from Daniel Lewart. This should address the issue you are seeing.

[sdellenb]

Yes, checking the certificates on postfix and dovecot works in the latest version. 👍

However, the Issuer column is always empty (should be "Let's Encrypt", as it shows when using version 3.30). Update: It also works on 4.11, seems to be a regression in 4.12.

[Matty9191]

Can you share one of the domains you are checking? That will help me debug.

[j75]

Yes, it seems now that it works - at the expense of not being able to set the TLS version anymore (it was possible before with the -v option).