If Autodiscovery is set in IIS and a single cert was present but an SSL CA cert has been added to exchange, does it need to be added in IIS as well?

Since installing a 3rd party cert to exchange and Intermediary cert to root, Outlook is asking for a password when trying to connect a new client to Exchange 2013. The password is set in AD and works on OWA but will not connect in Outlook. Does the cert or some other permissions need to be changed in IIS?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Bruno PACIIT ConsultantCommented:

Nothing as to be changed in IIS if it was working before wiht another certificate.

For a certificate to be accepted by clients, you must meet the following requirements :

1) The certificate of the issuer of the server certificate (in you case the certificate of the intermediary certification authority) must be trusted be the clients. To do that, you must ensure that client computers have the root authority and intermediray authority certificates in their "trusted root authorities" containers in the certificates console.
2) The name of the certificate must match exactly the hostname in the URL used by Outlook to access Exchange.
3) The server certificate must be valid.

Else, outlook fails to connect and asks for a password, but as the password is not the problem you'll still have the prompt after retyping the password.

As a simple test, from client computer open a web browser and go to the OWA url using the name in the certificate. To be more clear, if the certificate is issued for the host name myserver.mycompany.com then go to the URL https://myserver.mycompany.com/owa

If you have a certificate security alert then something is missing on the client computer to trust certificate.

Hope this helps.

Have a nice day.
NetoMeter ScreencastsCommented:
You don't have to configure anything in IIS. Normally, the new CSR (Certificate Signing Request) is generated in Exchange Admin center. When you download the new certificate, you make sure that the intermediate certs are in place and install the certificate again in Exchange Admin Center. Of course, if you love PowerShell, you can perform this in Exchange Management Shell.

In your case, you are dealing with a single domain certificate - for example "mail.yourdomain.com". And let's say that the internal Exchange 2013 FQDN is "exchange13.internaldomain.local". By default, the internal Exchange server URL use the internal Exchange server FQDN - "Exchange13.internaldomain.local" and that name is included in the self-signed certificate that's generated by Exchange 2013 setup. BTW, I hope you didn't delete this self-signed certificate as this might get you in a different problem.

You need to perform the following:
1. Configure Split-Brain DNS or PinPoint DNS zone (I recommend the second) for the name that is included in the certificate - "mail.yourdomain.com" on the internal DNS servers. If the PinPoint DNS zone is AD integrated, it will be propagated automatically to all internal DC/DNS servers.
2. Modify the Internal Virtual Directories URL - you might prefer to do this in EAC (Exchange Admin Center).
3. Modify the Autodiscover Internal URI in Exchange Management Shell - it cannot be modified in EAC, and has only Internal URI, that is modified with the Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri "https://mail.yourdomain.com/autodiscover/autodiscover.xml" (replace the domain name).

The internal Outlook clients are  using OutlookAnywhere as well, and they get the address from the SCP (Service Connection Point) which is stored in AD - that's how you change the SCP with Set-ClientAccessServer.

If you want to enable autodiscover for remote OutlookAnywhere clients, you need to delete the autodiscover CNAME record in the external/public DNS zone for "yourdomain.com" and configure an autodiscover SRV record.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
If you are having problems with all your users in your organization with this certificate you should check the name or names on it.

If you having this problem only with a new user on the organization, I will recommend you to start over the user profile and make sure the client is fully updated and the user information is entered in the format of DOMAIN\Username.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.