1

I have several vhosts on port 443 and each of these vhosts have the ServerName config option set and also the correct SSLCertificateFile and SSLCertificateKeyFile values as well which vary depending on the vhost. This all works fine.

The issue is if someone accesses the server using an address that doesn't match any of the values for any of the ServerName's then I think it uses the first one by default. I don't want it to do this. Instead I would like it to return nothing. At the moment it will try and load one of the other vhosts on port 443 instead and as a result a certificate error message is thrown up in the browser because the address on the certificate doesn't match, which makes sense.

Is this possible?

For the same scenario for non-https connections on port 80 it's simple. I just create another vhost with the ServerName option not specified, and this becomes the default and then I can have this show a 404. When I try to the exact same thing and create an entry for port 443 without the ServerName property set I can't start apache and this is what is in the error.log file.

[error] Server should be SSL-aware but has no certificate configured [Hint: SSLCertificateFile] ((null):0)

Anyone know if what I'm trying to do is possible?

E.g. lets say at the moment if I have 2 vhosts on port 443 with the correct config pointing to the correct certificates, one being site1.com and the other being site2.com. Anyone can go to either of those 2 sites in their browser and everything works fine. However if someone goes to site3.com (and its A record points to the same ip as the server as well) then apache then appears to presume that they are wanting the vhost corresponding to site1.com, and serve that, whcih I don't want. Instead I would want apache to send no data for a request to site3.com. How can I achieve this?

Thanks!

0

Without a valid certificate for whatever domain name the client is trying to request the HTTPS connection will fail with a certificate error. You have no real choice in the matter, they are connecting via HTTPS to you and you do not have an acceptable certificate to present, this is a scenario where failure is the designed outcome.

I think your problem may be that you are serving a mix of HTTP-only and HTTPS sites on the same IP address. Doing so will lead to a problem if clients try to use HTTPS for one of the sites that are only set up do HTTP and where you have no valid certificate to use for this HTTPS connection.

If instead HTTP-only sites are isolated to an IP address where no HTTPS is available at all (it's not even possible to connect to 443/tcp) then at least it's clear HTTPS is not available.

|improve this answer|||||
  • I understand why a certificate error will occur. What I want to do is instruct the server not to send any data to the web browser if the domain in the request doesn't match any of the vhosts, instead of just defaulting to the first vhost in the list and sending the response for that. Does this make sense? – Tom Jenkinson Apr 13 '14 at 10:50
  • E.g. lets say at the moment if I have 2 vhosts on port 443 with the correct config pointing to the correct certificates, one being site1.com and the other being site2.com. Anyone can go to either of those 2 sites in their browser and everything works fine. However if someone goes to site3.com (and its A record points to the same ip as the server as well) then apache then appears to presume that they are wanting the vhost corresponding to site1.com, and serve that, whcih I don't want. Instead I would want apache to send no data for a request to site3.com. Is this clearer? – Tom Jenkinson Apr 13 '14 at 10:54
  • I suppose then the answer is you can't do that. The TLS connection is already being established at the point when you know that there is a problem. You have no clean way of backing out of that; either you present a valid certificate or the client will be showing an error. – Håkan Lindqvist Apr 13 '14 at 10:55
  • Or is the point that you want a different variation of the error than the specific one that you are getting currently? – Håkan Lindqvist Apr 13 '14 at 10:57
  • 1
    I guess for that specific case you can either get a certificate that is actually valid for the IP address (see eg support.globalsign.com/customer/portal/articles/…), that way it would actually succeed if you set up a vhost for that purpose, or alternatively just have the first https vhost be something "neutral" if you just want the error not to expose something that comes off as strange. – Håkan Lindqvist Apr 13 '14 at 11:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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