1

A quick question.

I sign a certificate for PKILabServer.com (Listed under Common Name),

open /etc/hosts and add the following entry 127.0.0.1 PKILabServer.com

Then launch the server using the command % openssl s_server –cert server.pem -www

I point the browser to https://PKILabServer.com:4433 and then it shows "Invalid security certificate..." and then I load my certificate file ca.crt and the website loads perfectly.

The question is that, since PKILabServer.com points to the localhost, if we use https://localhost:4433 instead, we will be connecting to the same web server.

But when I point the browser to localhost:4433 , I get an error saying "This certificate is valid only for pkilabserver.com..." I'm required to explain the reason for this in my project, and this is what I answered. Please correct me if I'm wrong.

This is because the Certificate Signing Request that was generated was signed exclusively for PKILabServer.com (as it was listed under Common Name) Since the /etc/hosts file had entries for a lot of other websites which were listed under localhost, hence pointing the browser to localhost:4433 would take the website listed in the /etc/hosts file and since the websites don’t match, we get the error that “The certificate is only valid for PKILabServer.com”

2
  • Yes. The webserver delivers are certificate for your domain which is different from localhost and as such the browser says it's not valid. You'd need a second certificate; not use localhost and/or adjust your web server configuration. In addition it's a bad idea to use openssl s_server for anything except testing in a very narrow scope.
    – Seth
    Nov 15, 2016 at 12:41
  • CN=PKILabServer.com is probably wrong. Hostnames always go in the SAN. If its present in the CN, then it must be present in the SAN too (you have to list it twice in this case). For more rules and reasons, see How do you sign Certificate Signing Request with your Certification Authority and How to create a self-signed certificate with openssl?
    – jww
    Nov 18, 2016 at 12:03

1 Answer 1

1

I think you are confusing the role of an IP address and domain name with respect of HTTPS connections.

A certificate (in context of HTTPS) has no knowledge of IP addresses and cares even less - all it cares for is the domain name(s) it is associated with - and these are hardcoded into the cert.

When your HTTPS connection is being established, the domain name is passed using a header ("host: xxxx") - and the cert validates against this, regardless of the Interface it comes in on.

Hence when you go to localhost:XXX the cert does not match because localhost is not in the hosts line of the header and it throws up an error. Similarly, mapping 127.0.0.1 to the domain name and using the domain name works fine.

[ I note, for the sake of completeness, that I assume the Virtualhost can bind to any IP with the same config ]

5
  • Thanks for the explanation @davidgo. Could you please elaborate on this mapping 127.0.0.1 to the domain name and using the domain name works fine. I tried going to 127.0.0.1:4433 I get the same error as I got when I go to localhost:4433
    – Data Shark
    Nov 13, 2016 at 21:38
  • (Sorry, I just reread your question and realise I did not entirely answer it - I did not see the last paragraph) When you go to 127.0.0.1:4433 the webserver receives a request with "host: 127.0.0.1:443" in the header. It sees that this does not match any of the names (Common Name field) in the cert and throws up an error. The same is true if you go to localhost:443. IE, if you type in any name which has is not listed in the cert file it won't work, regardless of IP address.
    – davidgo
    Nov 13, 2016 at 21:43
  • one more quick question. After I launch the server, load the certificate into the browser and point to PKILabServer.com:4433, I get a bunch of cipher suites. I was required to explain the observation on this. I have done it, please have a look at the explanation and let me know if it's correct. i.imgsafe.org/8faa770a88.png
    – Data Shark
    Nov 13, 2016 at 23:49
  • I can't speak authoritatively on this, but I think your answer is correct. According to the s_server manpage "-www sends a status message back to the client when it connects. This includes lots of information about the ciphers used and various session parameters. The output is in HTML format so this option will normally be used with a web browser."
    – davidgo
    Nov 14, 2016 at 0:43
  • What's missing in this explanation (while it's good) that some years ago before SNI was a thing it was indeed only possible to bind one certificate to one IP. The certificate didn't have the IP in it but the Handshake process didn't include the hostname and as such the web server didn't have anyway to deliver different certificates.
    – Seth
    Nov 16, 2016 at 6:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .