AA-in-CA
asked on
Resolving Exchange 2013 FBA logon page "loop"
My customer is affected by the Forms-based authentication problem described in this TechNet blog article:
https://blogs.technet.microsoft.com/jasonsla/2015/01/15/the-one-with-the-fba-redirect-loop/
Specifically, installing a new SHA-2 based certificate causes OWA and ECP logins to 'loop' back to the login prompt even when correct credentials are supplied. The customer is running a single instance of Exchange 2013 CU 10 (build 15.0.1130.7).
I confirmed we're affected by the issue described because running certutil -store my [certificateSerialNumber] against the new cert receives a reply of "Provider = Microsoft Software Key Storage Provider", when in fact what Exchange supports is "Provider = Microsoft RSA SChannel Cryptographic Provider". In other words, it's a KSP-based certificate, and apparently Exchange 2013 FBA expects CSP-based ones.
Here's what doesn't make sense. We use an SSL certificate supplied by a third party CA (NameCheap/Comodo). That being the case:
1) Does his solution require us to go back to our third party provider, and get a reissued certificate? If so, what do I ask for?
2) Or can I use certutil as he describes, to "import the certificate into a CSP"? In other words, does running certutil -csp "Microsoft RSA SChannel Cryptographic Provider" -importpfx <CertificateFilename> work if you're NOT running your own in-house CA, and using a third party provider like Namecheap/Comodo/GoDaddy?
3) Will that command work against .cer files, or do they need to be in another format?
4) Is there a simpler solution to this, e.g. installing the latest cumulative update, which is CU 14? Or does Exchange 2013 FBA still not support KSP certificates?
https://blogs.technet.microsoft.com/jasonsla/2015/01/15/the-one-with-the-fba-redirect-loop/
Specifically, installing a new SHA-2 based certificate causes OWA and ECP logins to 'loop' back to the login prompt even when correct credentials are supplied. The customer is running a single instance of Exchange 2013 CU 10 (build 15.0.1130.7).
I confirmed we're affected by the issue described because running certutil -store my [certificateSerialNumber] against the new cert receives a reply of "Provider = Microsoft Software Key Storage Provider", when in fact what Exchange supports is "Provider = Microsoft RSA SChannel Cryptographic Provider". In other words, it's a KSP-based certificate, and apparently Exchange 2013 FBA expects CSP-based ones.
Here's what doesn't make sense. We use an SSL certificate supplied by a third party CA (NameCheap/Comodo). That being the case:
1) Does his solution require us to go back to our third party provider, and get a reissued certificate? If so, what do I ask for?
2) Or can I use certutil as he describes, to "import the certificate into a CSP"? In other words, does running certutil -csp "Microsoft RSA SChannel Cryptographic Provider" -importpfx <CertificateFilename> work if you're NOT running your own in-house CA, and using a third party provider like Namecheap/Comodo/GoDaddy?
3) Will that command work against .cer files, or do they need to be in another format?
4) Is there a simpler solution to this, e.g. installing the latest cumulative update, which is CU 14? Or does Exchange 2013 FBA still not support KSP certificates?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.