--preferred-chain compatibility with LE Android vs OpenSSL choice

[philpennock]

In https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816 LE detail their upcoming use of alternate chains, to let people choose to be compatible with unmaintained OpenSSL instead of compatible with unmaintained Android. Some TLS-protected services I manage will need to bias in favor of bad OpenSSL, not bad Android.

As far as I can tell from #1227 and #1298 and the current help text, the first chain found where any certificate in the chain has an Issuer CN matching the supplied string will be used. This is the same logic which certbot used to use, until certbot/certbot#8596 at which point they switched to only matching the root name.

1. I can't tell for sure without something to test against, but by inspection it looks as though the newer certbot behavior is needed for this situation, because my desired chain is, from the [sequence, of, CN] perspective, a subset of the first chain; thus there is there's no way to match the desired chain without also matching the first chain, so the current behavior is not useful for this ACME server in this scenario
2. I can't see any options for introspection/logging which would let people step through, perhaps interactively, and see the available options.

I think in my ideal scenario, I'd be able to use lego [...] run --interactive or lego [...] run --preferred-chain='?' to trigger a flow where lego will pause after getting the available chains, show the chains, let someone type/paste a matcher string, then list the matched results and show which one will be used and get confirmation, before continuing through to get the final cert. This flow would let folks see the available options and figure out the exact string to use, without excessive API requests.

Does this all make sense? Have I gone horribly wrong somewhere in my understanding?

Thanks.

[ldez]

Hello,

I think in my ideal scenario, I'd be able to use lego [...] run --interactive or lego [...] run --preferred-chain='?' to trigger a flow where lego will pause after getting the available chains

An interactive mode cannot be a solution because lego is mainly used as a lib, in the lib we cannot ask for user interaction.

[philpennock]

Oh, I thought the CLI would be able to do this without imposing it through the lib. Well, at least a way to ask it to --report-available-chains then?

[philpennock]

(We mostly care about being able to use lego at all for cert issuance to get the chain we need, the introspection is a convenience to reduce the calculate-from-first-principles work, but we've done that now for our contingency plan, so we're okay; I do think the introspection will be generally useful, it's just not critical.)