Re: openssl 1.0 vs 1.1 s_client verify CA cert expiration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux