HTTPS Certificate Industry Adopts New Security Requirements (googleblog.com) 27
The Certification Authority/Browser Forum "is a cross-industry group that works together to develop minimum requirements for TLS certificates," writes Google's Security blog. And earlier this month two proposals from Google's forward-looking roadmap "became required practices in the CA/Browser Forum Baseline Requirements," improving the security and agility of TLS connections...
Multi-Perspective Issuance Corroboration
Before issuing a certificate to a website, a Certification Authority (CA) must verify the requestor legitimately controls the domain whose name will be represented in the certificate. This process is referred to as "domain control validation" and there are several well-defined methods that can be used. For example, a CA can specify a random value to be placed on a website, and then perform a check to verify the value's presence has been published by the certificate requestor.
Despite the existing domain control validation requirements defined by the CA/Browser Forum, peer-reviewed research authored by the Center for Information Technology Policy of Princeton University and others highlighted the risk of Border Gateway Protocol (BGP) attacks and prefix-hijacking resulting in fraudulently issued certificates. This risk was not merely theoretical, as it was demonstrated that attackers successfully exploited this vulnerability on numerous occasions, with just one of these attacks resulting in approximately $2 million dollars of direct losses.
The Chrome Root Program led a work team of ecosystem participants, which culminated in a CA/Browser Forum Ballot to require adoption of MPIC via Ballot SC-067. The ballot received unanimous support from organizations who participated in voting. Beginning March 15, 2025, CAs issuing publicly-trusted certificates must now rely on MPIC as part of their certificate issuance process. Some of these CAs are relying on the Open MPIC Project to ensure their implementations are robust and consistent with ecosystem expectations...
Linting
Linting refers to the automated process of analyzing X.509 certificates to detect and prevent errors, inconsistencies, and non-compliance with requirements and industry standards. Linting ensures certificates are well-formatted and include the necessary data for their intended use, such as website authentication. Linting can expose the use of weak or obsolete cryptographic algorithms and other known insecure practices, improving overall security... The ballot received unanimous support from organizations who participated in voting. Beginning March 15, 2025, CAs issuing publicly-trusted certificates must now rely on linting as part of their certificate issuance process.
Linting also improves interoperability, according to the blog post, and helps reduce the risk of non-compliance with standards that can result in certificates being "mis-issued".
And coming up, weak domain control validation methods (currently permitted by the CA/Browser Forum TLS Baseline Requirements) will be prohibited beginning July 15, 2025.
"Looking forward, we're excited to explore a reimagined Web PKI and Chrome Root Program with even stronger security assurances for the web as we navigate the transition to post-quantum cryptography."
Before issuing a certificate to a website, a Certification Authority (CA) must verify the requestor legitimately controls the domain whose name will be represented in the certificate. This process is referred to as "domain control validation" and there are several well-defined methods that can be used. For example, a CA can specify a random value to be placed on a website, and then perform a check to verify the value's presence has been published by the certificate requestor.
Despite the existing domain control validation requirements defined by the CA/Browser Forum, peer-reviewed research authored by the Center for Information Technology Policy of Princeton University and others highlighted the risk of Border Gateway Protocol (BGP) attacks and prefix-hijacking resulting in fraudulently issued certificates. This risk was not merely theoretical, as it was demonstrated that attackers successfully exploited this vulnerability on numerous occasions, with just one of these attacks resulting in approximately $2 million dollars of direct losses.
The Chrome Root Program led a work team of ecosystem participants, which culminated in a CA/Browser Forum Ballot to require adoption of MPIC via Ballot SC-067. The ballot received unanimous support from organizations who participated in voting. Beginning March 15, 2025, CAs issuing publicly-trusted certificates must now rely on MPIC as part of their certificate issuance process. Some of these CAs are relying on the Open MPIC Project to ensure their implementations are robust and consistent with ecosystem expectations...
Linting
Linting refers to the automated process of analyzing X.509 certificates to detect and prevent errors, inconsistencies, and non-compliance with requirements and industry standards. Linting ensures certificates are well-formatted and include the necessary data for their intended use, such as website authentication. Linting can expose the use of weak or obsolete cryptographic algorithms and other known insecure practices, improving overall security... The ballot received unanimous support from organizations who participated in voting. Beginning March 15, 2025, CAs issuing publicly-trusted certificates must now rely on linting as part of their certificate issuance process.
Linting also improves interoperability, according to the blog post, and helps reduce the risk of non-compliance with standards that can result in certificates being "mis-issued".
And coming up, weak domain control validation methods (currently permitted by the CA/Browser Forum TLS Baseline Requirements) will be prohibited beginning July 15, 2025.
"Looking forward, we're excited to explore a reimagined Web PKI and Chrome Root Program with even stronger security assurances for the web as we navigate the transition to post-quantum cryptography."
Oye Vey (Score:2)
Re: (Score:2)
Re: (Score:3)
>"So what fresh new hell have they cooked up for my domain certs now?"
My thought, exactly. It is already a big mess. And something tells me that these measures will somehow favor Google platforms, browsers, procedures, and power.
I am also wondering how this affects Let'sEncrypt.
Re:Oye Vey; Let'sEncrypt. (Score:1)
Re: (Score:2)
One thing that really helps with DNS challenges is ACME DNS (https://github.com/joohoi/acme-dns)
I won't say it's perfect, among other issues:
- It becomes an issue if two sites need similar certificates
- You need to run a DNS server especially for it. If you only have a limited number of IPs that can be a PITA (but see dnsdist, which proxies DNS requests. No, the obvious solution - asking BIND to forward requests - is not possible due to the weird rules that govern DNS and what's allowed to produce an "autho
Re: (Score:3)
I feel like the majority use HTTP-01 challenge because it's so easy.
Bold of you to assume the certs are going to nginx or apache servers or something else that will serve up an HTTP request like that. Now, to be fair, you may be right that 51% of them are, but the majority of the certs I implement aren't.
Many go to firewalls; Fortigate, Sonicwall, and Sophos all have HTTP frontends to their VPN services; it's not like I can just throw a text file into the server's /var/www folder. Others go to reverse proxies, that don't themselves host the file in question. I've been able
Re: (Score:2)
HTTP challenge does not work with non-publicly accessible sites though. ACME-DNS works great up to the point that sub-domains need different security measures.
Re: (Score:3)
So what fresh new hell have they cooked up for my domain certs now?
... that they will no longer issue certificates for your domain to someone else? Sounds like a good thing, on the whole!
Re: (Score:2)
So what fresh new hell have they cooked up for my domain certs now?
... that they will no longer issue certificates for your domain to someone else? Sounds like a good thing, on the whole!
The thing is, they could shut down and guarantee that with 100% certainty. Making it harder for someone else to get certs for your domain is nice until it prevents you from getting certs for your own domain. Also, it does nothing for the gaping hole that lookalike domains represent.
As far as I am concerned, TLS certificates stopped being beneficial when they stopped costing thousands of dollars. Expanding TLS to every random person who wants to run a web server destroyed their value in recognizing a site
Re: (Score:2)
It's OK, you have plenty of time to migrate all your automated DNS scripts and tools, and buy new hardware and upgrade to new operating systems if needed, and rewrite your entire stack that was assuming the status quo, as it doesn't take affect until March 15th 2025, and 2025 is next year right? Yep, definitely next year, this check I just wrote says 2024...
Re: (Score:2)
Looks straightforward enough.
For the first, nothing on the requester's end to change, they just have to probe the infrastructure from multiple, disparate places to mitigate risk that their interrogating system is screwed with.
For the second, a linting that could be an issue, but shouldn't be an issue unless you have a mistake in your CSR that you shouldn't want out there anyway.
Re:Oye Vey (Score:5, Informative)
After reviewing it, it doesn't look as if the proposal will break anything.
https://www.ssl.com/blogs/mult... [ssl.com]
Basically the proposal is that for HTTP challenges of the sort Lets Encrypt does, when the registrar is checking, it needs to check multiple times in multiple parts of the world. This minimizes the chance of someone intercepting the IP packets or redirecting them and getting a certificate under false pretenses.
Unless you're using some weird challenge script that somehow detects when the authentication token has been fetched and immediately removes it without waiting for the registrar to give the all clear, there should be no changes needed for the person trying to get the certificate.
So, for once, this is a proposal to secure SSL certificates that doesn't cause hell for sysadmins. I'm sure they're thinking of ways to torture us anyway though, probably with one hour expirations coming next...
Re: (Score:2)
More work for the certificate re-issuer due to administrative overhead will result in increased costs for certificate renewal. Also, the free certificates you get from Let's Encrypt et. al. may become rarer.
Dreary (Score:2)
Re: (Score:2)
"News for Nerds".
WTF is MPIC? (Score:3)
Let's Encrypt (Score:2)
Re: Let's Encrypt (Score:4, Insightful)
CAs themselves are the problem (Score:3)
Re: (Score:2)
I looked up DANE. It moves the goal post to DNS, and employs DNSSEC.
There is a subtle but significant difference between trusting a domain name provider pointing me a correct IP, versus trusting a domain name provider to also safeguard if the content transmitted is not intercepted. The root DNS system is a lot more centralized. Over-centralization can lead to abuses too.
Both Chrome and Firefox has gone the route of DNS-over-HTTPS for DNS security.
Re: CAs themselves are the problem (Score:3)
In an ideal world... (Score:2)
Unless you are talking a toy-scale situation of telling a handful of admin endpoints about the thumbprints of a dozen self-signe
Re: (Score:2)
We need a middle ground between "trusting" each and every self-signed certs and "trusting" a custom CA to authenticate websites arbitrarily.
Fact: we get a lot of intranet web UIs that shouldn't (need to) request public cert from authorities outside the intranet.
Not sure how to best achieve that though.
Post-quantum cryptography (Score:2)
How exactly is it relevant to this issue? Why not mention blockchain and AI, while we're at it?
Re: (Score:2)
PQC is already in your browser, part of HTTPS negotiations and they are migrating away older ciphers towards PQC ciphers all the time.
I'm literally using X25519MLKEM768 to negotiate keys to talk to this server at Slashdot right now, as well as Elliptic Curves.
The primary encryption is still an AES variant (AES_128_GCM) but there's no need for it to be so... however AES is still proving QC-safe.
It would be absolutely remiss of such an organisation to NOT consider PQC in their designs, implementations, deploy