Ca.pem - how to test a valid and invalid file?

klimbot · April 8, 2024, 7:47am

Thought I’d start a new thread instead of hijacking the existing.

I’m trying to get ahead of this ca.pem certificate issue and need some help understanding how to know if my certificate will work with the upcoming change and removal of X3 based cert in the mDash certificate authority.

My stack

I use the ca-bundle package with mongoose-os on version 2.20.0.

Different ca.pem files

ca-bundle tagged 2.20.0 uses X3 based cert, and shows the following output from openssl:

$> openssl x509 -enddate -noout -in x3-based-ca.pem
notAfter=Sep 30 14:01:15 2021 GMT

ca-bundle tagged latest has the X3 based cert removed, and shows the following output from openssl:

$> openssl x509 -enddate -noout -in updated-ca.pem 
notAfter=Jan 15 12:00:00 2038 GMT

Alternatively, @cesanta has called out the ca.pem file only needs to be as small as

and outputs:

$> openssl x509 -enddate -noout -in lets-encrypt-ca.pem 
notAfter=Sep 17 16:00:00 2040 GMT

But I guess this ca.pem doesn’t work for non lets encrypt based SSL connections?

How to test a ca.pem file?

I’m trying to find a way to test these ca.pem files against servers called out by this post as having either the X3 based cert in the chain or without the X3 based cert it the chain. My intention is to verify if the ca.pem file I’m going to deploy on devices will survive the update.

mDash.net - has X3 cert in chain
mongoose.ws - does not have X3 cert in chain

Here is what I have come up with, but I don’t know enough about this to know what I’m doing wrong:

$> openssl s_client -connect mongoose.ws:443 -CAfile x3-based-ca.pem
---
SSL handshake has read 2777 bytes and written 399 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

and

$> openssl s_client -connect mongoose.ws:443 -CAfile updated-ca.pem
---
SSL handshake has read 2777 bytes and written 399 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Would appreciate any advice or suggestions

klimbot · April 18, 2024, 4:11am

Based on this reply over at community.letsencrypt.org the only way to test this is to do it from the device.

Sounds like it’s plausible that devices using esp-idf may be experiencing the issue but devices with mos may not.