> > >> Also yes, we're very aware of this possibility. This is in fact a large > part of why we're making this change: it's a mechanical way of > discouraging/preventing intermediate pinning. We went through this recently > with the change to the R3 and E1 intermediates, and although some people > had to make changes to accommodate the new intermediates, there were > relatively few breakages. We expect to handle a similar level of support > requests this time, but with the advantage that (in theory) we'll never > have to do so again during future intermediate transitions. > > For what it's worth, the intermediate *shouldn't* need to be configured > statically in any ACME setup, since it is provided in the same file as the > newly issued certificate itself at the end of issuance. >
There do exist some exotic platforms where a trust-list-matching root anchor, an intermediate issuer/chain, and the leaf cert all need to be provided in separate files or in various concatenated combinations. In other environments, there needs to be a pfx/pkcs12 file with the full chain including the trust-anchor-root to be incorporated as a single chained cert/key object. Ultimately, the right place to fix all of that is at the ACME client / cert deployment tooling. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAPAx59FuW0_Ezt97RRx3Gobun7uMNTHPXCdrDi6Uk6n6oYA63w%40mail.gmail.com.
