[HN Gopher] Six day and IP address certificate options in 2025
___________________________________________________________________
Six day and IP address certificate options in 2025
Author : SGran
Score : 139 points
Date : 2025-01-16 15:36 UTC (7 hours ago)
(HTM) web link (letsencrypt.org)
(TXT) w3m dump (letsencrypt.org)
| likeabatterycar wrote:
| > Our six-day certificates will not include OCSP or CRL URLs.
|
| If someone else did this, Mozilla would be threatening to remove
| them from their trusted roots.
|
| IP address certs sound like a security nightmare that could be
| subverted by BGP hijacking. Which is why most CAs don't issue
| them. Does accessing the ACME challenge from multiple endpoints
| adequately prevent this type of attack?
| dextercd wrote:
| Not true. CA's are explicitly allowed to omit CRL support for
| certificates with a lifetime <= 10 days.
| throw0101c wrote:
| > _SS1.6.1 Definitions_
|
| > _Short-lived Subscriber Certificate: For Certificates
| issued on or after 15 March 2024 and prior to 15 March 2026,
| a Subscriber Certificate with a Validity Period less than or
| equal to 10 days (864,000 seconds). For Certificates issued
| on or after 15 March 2026, a Subscriber Certificate with a
| Validity Period less than or equal to 7 days (604,800
| seconds)._
|
| [...]
|
| > _SS7.1.2.11.2 CRL Distribution Points_
|
| > _The CRL Distribution Points extension MUST be present in:
| Subordinate CA Certificates; and Subscriber Certificates that
| 1) do not qualify as "Short-lived Subscriber Certificates"
| and 2) do not include an Authority Information Access
| extension with an id-ad-ocspaccessMethod._
|
| * https://cabforum.org/working-groups/server/baseline-
| requirem...
|
| OCSP does not seem to be mandated in the latest Base
| Requirements.
| samcat116 wrote:
| I wonder if they could mandate that IP address certs could only
| be issued for IPs owned by an AS that has RPKI enabled.
| EQYV wrote:
| Last I read, RPKI data gets stripped if it passes through an
| AS that doesn't support it.. Has that changed?
| NewJazz wrote:
| Uh, not that I know of. You typically run your own
| validator and configure your router to use it if you care.
| crote wrote:
| > IP address certs sound like a security nightmare that could
| be subverted by BGP hijacking.
|
| The attack scenario is exactly the same as hostname
| certificates, which are often validated by HTTP or TLS ACME
| challenges.
|
| > Does accessing the ACME challenge from multiple endpoints
| adequately prevent this type of attack?
|
| Yes. You'd essentially have to MitM _all_ traffic towards the
| IP for it to work, and with more and more networks rolling out
| BGP origin validation a global BGP hijack becomes harder and
| harder to pull off.
|
| You'd still be in trouble if you expect your own ISP to be
| hostile, of course. Don't single-home with an ISP you don't
| trust, or stick with domain name certs and force DNS
| challenges.
| hedora wrote:
| Given this weakness in ACME, I don't understand why cloud
| providers don't provide transparent 443 proxying by default.
| I guess it's security theater.
| dextercd wrote:
| I'm very interested in trying this. acme.sh is planning to
| support certificate profiles, so hopefully that'll be ready when
| LE's short-lived certificates become available.
|
| (Or I'll switch to a different ACME client I suppose)
| mholt wrote:
| Caddy/CertMagic/ACMEz already support this in the latest
| commits. Should be ready in time for the production rollout!
| blakesterz wrote:
| I don't disagree with anything they say here:
|
| https://letsencrypt.org/2025/01/16/6-day-and-ip-certs/#short...
|
| But... How often do these types of compromises happen? I can't
| say I've ever seen or heard of it happening.
| H8crilA wrote:
| Impossible to say, as most people probably don't even know that
| their private key is stolen. I've personally seen it only once
| on a real certificate revocation. Yet another reason to have
| shorter lifespan.
| Spivak wrote:
| It's a pretty narrow threat model for Alice to get her cert
| stolen by Bob, be completely unaware that this has happened,
| and the means Bob used only works once.
| yjftsjthsd-h wrote:
| If they don't know they were breached, don't the odds favor
| the replaced key likewise getting re-stolen immediately?
| H8crilA wrote:
| Yes, but the odds are less than infinite, i.e. the
| probability is less than 1.0. At least some of such attacks
| take effort.
| ikiris wrote:
| Often enough a protocol was made to deal with it. The
| compromises have mostly been kept quiet though or at least
| didn't get much news traction.
| mholt wrote:
| That's the thing. We don't always know. Hence the need to
| reduce the attack lifetime.
| toast0 wrote:
| I had to get certificates revoked for HeartBleed. :P
| captn3m0 wrote:
| I remember being surprised when Cloudflare launched
| https://1.1.1.1 with a valid cert and I immediately wanted one,
| but couldn't find an easy way to get one.
|
| I am gonna try to run a DoH resolver on this and see how it goes.
| yegle wrote:
| For others who don't know how certificate for IP addresses
| relates to a DNS-over-HTTPS server:
| https://blog.cloudflare.com/announcing-ddr-support/
| prdonahue wrote:
| This was a fun conversation.
|
| I remember calling Clint and Jeremy at DigiCert and asking:
| "hey we have this cool IP address--what are the odds you guys
| can issue a certificate for it?"
|
| I'm not sure if they had to dust off some code or process to do
| it, but they got it done really quickly once the demonstration
| of control was handled.
| DonHopkins wrote:
| The coolest easiest to remember ip address I ever used was
| mimsy.cs.umd.edu: 128.8.128.8
| crtasm wrote:
| >We expect to issue the first valid short-lived certificates to
| ourselves in February of this year. Around April we will enable
| short-lived certificates for a small set of early adopting
| subscribers. We hope to make short-lived certificates generally
| available by the end of 2025.
| throw0101c wrote:
| Note that ACME profiles are new, to the extent that the draft
| spec is (a) personal (and not prefixed with _draft-ietf..._ ),
| and (b) currently versioned _-00_ :
|
| * https://datatracker.ietf.org/doc/draft-aaron-acme-profiles/
|
| The ACME spec is:
|
| * https://datatracker.ietf.org/doc/html/rfc8555
| mholt wrote:
| Yeah... thankfully, it's "pretty simple" for clients to
| implement. Just add a JSON field to your payload and that's it.
| (There's a little bit of error checking logic and input
| validation, like making sure the value is valid, but overall
| it's not too complex, unlike ARI, which is much more work.)
| mmastrac wrote:
| Will this work for IPv6?
| ZiiS wrote:
| Yes, a forward looking org like Let's Encrypt would have said
| IPv4 if needed. Here is an example from Cloudflare
| https://[2606:4700:4700::1111]
| wil421 wrote:
| Why does the url say one.one.one.one in my browser?
| mparlane wrote:
| Because it returns a 301 moved permanently with a header of
| location: https://one.one.one.one/
| Crosseye_Jack wrote:
| Because your are redirected to one.one.one.one via the
| location header and 301 status code from the ip address.
|
| http://1.1.1.1 redirects to https://1.1.1.1 which then
| redirects to https://one.one.one.one
|
| but the TLS cert on https://1.1.1.1 (or
| https://[2606:4700:4700::1111] on ipv6) is still valid for
| the ipaddress otherwise your browser would put up a warning
| during the tls handshake.
| ape4 wrote:
| Its too bad it does the last redirect.
| rickette wrote:
| Kinda funny to call the current 90 day certs "long lived". When
| Let's Encrypted started out more than 10 years ago most certs
| from major vendors had a 1 year life span. Let's Encrypt was (one
| of) the first to use drastically shorter life spans, hence all
| the ACME automation effort.
| ryandrake wrote:
| To someone like me with hobby-level serving needs, the 90 day
| certificate life is pretty inconvenient, despite having
| automation set up. I run a tiny VPS that hosts basic household
| stuff like e-mail and a few tiny web sites for people, and
| letsencrypt/certbot automation around certificate renewal is
| the only thing that I seem to need to regularly babysit and log
| in to manually run/fix. Everything else just hums along, but I
| know it's been 90 days because I suddenly can't connect to my
| E-mail or one of the web virtual hosts went down again. And
| sure enough, I just need to run certbot renew manually or
| restart lighttpd or whatever.
| rfoo wrote:
| ... which means automation was not setup correctly and 90
| days is still too long that you just tolerated it. If it was
| 6 days after a few turns you would have decided "fuck it I'm
| going to spend time fixing it once and for all".
| jonas21 wrote:
| Or perhaps, "I'm going to give up and switch to gmail once
| and for all"
| dingnuts wrote:
| there are other email providers, you know. the choices
| are not "do it all myself" and "be Google's product."
| likeabatterycar wrote:
| These are the attitudes we get when we have a WebPKI cabal
| drunk on power.
| Dries007 wrote:
| For me it's only ever an issue if I stop renewing a domain,
| which triggers issues somewhere next renewal and now nginx
| doesn't reload.
|
| Other than that, I've never had to babysit certbot. It's just
| a systemd timer job.
| jeroenhd wrote:
| Let's Encrypt doesn't work great when the Let's Encrypt
| client software has a bug or is misconfigured (one of those
| is true for your situation).
|
| I think keeping the validity long just removes incentives for
| people to bother fixing their setups. We've seen the shift
| from "Craig needs to spend a few days on certificate renewal
| every year" to full automation in most environments when the
| 90 day validity period was introduced, and shortening it to a
| week will only help further automation.
|
| You'll always have the option to skip the hassle (for a small
| fee, unless a Let's Encrypt competitor joins the market), but
| I feel the benefits outweigh the downsides.
|
| I personally would've preferred something like DANE working,
| but because the best we've got is DNSSEC and most of the
| internet doesn't even bother implementing that, I doubt we'll
| ever see that replace the current CA system.
| eikenberry wrote:
| I also use Certbot (v2.1.0) for my small VPS/hobby setup (www
| + email) and I haven't had to mess with it since I set it up
| in 2021. Just adding another data point so you know it
| doesn't have to be painful. I'll be happy to help, just drop
| me a line.
| Rodeoclash wrote:
| Is it possible for you to run Caddy as a reverse proxy in
| front of your services? I've done this in the past and it
| really is set and forget when it's configured correctly.
| ghxst wrote:
| Heard positive things about Caddy before, do you know if it
| works with ip adresses as well?
| outworlder wrote:
| > To someone like me with hobby-level serving needs, the 90
| day certificate life is pretty inconvenient
|
| I's only inconvenient because it isn't properly automated.
| That's by design.
|
| When this can be a acme.sh script cronjob, there isn't much
| of an excuse. Even my Raspberry Pi dedicated to my 3D printer
| is happily renewing certificates.
|
| At least with this thing breaking every 90 days you have it
| fresh on your mind. One year away you may not even remember
| what you have to do.
|
| Needless to say, you have a bug to fix.
| MaKey wrote:
| > [...] despite having automation set up.
|
| Clearly it's not working correctly, so a longer certificate
| lifetime wouldn't address the root cause - you would just
| have to fix your setup less often.
| tasuki wrote:
| > To someone like me with hobby-level serving needs, the 90
| day certificate life is pretty inconvenient, despite having
| automation set up.
|
| I also have hobby-level serving needs. I've been using
| LetsEncrypt since whenever it was they started. I have two
| top level domains and a whole lot of subdomains.
|
| I've never had to babysit certificate renewal, nor had to log
| in manually to fix anything. Not once. How comes?
| telotortium wrote:
| [delayed]
| duskwuff wrote:
| When Let's Encrypt got started in 2014, CAs could issue
| certificates valid for up to _five years_ - and many did. The
| CA /Browser Forum has slowly been ratcheting that down.
| Eikon wrote:
| This will get interesting for many CT transparency monitors which
| for many are already seeing scalability issues.
|
| I am operating https://www.merklemap.com/ and the current scale
| is already impressive.
| sebmellen wrote:
| What a cool site. For a long time I've been looking for
| something exactly like this for discovery purposes.
| Eikon wrote:
| Thank you!
| mholt wrote:
| I don't know much about CT requirements, but can't they prune
| data out of their logs after some time? Since the certs only
| last 6 days, the growth of the logs can be capped at some point
| right? If not now, provisions for such operations could surely
| be implemented, I imagine.
|
| PS. Neat site!
| Eikon wrote:
| > I don't know much about CT requirements, but can't they
| prune data out of their logs after some time? Since the certs
| only last 6 days, the growth of the logs can be capped at
| some point right?
|
| That's what happens - logs are "expired" after a few years.
| But if you want to have an exhaustive monitor, you probably
| don't want to discard the records of expired certificates.
|
| > PS. Neat site!
|
| Thank you!
| o11c wrote:
| Hmm, I wonder if it's possible to do dedicated intermediate
| certificates that promise to only sign short-lived certificates
| for a single site? That way the CT-log could be taught to only
| keep the intermediate?
| jabart wrote:
| Six days? I can't even set the cron job to weekly. Maybe that is
| the point of this though from being on call I really hate thing
| restarting every day. Caddy, Nginx, HAProxy, and IIS all seem to
| handle certs without a full restart. MS SQL Server, nope.
| mholt wrote:
| AFAIK, Caddy is the only integrated ACME client that is tuned
| for short-lived certificates. All its own self-signed certs are
| already 24-hour certificates, so 6-day certs will be no
| problem.
| yjftsjthsd-h wrote:
| Why would that matter? Replacing the cert and sighup'ing
| nginx or whatever isn't functionally different from doing it
| in-process.
| mholt wrote:
| Oh, my, yes it is :) (I don't have time to elaborate on
| this again right now, unfortunately.)
| jabart wrote:
| You have a link to a previous discussion on this? I'm
| curious if there is some hidden thing occurring or if
| just connection resets are happening or something else
| you are aware of.
| apitman wrote:
| As someone who has rolled my own cert updates and used
| Caddy, I much prefer the Caddy way.
| yjftsjthsd-h wrote:
| I'm happy to agree that caddy is easier, but the claim
| here is that it's "tuned for short-lived certificates",
| which... I guess could be true, but I seriously doubt
| that it's meaningful (on the basis that reloading certs
| isn't exactly expensive on any other major web server, so
| even if the most obvious interpretation is true and the
| made it take, say, 100 ms instead of 1000 ms, but we're
| talking about reloading every few days, who cares?).
| everfrustrated wrote:
| It feels like there's something of an attack vector here with
| cloud providers who lease IPs for hours at a time.
|
| 1. Lease IP
|
| 2. Obtain cert (verify can receive traffic to IP on port 80)
|
| 3. Give IP back
|
| 4. Cloud provider gives IP to another customer
|
| 5. Bgp attack IP with 6 days.
|
| While I support the idea of IP certs I do wonder how thought
| through this is and what the future consequences for security
| are.
|
| I agree with another commenter here who said this should be
| limited to IPs behind RPKI.
|
| Possibly also needs a mechanism for IP owners to clamp the cert
| time to be below their IP re-lease policy. As an example a
| provider like AWS could require max certs of (say) 6 hours and
| ensure any returned IPs stay unleased for 6 hours before
| reissuing them)
| Retr0id wrote:
| You can do the same BGP attacks with regular domain certs,
| though. If you hijack the IP that a domain resolves to, you can
| answer HTTP-01 challenges.
| toast0 wrote:
| If you control the IP or domain via a BGP hack, you can get a
| certificate issued while you control it, as long as you control
| it from the perspective of their CA.
|
| You've got to be pretty lucky, or do a lot of IP cycling for
| your vector to be terribly useful. A paranoid user of IP certs
| would let their new public facing assignments settle for a week
| before using them; but I suspect few people will start using IP
| address certs, because of usability.
| athrowaway3z wrote:
| I wouldn't write off the use of IP certs just yet.
|
| AFAIK IP address certs would provide a way to create a secure
| browsing context in your browser, which is required for
| service worker ('offline' background threads) and some File
| API, which could open up a new class of programs that host
| for friends and family.
| phasmantistes wrote:
| This is exactly why the LE IP certs will be limited to 6 days:
| this exact attack is possible today against any IP address
| cert, and such certs in general are allowed to have lifetimes
| up to 398 days. LE isn't comfortable with that situation, so IP
| certs will have the shortest feasible lifetimes.
| Retr0id wrote:
| If I wanted to get a cert for an IP address _today_ , what the
| cheapest CA?
| mholt wrote:
| ZeroSSL I think will get you IP certificates with their
| cheapest plan. (Disclaimer: I work on Caddy, which is a ZeroSSL
| project; but I do so independently.)
| Retr0id wrote:
| "cheapest" being the free plan, or the cheapest non-free
| plan?
| DonHopkins wrote:
| Careful, sometimes free plans are more expensive than
| money! ;)
| apitman wrote:
| IP certs improve a niche but interesting use case for me. I run a
| domain registrar that implements a simple OAuth2 protocol[0] for
| delegating domains/subdomains. I also have an open source
| tunneling tool called boringproxy that implements the client side
| of this protocol[1].
|
| boringproxy needs to provide a callback redirect_uri to the oauth
| server in order to retrieve it's token, which it can then use for
| setting DNS records. However, it can't provide an HTTPS endpoint
| until it can set up those DNS records and get a cert.
| Chicken/egg. Currently the spec requires the server to implement
| a `GET /temp-domain` endpoint which creates a DNS record like
| 157-245-231-242.example.com which points at the client's IP. This
| lets boringproxy bootstrap a secure OAuth2 callback endpoint.
|
| IP certs would remove an entire step from this process.
|
| [0]: https://github.com/takingnames/namedrop-protocol-spec
|
| [1]: This is actually broken in boringproxy at the moment, but
| there's a demo video here:
| https://www.youtube.com/watch?v=9hf72-fYTts
| ray_v wrote:
| This feels like a disaster waiting to happen -- like what happens
| if (when?) Let's Encrypt suffers a significant outage and sites
| can't refresh certificates? Do we just tolerate a significant
| portion of the Internet being down or broken due to expired
| certificates? And for what tradeoff? A very small amount of extra
| security? Is this because certificate revocation is a harder
| problem to solve / implement at Internet scale?
| arianvanp wrote:
| A 7 day outage seems rather unlikely no?
| pilif wrote:
| In average half of the certs would expire in half of the
| time. A 3.5 days sustained DDoS attack would cause half of
| the sites using a 6 day certificate to be offline.
| zzyzxd wrote:
| I am not saying 6 days is long enough, but if your
| automation always wait until the last minute to renew
| certs, you may have more issues to worry about than the
| CA's availability. If I am going to use a cert with 6 days
| lifetime I will be renewing it at least once a day.
| ncruces wrote:
| Yeah, that conflicts with their rate limits, which I hope
| they'll revise under this scheme.
|
| https://letsencrypt.org/docs/rate-limits/
|
| For the "exact same set of hostnames" (aka. renewals) the
| rate limit is 5 certificates every 7 days.
|
| So you could do it every _other_ day, _if_ you can make
| sure there 's only one client doing it.
|
| And they're very clear this is a global limit: creating
| multiple accounts doesn't subvert it.
|
| So you'll _need_ to manage this centrally, if you have
| multiple hosts sharing a hostname.
| mholt wrote:
| Fortunately, most ACME clients, including my own, support other
| CAs as fallbacks. (Caddy's ACME stack falls back to ZeroSSL by
| default, automatically.)
|
| That, and extended week-long outages are extremely unlikely.
| deathanatos wrote:
| > _That, and extended week-long outages are extremely
| unlikely._
|
| You only need the outage to last for the window of [begin
| renewal attempts, expiration], not the entire 6d lifetime.
|
| For example, with the 90d certs, I think cert-manager
| defaults to renewal at 30d out. Let's assume the same grace,
| of ~33% of the total life, for the 6d certs: that means renew
| at 2d out. So if an outage persisted for 2d, those certs
| would be at risk of expiring.
| mholt wrote:
| True, but it doesn't matter since competent clients should
| be falling back to other CAs anyway.
| zie wrote:
| Meanwhile Qualsys has a "vulnerability scanner" that says a
| certificate that expires in under a month is a level 1
| vulnerability(ID #38174):
| https://docs.qualys.com/en/certview/latest/get_started/certv...
| TacticalCoder wrote:
| Curiosity killed the cat: is it possible to get a valid cert for
| IPs on private LANs, like for example 192.168.1.42 or 10.0.0.84?
| outworlder wrote:
| Generally I just get DNS names for those.
|
| It does 'leak' your internal host addresses but that shouldn't
| be an issue.
| remram wrote:
| What are reasons to use a certificate for an IP? Why wouldn't you
| use a name?
|
| Someone already mentioned that it's needed for Discovery of
| Designated Resolvers (DDR) for DNS-over-HTTPS. Anything else?
___________________________________________________________________
(page generated 2025-01-16 23:00 UTC)