It works, but as another comment mentioned there may be quirks with IP certs, specifically IPv6, that I hope will be fixed by v2.11.

IPv4 certs are already working fine for me in Caddy, but I think there's some kinks to work out with IPv6.

> 6 days means on a long enough enough timeframe the load will end up evenly distributed across a week.

people will put */5 in cron and result will be same, because that's obvious, easy and nice number.

I thought people generally run it daily? It’s a no-op if it doesn’t need renewal.

so now people that want humans around will now renew twice in a week instead of once?

Mr Ramanujan, I presume?

I don't think He worked after the 6th day. Went on doing other pet projects

² By the seventh day God had finished the work He had been doing; so on the seventh day He rested from all His work. ³ Then the on-call tech, Lucifer, the Son of Dawn, was awoken at midnight because God did not renew the heavens' and the earths' HTTPS certificate. ⁴ Thusly Lucifer drafted his resignation in a great fury.

I chose 160 hours.

The CA/B Forum defines a "short-lived" certificate as 7 days, which has some reduced requirements on revocation that we want. That time, in turn, was chosen based on previous requirements on OCSP responses.

We chose a value that's under the maximum, which we do in general, to make sure we have some wiggle room. https://bugzilla.mozilla.org/show_bug.cgi?id=1715455 is one example of why.

Those are based on a rough idea that responding to any incident (outage, etc) might take a day or two, so (assuming renewal of certificate or OCSP response midway through lifetime) you need at least 2 days for incident response + another day to resign everything, so your lifetime needs to be at least 6 days, and then the requirement is rounded up to another day (to allow the wiggle, as previously mentioned).

Plus, in general, we don't want to align to things like days or weeks or months, or else you can get "resonant frequency" type problems.

We've always struggled with people doing things like renewing on a cronjob at midnight on the 1st monday of the month, which leads to huge traffic surges. I spend more time than I'd like convincing people to update their cronjobs to run at a randomized time.

It's less than 7 exactly so you cannot set it on a weekly rotation

For example HTTP/2 and HTTP/3 require HTTPS. While technically HTTPS is redundant, .onion sites should avoid requiring browsers to add special casing for them due to their low popularity compared to regular web sites.

Yes, but browsers moan if you connect to a website without https, no matter if it's on localhost or an onion service.

It would give you a certificate chain which may authenticate the onion service as being operated as who it purports to. Of course, depending on context, a certificate that is useful for that purpose might itself be too much if an information leak

cert-manager maintainter chiming in to say that yes, cert-manager should support IP address certs - if anyone finds any bugs, we'd love to hear from you!

We also support ACME profiles (required for short lived certs) as of v1.18 which is our oldest currently supported[1] version.

We've got some basic docs[2] available. Profiles are set on a per-issuer basis, so it's easy to have two separate ACME issuers, one issuing longer lived certs and one issuing shorter, allowing for a gradual migration to shorter certs.

[1]: https://cert-manager.io/docs/releases/ [2]: https://cert-manager.io/docs/configuration/acme/#acme-certif...

Which wider world?

These changes are coming from the CAB forum, which includes basically every entity that ships a popular web browser and every entity that ships certificates trusted in those browsers.

There are use cases for certificates that exist outside of that umbrella, but they are by definition niche.

Well they offer a money-back guarantee. And other providers of SSL certificates exist.

At some point it makes sense to just let us use self signed certs. Nobody believes SSL is providing attestation anyways.

Rule by the few, us little people don't matter.

Thing is, NOTHING, is stopping anyone from already getting short lived certs and being 'proactive' and rotating through. What it is saying is, well, we own the process so we'll make Chrome not play ball with your site anymore unless you do as we say...

The CA system has cracks, that short lived certs don't fix, so meanwhile we'll make everyone as uncomfortable as possible while we rearrange deck chairs.

awaiting downvotes in earnest.

It's really security theater, too.

Though if I may put on my tinfoil hat for a moment, I wonder if current algorithms for certificate signing have been broken by some government agency or hacker group and now they're able to generate valid certificates.

But I guess if that were true, then shorter cert lives wouldn't save you.

Ok, though if you're in that situation, is an IP cert the correct solution?

Some ACME clients can failover to another provider automatically if the primary one doesn't work, so you wouldn't necessarily need manual intervention on short notice as long as you have the foresight to set up a secondary provider.

This is a two-sided solution, and one significant reason for shorter certificate lifetimes helps make revocation work better.

People have tried. Revocation is a very hard problem to solve on this scale.

There will be no certificates longer than 45 days by any CA in browsers in a few years.

He's expressly talking about broken automation.

You're not thinking creatively enough. I'm only interested in ESP, not IKE. Consider having the TLS handshake negotiate the use of ESP, and when selected the system would plumb ESP for this connection using keys negotiated by TLS (using the exporter). Think ktls/kssl but with ESP. Presto -- no orchestration of IKE credentials, nothing -- it should just work.

The real key is getting ESP HW offload.

But the very nice thing about ESP (over UDP or not) is that it's much simpler to build HW offload than for TLS.

Using the long ago past as FUD here is not useful.

I use a fairly niche provider (https://go-acme.github.io/lego/dns/zonomi/index.html) and it's supported - I'd go further and say they support most providers

Exactly -- how many 192.168.0.1 certs do you think LetsEncrypt wants to issue?

Also I don't see the point of what TLS is supposed to solve here? If you and I (and everyone else) can legitimately get a certificate for 10.0.0.1, then what are you proving exactly over using a self-signed cert?

There would be no way of determining that I can connecting to my-organisation's 10.0.0.1 and not bad-org's 10.0.0.1.

For ipv6 proof of ownership can easily be done with an outbound connection instead. And would work great for provisioning certs for internal only services.

> run a CA

> easier than remembering IP addresses

idk, the 192.168.0 part has been around since forever. The rest is just a matter of .12 for my laptop, .13 for the one behind the telly, .14 for the pi, etc.

Every time I try to "run a CA", I start splitting hairs.

There’s also the DNS-01 challenge that works well for devices on private networks.

That doesn't work, as neither SNI nor the server_name field of the ECHConfig are allowed to contain IP addresses: https://www.ietf.org/archive/id/draft-ietf-tls-esni-25.html#...

Even if it did work, the privacy value of hiding the SNI is pretty minimal for an IP address that hosts only a couple domains, as there are plenty of databases that let you look up an IP address to determine what domain names point there - e.g. https://bgp.tools/prefix/18.220.0.0/14#dns

I don't really see the value in ECH for self-hosted sites regardless. It works for Cloudflare and similar because they have millions of unrelated domains behind their IP addresses, so connecting to their IPs reveals essentially nothing, but if your IP is only used for a handful of related things then it's pretty obvious what's going on even if the SNI is obscured.

As far as I understand you cannot use IP address as the outer certificate as per https://www.ietf.org/archive/id/draft-ietf-tls-esni-25.txt

> In verifying the client-facing server certificate, the client MUST interpret the public name as a DNS-based reference identity [RFC6125]. Clients that incorporate DNS names and IP addresses into the same syntax (e.g. Section 7.4 of [RFC3986] and [WHATWG-IPV4]) MUST reject names that would be interpreted as IPv4 addresses.

Thanks! This is helpful to read.

> No dependency on a registrar sounds nice.

Actually the main benefit is no dependency on DNS (booth direct and root).

IP is a simple primitive, i.e. "is it routable or not ?".

IP addresses also are assigned by registrars (ARIN in the US and Canada, for instance).

I don't quite understand how this relates?

Very very true, never thought about orgs like that. However, I don't think someone should use this like a bandaid like that. If the idea is that you want to have a domain associated with a service, then organizationally you probably need to have systems in place to make that easier.

I get why Chrome doesn't want it (it doesn't serve Chrome's interests), but that doesn't explain why Let's Encrypt had to remove it. The reason seems to be "you can't be a Chrome CA and not do exactly what Chrome wants, which is... only things Chrome wants to do". In other words, CAs have been entirely captured by Chrome. They're Chrome Authorities.

Am I the only person that thinks this is insane? All web security is now at the whims of Google?

To save others a trip to Kagi: DoT / DoH = DNS over TLS [1] / https [2]

E.g.:

[1] https://developers.cloudflare.com/1.1.1.1/encryption/dns-ove...

[2] https://developers.cloudflare.com/1.1.1.1/encryption/dns-ove...

IP addresses arent valid for the SNI used with ECH, even with TLS. On paper I do agree though it would be a decent option should things one day change there.

Oh nice! I hadn't considered DoT/DoH. The ECH angle is interesting. Thanks.

Finally a reason to adopt IPv6 for your local development

Sorry, I wasn’t precise enough. I’m at a university and our IP addresses are publicly routable, I think.

A lot of publicly routable IP addresses are assigned by DHCP...

It's just control isn't it, not ownership? I can't prove ownership of the IPs assigned to me, but I can prove control.

it's nice to be able to use https locally if you're doing things with HTTP/2 specifically.

One can also use the DNS-01 challenge in that scenario.

Very nice, thank you guys!

Thank you, I missed the part with several "top of the chain" providers. So all of them would need to go down at the same time for things to really stop working.

How many "top of chain" providers is letsencrypt using? Are they a single point of failure in that regard?

I'd imagine that other "top of chain" providers want money for their certificates and that they might have a manual process which is slower than letsencrypt?

Then it would be a grave error to issue an IP cert without active insight into BGP. (Or it doesn't matter which chain you have.. But calling a website from a sampling of locations can't be a more correct answer.)

They can just do id verification instead of domain, either in-house or outsource it.

app store review isn't what I was talking about, I meant not having to verify your identity with the appstore, and use your own signing cert which can be used between platforms. Moreover, it would be less costly to develop signed windows apps. It costs several hundred dollars today.

I see no problem with outsourcing id verification to a trusted partner. Or they could verify payment by charging you $1 to verify you control the payment card, and combine that with address verification by paper-mailing a verification code.