Server's certificate is not trusted - Naming mismatch (Alternative names)

Are there any limitation when requesting certificates for multiply servers using 1 public interfacing IP? Asking since I’ve in the past setup one Server (A) which I have couple of domains which have been setup with certificates and which works fine.
I’ve now setup another Server (B) which went fine but when check the certificate by pulling a SSL Report I get that the the certificate isn’t trusted due to naming mismatch (Alternative names). The the report indicates that the Server A’s domain name is the mismatch compared with what I used for Server B.
So is this to be understood that when having only 1 public IP and using multiply servers the certificate will be locked to the first server certificates and everything else will be generate a warning of mismatch?
By the end of the day, Server B, is supposed to be setup as a mail server and where Server A is a web server. When setting up Server B I redirected port 80 from Server A to Server B for the authentication process. Would it make any difference if I make the authentication via dns txt entry instead?

There might be an limitations due to your web server, not the certificate. You could check if a web server support multiple certificate per IP by searching if it support SNI. Most recent web servers support SNI.

That's not true. If you didn't setup those virtual hosts correctly or the server does not recognize the host the browser visits, it'll be defaulted to the first virtual host or the default virtual host (which might be in your case).

If you could, share us your domain name and server configuration file (virtual host files) so we could help you fix it....

Thank you

Server A is running with Apache and it does handles multiply certificates without any problem as it’s currently been setup with 3 certificates for 3 virtual domains. So Server A isn’t the problem.

Server B which is primary running as Postfix mail server only and has a default Apache installation without the usage of virtual hosts. Certificates was pulled to support Postfix.

Ran Qualys SSL Test ( on the host name just to verify. As mentioned, for this I had to redirect port 80 from Server A to Server B, so the check is done against the correct server as the SSL report reflects the correct host but the reports claims a domain mismatch based on a domain hosted as virtual domain on Server A. Hence why I’m a bit confused and wondering whether there are any constrains in the usage of certificates using one public IP (firewall) and having multiply (in my case) physical servers using NAT.

Based on what you’re saying there shouldn’t be any problem with above scenario?

It’s possible that your firewall doesn’t properly dispatch HTTPS requests. Serving different HTTPS names on different physical servers requires more complex logic than a simple port forward (and usually, though not always, the certificates and keys would be installed on the router or firewall). There’s nothing in the technical standards, or in the certificates, that forbids this, but you probably won’t be able to get there with this configuration unless the firewall/router is sophisticated enough to understand what you’re trying to do.

This is assuming that the Qualys test is all over port 443 (in which case your firewall probably always forwards that port to one server, not to the other, when someone connects from the Internet).

Schoen you’re right, I just forgot to verify whether port 443 was redirected proper which it wasn’t… Once I did the change and applied the change to the fw it worked out as expected, so I don’t get the domain mismatch anymore… Well, so classic error 40 on this one.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.