This article is an excerpt from the Exchange Server 2003 to 2010 Migration Guide.
When Exchange Server 2010 is first installed many administrators encounter an issue with Outlook clients and SSL certificate warnings, relating to the Autodiscover service and the use of SSL for Exchange Server 2010 by default.
Autodiscover is a service that allows compatible Outlook versions and mobile devices to automatically detect and configure a user’s mailbox settings. When the Exchange Server 2010 Client Access server role is installed into an Exchange organization it automatically registers the Autodiscover service in Active Directory.
Outlook clients will connect to Autodiscover using SSL (HTTPS), but the new Exchange 2010 Client Access server is only configured with a self-signed SSL certificate when it is first installed. This can lead to certificate warnings for your end users who are running Outlook 2007 or Outlook 2010.
So you may wish to install the first Exchange 2010 server outside of business hours, so that you have time to resolve the SSL certificate warnings without impacting your end users.
There are three ways to quickly resolve the Outlook SSL certificate warnings in Exchange 2010 environments:
- Adding the Exchange Server certificate to the Trusted Root Certification Authorities on all of your end user computers using a Group Policy (not recommended)
- Issuing a new Exchange 2010 SSL certificate from a private Certificate Authority on your network (not ideal, but resolves the issue for computers that are domain members)
- Purchasing a new Exchange 2010 SSL certificate from a commercial Certificate Authority and installing it on the Exchange 2010 server (this is the best solution, but will of course require you to spend money)
You have to generate the request from the new Exchange 2010 server before you can get the certificate, right?
Just trying to plan this in the most efficient way since it will be working with a customer after hours to do this..
Is it:
1. Install Exchange 2010
2. Generate Cert Request
3. Buy cert via godaddy or similar
4. Install cert and enabled
?
Thanks
The Real Person!
The Real Person!
I’ve seen people do it using just the IIS method and a few other little tricks. I always just set the AutodiscoverInternalServiceURI for the server to $null or to an existing Autodiscover namespace for that site (that resolves to other CAS) then you have as much time as you need to generate the cert request and acquire the cert.
So install 2010 after hours.. Set the AutodiscoverInternalServiceURI to $null and then there won’t be the issue with the clients getting the error?
The Real Person!
The Real Person!
Yeah that generally works well.
After we applied from internal exchange servers ssl to Wildcard certificate for the Autodiscover in exchange 2013, lots users having certificate pop ups with internal SSl certifcate. Therefore , we are recreating the Outlook profile to solve the issue. How can i Automate this?
Thanks
In E2K3-E2K10 Coexistence environment, If I configure the certificate on E2K10 CAS Servers with the SAN names Outlook 2007 or Later is looking for, Client will connect to E2K10 for autodiscover and will get OAB and OOF Url from E2K10, Right? But if I have not moved the E2K3 OAB to E2K10 Servers yet. Then wouldn’t it create more problem in the current E2K3 Production environment?
The Real Person!
The Real Person!
The OAB URL will only come into play if the OAB has been moved to Exchange 2010 and enabled for web-distribution. Move the OAB generation server after you’ve moved all the mailboxes.
Pingback: Exchange 2010 to 2013 Migration - Reviewing Autodiscover Configuration
I have an Exchange 2003 environment that I need to migrate to 2010.. I’ve done this to 3 other environments.. This time I decided to purchase your guide for reference..
For the other 3 migrations I have done I have never purchased and installed the cert right off the bat and have never had these issues.. Reading this warning makes me nervous though…
Any ideas why I would have no issues on the other 3 migrations when your guide says it can happen? I’ve done them all during business hours and they’ve all had Outlook 07/10.
Thanks!!
The Real Person!
The Real Person!
I’ve never really nailed down the exact conditions where it will occur, only that it happened almost every time I deployed into an Exchange 2003 org.
Paul, do you always check the box “The Client Access server role will be internet-facing.” during your installs? I’m just wondering if that’s what causes the warning..
I’d really like to know exactly what causes this.
Thanks mate!
The Real Person!
The Real Person!
I tick that box on any internet-facing server. As far as I know all that does is pre-configure the external URLs for you.
Hi Paul, You post is very very helpful But can we use the same certificate that we used for Activesync (this is a paid ssl certificate)
If yes, how can I do this?
The Real Person!
The Real Person!
You can use any certificate that meets the requirements of Exchange 2010:
https://www.practical365.com/exchange-2010-ssl-certificates
we seem to have an interesting issue. Everything was working fine then we had a random SSL cert pointing to our company.com website from our webhost provider. it expired and now our outlook it getting the popup for ourwebsite.com for a ssl cert error.
What doesnt make sense is we have a valid SSL cert in exchange 2010 that has the 5 entries needed and it shows ourwebsite.com and mail.ourwebsite.com I dont see anywhere referring to that expired SSL cert we never used.
The Real Person!
The Real Person!
Keep in mind that it is DNS that controls where (ie the IP address) a client will connect for a given name, not the SSL certificate.
So if your clients are trying to connect to company.com, and DNS resolves that to your webhost provider, and it has an SSL certificate that is failing validation, then that may be what you’re seeing.
that is exactly what is happening. Is there a way for me to resolve that? I know the simple solution is to just buy a cert for the website.com since thats where DNS points to. But that is a external provider as we do not host it inside. And since we already have the website.com on the exchange cert i would hate to pay twice for the same thing.
The Real Person!
The Real Person!
Yes, the solution is to buy a cert for the website.
Paul,
Great post as always! Thanks for sharing your wonderful Exchange knowledge with the rest of the community
I’m planning to introduce the first Exchange 2010 server to my Exch 2007 Organization this week. I’m planning on the SSL cert and I was wondering if I could get your feedback or anyone’s feedback in your forum.
1. As you explained in this post, we may expect SSL certificate warnings, relating to the Autodiscover service. In order to avoid that, I was planning to purchase a new UCC (SAN) cert from our commercial Certificate Authority prior the introduction of the first Exch 2010 CAS server. I know I can generate the SSL request file from the new Exchange 2010 CAS server once it is setup; however after talking to the commercial Certificate Authority, I realized that the new SAN certificate could take up to 3 days to get issued (it could be faster but I’m not sure). I cannot afford to get these SSL certificate warnings for so long so I was wondering if I could generate the request from the current Exchange 2007 CAS server instead. Would that be any problem? If not, I could generate the new SAN certificate request from the Exchange 2007 CAS server, once I get the cert, then import it to Exchange 2007 (I already have SSL on the Exch 2007 server but need to add legacy.domain.com to it.). Then export the SAN cert from Exch 2007 (which will have the names I also need for the new Exch 2010 server) and have it ready so I can import the cert to the Exch 2010 as soon as it is up and running. Would that work ok?
2. Another aspect in regards to SSL certs is around the names to be included in the cert. I have read and seen on slides shown in Microsoft webcasts that machine hostnames should not be listed in the certs hostname list as the goal is to minimize the number of hostnames. However in your “Exchange Server 2007 to 2010 Migration Guide” (by the way a wonderful guide), I can see you include host server names in the SSL Certificate names in the SSL certificate planning section; which makes sense to me. As you well explained here: https://www.practical365.com/exchange-2010-faq-autodiscover-names-ssl-certificate
“So for an internal, domain-joined computer, the SSL certificate must include the name (or names, if more than one exists) for the Client Access servers in the organization that a client will be discovering via that SCP lookup. Externally connected clients are different, because they can’t look up the SCP in Active Directory from outside of the network.”
I guess that what is not clearly explained is the fact that if your Organization is implementing Split DNS (having an internal DNS zone that matches your external internet DNS), then you can also use the external DNS namespace (i.e mail.domain.com) to configure the internalURLs and therefore there is no need to include host server names in the SSL Certificate names. So bottom line, the Internal URLs will depend on whether or not you use Split DNS for the Exchange 2010 implementation and that in turn will determine whether or not it is necessary to include host server names in the SSL Certificate
Am I understanding this correctly?
Thanks in advance!
FT
FT, we are going to be running into the same issue. What did you guys end up doing?
I ended up generating the new SAN certificate request from the Exchange 2007 CAS server. I was able to obtain the cert within minutes of my request. Once I got the cert, then imported it and enabled it in Exchange 2007. (After importing and enabling the new UCC cert in AC-HTCAS, I had to go to IIS and manually replace the old cert with the new one using the ISS wizard interface )
NOTE: since I already had a SAN cert on the Exch 2007 server, I did not have to install the Intermediate certificate that is sent with the SAN cert. the Intermediate certificate must be installed on the Exch 2010 servers though
Then Export the UCC SSL from Exchange 2007 so you can later import into each of the existing Exchange 2007 servers and Exchange 2010 Servers. I exported the UCC into a .pfx file.
1. Install Exchange First 2010 HUB/CAS server
2. Import new UCC SSL cert into Exch 2010 using the new Import Certificate feature within the EMC. Alternatively you can also do it via EMS
3. Test Cert: http://www.digicert.com/help/
everything went well on my end (thanks God!)
Thank you for the feedback. This really helps.
I have installed CAS servers and users are gettings these ssl errors. I am using wildcard from digicert. Still getting the warning even though I have used SAN names on wildcard cert too, and AutoDiscover internaluri matches one name on the cert.
Anyone have any ideas on how to fix this issue?
The Real Person!
The Real Person!
An SSL certificate must:
– match the name of the site being connected to (either as a single-name cert, SAN cert, or wildcard)
– be from a trusted certificate authority
– be still valid, ie not expired
To help you any further I’d need to know exactly which of those three your certificate warning is telling you is wrong. You should also verify that you’ve not only installed the certificate but that you’ve also *enabled* it for Exchange usage.
I am going to migrate single Exchange 2010 server to High Availability 2010 Exchange. First I wiil establish two-node CAS array using new servers. If I install two new CAS Exchange 2010 will I get Autodiscover and SSL Warnings.
The Real Person!
The Real Person!
Possibly yes. I recommend planning to use one of the three solutions mentioned at the end of the article.
I think the above warning will be appearing if we are not properly configuring the internal and external urls of the autodiscover and availabilty service on the CAS server after a trusted thrid party cerificate like verisign or digicert etc applied.
I think the above warning will be appearing if we are not properly configuring the internal and external urls of the autodiscover and availabilty service on the CAS server after a trusted thrid party cerificate like verisign or digicert etc.
The Real Person!
The Real Person!
Yes, you will also see warnings if your internal/external URLs don’t match the names on the certificate.