Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 332
  • Last Modified:

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?
2 Solutions
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.
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.

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now