For an embedded device under development we have a requirement for logging in to its web without sending user credentials in clear text.
The look of the log in form should be customizable, so digest authentication is not possible. The only remaining option as we see it, is to use HTTPS with SSL.
The device is usually accessed from the local network by it’s IP address, but could also be made accessible from the internet.
My question is: Is it at all possible to prevent the “Could not be certified” browser warning, when no DNS name is assigned to the locally accessed device? As I see it, a SSL certificate must be bound to a DNS name and certified at a Certificate Authority for the browser to fully accept the certificate.
I am fully aware of the fact that without a certified certification the browser can not authenticate the web server, which could lead to a “man-in-the-middle” attack.
When the device is fully configured it’s only accessed very rarely, but it should be easily accessible.
HTTPS does allow for a certificate to be issued to an IP address instead of a hostname. Indeed, the HTTPS specification (RFC 2818) states “In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.”
So, if you can obtain an SSL/TLS certificate from a CA that is bound to the IP address of your device, then clients connecting to it should accept it as valid as (1) the URI used to access the device is the IP address that matches that contained within the certificate, and (2) the certificate is issued by a CA chain trusted by the client device.
If you only need to access this device using clients that you control, you can use a self-signed, bound to the IP address, certificate that you generate, but you would need to configure each client that would access it to explicitly trust that certificate since it would not be issued by a trusted CA.