IP Address SSL Creation

Will Let's Enrypt provide SSL for IP Address? Will this be in your roadmap?

I think this is the last thread with an "official" answer:

Basically I think it's something they'd like to do at some point, but so are many other things that they're working on first so you shouldn't hold your breath.


I don't get the use case.
DNS is intended to make numbers easy to remember by changing them into names.
Even phone numbers are entered into [smart]phones only once, then it's just call "person/name".
Who wants to remember an IP? And why?

Naturally, not all things on the Internet were made for direct human interaction.
Still, there are plenty of advantages of using DNS over not using it - even for non-humans.

Again, I'd love to hear a good use case for this.


Here's the reason why we need IP addresses to have ssl certified.
Cybersecurity Risk Management Services such as BitSight are NOT ONLY looking at the FQDN of a publicly accessible web servers. They now requires you to add a valid SSL to the associated IP address.

If you dont have an SSL to the IP address, they will flag it as a security risk.
In effect:

  1. Lower your score on the Cyber Security from Rank A to Rank E.
  2. The lower your, your Cyber Security Insurance Policies will cost higher and/or worst deny your company from getting the insurance policy.
1 Like

Please define: "valid SSL"
[per their actual requirement verbiage]


Pubicly Valid Registered SSL Certificate. For now, I generate the Public IP Address of our web server with DigiCert. They are one of very short list of SSL providers that offer Public IP Address SSL.

That just seems like a silly requirement, but the industry is full of that so this isn't the place to debate how useful that is.

There are definitely legitimate uses of IP certificates, such as avoiding various problems with DNS.

As we've said in the linked post before, it is something we're aware that there's desire for, but don't currently have a planned timeline to implement IP Certificates.


Some services need to be IP based. Sometimes you need to serve content on an IP and not a hostname.

You are most likely getting this error, because your web server is configured to use a fallback and answers to IP based requests. Unless you have a specific reason to host data on that IP, the standard way to handle that is to disable serving content on the IP address. Many people handle things like this by using an untrusted self-signed certificate as the default server and not having any content mapped to it.

Here's a way to do it in nginx: Nginx allow via Domain but not via the IP - Stack Overflow


Thank you and currently, I'm using DigiCert for creating SSL certificates for IP Addresses.
So no rush. I just hope that Let's Encrypt will consider planning this implementation sooner.

Anyway, thank you very much for responding quickly to my inquiries.


IP address certificates are relevant for DNS over TLS: If I have to use DNS to find my DNS resolver, it creates a catch-22 problem (which can be resolved if I use another bootstraping DNS resolver, but avoiding this altogether may be desirable). If my DNS resolver has a cert for its IP address however, I can avoid this issue altogether.

DoT providers like Cloudflare (+ various others) use IP address certificates for exactly this use case:

# openssl s_client -connect
 X509v3 Subject Alternative Name:
DNS:cloudflare-dns.com, DNS:*.cloudflare-dns.com, DNS:one.one.one.one, IP Address:, IP Address:, IP Address:, IP Address:, IP Address:2606:4700:4700:0:0:0:0:1001, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:64, IP Address:2606:4700:4700:0:0:0:0:6400

That is a very unique case: I'm a global DNS service provider and I need...

The "average Joe" isn't being flagged by "BitSight" for anything anywhere near this.
I'm leaning towards @jvanasco's thinking:

  • they are responding to HTTP(S)://IP.IP.IP.IP [for no apparent reason]

Removing such response(s) should also remove the complaint(s).


I'd like to run my own public DNS over HTTPS resolver for my devices. Since it doesn't carry the same risks as regular DNS. (I guess that makes me a global DNS service provider?)

Being able to get an IP address certificate would simplify that a lot.

No, and it's a legitimate use. But I'm not sure what the validation requirements are in CA/B BR.

GTS makes certificates for IP addresses but they require you (not your ISP!) actually own the IP address. I don't know if that's them or a baseline requirement.


Sadly, we can only speak with any certainty about LE here.
And LE doesn't provide certs for IPs.
So, you will have to try the other CAs.
Some must do it.
Some may charge for it.
Some may charge more/less than others.
So... be sure to compare pricing before diving into anything.

Also, even though I provide DNS over HTTPS...
It really only matters when the client uses your IP as their starting point.
If they default elsewhere, then the point is somewhat mute.

1 Like

TLS BR section and 7 specifically allows acme challenges used for ip address as it in rfc8738


Now that's a very strong case for the very short certificate lifetimes [like one week].


If it's just for your own devices, you could consider making your own private CA for it. A bit more complicated, sure, but a bit more control too. I don't know how that would interact with your "security scan", but I think it's pretty common for medium-to-large organizations to run their own CA.


I have my own internal CA, but the process of trusting certificates definitely adds some friction.

I was just trying to point out a good use case for IP address certificates, and that was an idea I had kicked around a bit. Right now I just tunnel DNS with wireguard.


There are many. Some CAs offer it. Its on the LetsEncrypt roadmap to eventually happen.

Most subscribers who post here wanting IP Certificates do not need them and would be better off using a FQDN instead. I think that history is the motivation behind the strong perspectives shown above in this thread.

The subscribers who actually do need IP Certificates are fortunately small in number - so this deficiency in LE's current offering does not negatively affect a large number of potential users.


Let's Encrypt used to plan to support iPAddress, but cancelled that roadmap.

I think Lets Encrypt worries same what Google Trust Services worries, IP's validity doesn't likely a domain name, has validity at least 1 year. but IP changes its ownership frequent.