When using internal certificates for Exchange 2013, nowadays it’s common for customers to request SHA256 certificates as SHA1 might soon be vulnerable to brute-force attacks, given the ever
increasing compute power that is available. SHA256 is the same as SHA2, by the way. To read Microsoft’s opinion about SHA1
deprecation, see here.
Creating a SHA256 certificate for Exchange is fairly simple, as
explained here. When your certificate is ready, you assign it to all
services and reboot.
Now all of this may seem to work until you try to open the ECP or OWA. The login page opens up just fine but whatever credentials you enter, you only end up again where you started. Frustrating!
So what is wrong? No, you ECP virtual directory does not need to be recreated (as explained here). All Exchange services are running, the Event Log looks OK, and mail flow isn’t impacted. Recycling
application pools, running iisreset, or even rebooting the server does not help. And ECP and OWA authentication should not be touched unless you have very good reasons to do so. What then?
It turns out that Exchange 2013 isn’t compatible with SHA256
certificates as they are signed with the Microsoft Software Key Storage Provider. Instead, only the Microsoft RSA SChannel
Cryptographic Provider is supported – but that is not an option while creating your SHA256 certificate.
To verify this, run certutil -store my in a command prompt:
================ Certificate 0 ================
Serial Number: 1D000000173f9d608d46c15e18000100000047
Issuer: CN=CA, DC=domain, DC=local
NotBefore: 14/12/2015 13:46
NotAfter: 14/12/2017 13:56
Template: ExchangeWebServer, Exchange Web Server
Cert Hash(sha1): d2 fe e6 3f 23 87 74 d0 6b f6 b9 df b4 ee e4 63 12 5a a1 71
Key Container = ld-ExchangeWebServer-b994773e-2f19-4d8f-ac58-ae168bd8d4f2
Unique container name: b71b68251ae6117453ece6978affadcd_0caf5f43-47b0-49ad-b241-ce4a91571345
Provider = Microsoft Software Key Storage Provider
Encryption test passed
If it sais “Provider = Microsoft Software Key Storage Provider” for your Exchange certificate, you have a problem.
So what are your options here?
- Follow best practices and use a public certificate instead. While creating your certificate request, follow the SHA1 route. Then, when sending the request to the public CA, clearly indicate on their webpage you need a SHA256 certificate instead, even if your .req file sais you want an SHA1 one. When you receive the certificate, assign it using Enable-ExchangeCertificate
-ThumbPrint “…” -Services “IIS,IMAP,POP,SMTP” and reboot your server.
- If you want an internal certificate, this would mean that security is less of an issue. This may be a test setup, or perhaps the SSL tunnel ends at the load balancer? Anyway, an SHA1 certificate would do just fine.