Exchange SSL Offloading and the upcoming update blocking certificates with RSA key length less than 1024bit
Microsoft announced yesterday new approach regarding the validation of certificates coming in august this year. Certificates with a key length less than 1024bit will be blocked:
Adding to our defense-in-depth measures, in August, we will release a change to how Windows manages certificates that have RSA keys of less than 1024 bits in length. Once this key length update is released, we will treat all of these certificates as invalid, even if they are currently valid and signed by a trusted certificate authority. We’re announcing this now to allow folks time to make needed adjustments. Further information on this change can be found on the PKI blog.
As 512 bit key length are not regarded as safe anymore quite some time now, this is a good thing. However, there are instances when this key length is not a major issue.
Consider the following scenario:
You have an Exchange 2010 organization with at least two Client Access servers and you use a Client Access Array (CAS Array). A Network Load Balancer (LB) is the endpoint for the CAS Array IP and has been configured with SSL Offloading. However, company policy dictates that (when possible) no unencrypted transmission of data occurs. As the internal network already has some security in place, this does not have to be high-grade security.
Thus, the admin chooses to use SSL from the LB to the Exchange Client Access Servers (Reverse SLL/SSL Bridging). To limit the load on the servers, she or he chooses a 512 bit key length for the certificate used between Exchange and the LB. This TechNet Wiki article by Henrik Walther describes these configurations.
If I understand the articles regarding the change on certificate validation correctly, Reverse SSL/SSL Bridging with a 512 bit key length certificate on the Client Access servers will not work anymore when this update is installed on these servers. I haven’t implemented these scenarios, but I know the 512 bit key length option is described either by Microsoft or LB vendors (can’t find them though…).
To be clear, this is only an issue when using 512 bit key length certificates! Solution would be to use at least 1024 bit key length certificates or discontinue the use of Reverse SLL before august. If someone know other options, let me know!