Please see the announcement on the Let's Encrypt website
If you have any questions, feel free to ask them in this thread.
8 Likes
Around April we will enable short-lived certificates for a small set of early adopting subscribers.
How to get involved as âearly adopting subscribersâ? Does âa small setâ means limited capacity? Will you reuse the ECDSA allowlist?
1 Like
At this time, we arenât going to be taking applications, or having something like the ECDSA list. That may change later in the year once initial testing has completed.
3 Likes
Not a question. But in case anyone is looking for a compatible client, IP identifiers have been supported in Posh-ACME for quite a while and the necessary profile support is now available in the main/dev branch. Might be another few weeks until I push a release with those bits.
4 Likes
I implemented ACME profiles for bash-based ACME client dehydrated. It has built-in support for IP subjectAltName.
But the client itself was not actively maintained for more than 1 year now. No idea when and will the author pick my PR.
2 Likes
Does the client need both IP identifier support as well as profile support? Or will it be possible for a client to request an IP cert without specifying a profile (and it's just that the default profile for IP certs will be one that uses six-day validity)? The blog post says "requesting an IP address in a certificate will automatically select a short-lived certificate profile."
2 Likes
Our plan is to automatically select the short-lived profile for requests with an IP identifier and no profile selected.
4 Likes
On the flip side, what is the error condition if an IP identifier and a non-short-lived profile is specified?
3 Likes
I believe this (from here)
If the server receives a newOrder request specifying a profile that
it is not advertising, or specifying a profile which is incompatible
with the rest of the contents of the request (e.g. a "tls-server-
auth" profile alongside an identifier of type "email"), it MUST
reject the request with a problem document of type "invalidProfile"
(see Section 6.3).
5 Likes
That makes sense. Thanks. When I originally read that, I only though about it in the context of a requested profile simply not existing.
4 Likes
We have ip.arpa and ip6.arpa DNS trees for IP addresses, usually used for rDNS - is there a reason why CAA records can't be checked there? Is it just a case that nobody has thought to specify the mechanics of how that should work, or is there some more fundamental reason why that's not possible?
3 Likes
I'm sure there's been some thinking about it, and I did a little searching and found that one person published a draft at some point, but I suspect it's mainly that the work for standardizing it hasn't been done. There probably isn't a lot of demand, either. IP-address certs are pretty niche as it is, with the only main use case I know of is things like DNS over HTTPS, though I'm sure some would appreciate not needing to have a registered domain name for their temporary or internal-use systems. It's probably also hard for a lot of people to be able to use; even some forward-DNS providers don't support their users setting CAA yet.
In terms of fundamental reasons, I don't know if people delegating reverse resolution to some system would want or intend for that to also mean that they're delegating the ability to set which CAs can be used for IP-address certificates. Probably some people have given some thought to it somewhere. I don't think there's a DNS TXT authentication method yet for proving control over an IP for getting a cert either, which I think might be even more useful.
3 Likes
I hope they won't do that, because the rDNS is often not configurable by the user. For larger companies with complete access to anything related to their IP space, sure, but smaller customers or perhaps home users behind a regular ISP, not so much.
2 Likes
There's a good chance, since Caddy already has years of experience automating sub-24-hour certificates (not public ones though) in production, we may very well make the short-lived-certs profile the default. ... If not at the initial release, probably shortly thereafter.
2 Likes
CAA in rDNS is a possibility, but has some challenges with how CAA "tree climbing" works, especially for IPv6. There was an IETF LAMPS draft a while ago using that idea, and it's possible that design work could continue.
As we approach launch, we'll have some more discussions in venues like the IETF and cabforum about CAA records.
But as of now, there's no standard to follow.
3 Likes
discussion of why dns-01 option was removed from acme-ip when writing that rfc :[Acme] acme-ip reverse-dns discussion
The argument for removing this was that there are no technical issues with the method as-is but that the reverse DNS zones are historically badly managed and that using them for validation will cause problems down the line (presumably misissuance by a person who controls the zone but doesnât actually control the IPs the zone represents). The argument for keeping it is that the IETF (or more specifically the ACME WG) should not be where CA or browser policy is dictated and that given these methods are currently allowed under the CABF BRs and browser root programs it would actually be useful to have a technically defined method for validation that can at least be used as a tool for further research on the topic.
it looks like RDNS was so poorly managed at that time. not sure rDNS mapping get better after 2018 though
original opposition happened inside IETF meeting, so I have no idea who it was, but old CAA draft was past employee of LE: @roland
2 Likes
Dang, just had a proper look at profiles implementation and see that the [directory] json is using dynamic keys instead of a key value pair or similar, this means that de-serializing the output from JSON needs dynamic keys as well (i.e. can't be mapped to an object or pre-defined structure), which wasn't previously required for ACME. [This is not a significant problem, just an observation]
3 Likes
In theory, the keys should be stable. New ones could be added, but it should be rare for a CA to remove keys.
In Go, deserializing this is just a map[string]string -- about as simple as it gets. You could map it to a struct:
type Profiles struct {
Classic string `json:"classic"`
TLSServer string `json:"tlsserver"`
}
I guess you are in .NET-land, IIRC, so it's probably very different over there. I dunno. Seems fine to me?
3 Likes
Can we expect Pebble to offer basic support for IP Addresses in the near future?
Edit: I forgot Pebble already has Profiles.
4 Likes