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
well that would make it not much better because everyone on a hoster can invoke a curl or whatever on PHP to access the file and get a cert for the entire hoster.
I dont know what you can set in reverse-DNS but if you can make txt records for IPs you could do that, that requires a lot more control.
Why would CURL be able to do that, the Random String would be generated on demand hwen the users requests an IP cert, and then dumped afterwards (not to mention, the system would disregard it if it wasn’t accessed by the IP in question).
The problem is, the IP address doesn’t have to be unique to that user.
Imagine a server with 100 users and only one IP address. Every user which would envoke
copy would be able to “be the owner” of that IP address in your situation, because every connection from that server would be from that single IP address. Therefore, that method could never be used to uniquely identify the owner of the IP address…
Dont underestimate the power of some nice php, i could easily craft a form where i enter the url and that gets curl’d.
Or i just write the url in the code after i got it from the ca.
Obviously @Osiris answer is exactly what i am saying. Anybody with curl, or fsockopen or similar (which most hosters actually have so users can use cms or forum software better (auto updates etc)
But, unless they have the issued http link that would only be valid one time, it would be just noise to the server, and in fact, if it were me, I would set a connection limit to prevent spamming of the server.
Basically, the IP may not be unique, but the http link would be, and would be expired as soon as either the link was confirmed, or the connection limit was reached.
As I said above, the link that LE (or other CA) would be a one time use, self expiring link (either expires once used, or some configured failed number of attempts from an IP). Yes, I get that there are situations where it’s not useful, but there are many times where it would be, such as firewalls/routers, etc, where you typically would not assign a DNS name, but just access the IP address.
Unless I am missing something, here is how I see it:
- IP certificates are not against the rules, but is also not required
- There are ways for the CA to ensure that the person requesting the certificate are actually authorized to use the IP address, some ways are, unique, one-time use https links to CA’s verification website (server side), require posting of an HTML/TXT file with a specific name & data in it to the IP web server (client side), rate limiting requests in general to prevent automated processes from trying to guess the server side web link
- There are many use cases where using a domain name would not be preferable or pointless, such as for device management (i.e., routers, firewalls, etc)
- At this time, it appears that LE has decided to NOT allow this, which is perfectly within their purview to allow or disallow, as it is not required, but I do hope that they revisit that decision at a later time
- Even if multiple people had a “valid” certificate to the IP address, only the users that are actually connected to the IP could use the certificate, which would also require cooperation with the user that controls the gateway, so that argument is moot, as the gateway controller would have to forward the appropriate ports to the inside users. This would also mean that anyone who got a certificate from a dynamic IP pool would not be able to continue using the certificate (at least not without triggering the browser warning alarms that the DN was not valid) once that user’s IP had changed.