Allow preferred chain option

[JustInVTime]

What are you trying to do

With the expiration of the DST Root X3 cert, I would like to use the ISRG Root X1 cert as the only chain for Let's encrypt certs.
Tools like certbot and dehydrated have an option to specify the preferred chain to set it to ISRG Root X1.

What HAProxy Ingress should do or how it should behave differently

Currently the certs are still created with the ISGR Root X1 cert, which was signed by this expired DST Root X3.
Clients with on older version of openssl don't trust the current chain: cert (valid) -> x3 intermediate (valid) - > ISRG Root X1 (valid) -> DST Root X3 (expired self signed).
Using the new chain "cert (valid) -> x3 intermediate (valid) - > ISRG Root X1 (valid, self signed)" solves this issue, as long as the this ISRG root X1 certificate is in their trust store of course.

[jcmoraisjr]

Hi, just to confirm if I understood you correctly as well as the problem itself. Older openssl versions doesn't correctly walk through the certificates of a chain and, if the client has the expired dst x3, it won't give the chance to check that the ISRG x1 is in fact self signed and trusted. So the client should either update openssl or remove dst x3 from its truststore.

So a work around that could be made in the server side is, instead of build the crt chain with leaf + R3 + ISRG x1, we'd only add leaf and R3, being R3 valid due to the presence of the ISRG x1 in the client's truststore, without needing to wrongly use DST x3. Did I miss or wrongly understood anything?

[JustInVTime]

Hi

Hi, just to confirm if I understood you correctly as well as the problem itself. Older openssl versions doesn't correctly walk through the certificates of a chain and, if the client has the expired dst x3, it won't give the chance to check that the ISRG x1 is in fact self signed and trusted. So the client should either update openssl or remove dst x3 from it's truststore.

Yes they should update their openssl version, and update their truststore, but that's not always possible (unsupported devices).

So a work around that could be made in the server side is, instead of build the crt chain with leaf + R3 + ISRG x1, we'd only add leaf and R3, being R3 valid due to the presence of the ISRG x1 in the client's truststore, without needing to wrongly use DST x3. Did I miss or wrongly understood anything?

Well if you do that, you would exclude some older android devices. Because apparently Android doesn't enforce the expiration dates of certificates used as trust anchors.

More info about this see https://letsencrypt.org/2020/12/21/extending-android-compatibility.html and https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816

So basically it's up to the user base of the application behind the certificate which chain path you would like to have.

I was more thinking about an annotation for the ingress object, to specify if you would like the alternative certificate chain. This is fully supported by the Let's encrypt API. When it sends back the certificate, it contains the default chain (based on the expired DST root), so android devices and clients with openssl > 1.1.0 are fine. It also sends an alternative link attribute in the response headers, with a url which points the the alternative chain, based on the self signed ISRG root.

For example: haproxy-ingress.github.io/acme-preferred-chain: "ISRG Root X1"

Don't know if you are familiar with dehydraded? A bash implemented ACME client.
See https://github.com/dehydrated-io/dehydrated/blob/master/dehydrated#L1187-L1206

[jcmoraisjr]

I did some tests with Let's Encrypt production (staging unfortunately doesn't have alternative chains) and I can confirm that we can use a global or per-ingress config to find alternative chains provided by the acme response. However I realized on my tests that the alternative chain doesn't provide the self signed ISRG Root X1 , but instead only leaf + R3. This is somewhat close to my proposal, but provided by acme API instead changing the chain myself. Did you find the same results?

[JustInVTime]

I did some tests with Let's Encrypt production (staging unfortunately doesn't have alternative chains) and I can confirm that we can use a global or per-ingress config to find alternative chains provided by the acme response.

Nice!

However I realized on my tests that the alternative chain doesn't provide the self signed ISRG Root X1 , but instead only leaf + R3. This is somewhat close to my proposal, but provided by acme API instead changing the chain myself. Did you find the same results?

Yes that's correct. The root certificate is never returned. With the default chain you get leaf > X3 > ISRG Root X1. For the latter not the self signed, but the one signed by the expired DST Root X3. The self signed ISRG X1 (valid till June 2035) and the one signed by the DST Root X3 (valid till september 2024) are different certs.

[github-actions]

This issue got stale and will be closed in 7 days.

[jcmoraisjr]

Finally tag and released. Closing.