Exchange 2007 Certificate with Split DNS
I requested a UCC certificate from goDaddy listing domain names that include both our outward facing domain and our internal inward facing domain. We never registered the internal domain as it was just for inside our network.
GoDaddy is checking the ownership of both domains. They won’t issue the certificate with the inward domain names as we don’t own it. Will Exchange 2007 work when protected by a certificate that only lists our outside domain? We have what I believe is called Split DNS and actually have both domain names listed in our Forward and Reverse Lookup Zones.
Maybe I should keep the default certificate that Exchange 2007 automatically creates and only use the GoDaddy certificate for OWA, Autodiscover & ActiveSync? Would the new certificate request work for them? That would change our certificate request from:
cn=mobile.external.org, -DomainName autodiscover.external.org, castor.external.org, castor.internal.gov, autodiscover.internal.gov
to:
cn=mobile.external.org, -DomainName autodiscover.external.org, castor.external.org, castor
Castor=our Exchange 2007 Server
Software/Hardware used:
Software/Hardware used:
ASKED:
April 27, 2009 3:29 PM
UPDATED:
April 27, 2009 6:38 PM
RELATED QUESTIONS
Answer Wiki:
Either certificate will work - however, the issue is that the user will get a notification message when they go to the page referred to by the "untrusted" name. So, if the GoDaddy cert is used and the user visits the internal.gov address, they will get prompted that the certificate is bad. The traffic will still be encrypted between client and server. It's a matter of the user understanding the implication of clicking through the certificate error message.
To see all answers submitted to the Answer Wiki: View Answer History.
So, is there any point to buy a certificate from a trusted authority rather than creating one internally?
Yes – to take away the issue of TRUST that accepting a “bad” certificate error will create. If you train your users to always accept this certificate trusting that the destination server is who it says it is, what is there to say they won’t accept a certificate from a spoofed or phishing site that steals their credentials or identity? I know some say that best practice is to have a .local domain inside and another domain outside of the firewall, but this does complicate matters when looking at things like this certificate issue. Check out my blog posting Certificates – who do YOU trust?
In the IT trenches? So am I – read my IT-Trenches blog