So I recently took over IT needs for a new company, and they have an existing exchange server which I am fairly sure is not configured with even the remotest concept of "best practice" in mind. The situation is that the exchange server resides in the original parent companies domain. Lets call it exchangeserver.parent.company.com. However the exchange server provides mail for a new vision of this company with an web domain name of childcompany.com. The CEO wanted an SSL certificate for mail.childcompany.com which he got and asked to have installed. the problem is that if I install it then all connections internal to exchangeserver.parent.company.com will pop messages about the certificate not mathcing the different domain name. The external mail OWA settings will be great because mail.childcompany.com is working and providing the mail. However, what can I do about parent.company.com? A wildcard certificate will not help since the domain "exchangeserver" resides in is different than the one it provides OWA functionality on. Anyway to issue two SSL's to one server and have it use one for internal exchange connectivity via Outlook and one for external OWA connectivity?

Issue one SSL cert with Subject Alternative Names to cover all the different possible DNS names. Then modify/add the appropriate DNS records in both external and internal DNS to point at the OWA server for the FQDNs that match the names in the cert.

Ok Andy, I want to make sure I understand this correctly. A SAN certificate would allow me to change the domain name, not just the root or subdomain. So I could have exchange.dumbdomainname.com internal, and mail.companyname.com external? Thanks so much for the reply.

In a SAN cert, you can use as many domain names as you want. There is no restriction on whether they are part of the same root: if a name is in the cert, it's covered by the cert. So you'd use your new mail.childco.com name as the common name on the cert, since it would be public-facing, and then you'd put all relevant internal names in the cert as well. So you might have: mail.childcompany.com autodiscover.childcompany.com exchsrv1.parent.company.com exchsrv1 (the simple netbios name of the exchange server) That would cover the scenario that you are working with. Honestly, you haven't described anything particularly counter to best practices yet: tens of thousands of organizations out there have completely different internal domain names than external. The thing to note is that if their internal domain name ends with .com, the cert provider who creates the SAN cert for you is going to have to get permission for that cert creation from the owner of the root level domain. So in this case, they'd go to the admin contact for company.com and for childcompany.com before allowing the cert to be issued. Sometimes people use internal domain names that they don't actually own, and that screws things up because even though they want to include those names on the SAN cert for the reasons we've laid out here, they can't put that name on their cert since it's a public name and they don't own it. So there are some workarounds for that: bringing the external DNS namespace inside to some degree and having the Exchange environment always refer to itself by its external domain name, even internally.

You might want to consider using the external name for internal purposes by setting up a split-brain DNS.-- Ed Crowley MVP"There are seldom good technological solutions to behavioral problems.". "Wes Anderson" wrote in message news:4e88547f-92be-4702-9f0a-6d7a3b8536d0...Ok Andy, I want to make sure I understand this correctly.A SAN certificate would allow me to change the domain name, not just the root or subdomain.So I could have exchange.dumbdomainname.com internal, and mail.companyname.com external?Thanks so much for the reply. Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Thanks, then I did understand correctly. Now I just wish I had bought a single wildcard SAN cert for the various things I needed, which aren't that many.