On Thu, Jan 08, 2026 at 02:38:50PM -0600, Mike Ounsworth wrote: > Ilari also makes the excellent point that a profile-set may be making > a recommendation that's incompatible with your webserver technology > stack -- for example if a profile-set suddenly adds a 2-chain version > of the existing 3-chain profile, or adds a no-ocsp version of the one > that normally comes with ocsp-staple, your ACME client may blow up when > you try to insert those into your webserver, or your webserver may blow > up in handshake when your server stack isn't designed to switch those > sorts of things on a per-SNI basis.
Or even worse, not visibly blowing up, but instead silently sending wrong certificates to clients. If there are overlapping certificates of the same type, which one is the default is important. Even if all the certificates share the private key. And due to how TLS trust anchor negotiation works (fallback to default), dropping all non-default certificates if your webserver does not support trust anchor negotiation with default certificates does not work. Ouch. I suppose it would be possible to have key type selected (which is not the same as key type default) and global selected (which I think is always key type selected for its key type) flags, signaling what should be used in case where only one cert per key type or only one cert is supported. Of course, merging that information across ACME servers (if one uses multiple) is challenging. -Ilari _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
