We are resolving this incident as it was never an issue with cloud.gov. We created this issue when a customer reported issues, and there was some question whether some of the TLS certificates we had issued did not have the correct trust chain, but that was not the case.
For context, if you use TLS certificates through our external domain service (https://cloud.gov/docs/services/external-domain-service/
), those certs are issued by Let's Encrypt. The certificates serve a trust chain given to us by Lets Encrypt. Clients can use the first cert in the chain to build a full chain up to "DST Root CA X3", which expired 30 September 2021, or the second cert in the chain to build a full chain up to "ISRG Root X1".
If a client (e.g. the web browser on an older system) has "DST Root CA X3" as a trust anchor but not "ISRG Root X1", they will probably get a certificate validation error because "DST Root CA X3" expired earlier today.
If they have BOTH certs in their trust anchors, it's possible they'll get an error, as "DST Root CA X3" is expired, and the client may give up after constructing a bad chain, but most well-behaved clients will continue checking for a valid chain and find it. However, either client configuration is wholly outside cloud.gov's purview.
As Let's Encrypt tweeted today:
> Our cross-signed DST Root CA X3 expired today. If you are hitting an error, check out fixes in our community forum: https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/212
If you have questions, please consult the resources above, or open a support issue.