Intermediate certificate is not checked for expiry if server certificate is not due for expiry

[andrewbonney]

This is a fresh report for #8917 which was closed due to inactivity. The same issue persists in the latest versions.

My operating system is (include version):

Ubuntu 20.04

I installed Certbot with (snap, OS package manager, pip, certbot-auto, etc):

Snap (v2.8.0)

I ran this command and it produced this output:

root@mirror:~# certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/mirror.<redacted>.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate not yet due for renewal

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The following certificates are not due for renewal yet:
  /etc/letsencrypt/live/mirror.<redacted>/fullchain.pem expires on 2024-02-22 (skipped)
No renewals were attempted.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Certbot's behavior differed from what I expected because:

Whilst the server certificate was in date, the intermediate certificate was less than 30 days from expiry and required renewal before the server certificate would next be requested by certbot as shown below:

root@mirror:~# echo | timeout 1 openssl s_client -connect 127.0.0.1:443 -showcerts 2>/dev/null > certs
root@mirror:~# openssl crl2pkcs7 -nocrl -certfile certs | openssl pkcs7 -print_certs -text | grep Not
            Not Before: Nov 24 13:23:58 2023 GMT
            Not After : Feb 22 13:24:58 2024 GMT
            Not Before: Jan  9 10:20:31 2023 GMT
            Not After : Jan  9 10:20:31 2024 GMT <--- Due for renewal

Re-running certbot with --force-renewal produced the following output and did successfully renew the intermediate.

root@mirror:~# certbot renew --force-renewal
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/mirror.<redacted>.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewing an existing certificate for mirror.<redacted>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all renewals succeeded: 
  /etc/letsencrypt/live/mirror.<redacted>/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
root@mirror:~# echo | timeout 1 openssl s_client -connect 127.0.0.1:443 -showcerts 2>/dev/null > certs
root@mirror:~# openssl crl2pkcs7 -nocrl -certfile certs | openssl pkcs7 -print_certs -text | grep Not
            Not Before: Dec 12 08:27:36 2023 GMT
            Not After : Mar 11 08:28:36 2024 GMT
            Not Before: Nov 24 15:13:59 2023 GMT
            Not After : Nov 23 15:13:59 2025 GMT <--- New intermediate loaded

[osirisinferi]

While @bmw mentioned in #8917 it would make sense to check the expiry status of intermediate, I'm not sure I agree: personally I'd say it's the responsibility of the ACME server not to issue from intermediates with an expiry date shorter than the expiry date of the end leaf certs. I don't think there's a role for the client in this.

I'm interested in a discussion in this regard.