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.
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.
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?
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.
>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.
rickette ·19 days ago
Show replies
apitman ·19 days ago
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 ·19 days ago
Show replies
captn3m0 ·19 days ago
I am gonna try to run a DoH resolver on this and see how it goes.
Show replies
crtasm ·19 days ago