SSL_ERROR_BAD_CERT_DOMAIN on http-Sites

Question

Hi There! 
 I've found a peculiar behavior in our Sophos UTM 9. 
 We protect our webservers on which we host several customers with a UTM 9. Now let's say customer A has an SSL certificate and customer B doesn't. 
 We create a virtual webserver with the ssl certificate for customer A and set it to encrypted (HTTPS) & redirect. Then we create another virtual webserver for customer B but with plain http. Both virtual webservers route to the same real webserver. 
 Now the interesting part: When you open the website of customer b , everything works fine. But if you manually type https:// before the URL, say https://customerb.com, you get a SSL_ERROR_BAD_CERT_DOMAIN error (or similar, depending on browser). That in itself isn't that bad but if you click on advanced you can see the certificate of customer A ! The message looks like this: 
 customerB.com uses an invalid security certificate. The certificate is only valid for the following names: *.customerA.com, customerA.com 
 Error code: SSL_ERROR_BAD_CERT_DOMAIN 
 Naturally we don't want to let everyone see which other customers we host on that server. 
 Is there a way to prevent this? The real webserver is a Windows Server with IIS. 
 Thanks and kind regards, 
 Markus

ewadie · Accepted Answer

That's standard Apache behavior (WAF is based on Apache). 
 If you have multiple IP addresses available you could host your HTTP-only customers from one IP address and your HTTPS customers from a second one.

ewadie · Answer

Markus Quirmbach said: Another idea: Is there a way to set the "standard" ssl certificate for a virtual webserver? So we could decide which certificate shows up in the error message? This would at least prevent everybody to see the certificate of another customer of us. 
 Create a wildcard certificate in WebAdmin, clone the virtual webservers of your HTTP-only customers, switch the clones to HTTPS and select the wildcard certificate. Don't forget to enable the new virtual webservers. Accidental HTTPS requests to your HTTP-only customers will now use this wildcard certificate instead of a legitimate certificate of one of your HTTPS customers.