What is the greater picture here?
If I recall correctly, the standard forbids SSL certificates assigned directly to IP addresses.
well it is possible iirc but LE certainly does not do that since checking that you “own” an IP is quite a bit harder than just for a domain, especially in the realm of dyn-IPs
No, no certificates will be issued for IPs, only for DNS names.
Well I saw some hosters or cas give certs for IPs, so it must be possible, but as i said LE won’t do that.
I think the current Baseline Requirements norm is not to issue certificates for private (RFC 1918-reserved) IP addresses, while certificates for public IP addresses are still permitted. However, Let’s Encrypt has decided not to issue certificates for bare IP addresses even if this would be permitted by the Baseline Requirements.
This is probably a good idea. Site owners typically don’t have as much control over their IP addresses as they do over their domain names.
Thanks for all your replies. I’m working on an application for an organisation, they have an external IP address to allow external access on the web server but no domain names and I wanted to use https.
Buy a random domain name? Cheap and easy.
Free speech, dissent, journalistic privacy, privileged communication, whistleblowing, umpopular opinions - all of these are stifled without anonymity and encryption. By using and restricting useable SSL to the Domain Name System it makes free and secure communication subject to identification of name and address and therefore targeting by opponents, DNS also is used for censorship and is easy to poison for redirection.
An https self signed direct IP address connection miimizes all these risks including MITM attacks, and is as easy to remember as a phone number. There is no good reason to ban public IP addresses, especially if root control is validated using the webroot method.
The main problem is with the browser/CA cartel crippling https for those who do not pay them - with red flags and warning screens. A self signed direct IP address with https is much more secure than http to the same address, and yet http is not hindered. And there is absolutely no excuse for red flagging and alarm screens for internal IP addresses.
Even for https encryption on a domain name most websites just want to get rid of the red warning and do not care about green address bars or ID validation. So why is self signed https treated even worse than completely unprotected http? Only because of the CA/Browser Forum cartel.
You could use something like http://xip.io/ by Basecamp if you didn’t want to register a domain or get an account on a freedns provider
the problem is that anyone could self-sign a cert for any IP and MITM the connection. also IP certs were probably taken out because at least for home users the IP literally changes every day or on a reconnect which means that they lose the IP address fast enough to make a certificate meaningless or rather insecure because you would have a cert for an IP you dont own.
We are really need ability to issue certificates for IP itself. We are developer of hosting automation panel. Our customers install panel on their servers. But actually we do not know any hostnames about customer. So we have only single way to get access to customer. We are using: https://10.0.1.xx for access to management interface. But self signed certificates is not security for this case because they could be hijacked and customer will not detect it.
So much another companies who offer routers / switches / CPE devices / security devices have really similar issue.
So we need some way to issue certificates for dedicated globally routable IPv4 addresses (IPv6 will be fine too). With this option we could secure all conversations between customer and our appliances.
As has been stated;
the current Baseline Requirements norm is not to issue certificates for private (RFC 1918-reserved) IP addresses, while certificates for public IP addresses are still permitted. However, Let’s Encrypt has decided not to issue certificates for bare IP addresses even if this would be permitted by the Baseline Requirements.
So in short Let’s Encrypt isn’t the right solution for you.
There are a number of possible alternate solutions for you, depending on your system. For example if you have a link into the routing / DNS (I’m guessing you do in some way as you are on a private IP range that they need to be able to route to) then you could still have a domain name on your panel.
wait, wait stop.
10.x.y.z is a PRIVATE IP. you wont get ANY cert from ANY provider for that.
also why can the customer not just give you their host names?
10.10.10.10 was example. We are using globally routable IP identification.
Actually we could not use host names because in normal case customer haven’t any hostnames on server. Customers could run VPN, IRC, Torrent and they really do not need any domains and do not have any domains. And we could not request domain when customer haven’t it. So that’s why I’m asking for this capability.
well then you have to get the certs elsewhere.
it might be a lot harder to prove actual IP possession than just the possession of a single domain.
yep, it’s complicated. But this could make Internet more secure!
My1, while I agree that it is potentially harder to verify, perhaps there could be a requirement that a site be visited FROM the IP in question, in order to show control over it. As an example:
My Cisco router is at 184.108.40.206 (theoretically a public routable IP), the CA would tell me to access https://verify.CA.com/randomstring/verify.txt from IP 220.127.116.11 to confirm control. on my Cisco, I would just enter the following command in the CLI:
copy https://verify.CA.com/randomstring/verify.txt verify.txt