Encrypting local HTTP traffic using a self-signed certificate

Question

For the past couple of hours I've been trying to create a self-signed certificate which I'd like to use to encrypt HTTP traffic between computers and a server on my home network (because I'm paranoid like that). However, I'm not sure if I'm doing this right because I keep getting security warnings in my web browsers. Especially Google Chrome does not like what I'm doing.

Hopefully someone more experienced can provide guidance.

My server (a Synology DiskStation) can be reached both internally (via its local IP address or hostname), or through the internet (via a public IP address or DNS name). Unfortunately, the public IP address is dynamic. However, a service running on my server updates the DNS entry every 60 minutes.

What I've done is I've used OpenSSL to generate a self-signed X.509 certificate (using default settings for the biggest part). I did not specify a CN (Common Name), because during earlier testing I found that it would cause even more security warnings when accessing the server internally. Instead, I included the DNS name, hostname and local IP address in the subjectAltName extension field.

My server's certificate now looks like this: https://dl.dropbox.com/u/14454764/cert.crt

I then proceeded to install this certificate in the Trusted Root Certification Authorities certificate store on my windows machine. I can now access the webserver using HTTPS, but not without warning.

Errors include:

• (Google Chrome) Server's certificate does not match the URL. (when using hostname)
• (Google Chrome) The identity of this website has not been verified. (when using local IP)
• (Internet Explorer) The security certificate presented by this website was issued for a different website's address. (when using local IP)

These warnings return whenever I restart the browser. If I access the webserver from the internet (using the DNS name), none of my browsers complain and everything is fine.

Can I generate certificates for internal use which do not trigger such errors? I'd greatly appreciate your help.

Answer 1

When doing SSL access to a server, the client performs the following verifications:

1. The client validates the certificate with regards to the local "trust anchors", also known as "root CA", which are embedded in the client (the browser or the operating system). Validation is about building a chain of certificates from a trust anchor down to the SSL server's certificate, each certificate signing the next. Algorithm is a bit complex in its details (section 6 of RFC 5280).

2. The client verifies that the name of the intended server appears in the server's certificate (validation tells him that it is a valid certificate for some server; this step is about checking that it is the right server, not any other). This step is described in RFC 2818.

For the first step, you need to tell your client system that it should accept the self-signed certificate as valid. Since you talk about Internet Explorer, I infer a Windows operating system; see this answer for how to do it (since Chrome also uses the OS trust stores, chances are that it will fix it for Chrome too).

For the second step, you must use a URL with a server name (not IP address) which matches the name of type dNSName which appears in the Subject Alt Name extension of the certificate (when there is no dNSName in that extension, or when the extension is missing altogether, the Common Name in the subjectDN field is used). If the URL looks like this:

https://www.example.com/path/to/whatever.html

then the browser will try to find www.example.com in the certificate. If it does not find it, then you are due for a scary warning, as you experience.

You may have to play a bit with your DNS settings so that the same name can be used regardless of the network place you are. Remember that it is a name matching: it does not work with IP addresses. Also, note that you can put several names of type dNSName in a Subject Alt Name extension, which is useful for SSL servers who are to be contacted under several names.