My situation: I want to run a webserver on a device in an unknown network. Requests on port 80 or 443 will be forwarded to this device from the global ip.
The device regularly posts its IP address to a server on the web and it is saved on this server.
Is it possible to access this device via https without much trouble? The problem of course is, that the ip can change and a SSL certificate needs to have a hostname.
Edit: The device doesn't have a domain assigned to it that I could use for a certificate. Is it maybe possible to use a domain I own and reroute that to the dynamic ip without changing the header? As far as I understand it that would make using https possible
This option allows you to specify a public IP address as the Common Name in your Certificate Signing Request (CSR). The issued certificate can then be used to secure connections directly with the public IP address (e.g., https://123.456.78.99.).
If you have dynamic IP, you will need to sign up for dynamic DNS service. This service will regularly update your domain name to point to whichever IP address your ISP assigns you. Take a look at this introduction to DDNS for more details. Your DDNS provider may also be able to register you for a domain name.
Dynamic IP addresses are cheaper than static IP addresses. They also offer more security and privacy as hackers cannot know what IP address will be assigned to your servers by the ISP. Whatever they may have is guaranteed to change after a while.
Assuming you will be hosting your services behind a domain name, not the IP address (e.g. http://myservice.com , not http://192.168.0.1 ) the IP address for an SSL does NOT need to be static, it just needs to be dedicated.
The common wisdom of SSL certificates being associated with one IP address is misleading. An SSL certificate is issued for the domain name, not the IP address. The issue with IP addresses stems from the details of the HTTPS protocol, and namely just the issue of name resolution. An HTTP server can host many different sites for many different domains, all on the same port and IP address. It knows which site is being requested based on an HTTP header.
Now, with HTTPS, the server first needs to negotiate a secure SSL connection before any HTTP headers are exchanged. The issue therefore is that it can't know which certificate for which domain it's supposed to use to negotiate a secure connection, because it hasn't yet had a chance to talk to the client about the domain it'd like to visit.
There are actually mechanisms for name negotiation before encryption in later versions of the HTTPS protocol, but the practical problem is that older clients do not support it yet (stare at IE6).
So the practical solution is to reserve one IP address and/or port for each HTTPS site, because then there's no issue of multiple name resolutions. One IP/port is reserved for one specific HTTPS site and in extension for one SSL certificate.
Which means, as long as your server is only serving one HTTPS domain, its IP address can change as often as it wants; there's no issue there.
There is no problem with dynamic IP. In SSL certificate you store a static hostname (domain.com
), no IP address.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With