There was an interesting case that was brought to my attention just the other day: a SAN SSL certificate for the Exchange environment has been replaced and properly installed on all Internet-facing Client Access Servers, reverse proxy servers, and load balancers. The SAN certificate contained all the required subject names for autodiscover, OWA and EWS to work without a hitch. All initial tests did not reveal any problems with the certificate replacement. It was a day or two later when some users started complaining about the error that popped up on their mobile devices about certificate not being fully trusted, when they tried accessing Webmail/ECP from a mobile device. The problem affected iOS and Android users alike, but only certain browsers on those platforms were complaining (e.g. Chrome for iPhone worked fine (i.e. trusted the new cert), but Safari for iPhone did not). Also, the issue was only affecting clients that connect from internal network (clients connecting from the Internet were not affected). I’ve narrowed it down to the load balancer (F5 LTM) where the users are pointed to for internal access to OWA/ECP.
I recalled a similar case with CWMS certificate replacement, when WebEx for iPhone/Android apps did not trust third-party CA issued SAN certificate. The fix for it was to chain the certificate with intermediary and root certs prior to importing into CWMS (click here for more info). So I decided to give it a try and upload a chained cert to the F5 LTM. This solved the problem. Here’s what you need to do:
- Download the server, root and intermediary certs from the issuing CA (e.g. GoDaddy).
- In a text editor of your choice (which should be Notepad++, naturally) combine server, root and intermediary certs in the following order:
- server cert
- intermediary cert
- root cert
- Export the certificate with key from Exchange in PKCS#12 format
- Export the certificate’s private key using openssl
- Upload the new (chained) cert to F5 LTM (System -> File Management -> SSL Certificate List -> Import
- Upload cert key
In newer versions of LTM (v.11 and above, I think), you can import PKCS#12 certificate directly. So you can skip the openssl part in step #4 and just import PKCS#12 cert first (which includes private key), then re-upload the chained cert overwriting existing (non-chained) certificate.
Hope this will help someone.