openssl 1.0 vs 1.1 s_client verify CA cert expiration

nate openssl at linuxpowered.net
Thu Sep 30 18:26:14 UTC 2021


On 2021-09-30 10:51, Viktor Dukhovni wrote:

>> I get at the end a clear: Verify return code: 10 (certificate has 
>> expired)
> 
> This is because OpenSSL 1.0.2 looks at the peer's certificate chain
> before looking in the trust store.

Ok, good to know, thanks!

> 
>> If I run on the same OpenSSL:
>> 
>> openssl s_client -connect bad_server_name:443 -servername 
>> bad_server_name | openssl x509 -noout -dates
> 
> This is *not* the correct way to see all the expiration dates in the
> chain.  It will show only the leaf certificate dates.  The right
> incantation is:
> 
>   $ openssl s_client -connect bad_server_name:443 -servername 
> bad_server_name |
>     openssl crl2pkcs7 -nocrl -certfile /dev/stdin |
>     openssl pkcs7 -print_certs -noout -text |
>     egrep 'not(Before|After)'

At least in this case the command you supplied appears to provide less 
information:

(OpenSSL 1.0.2g)
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT

(OpenSSL 1.0.2g with -trusted_first option)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = bad_server_name
verify return:1

(OpenSSL 1.1.1f)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = bad_server_name
verify return:1

than the one I did(which I found with a web search earlier today), 
though
that is an edge case for sure since it is only showing the CA that is
expired. Tried it on other sites and it doesn't show the CA info.

Is there a command sequence that could get openssl to show all dates in
the tree whether it is being served by the server or checked in the
local trusted store? I assume your command is intended to do that, but
it doesn't for me.

> Correctly configured systems that use the Let's Encrypt 
> "full_chain.pem"
> file are using the ISRG version, and should not have any issues,
> provided the client system is using OpenSSL 1.1.1 and has the ISRG root
> CA

yes I got that from a link another person posted, thanks! Though I 
realized
that this app stack uses an embedded openssl 1.0.2u which isn't possible
to upgrade at this time so the easiest solution is to fix the cert on
the remote end, it's a very small site so not concerned about 
compatibility
with super old clients. Been blocked on upgrading the OS on these app
servers for 4+ months now, not that upgrading Ubuntu would help since
the app uses it's own openssl anyway. Doing a major openssl change on 
the
app itself would probably be a big change that would be done by staff
that aren't at the org anymore. So not expecting that to happen anytime
soon. The app openssl is only used for outbound connections, all inbound
ssl is handled on external load balancers.

thanks

nate


More information about the openssl-users mailing list