Hi @jsha, what is your suggestion for client developers who want to implement:
Subscribers who support very old TLS/SSL clients may want to manually configure the older intermediate to increase backwards compatibility
At the moment I haven’t found any proposed implementations in the popular clients:
I plan to implement this in our cPanel client for as long as the old chain is valid, since the compatibility situation doesn’t look so hot and we don’t want to surprise our users.
From what I can tell, there isn’t currently any way to find the cross-signed issuer certificate from a leaf certificate.
So at present, I would have to hard-code a substitution of the intermediate, which seems too risky and I can’t think of a way to do it that would be future-proof (X2->X3 transition tripped up a lot of client developers). Putting the burden on end-users to configure the chain seems backwards too - ACME clients are often completely non-interactive.
The AIA extension seems to provide the ability to include multiple caIssuers, though Boulder seems to explicitly say it won’t do that. If it did, we could choose the most compatible issuer by looking at the certificate itself.
Alternatively, and although it’s not strictly what’s written in RFC8555, could the server include the alternate issuer in an
Link: rel="up" header, when downloading the certificate?
Any ideas would be great …
e: @eggsampler pointed out to me that
rel="alternate" exists (https://tools.ietf.org/html/rfc8555#section-7.4.2). That seems like the obvious and correct solution, is there a plan to use it? I’ve written an extremely rough draft implementation for how it might work.