Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
    
I think this question would better be asked to serverfault.com –  F. Hauri Jan 12 '13 at 10:28
    
Good point but I'll have to flag it for moderator assistance since I don't have enough rep. –  Steven Liekens Jan 12 '13 at 12:20
add comment

2 Answers

up vote 4 down vote accepted

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.

share|improve this answer
    
I was under the impression that URL matching was also supposed to work with IP addresses, because you can actually add IP address entries to the Subject Alternative Name extension. Everything does seem to work as expected when I use the DNS name or hostname to reach the web server. –  Steven Liekens Jan 12 '13 at 22:26
add comment

First answer to your question is yes, you must be able to use private certificates on private web server.

The certificate you point @dropbox, miss some important fields (don't have a valid CN field)! So it can't be used as a web server certificate (browser don't know how to store them). Maybe your server already blame against this certificat.

You can check you certificat with:

openssl x509 -in cert.crt -text | grep Issuer

Take a look at

  1. Your server's logs.
  2. Your web server's documentation
  3. Well known public docs, like RFC, W3 and Apache.
  4. I've found this interesent article on wikipedia

Good luck!

share|improve this answer
    
But what should I use as the Common Name? I tried using the DNS name, but that somehow resulted in Chrome completely ignoring the values in the Subject Alternative Name field. Setting a CN seems to do more harm than good... –  Steven Liekens Jan 12 '13 at 9:37
    
Take a look at this SO question: stackoverflow.com/questions/8744607/… –  F. Hauri Jan 12 '13 at 10:27
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.