OWA and ECP doesn't log in after Renewing Certificate

I had an issue on an Exchange 2013 cluster renewing a certificate on the Client Access servers.  The current certificate was about to expire and the customer provided me with a newly created wildcard GoDaddy certificate in the form of a PFX.

Symptoms

I imported the certificate in into the Computer Certificate Store on all Exchange Servers in the cluster then enabled the certificate with the Enable-ExchangeCertificate.  I also updated the Load Balancers performing SSL Bridging with the new certificate.

After performing these changes the following services worked correctly:

• Exchange ActiveSync
• MAPI over HTTPS
• RPC over HTTPS
• OAB Distribution
• Exchange Web Services

The following services with Forms Based Authentication no longer worked OWA and ECP.  Apparently if these services were setup with Basic Authentication, they would function fine but I did not try this.

When attempting to access the OWA or ECP websites with forms based authentication, after entering your username and password we were being redirected back to the forms based login page in an infinite loop without any error message.

Issue

Exchange requires a certificate that’s created with the "Microsoft RSA SChannel Cryptographic Provider" otherwise OWA and ECP do not login and return back to the default login page in a loop.  This occurs when OWA and ECP are setup to use forms based authentication.

The certificate PFX provided to me by the customer was setup with the "Microsoft Software Key Storage Provider" instead of the "Microsoft RSA SChannel Cryptographic Provider".

To check the provider of an installed certificate use the following command:

certutil -store my CERTTHUMBPRINT

On my customers Exchange Server, the Provider looked like this:

The certificate provider should look like this:

To get the Thumbprint you can use the Get-ExchangeCertificate PowerShell cmdlet.

Resolution

Microsoft has published a technical writeup of this known issue called "The One with the FBA Redirect Loop" which is available here:

https://blogs.technet.microsoft.com/jasonsla/2015/01/15/the-one-with-the-fba-redirect-loop/

The resolution they have for this issue is as follows:

1. Backup your existing certificate, including the private key.  For more information on how to do this, please reference the Export-ExchangeCertificate cmdlet.
2. Note which services are bound to the certificate currently using Get-ExchangeCertificate.
3. Delete the certificate and private key.  If you use Remove-ExchangeCertificate, you'll need to temporarily assign a different certificate to the bound services first.  If you just use PowerShell or MMC you'll need to reboot the server afterwards as bound services cache the certificate.
4. Import the new certificate into a CSP using certutil (pfx/p12):
   certutil -csp "Microsoft RSA SChannel Cryptographic Provider" -importpfx
5. Ensure the certificate is still bound to the same services using Get-ExchangeCertificate, and if not, re-set them using Enable-ExchangeCertificate.
6. Restart the server (see step 3).

For my customer we ended up creating a new dedicated certificate for the Exchange cluster using the New-ExchangeCertificate cmdlet to generate a new CSR.