Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
we have a hosted service in which a small number of our customers perform local validation of connection using a local cert bundle which we provide for them. Understand this is not recommended, but some customers insist. We are trying to stay ahead of any new updates to the intermediate certificates used for issuance. In the March 2024 blog post announcing the new intermediate certificates, it was mentioned that the backup certs would be introduced in about a year.
For the web page showing chaines of trust, under the drop down description for the backup intermediate certs, I see this notice: These intermediate CAs have currently-valid certificates, but are not being issued from. We may begin issuing Subscriber certificates from them at any time, without warning.
Just want to clarify if I need to take immediate action to have my customers upload local cert bundle to include these backups or if it is still panned to be introduced next year sometime?
You should have the customers upload the local cert bundle now, if possible. Even better, have them move to a system that allows them to trust our roots (X1 and X2) instead of our intermediates.
We plan to switch to the backup intermediates in about a year. But plans don't always work out. We may have to switch to the backup intermediates at literally any time due to a variety of different emergencies, so you and your customers should plan for that possibility.
Can you describe what is in the "local cert bundle" and how/when they validate?
Going beyond what aarongable said, I think there may be multiple anti-patterns deployed.
I just looked at the docs on your site, and I saw the ability to specify a SSL Cert, but not a fullchain (of intermediates to the root). Did I miss something?
As mentioned above, the two roots should be trusted - not the intermediates. There are currently two live intermediates, and six backups in reserve; a given certificate might be signed by any one of them.
An online test should be pulling the end-entity/leaf and intermediates from the connection.
An offline test should include a "fullchain' that is the end-entity/leaf
and signing intermediates that you somehow provide to them, and update on reissue, as they are paired to that certificate.
Both of those should be checked to trust up to the X1/X2 root.
Based on what you shared, and the docs on your site, it looks to me like your cloud system is treating the intermediates as roots. That runs the risk of creating many problems, and you should either have a new configuration option for the intermediates chain or support fullchains (cert + intermediates in one file).