Jeremy Sherlock
asked on
What is the impact of removing internal Domain names (SAN) from a UCC Exchange Certificate?
Hello
We currently use a private internal active directory domain of .group and our external domain is .co.uk . As part of our Exchange infrastructure we used a Subject Alternative Name (SAN) certificate issued by GoDaddy, prior to changes in the use of non-verifiable SAN's, that secures access to the Exchange server. We've just received a certificate revocation warning from GoDaddy for this certificate as the .group extension has been registered as a gTLD and we now need to prove our right to use that domain. Unfortunatley .group domain's are not currently available to purchase so we need to lose the .group SANs from our certificate.
My knowledge of certificate services is quite basic and I need to understand what the impact of dropping the internal domain, .group, will be on our email infrastructure. I know I need to generate a new CSR on the Exchange server and re-key my existing certificate, then import the certificate into Exchange and activate it. However I'm concerned about the following....
1. Internal access to Exchange services via OWA and OUTLOOK will generate certificate errors when a user connects.
3. Is it possible to have a second self-certified certificate for internal connections to the mail server?
I trust I've made myself clear and that my questions make sense.
Many thanks for your assistance
Blessings
Jez
We currently use a private internal active directory domain of .group and our external domain is .co.uk . As part of our Exchange infrastructure we used a Subject Alternative Name (SAN) certificate issued by GoDaddy, prior to changes in the use of non-verifiable SAN's, that secures access to the Exchange server. We've just received a certificate revocation warning from GoDaddy for this certificate as the .group extension has been registered as a gTLD and we now need to prove our right to use that domain. Unfortunatley .group domain's are not currently available to purchase so we need to lose the .group SANs from our certificate.
My knowledge of certificate services is quite basic and I need to understand what the impact of dropping the internal domain, .group, will be on our email infrastructure. I know I need to generate a new CSR on the Exchange server and re-key my existing certificate, then import the certificate into Exchange and activate it. However I'm concerned about the following....
1. Internal access to Exchange services via OWA and OUTLOOK will generate certificate errors when a user connects.
a. Is it possible to avoid these certificate errors?
b. Will OUTLOOK refuse to connect to the server because of the errors or is it possible to continue past the errors?
2. Will it break the internal autodiscover process for setting up email?b. Will OUTLOOK refuse to connect to the server because of the errors or is it possible to continue past the errors?
3. Is it possible to have a second self-certified certificate for internal connections to the mail server?
I trust I've made myself clear and that my questions make sense.
Many thanks for your assistance
Blessings
Jez
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi Jeremy,
I do not know the workaround for autodiscover, and unless something has changed in Active Directory for Server 2012/Echange 2013, then you are limited by the Activer Directory local domain you use.
When we setup our UCC certificate for Exchange (2010) we were aware of all the localized domains 'going away'.
We did nothing to our Active Directory, *but* we set Microsoft's DNS server up in such a way that people internal to our network (Using Microsoft's DNS server were using external FQDS and internal IP addreses for our mail environment).
We created a zone that matched our external DNS on our internal servers, and setup something like the examples in my aforementioned comment.
The name for this DNS configuration is typically called 'split DNS'.
This is possibly the 'cleanest' explanation of this concept I have found, and a basic 'how to'.
http://www.petenetlive.com/KB/Article/0000830.htm
Here's a short project list I would use before scheduling maintenance for this.
** Call Godaddy if you need assistance, they are VERY helpful and have fielded many calls about these UCC certs.
1. Read and understand what split DNS is, and how to implement it.
2. Collect all your existing DNS records for your external domain (domain.co.uk)
3. Find the internal IPs of all those DNS records.
4. Notify your mail users of the upcoming change and schedule a maintenance window.
5. Make any necessary configuration backups
6. Implement domain forwarders
7. Build out out your internal (presumably Microsoft) DNS to reflect the split DNS scenario.
8. Test connectivity
9. Once all tests prove correct, change and re-issue your UCC certificate.
10. Test connectivity
11. Once all tests complete, close maintenance window, and notify users.
Also...for the certificates, the digicert SSL tool is fantastic. It reduces some of the learning curve for cert deployment, and is system agnostic.
https://www.digicert.com/util/
Hope this helps.
Bri...
Brian Holcomb
I do not know the workaround for autodiscover, and unless something has changed in Active Directory for Server 2012/Echange 2013, then you are limited by the Activer Directory local domain you use.
When we setup our UCC certificate for Exchange (2010) we were aware of all the localized domains 'going away'.
We did nothing to our Active Directory, *but* we set Microsoft's DNS server up in such a way that people internal to our network (Using Microsoft's DNS server were using external FQDS and internal IP addreses for our mail environment).
We created a zone that matched our external DNS on our internal servers, and setup something like the examples in my aforementioned comment.
The name for this DNS configuration is typically called 'split DNS'.
This is possibly the 'cleanest' explanation of this concept I have found, and a basic 'how to'.
http://www.petenetlive.com/KB/Article/0000830.htm
Here's a short project list I would use before scheduling maintenance for this.
** Call Godaddy if you need assistance, they are VERY helpful and have fielded many calls about these UCC certs.
1. Read and understand what split DNS is, and how to implement it.
2. Collect all your existing DNS records for your external domain (domain.co.uk)
3. Find the internal IPs of all those DNS records.
4. Notify your mail users of the upcoming change and schedule a maintenance window.
5. Make any necessary configuration backups
6. Implement domain forwarders
7. Build out out your internal (presumably Microsoft) DNS to reflect the split DNS scenario.
8. Test connectivity
9. Once all tests prove correct, change and re-issue your UCC certificate.
10. Test connectivity
11. Once all tests complete, close maintenance window, and notify users.
Also...for the certificates, the digicert SSL tool is fantastic. It reduces some of the learning curve for cert deployment, and is system agnostic.
https://www.digicert.com/util/
Hope this helps.
Bri...
Brian Holcomb
ASKER
Hi Brian
I read up on DNS (again), which didn't really help much :), and then followed the instructions from PeteNetLive to create an internal DNS zone for our external address. Fortunately our external DNS entries only number 19 so I followed option 2 and completely mapped the external zone on the internal zone. This includes our external autodiscover address. I created the A records for all the external records repointing as necessary the host names to internal IP's. Whilst I haven't changed the certificate yet it all seems to be working, including Autodiscover - although I've not tried this externally yet.
The next step is to re-key and install the certificate, but that's a job for Thursday. Thanks for all your help so far, I will comment here on the certificate install and if it is all working as hoped/expected.
Blessings
Jez
I read up on DNS (again), which didn't really help much :), and then followed the instructions from PeteNetLive to create an internal DNS zone for our external address. Fortunately our external DNS entries only number 19 so I followed option 2 and completely mapped the external zone on the internal zone. This includes our external autodiscover address. I created the A records for all the external records repointing as necessary the host names to internal IP's. Whilst I haven't changed the certificate yet it all seems to be working, including Autodiscover - although I've not tried this externally yet.
The next step is to re-key and install the certificate, but that's a job for Thursday. Thanks for all your help so far, I will comment here on the certificate install and if it is all working as hoped/expected.
Blessings
Jez
ASKER
Hi,
Well sadly it didn't work and I've realised I missed what I might be an important factor. Our external MX records point to the Mimecast smarthost whereas Outlook connects directly to the server itself. However whilst I've created the internal split DNS zone such that it mirrors the external zone when we set up Outlook it defaults to the internal name of the server regardless of whether we use autodiscover or set it up manually. Clearly Outlook is picking up the internal name from somewhere I don't know where that setting is or even if it can be changed.
Currenly outlook internally is working staff are just getting the irritating warning message saying the certificate name is different from the server they are conneting too.
Will keep looking into the issue.
Blessings
Jez
Well sadly it didn't work and I've realised I missed what I might be an important factor. Our external MX records point to the Mimecast smarthost whereas Outlook connects directly to the server itself. However whilst I've created the internal split DNS zone such that it mirrors the external zone when we set up Outlook it defaults to the internal name of the server regardless of whether we use autodiscover or set it up manually. Clearly Outlook is picking up the internal name from somewhere I don't know where that setting is or even if it can be changed.
Currenly outlook internally is working staff are just getting the irritating warning message saying the certificate name is different from the server they are conneting too.
Will keep looking into the issue.
Blessings
Jez
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi Jez,
Sorry for the late response.
I am glad you have made progress on this monster project!
I am super excited about the info you pulled up about autodiscover as well. Looks like I have some reading to do!
As for the client, there *should* be no impact unless the connection address has changed.
Please let me know how you fare.
Thanks!
Brian Holcomb
Sorry for the late response.
I am glad you have made progress on this monster project!
I am super excited about the info you pulled up about autodiscover as well. Looks like I have some reading to do!
As for the client, there *should* be no impact unless the connection address has changed.
Please let me know how you fare.
Thanks!
Brian Holcomb
ASKER
Hi Brian,
Betweem your suggestions for the split DNS and changing the internal URL everything has worked perfectly. You were correct there was no impact on the client the certificate errors simply stopped working. Everything is currently working as intended so I'm appreciative of your time and suggestions.
Blessings
Jez
Betweem your suggestions for the split DNS and changing the internal URL everything has worked perfectly. You were correct there was no impact on the client the certificate errors simply stopped working. Everything is currently working as intended so I'm appreciative of your time and suggestions.
Blessings
Jez
Awesome Jeremy,
I am glad it worked out and the job is done.
...and thank YOU for sending the autodiscover information, it very well might solve my issues,
Cheers!
Bri...
Brian Holcomb
I am glad it worked out and the job is done.
...and thank YOU for sending the autodiscover information, it very well might solve my issues,
Cheers!
Bri...
Brian Holcomb
ASKER
The expert solution indicated a significant part of the fix and pointed me in the right direction to find the reminder of the solution. My own comment includes the remainder of the solution. Between the two a full solution was found.
ASKER
Thanks for your answer, however I'm puzzled as to how to set up the DNS records. I'm assuming I will need to create another DNS zone as our current Active Directory Integrated DNS zone will authomatically try to add the .group extention to any A host or MX record that we create? My knowledge of DNS is not particularly great either but I'll look into another DNS zone.
Cheers
Jez