Plans to support RFC 8738

I’ve just implemented RFC8738 in uacme (ualpn branch)

I’ve tested it against the staging endpoint but it does not accept “ip” identifiers yet:

uacme: creating new order for at
uacme: acme_post: url= payload={“identifiers”:[{“type”:“ip”,“value”:“”}]}
uacme: acme_post: return code 400, json=
“type”: “urn:ietf:params:acme:error:malformed”,
“detail”: "NewOrder request included invalid non-DNS type identifier: type “ip”, value “"”,
“status”: 400

@ndilieto Pebble supports ip identifiers.

Did you really try ?

1 Like

Right, Let’s Encrypt has not implemented this new standard (in staging or production). It’s only mentioned on the roadmap of future features.


Are you sure you need a publicly trusted cert to do that?

I find no mentions of it being necessary on dnscrypt-proxy server install instructions., it also says it rotates keys every 8 hours (too fast for LE not to complain)

1 Like

I guess that depends on the overall scope and definition of “for my own use”.

— and there is the overall increased “coolness” factor —
— FYI using LE is officially COOL —


No, no. It’s the first time I see a DoH resolver using a PKI infrastructure. I have always seen list being distributed with their authentication fingerprints.

Anyway, OP: if you need a fqdn you can get one from dynamic dns providers (duckdns, afraid, nsupdate, …) or you can buy a very cheap .xyz domain (numeric only, 6-9 digits, should be around a dollar per year).

1 Like

I think I read it in a completely different light. But you might be right.
So it still depends on what is exactly meant by “for my own use”.
Maybe @ski192man can chime in with a few more details about it and clear things up a bit.

1 Like

Yeah, I do not fully understand what “bootstrapping requirements” he’s talking about…

1 Like

DNS over HTTPS is normally accessed over domain name, i.e. cloudflare’s resolver is This presents a chicken before the egg problem, to know where your resolver is you must first resolve it, the current typical solution is to query the system / network provided resolver.

Alternatively you can access cloudflare dns at (or their IPv6 alternative), this solves the problem of how do you know where the resolver is because it’s an IP address so you do not have to use the traditional resolver for anything. The catch is you have to have a certificate for your IP address.

And yes, I mainly want a LE cert because it’s cool to have a publicly trusted cert on your IP address, also some people I know might use it since i’ll run it through pihole. I already have quite a collection of domain name and am running a resolver on one of them at

Regarding dnscrypt-proxy, I think you may be thinking of it’s DNScrypt mode (which i’m not familiar with), DoH and DoT uses the existing PKI infrastructure

@9peppe I updated my post with a bit more information, I didn’t see your other posts when I submitted mine.

Hopefully this will give some people a sense as to what is possible with this RFC, I have no doubt there are many other cool things you could do with this.


At a bare minimum, it can allow those that truly can’t afford encryption, or are blocked from using free services, the opportunity to have encrypted services with as minimal “complications”/costs as possible.
Power To The People!


Yeah, it looks cool indeed. Think of ephemeral certs on dynamic ips or even validation based on reverse dns entries.

It’s probably not as useful as it could on dynamic ips, though. That’s more of a wireguard/tinc domain.

No CA will ever be able to issue certificates for that IP anyway (it’s prohibited by the Baseline Requirements). If you want to run tests with that IP, you need Pebble or some other test CA you can run locally. Of course the resulting cert will never be publicly trusted :slight_smile:

1 Like

5 words
50 words
…and yet…
they are saying the same thing.

Nah! Yours is much more colorful! :+1:

1 Like

Is it true that applying for a certificate with a private IP address could eventually lead to the Death Penalty or - worse - affect one’s Credit Rating?


It would be possible to use ip based links in websites.

Without using a domain name.

Or with a mail server, so users are able to connect raw ipv6 addresses.

The main question: Same life time - 90 days? So it would be possible to create a certificate:

ipv4 of that domain
ipv6 of that domain

Next step: Define a DNS entry, so the domain based certificate must have the correct ipv4 and ipv6 address.

If not -> something is wrong.

1 Like

Hey, author of the RFC here. The main impetus for this extension was to widen the applicability of ACME to non-HTTPS based TLS systems that rely on the web PKI but may not use DNS names. One major example of this is DNS-over-TLS (DoT), but there are numerous other protocols where DNS names are not routinely used.

This document was also aimed at bringing ACME CAs up to parity with the capabilities of existing non-ACME CAs. Being able to standardize how the validation of IP addresses should be performed also allows us to push for further tightening of the CABF Baseline Requirements on validation techniques.



if you have a minute I’d appreciate your feedback on this. It should support both RFC8737 and RFC8738…


Cool! I’ll put it on my TODO list to check out, but I suspect the fact I’ve not seriously worked on C code in quite a while will impair my ability to provide much valuable feedback.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.