Just some questions about this announcement:
Has this already been done in staging? While I agree that the change shouldn't break anything, weirder things have happened. Is there any good way to test that applications will continue to work before the change takes effect? (Especially for those use cases that don't involve web browsers, like API calls, client auth, SMTP, and other non-HTTP protocols.) Do other common CAs already not include this data?
Thanks. Just being nosy; I don't actually anticipate any problems directly affecting me, but it'd be good to have resources for people to use in case people think it might affect them.
Good point! It has not yet been made in staging but we will do that first, probably with next week's deploy.
I had a short look into the X509v3 Certificate Policies and, oh my, this is confusingly worded in many places (especially the BRs).
As I understand it, the Certificate Policies (188.8.131.52) extension itself is mandatory for TLS leaf certificates. It must include at least one
policyIdentifier entry. This is either 184.108.40.206.2.1 (domain-validated certificate), 220.127.116.11.2.2 (OV cert), or 18.104.22.168.1 (EV cert). You will find this in all BR compliant certificates.
Next, with the current BR version, CAs may add additional
policyIdentifiers to their certificates. This is now purely optional (but not discouraged) it seems. Each
policyIdentifier can optionally have one or more
policyQualifiers, the (current) BR's only allow
id-qt-cps (22.214.171.124.126.96.36.199.1), which is a URL to a CPS. These
policyQualifiers are now discouraged.
I understand that Let's Encrypt wants to remove their custom
policyIdentifier they use for the CPS and the corresponding
policyQualifiers (the CPS link).
I didn't look too deep into other CAs, but it appears that up until recently CAs have typically used the
- ZeroSSL (Sectigo) issuer ZeroSSL RSA Domain Secure Site CA includes both a custom
policyIdentifier and a corresponding
policyQualifier (example cert)
- Buypass issuer Buypass Class 3 CA 2 includes not only a custom
policyIdentifier, but also includes its CPS (
policyQualifier) twice, in both the reserved and the custom
policyIdentifier (example cert).
- The Google Trust Services issuer GTS CA 1P5 appears to include a custom
policyIdentifier, but without any
policyQualifiers (example cert). During my quick check, this was the only CA without a
policyQualifier, but like I said, I haven't looked in greater detail.
I would also like to remind Let's Encrypt that they should reflect the change (when it's made) in their CPS, since it explicitly mentions the custom OID and the CPS link as being part of the subscriber certificate.
Thanks! We’re already planning to have the CPS updated before we go live. (Changes: Remove CPS OID and URL from Subscriber Certificate profile by aarongable · Pull Request #191 · letsencrypt/cp-cps · GitHub)
This change is now live in staging, as of about 5 minutes ago.
Thank you; are there any changes to be made to Pebble for testing this? Or do Pebble certificates already not include these fields?
To be clear, the change here is about the certificate that Let's Encrypt gives you. There isn't any change I'm aware of to how Let's Encrypt reads the CSR you send it, and as far as I understand it, it only picks out the couple pieces it uses from that CSR and ignores the rest.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.