[HN Gopher] Certification Authority/Browser Forum adopts new sec...
___________________________________________________________________
Certification Authority/Browser Forum adopts new security standards
Author : terminalbraid
Score : 43 points
Date : 2025-03-31 09:56 UTC (2 days ago)
(HTM) web link (security.googleblog.com)
(TXT) w3m dump (security.googleblog.com)
| Y-bar wrote:
| 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?
| electroly wrote:
| 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 wrote:
| The article doesn't even mention cert lifetimes.
|
| But the answer is no, self-signed certs dont have to folllw
| c/ab.
| Y-bar wrote:
| The links in the article mentions the hard limit on
| certificate lifetime.
| tptacek wrote:
| Notably, I think LetsEncrypt has been MPIC for some time now.
| schoen wrote:
| Yep, they started in 2020:
| 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-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.)
| amiga386 wrote:
| 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 wrote:
| >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 wrote:
| 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)
___________________________________________________________________
(page generated 2025-04-02 23:01 UTC)