Does Let's Encrypt support IP certificates?

Feature Requests
1

Does Let's Encrypt support IP certificates?

2

Please see

5 Likes
3

Our initial implementation of IP certs is nearly ready to begin testing, and will be available in staging soon! It’ll still be a while for prod as there are still a bunch of “production quality” things we need to do still

8 Likes
4

Has LE coalesced yet on a term that encompass both Hostnames and IP Addresses when used in x509 Certificates?

4 Likes
5

Not yet. But "hosts", "SANs", and "names" (since they're encoded as asn.1 GeneralNames) are all candidates.

5 Likes
6

Thanks for the quick reply!

This has been annoying me for a few days, as I try to figure out how to support IP Addresses into existing data modeling. In other contexts, "endpoint" and "server" are often used - but that doesn't work here. I've just been using "address" for now, but am not particularly happy with it ("address" seems biased to IPs, "hosts" seems biased to hostname; I worry about the name implying one of the two possible contexts).

4 Likes
7

Maybe, but I see a "host" as some device on the internet. Reachable using either a FQDN/hostname or IP address. Not sure if my "definition" would be the proper word for the contents of a X.509 SAN entry though.

3 Likes
8

@Osiris I agree with what you're saying, but when dealing with terms I try to focus on clarity and avoid any potential misunderstandings.

All-

After going through a bunch of regexes on different IPV6 notations, does anyone know if there is any guidance yet on the various ipv6 formats that will be supported in ACME? rfc8738 is silent on this. i couldn't find anything in pebble or boulder source, aside from a few relevant test cases and leveraging the net-ip module.

  • will compressed :: sections be allowed, or must they be expanded? (some tests use these, so assuming yes)
  • will IPv4-translated addresses be allowed? e.g ::ffff:255.255.255.255
  • IPv4-Embedded IPv6 Addresses, like 2001:db8:3:4::192.0.2.33 64:ff9b::192.0.2.3
  • any other edge cases to be wary of?
6 Likes
9

RFC 8738 section 3 says "The value field of the identifier MUST contain the textual form of the address as defined in Section 2.1 of RFC1123 for IPv4 and in Section 4 of RFC5952 for IPv6"

Section 4 of RFC 5952 says that "all implementations MUST accept and be able to handle any legitimate RFC4291 format".

And RFC 4291 seems to allow any of those formats.

So I think an ACME server that purports to comply with RFC 8738 would need to understand what 2001:db8:3:4::192.0.2.33 means, though I suppose it might refuse to issue for it for any number of reasons. And maybe even refuse to issue for it, even though it would otherwise be okay with issuing 2001:0db8:0003:0004:0000:0000:c000:0221. Hmm… :thinking:

5 Likes
10

though I suppose it might refuse to issue for it for any number of reasons.

Yeah, thats why I asked. The instant RFC itself is silent on these things, aside from pointing to inherited RFCs, and there are some weird things one can do with IPV6 notation, especially like translated addresses. Boulder and Pebble both leverage upstream libraries, which generically support these, however their test suites don't seem to address this.

The lack of translated/embedded examples in testing suggests to me that ISRG may not have gotten to addressing this at a policy level (in addition to the technical level). When it comes to the concept of compression/expansion - there is not just the question of valid inputs, but also of expected outputs. Should output and input be identical, or should the ACME server standardize to a preferred notation for two equivalents? Given the existence of rate limits that incorporate the ip address, would that apply to equivalent notations, or just the literal notations?

Personally, I would prefer if there were some sort of standardization across the outputs. I don't care about the preferred notation, and I don't care if it's restricted by the input or translated if needed on the server. I would just prefer the ACME server to be opinionated so I don't have to deal with the scenario of two different certificates that cover the same ip address but using different notations.

2 Likes
11

The Let's Encrypt API will always return the normalized (RFC 5952, Sec. 4) form of an IPv6 address. Ultimately, IP addresses in certificates' SANs are stored as raw bytes, not as strings.

4in6 addresses in 2001:db8::/32, 64:ff9b::/96, etc. will be rejected because they're in the IANA IPv6 Special-Purpose Address Registry.

6 Likes
12

Thank you so much, James!

4 Likes
13

For now, we only accept IPs that are already formatted in the way described by RFC 5952, Section 4. This is because we think it is likely that a client requesting a fully-expanded IPv6 addr and receiving back the collapsed form might become very confused. So for now at least, we're going to be strict in what we produce and strict in what we accept. We may revisit this decision in the future.

Note that all of this only applies to the way IPs are represented in the ACME API (i.e. as json strings). Once they're baked into an x509 cert, they are always in their canonical byte-based, non-textual representation.

8 Likes
14

Thanks, @aaron. That is excellent news! I had similar concerns (though I didn't care for compressed vs expanded) and it's great knowing that you've already decided to simplify things for Client Developers and Subscribers alike, by enforcing strict input and standardizing the API output.

If you do revisit this decision in the future for any reason, please keep in mind that a lax input will complicate troubleshooting and auditing logs, as the input may not match data that appears in JSON API payloads.

3 Likes
15

I think there's a reading of RFC 5952 Sec. 4 ("all implementations MUST accept") that requires accepting all the formats (uncompressed, with v4 addresses on the end, etc.) even though it's recommended to stick to the "standard" compressed format for output. So sending the API 2001:db8:3:4::192.0.2.33 or 2001:0db8:0003:0004:0000:0000:c000:0221, and getting back in the output 2001:db8:3:4::c000:221 wouldn't surprise me. (And yes, it's an example IP there so you wouldn't actually issue for that range, but assuming it were a "real" prefix being used instead.) But I am nowhere near as proficient in reading RFCs as you guys all would be.

4 Likes
16

Keep in mind, it is common for software to not be fully RFC compliant. Boulder and Pebble both have divergences from the ACME RFC – which was primarily authored by ISRG.

Anyways, the RFC states:

The recommendation in this section SHOULD be followed by systems when generating an address to be represented as text, but all implementations MUST accept and be able to handle any legitimate [RFC4291] format.

I think there is a legitimate argument here the API would be compliant for recognizing the non-preferred IPV6 notation, and handling it with an error code.

4 Likes
17

Given the IPv4-mapped addresses are on special purpose list, the answer should be "no".