In the meantime, more CA's are announcing their deprecation plans:
6 Likes
(boggle)
Verisign is going to be feeling ...great love for the Chrome team right about now. They provide registry infrastructure for an enormous number of domains, reportedly more than 300 million of them.
Given who they are and the scale of the issue they'll presumably be in a position to make and implement suitable decisions, even if those decisions are to tell up to ~3,000 registrars to get more expensive certificates.
2 Likes
Interesting. I could not find the quoted/paraphrased manual anywhere, so I guess it is somewhat mis-quoted. It would be interesting to see what the full paragraph was, as the paraphrased sentence is rather self-contradicting. It should only be possible to be EITHER publicly trusted OR of Verisign's choosing.
I don't think this is a contradiction.
"Publicly-trusted CA" presumably means compliance with the relevant profile in the WebTrust criteria (which is the CA/Browser Forum basis for entry into browser trust bases), which include requirements about the relationship with certified organisations. There's no obvious problem with a trust agreement stating that Verisign can specify any CA it likes, so long as it is one which meets these criteria, thereby bounding the obligations that the registrar is thereby taking on. Removing this limit would put registrars in the position of agreeing to accept arbitrary criteria from a Verisign-controlled CA.
What surprised me was the claim that the change arose from CA/BF, which does not appear to be the case. It really does look like the Chrome team exercising its right to tighten security criteria unilaterally.
2 Likes
While I don't have access to the Verisign Registrar Reference Manual (or I can't find it), subsection 2.8.b of the .COM Registry-Registrar Agreement requires that a server certificate is used for client authentication.
...
Registrar agrees to authenticate every EPP client connection with the System using both an X.509 server certificate issued by a commercial Certification Authority identified by the Registry and its Registrar password, which it shall disclose only to its employees with a need to know.
...
5 Likes
Interestingly, certs I get now from Google Public CA using ACME only have the Server Authentication EKU.
Confusingly, their FAQ says clientAuth EKU is set with serverAuth default. They warn this is likely to go away. I think it likely the FAQ info is stale but not sure. See: Google Trust Services | FAQ and contact
They also describe their various cert "profiles". I'm not sure how you make use of these from ACME. Looks like may need to use their REST or console to take advantage. See: Certificate profiles | Certificate Authority Service | Google Cloud I hope they will support Aaron's draft for ACME "profiles" but they didn't mention that in these docs.
That doesn't contradict anything you said. Just adding info for those who wish to pursue it. They describe a profile with both client and server EKU. Maybe that is an option for some cases?
2 Likes
Keep in mind that Google, Microsoft, and other tech "giants" are, well, "giant". The teams working on somewhat interconnected products are often independent of one another and do not coordinate on anything.
Personally, I would not make any inferences from product features at this point, and just look towards product and security announcements for guidance.
1 Like
I got caught up in believing that claim initially too, as normally the list of accepted fields within a certificate is part of the baseline requirements. e.g. which EKU values "MUST", "MAY", "MUST NOT" be included. Aka. what the CA/BF decides and publishes.
Furthermore the Chrome Root Program Policy also says this (Chrome Root Program Policy, Version 1.6):
As well as what the Chrome Root Program Policy makes it look like by the introduction:
Chrome Root Program Participants that issue TLS server authentication certificates trusted by Chrome MUST adhere to the latest version of the "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" ("Baseline Requirements"). The Baseline Requirements are consensus-driven requirements owned by a community of participants represented in the CA/Browser Forum Server Certificate Working Group. No single organization, including Google, has the authority to grant exceptions to the Baseline Requirements.
Only issue is that this has never been discussed anywhere over at the CA/BF so far. Neither on the github nor on the mailing list. I've searched through it for quite a while yesterday.
What I find interesting is however the claim that all participants must adhear to the rules of the CA/BF. Well the CA/BF says that a server certificate MAY contain clientAuth. So now these two policies are in conflict with each other. So the next part "No single organization, including Google, has the authority to grant exceptions to the Baseline Requirements" either becomes a blatant lie or (what the other participants thought happened) the CA/BF supported this policy change.
Well it appears this sentence is a lie now and Google is ignoring the CA/BF and dictating their own rules now. And considering this it is also kinda obvious why someone would arrive at the conclusion that Lets Encrypt was influenced by Google as one of it's biggest sponsors to silently take part in this coup d'etat (at least some may for sure perceive it as such) that causes all server-to-server usages across organizations to break.
Furthermore organizations like e.g. Microsoft also were pushing this usage btw, Microsoft currently still requires such certificates for mutual SMTP between on-prem and O365 as well as for AD FS and they even advice explicitly against using a private ca as this would pose a quite severe security risk. Furthermore same with Cisco for VoIP infrastructure at ISPs and enterprises. And so on, I've put a few ones into the thread over at the CA/BF. And by now I've also sent the Chrome Root Program people an email asking them to take part in the discussion and help find a way forward that works for everything and doesn't break so many things. After all we've at least 4 potential solutions so far.
GitHub Issue at the CA/BF servercert working group: Please add a requirement that CAs must issue certificates with key usages āTLS serverā and āTLS clientā, at the least, to end users Ā· Issue #599 Ā· cabforum/servercert Ā· GitHub (there are two ones, but we centralized the discussion in this one, the other one 598 is about the same issue but suggesting a different solution).
Suggested solution so far:
- CAs must always issue server certificates with serverAuth and clientAuth
- Moving towards DANE (with certificate usage set to either 2 or 3 only) for everything, and aim for decommissioning the entire trust store
- Change RFC to define clientAuth as personal and serverAuth as machine thereby allowing serverAuth to be used for TLS-Clientauth between distributed systems where either side may establish the connection first and both sides need to be authenticated using the public CA infrastructure. This also would assure the binding between an inbound connection from and an outbound connection to a specific system is preserved. This assurance would open a vector of attack when dedicated certificates for client and server auth are used in between. (Also not all existing systems support using dedicated keys).
- Remove validation of EKU entirely. After all this property may not even exist within the cert to begin with when everyone is forced to disable its validation because of the inability of getting publicly signed certificates for the servers with values reflecting their actual intended usage.
Clarification and summary of the discussed within the GitHub ticket so far:
- This is about server-to-server, NOT user-to-server authentication.
- The biggest issue is not having ANY CA (especially no free ones like LetsEncrypt) issuing clientAuth certificates for servers anymore.
- Private CAs are not an option because the systems often belong to different organizations (see also referenced security assessments in the above mentioned github thread). E.g. Microsoft Pointed it out best by: "AD FS 2.0 does not require that certificates be issued by a CA. However, the service communications certificate must be trusted by the AD FS 2.0 clients. We recommend that you not use self-signed certificates for these certificate types. Use of self-signed, SSL certificates in a production environment can allow a malicious user in an account partner organization to take control of federation servers in a resource partner organization. This security risk exists because self-signed certificates are root certificates. They must be added to the trusted root store of another federation server (for example, the resource federation server), which can leave that server vulnerable to attack."
- Domain validation of the client side is enough as the client of the connection is also a server itself and therefore it can be validated the same way as a server certificate by the server.
- Either side may initiate the connection. Therefore clientAuth and serverAuth MUST be within the same certificate to ensure the connection is between the correct endpoints (binding the channels together) and for neither the certificate was compromised and revoked.
- Most affected parties will very likely first notice this issue when they have to renew their certificates and can't get them from any CA anymore.
- The stated claims of "security" are currently not just not obvious but appear to even weaken security quite significantly for a lot of critical infrastructure and enterprise needs.
- Relying upon the browsers trust store was commonly used to work around the issues and ambiguity of distribution root CA certificates for other usages as was commonly observable ten years ago for mail servers when RFC7672 was published. With this Policy change of the Chrome Root Program and all of the CAs following by changing their issuing policy to no longer issue usable certificates exactly the same argument becomes valid once more (but not just for mail servers but for generic server-to-server connections) and therefore it should be considered to abandon the PKIX infrastructure all together this time to avoid a 3rd occurrence down the line. The PKIX infrastructure is becoming a liability basically.
- Is the plan of Chrome really to throw all of the European eIDAS issuing CAs out of the trust store when they (as I expect) refuse to comply with this policy? Especially considering them complying would directly cause breakage of a lot of critical infrastructure. QWAC certificates are currently intentionally issued with both clientAuth and serverAuth to allow it being used for both client-to-server (on the server side) and server-to-server (on both sides).
- If yes, is it acceptable to to the Chrome Root Program to have European users see a lot of "certificate invalid" webpages then? QWAC certs are often simultaneously used for the website too.
This is not in conflict: clientAuth is permitted by CA/BF rules. But there's no rule that they must be present, and many CAs already issue certificates without clientAuth.
Some CAs may wish to be validated under CA/BF rules and issue client certs. Those roots will not be included in Chrome. Chrome's root program is only for their browser which doesn't use client certs, so it doesn't matter. Chrome gets to choose what roots they include in their browser.
CAs could choose to have another root which issues clientAuth and serverAuth together. That root could still be audited under CA/BR rules, and could be included in root programs which aren't chrome. For S2S use-cases, it doesn't matter if they're included in Chrome.
Let's Encrypt has chosen to not maintain a separate hierarchy, for all the reasons previously outlined.
6 Likes
TLS client authentication is only performed by request of the server as per RFC 8446 section 4.6.2. As such mTLS does not need a certificate with both serverAuth and clientAuth EKUs.
...
The client MUST send a Certificate message if and only if the server has requested client authentication via a CertificateRequest message (Section 4.3.2).
...
Well if you're not included in the common trust store(s) then you obviously also do not have to follow the CA/BF rules to begin with...
I'm fine with the client authentication EKU bring removed from publicly trusted certs, I'm however curious how root programs decide whether to implement changes via a CABF ballot vs. unilaterally changing their root program requirements.
While this approach allows CAs to operate separate separate roots for Chrome vs. non-Chrome, I really doubt any will actually do that, so the end results are the same, just without a vote/discussion.
Maybe the Chrome root program doesn't think the discussions would change anyone's opinions, nor raise any important issues, and they want this change implemented no matter if it would/wouldn't pass a hypothetical vote?
That's just my theory, it could definitely be wrong. Anyone have any more insights?
1 Like
And where exactly does that section say that the EKU should NOT be checked? To se if it is a valid certificate? Otherwise one may send a self signed, S/MIME, or whatever certificate.
Also a lot of gov documentation says that "clientAuth" is for "TLS Client", so even if the RFC would say otherwise that'd still be an issue. (However the RFC saying otherwise would be a good reason to get that regulations and guidelines changed as well)
Thereās not a single trust store. This rule is for Chrome's, which isnāt meant to be used for S2S use cases.
3 Likes
I didn't say that the EKU shouldn't be checked, I just said that even when using mTLS, there is a server certificate and client certificate (which must be requested by the server) so a unified hierarchy isn't required.
1 Like
It is, in practice:
ā¢ there is only one root CA store for general trust
(if using private CAs this is not a problem, but that is not
possible if the communication parties donāt have a common
administration, such as with general XMPP)
ā¢ many softwares have only a configuration option for the server
to set ātheā certificate, which is then used both when initiating
TLS connections and when being called via a TLS connection
Besides, this WORKS at the moment, so please just donāt break it.
1 Like
Your position is due to a fundamental misunderstanding of the BRs. The Chrome policy is 100% compliant. They are not granting an exception to themselves or forcing others to violate any rules.
The CA/B Forum Baseline Requirements are really just a framework for minimum compliance. The Browsers/OS/Libraries and CAs constantly iterate new technologies and constraints within this framework and exceed minimum standards. The CA/B Forum Ballots are usually to adopt a new technology, sunset an older one, or tighten/relax constraints to ensure security.
Browsers often drive the change to champion security for users and improve the minimum standards. In 2019, Apple proposed Certificates be reduced to 398 days - most CAs voted against it. Apple, Google, Mozilla, Microsoft and Opera decided they would still implement it anyways. A few months later, the measure passed a CA/B Forum vote as a "browser realignment".
This type of posturing by "Browsers" is the status quo and how things change over time.
4 Likes
It's still a connection between two servers and it breaks binding of channels when there are two distinct certificates.
Also because of this policy change there isn't any publicly trusted CA issuing clientAuth certificates for dNSNames anymore all that is left is some that do to individuals but even those can't be seen as "trusted everywhere" anymore as Chrome decided to demand that they use a different CA cert so even where other trust stores are used as long as they contain the same CA certs are also affected. It takes time to propagate new CA certs to everything....
Well I see it as a violation, as a "MAY" implies the ability to have it. And that is no longer possible...
No, it simply doesn't. "May" means that the action in question is permitted (i.e., that a CA is allowed to do it), not that a CA must allow it. Your understanding is simply incorrect, as you've been told repeatedly.
5 Likes