`fullchain.pem` includes both root certificates (ISRG Root X1 and X2) instead of just leaf + intermediate — expected with Certbot?

Help
1

Body:

I issued a certificate via Certbot against the production Let's Encrypt API, and noticed my fullchain.pem contains 4 certificate blocks instead of the 2 I expected:

  1. Leaf certificate (my domain)
  2. Intermediate certificate (short-lived intermediate, "R-YE"/"E-YE" style)
  3. ISRG Root X2
  4. ISRG Root X1

I understood the standard convention for fullchain.pem to be leaf + intermediate only — since root certificates are already present in client trust stores and shouldn't need to be sent by the server. But this issuance includes both root certificates too.

Questions:

  1. Is this expected/current default behavior for Certbot's fullchain.pem output, or does it depend on some chain preference/flag I might be missing (e.g. --preferred-chain)?
  2. Is there a Certbot option to get the shorter chain (leaf + intermediate only, no roots) instead?
  3. Any functional downside to deploying this 4-block version as-is to something like nginx, versus manually trimming it to leaf + intermediate only?

Happy to share more chain details if useful for diagnosis.

2

For an ECC certificate (which is now the default in certbot), the default chain has four certificates, however they're different to the ones you list. It's possible you were looking as the issuer field instead of the subject field.

  1. Leaf certificate
  2. YE* signed by YE
  3. YE signed by X2
  4. X2 signed by X1

Certificates 2-4 are all intermediates and the four certificate chain can be served as-is by most TLS servers including Nginx.

If you can be certain that all your clients trust X2, you can eliminate certificate 4 in the chain by using --preferred-chain "ISRG Root X2", however certificate 3 (YE signed by X2) is still currently required by most clients.

3

You could show the last two certs in that file.

4

For the most part, for general web sites (and other TLS uses), you should just use the fullchain as is, since it's designed to be the most compatible and work best. If you know more about the root stores of the devices connecting (like, this is some API server that only some dedicated devices are supposed to connect to) you can request a specific appropriate chain for it with --preferred-chain, but then you should be paying more attention to future changes to ensure you're always selecting a chain that will work for your use case. Most people don't need to worry about it and should just use the default.