cvadmin
asked on
Exchange 2007 SSL Certificate DNS issue
Good day,
I work for a managed service provider, and we have inherited a client in a unique situation with their exchange SSL certificate we could really use some advice on. The situation is as follows:
Client has Exchange 2007 running on Windows Server 2k3 x64 on an active directory domain. Outlook anywhere is configured.
When the client's domain was setup by their old IT provider setupa whole-brain DNS configuration. Meaning, the external domain name registration and DNS is the same as their internal active directory DNS domain and AD integrated zone. Lets jsut call this clientdomain.com
The old IT company registered/issued and applied an SSL certificate to exchange for clientdomain.com . Of course OWA and Outlook anywhere used this certificate, life was peachy.
The client and the old IT company very poorly managed external DNS registrations. Lets just say they had over 30 domains (for a small org), spread accross roughly 3-5 different registrars and such. Well during this period of time clientdomain.com was so poorly managed no one was notified of it expiring, it expired. The domain clientdomain.com was then registered by another 3rd party and is now a camping website (like actual outdoors camping website, not "camped" by a domain squatter or anything).
The old IT company's solution to this problem was to simply register a new domain. Lets call this new domain cldm.ca . So the old IT company directed all things external using this new domain life went on. That old IT company got punted by the client, this is where the company I work for steps in.
Turns out the old SSL certificate for clientdomain.com was still applied to exchange, and in use for OWA, Exchange anywhere etc. This certificate remained valid AFTER the client lost registration to clientdomain.com as the certificate was configured to expire 1-2 years after their domain was lost to a 3rd party. Well the certificate expired afew weeks back.
So the clients gets promted to contnue untrusted in OWA, outlook anywhere is broken, and everyone on the internal domain using outlook gets non stop certificate prompts.
Unfortuantly, since the DNS is whole-brain, and internally AD exchange, essentially everything still uses clientdomain.com , and we don't own clientdomain.com anymore, an external SSL certiciate cannot be generated with clientdomain.com in the name by a trusted CA authority. Puts us in a tight spot.
The interim solution, we have generated a self-signed certificate for clientdomain.com , applied this to Exchange/IIS. Internal outlook clients no longer prompt with certificate issues, unfortuantly externally the certificate is not trusted do OWA has a warning before the logon screen, and outlook anywhere used externally is riddled with certificate prompts that cant be rid of.
We have registered a certificate for their new domain cldm.ca , sure it gets rid of the OWA prompt, but internally outlook cert prompts come back since they are using clientdomain.com, and still does not fix outlook anywhere. We've left this client running as described in the above paragraph.
So as far as solutions go, thing's considered:
-Contact the new admin of clientdomain.com, see if they can generate an SSL cert for us, or buyout the domain. This is NOT an option. This will not be explored.
-The other option is to change their internal active directory dns integrated zone from clientdomain.com to cldm.ca. So changing their forest root domain... then somehow changing exchange to also use cldm.ca. Then as far as certificates go, use cldm.ca. This is where things are unclear on the how-to side, and we are not entirly sure how to go about this properly, if such a thing should be done at all. We are looking for a complete, and quickest fix as possible.
So my question. With the scenario described, what would be the best course of action to fix this? what things should be considered.
(Keep in mind as far as external registrations go clientdomain.com is out of the picture. We only have cldm.ca to work with.)
Thanks for sticking with this TL;DR question.
I work for a managed service provider, and we have inherited a client in a unique situation with their exchange SSL certificate we could really use some advice on. The situation is as follows:
Client has Exchange 2007 running on Windows Server 2k3 x64 on an active directory domain. Outlook anywhere is configured.
When the client's domain was setup by their old IT provider setupa whole-brain DNS configuration. Meaning, the external domain name registration and DNS is the same as their internal active directory DNS domain and AD integrated zone. Lets jsut call this clientdomain.com
The old IT company registered/issued and applied an SSL certificate to exchange for clientdomain.com . Of course OWA and Outlook anywhere used this certificate, life was peachy.
The client and the old IT company very poorly managed external DNS registrations. Lets just say they had over 30 domains (for a small org), spread accross roughly 3-5 different registrars and such. Well during this period of time clientdomain.com was so poorly managed no one was notified of it expiring, it expired. The domain clientdomain.com was then registered by another 3rd party and is now a camping website (like actual outdoors camping website, not "camped" by a domain squatter or anything).
The old IT company's solution to this problem was to simply register a new domain. Lets call this new domain cldm.ca . So the old IT company directed all things external using this new domain life went on. That old IT company got punted by the client, this is where the company I work for steps in.
Turns out the old SSL certificate for clientdomain.com was still applied to exchange, and in use for OWA, Exchange anywhere etc. This certificate remained valid AFTER the client lost registration to clientdomain.com as the certificate was configured to expire 1-2 years after their domain was lost to a 3rd party. Well the certificate expired afew weeks back.
So the clients gets promted to contnue untrusted in OWA, outlook anywhere is broken, and everyone on the internal domain using outlook gets non stop certificate prompts.
Unfortuantly, since the DNS is whole-brain, and internally AD exchange, essentially everything still uses clientdomain.com , and we don't own clientdomain.com anymore, an external SSL certiciate cannot be generated with clientdomain.com in the name by a trusted CA authority. Puts us in a tight spot.
The interim solution, we have generated a self-signed certificate for clientdomain.com , applied this to Exchange/IIS. Internal outlook clients no longer prompt with certificate issues, unfortuantly externally the certificate is not trusted do OWA has a warning before the logon screen, and outlook anywhere used externally is riddled with certificate prompts that cant be rid of.
We have registered a certificate for their new domain cldm.ca , sure it gets rid of the OWA prompt, but internally outlook cert prompts come back since they are using clientdomain.com, and still does not fix outlook anywhere. We've left this client running as described in the above paragraph.
So as far as solutions go, thing's considered:
-Contact the new admin of clientdomain.com, see if they can generate an SSL cert for us, or buyout the domain. This is NOT an option. This will not be explored.
-The other option is to change their internal active directory dns integrated zone from clientdomain.com to cldm.ca. So changing their forest root domain... then somehow changing exchange to also use cldm.ca. Then as far as certificates go, use cldm.ca. This is where things are unclear on the how-to side, and we are not entirly sure how to go about this properly, if such a thing should be done at all. We are looking for a complete, and quickest fix as possible.
So my question. With the scenario described, what would be the best course of action to fix this? what things should be considered.
(Keep in mind as far as external registrations go clientdomain.com is out of the picture. We only have cldm.ca to work with.)
Thanks for sticking with this TL;DR question.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Just wanted to confirm this was the case.