Hi everybody,
My users see the following error every time they open Outlook or Skype. We’re using HAproxy as a load balancer and the name of the server is different from the CA name used in DNS. How should I resolve the issue.
(Figure 1)
Configuring another server that has some configuration related to mail server, I see the following error (figure 2) and couldn’t find a way to solve the problem and I think this problem is also related to the first one.
Hi rg305,
thank you for your quick reply. As I’m a new recruit and don’t know so much about legality of disclosing internal server’s addresses and URLs outside my company, I blurred the address; my apologies. But I can describe the situation as clear as I can.
let’s assume that company.com is my URL, then actual server name (computer name, as it’s a windows machine) is srv-mail1, so the server is accessible with the url sr-mail.company.com inside the corporation.
CNAME record “mail” is created for the server. hence, the server also accessible by mail.company.com.
Issued certificate is for mail.company.com (the blurred out part of the picture) but the machine name is srv-mail1. So, as I fathom it, the problem lays here. to summarize, I have a server accessible with two names and a certificate issued for one address. How can I solve this problem? Thanks again.
Or get a cert that has both names on it.
But that may require that both names resolve publicly.
Or you would need to get a wildcard cert to cover the name that doesn’t resolve publicly.
Users just see the errors and if they press yes they still could go on without problem. However, the real problem is when I want to configure a service trying to connect to the mail server. (as you see in figure 2.)
Note also that if your internal name is not fully qualified (e,g it’s ‘srv-mail1’ instead of ‘srv1-mail1.company.com’ then you can’t get a cert for it (from any service, but you can issue a self signed cert, not that that’s much use).
If users are seeing the actual server name rather than it’s friendly name (the one on the cert) then it’s most likely you can change a setting in exchange for the default URL of the web part of exchange services (Client Access server?) maybe something like: https://gallery.technet.microsoft.com/office/Exchange-Server-Client-510ad60b
So yes, your certificate must include all of the names which will be used via browsers (or apps etc) over https. If you find an app that’s using a name you don’t expect it to then check the configuration of the server and the client. For MS Exchange you need to configure which URLs the services will be accessible over (there can be more than one).
One way to think of this is that the app has no way of knowing whether foo.company.com and bar.company.com and mail.company.com are all run by the same person (or the same department, or the same company). There are many cases on the Internet where they’re not, and so the app has to assume that they’re totally unrelated. In that case, if the app is configured to connect to mail.company.com and it receives a certificate that’s only valid for foo.company.com and bar.company.com, the app has to assume that this certificate is totally invalid. It can’t make the inference or guess that this might be run by the same person, because that would allow a number of kinds of attacks.
As the other folks in this thread have said, the app will simply not accept connecting to a service if it was configured to refer to that service by a name that is not listed in the service’s certificate. It simply has no way of knowing by itself whether or not two related-but-not-identical names are supposed to refer to the same computer. To get rid of the error, you have to make sure that the service is only ever referred to by names that are listed in a certificate that the server possesses, and that’s issued by a certificate authority that the clients trust.
From the point of view of the Outlook developers (for example), this is totally intentional, to stop a café owner from creating a machine simply called “mail” on their wifi network and then stealing your users’ passwords when their Outlook application auto-connects to it! (or to prevent people who connect their laptop to someone else’s corporate network from attempting to automatically log in to the equivalent services on that network, and thereby telling the other corporation their passwords)
