4 ms·

Certification Authority/Browser Forum adopts new security standards

62 points by terminalbraid 2y ago

Y-bar 2y ago
How will this impact self-signed local certificates? Can we still use a five-year lifespan on those or do we need to reduce it to <398 days?
- deleted 2y ago
  [deleted]
- electroly 2y ago
  Your local certificates are not bound by the Baseline Requirements at all; they're irrelevant to you. You can do whatever you want if your CA is not in a root program.
- bawolff 2y ago
  The article doesn't even mention cert lifetimes. But the answer is no, self-signed certs dont have to folllw c/ab.
  - Y-bar 2y ago
    The links in the article mentions the hard limit on certificate lifetime.
tptacek 2y ago
Notably, I think LetsEncrypt has been MPIC for some time now.
- schoen 2y ago
  Yep, they started in 2020: https://letsencrypt.org/2020/02/19/multi-perspective-validation/ https://letsencrypt.org/2020/02/19/multi-perspective-validat... This has been challenging for some subscribers who are unaccustomed to receiving any legitimate site traffic from foreign countries. https://community.letsencrypt.org/t/multi-perspective-validation-geoblocking-faq/218158 https://community.letsencrypt.org/t/multi-perspective-valida... Now that it's a requirement for the whole web PKI, it will be interesting to see the pressure against blanket geoblocking increase. (Or maybe more web hosts will make it easier to use DNS challenge methods to get certificates.)
  - ocdtrekkie 2y ago
    Geoblocking is one of the most drastically effective ways someone can reduce their attack surface. I'd give up encrypting traffic entirely before I'd give up geoblocking.
    - tptacek 2y ago
      You don't have to give up geoblocking, right? You only need enough "unblocked" surface to resolve domain ownership challenges.
      - ocdtrekkie 2y ago
        Sure, and I think generally speaking this is also not a hard problem: A CA can advertise the networks it expects to be able to validate your control from, and you can also choose to selectively allow access for domain validation purposes to those networks. The modern firewall is quite discriminatory. I just find a constant frustration that geoblocking is often discussed as "bad" when... if you aren't running a global service, is an incredibly powerful tool. Even among global services, the hesitation to intelligently use risk-based authentication strategies remains deeply frustrating... there's no reason an account which has never been accessed outside the United States should be permitted to suddenly log in from Nigeria. Credit card companies figured this stuff out decades ago.
amiga386 2y ago
What does this mean for CAs that issue certs for completely internal corporate DNS? Does this mean the corporations have to reveal all their internal DNS and sites to the public (or at least the CA) and let them do DV, if they want certs issued for their wholly-internal domains that will be valid in normal browsers?
- gruez 2y ago
  >Does this mean the corporations have to reveal all their internal DNS and sites to the public (or at least the CA) and let them do DV, if they want certs issued for their wholly-internal domains that will be valid in normal browsers? The blog post has nothing to do with this, because it was already the case with certificate transparency. The solution is to use wildcard certificates. For instance if you don't want secretproject.evil.corp to be visible to everyone, you could get a wildcard certificate for *.evil.corp instead.
  - wolfgang42 2y ago
    There are also plenty of ways to set it up so the only thing the public can see is that the name exists; and you should probably be prepared for that to become public knowledge anyway (even if using a wildcard certificate), if only because there are so many ways for users to accidentally cause DNS leaks. Using an ACME DNS challenge would be the simplest option if it wasn’t such a pain to integrate with most DNS services; but even HTTP challenges don’t actually need to expose the same server that actually runs the service, just one that serves /.well-known/acme-challenge/* during the validation process. (For example, this could be the same server via access control rules that check what interface the request came in on, or a completely different server with split-horizon DNS and/or routing, or a special service running on port 80 that’s only used for challenges.) (I was thinking about this a lot recently because I had a service that wanted to do HTTP challenges but I didn’t want to put the whole thing on the Internet. In the end my solution was to assign an IPv6 range which is routed by VPN internally but to a proxy server for public requests: https://search.feep.dev/blog/post/2025-03-18-private-acme https://search.feep.dev/blog/post/2025-03-18-private-acme)
infogulch 2y ago
Glad to see DNS validation from multiple perspectives, that's a scary attack vector. I wonder if we can ever hope for CA/B to permit name constrained, short lifespan, automatically issued intermediate CAs, authenticated with something like a DNS-01 challenge. I've advocated for this before [1][2], but here's my pitch again: I want to issue certificates from my own ICA for my homelab and office, to avoid ratelimits and hide hostnames for private services. I submit that issuing a 90-day ICA certificate with a name constraint that only allows it to issue certificates for the specific domain is no more dangerous than issuing a wildcard certificate, and offers enough utility that it should be considered seriously. Objection 1: "Just use a wildcard cert." Wildcard certs are not sufficient here because they don't support nested wildcards, and — more importantly — they don't allow you to isolate hosts since any host can serve all subdomains. I'd rather not give some rando vibecoded nodejs app the same certificate that I use to handle auth. Objection 2: "Just install a self-signed CA on all your devices." Installing and managing self-signed CAs on every device is tedious, error prone, and arguably more dangerous than issuing a 90-day name-constrained ICA. Objection 3: "Aren't name constraints not supported by all clients?" On the contrary, they've had wide support for almost a decade, and for those just set the critical bit. I understand this is not a "just ship it lmao" kind of change, but if we want this by 2030 planning for it needs to start happening now. [1]: https://news.ycombinator.com/item?id=37537689 https://news.ycombinator.com/item?id=37537689 [2]: https://news.ycombinator.com/item?id=29808233 https://news.ycombinator.com/item?id=29808233
- mcpherrinm 2y ago
  I can’t see freely available intermediates ever happening. The first three reasons I can think of are here, but there’s more I’m sure. 1. No way to enforce what the issued end-entity certificates look like, beyond name constraints. X509 is an overly-flexible format and a lot of the ecosystem depends on a subset of them being used, which is enforced by policy on CAs. 2. Hiding private domains wouldn’t be any different than today. CT requirements are enforced by the clients, and presumably still would be. Some CAs support issuing certs without CT now, but browsers won’t accept them. 3. Allowing effectively unlimited issuance would likely overwhelm CT, and the whole ecosystem collapses.
notepad0x90 2y ago
Cheaper code-signing certs would be great. I don't like how the CA/B is so focused on TLS only. PKI is a slightly wider landscape. I sincerely hope PKI-centric code and package signing makes its way to the Linux world where most influential people in these discussions live, so they can appreciate the importance of having a "letsencrypt" for other types of PKI usage like S/MIME and Authenticode.
- dadrian 2y ago
  There is literally a code-signing working group in the CA/BF. However, the browsers don't really participate in it, since it's irrelevant to browsers. This is the entire point of moving to dedicated hierarchies per use-case---each PKI (web, code signing, etc) can evolve independently.
pabs3 2y ago
Hopefully they also adopt the ACME revocation extension proposed in the Revokinator FAQ. https://pwnedkeys.com/revokinator https://pwnedkeys.com/revokinator
- dadrian 2y ago
  ARI is outside the scope of the CABF

62 points by terminalbraid 2y ago

How will this impact self-signed local certificates? Can we still use a five-year lifespan on those or do we need to reduce it to <398 days?

deleted 2y ago
[deleted]
electroly 2y ago
Your local certificates are not bound by the Baseline Requirements at all; they're irrelevant to you. You can do whatever you want if your CA is not in a root program.
bawolff 2y ago
The article doesn't even mention cert lifetimes. But the answer is no, self-signed certs dont have to folllw c/ab.
- Y-bar 2y ago
  The links in the article mentions the hard limit on certificate lifetime.

tptacek 2y ago

Notably, I think LetsEncrypt has been MPIC for some time now.

schoen 2y ago
Yep, they started in 2020: https://letsencrypt.org/2020/02/19/multi-perspective-validation/ https://letsencrypt.org/2020/02/19/multi-perspective-validat... This has been challenging for some subscribers who are unaccustomed to receiving any legitimate site traffic from foreign countries. https://community.letsencrypt.org/t/multi-perspective-validation-geoblocking-faq/218158 https://community.letsencrypt.org/t/multi-perspective-valida... Now that it's a requirement for the whole web PKI, it will be interesting to see the pressure against blanket geoblocking increase. (Or maybe more web hosts will make it easier to use DNS challenge methods to get certificates.)
- ocdtrekkie 2y ago
  Geoblocking is one of the most drastically effective ways someone can reduce their attack surface. I'd give up encrypting traffic entirely before I'd give up geoblocking.
  - tptacek 2y ago
    You don't have to give up geoblocking, right? You only need enough "unblocked" surface to resolve domain ownership challenges.
    - ocdtrekkie 2y ago
      Sure, and I think generally speaking this is also not a hard problem: A CA can advertise the networks it expects to be able to validate your control from, and you can also choose to selectively allow access for domain validation purposes to those networks. The modern firewall is quite discriminatory. I just find a constant frustration that geoblocking is often discussed as "bad" when... if you aren't running a global service, is an incredibly powerful tool. Even among global services, the hesitation to intelligently use risk-based authentication strategies remains deeply frustrating... there's no reason an account which has never been accessed outside the United States should be permitted to suddenly log in from Nigeria. Credit card companies figured this stuff out decades ago.

amiga386 2y ago

What does this mean for CAs that issue certs for completely internal corporate DNS? Does this mean the corporations have to reveal all their internal DNS and sites to the public (or at least the CA) and let them do DV, if they want certs issued for their wholly-internal domains that will be valid in normal browsers?

gruez 2y ago
>Does this mean the corporations have to reveal all their internal DNS and sites to the public (or at least the CA) and let them do DV, if they want certs issued for their wholly-internal domains that will be valid in normal browsers? The blog post has nothing to do with this, because it was already the case with certificate transparency. The solution is to use wildcard certificates. For instance if you don't want secretproject.evil.corp to be visible to everyone, you could get a wildcard certificate for *.evil.corp instead.
- wolfgang42 2y ago
  There are also plenty of ways to set it up so the only thing the public can see is that the name exists; and you should probably be prepared for that to become public knowledge anyway (even if using a wildcard certificate), if only because there are so many ways for users to accidentally cause DNS leaks. Using an ACME DNS challenge would be the simplest option if it wasn’t such a pain to integrate with most DNS services; but even HTTP challenges don’t actually need to expose the same server that actually runs the service, just one that serves /.well-known/acme-challenge/* during the validation process. (For example, this could be the same server via access control rules that check what interface the request came in on, or a completely different server with split-horizon DNS and/or routing, or a special service running on port 80 that’s only used for challenges.) (I was thinking about this a lot recently because I had a service that wanted to do HTTP challenges but I didn’t want to put the whole thing on the Internet. In the end my solution was to assign an IPv6 range which is routed by VPN internally but to a proxy server for public requests: https://search.feep.dev/blog/post/2025-03-18-private-acme https://search.feep.dev/blog/post/2025-03-18-private-acme)

infogulch 2y ago

Glad to see DNS validation from multiple perspectives, that's a scary attack vector. I wonder if we can ever hope for CA/B to permit name constrained, short lifespan, automatically issued intermediate CAs, authenticated with something like a DNS-01 challenge. I've advocated for this before [1][2], but here's my pitch again: I want to issue certificates from my own ICA for my homelab and office, to avoid ratelimits and hide hostnames for private services. I submit that issuing a 90-day ICA certificate with a name constraint that only allows it to issue certificates for the specific domain is no more dangerous than issuing a wildcard certificate, and offers enough utility that it should be considered seriously. Objection 1: "Just use a wildcard cert." Wildcard certs are not sufficient here because they don't support nested wildcards, and — more importantly — they don't allow you to isolate hosts since any host can serve all subdomains. I'd rather not give some rando vibecoded nodejs app the same certificate that I use to handle auth. Objection 2: "Just install a self-signed CA on all your devices." Installing and managing self-signed CAs on every device is tedious, error prone, and arguably more dangerous than issuing a 90-day name-constrained ICA. Objection 3: "Aren't name constraints not supported by all clients?" On the contrary, they've had wide support for almost a decade, and for those just set the critical bit. I understand this is not a "just ship it lmao" kind of change, but if we want this by 2030 planning for it needs to start happening now. [1]: https://news.ycombinator.com/item?id=37537689 https://news.ycombinator.com/item?id=37537689 [2]: https://news.ycombinator.com/item?id=29808233 https://news.ycombinator.com/item?id=29808233

mcpherrinm 2y ago
I can’t see freely available intermediates ever happening. The first three reasons I can think of are here, but there’s more I’m sure. 1. No way to enforce what the issued end-entity certificates look like, beyond name constraints. X509 is an overly-flexible format and a lot of the ecosystem depends on a subset of them being used, which is enforced by policy on CAs. 2. Hiding private domains wouldn’t be any different than today. CT requirements are enforced by the clients, and presumably still would be. Some CAs support issuing certs without CT now, but browsers won’t accept them. 3. Allowing effectively unlimited issuance would likely overwhelm CT, and the whole ecosystem collapses.

notepad0x90 2y ago

Cheaper code-signing certs would be great. I don't like how the CA/B is so focused on TLS only. PKI is a slightly wider landscape. I sincerely hope PKI-centric code and package signing makes its way to the Linux world where most influential people in these discussions live, so they can appreciate the importance of having a "letsencrypt" for other types of PKI usage like S/MIME and Authenticode.

dadrian 2y ago
There is literally a code-signing working group in the CA/BF. However, the browsers don't really participate in it, since it's irrelevant to browsers. This is the entire point of moving to dedicated hierarchies per use-case---each PKI (web, code signing, etc) can evolve independently.

pabs3 2y ago

Hopefully they also adopt the ACME revocation extension proposed in the Revokinator FAQ. https://pwnedkeys.com/revokinator https://pwnedkeys.com/revokinator

dadrian 2y ago
ARI is outside the scope of the CABF