Server Identity Cannot Be Verified

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:

  1. Download the server, root and intermediary certs from the issuing CA (e.g. GoDaddy).
  2. In a text editor of your choice (which should be Notepad++, naturally) combine server, root and intermediary certs in the following order:
    1. server cert
    2. intermediary cert
    3. root cert
  3. Export the certificate with key from Exchange in PKCS#12 format
  4. Export the certificate’s private key using openssl
  5. Upload the new (chained) cert to F5 LTM (System -> File Management -> SSL Certificate List -> Import
  6. 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.

Jabber vs. OCS/Lync – Feature Comparison

Many are wondering how Cisco Jabber compares to OCS/Lync in terms of features and user experience. The two share some similarities and clearly leave other competing products far behind – as Gartner analysts clearly suggest. I have tried to summarize all features of the two in the following table:

Feature Jabber OCS/Lync
Presence indicators in Microsoft applications Yes Yes
Rich presence (e.g. “on the phone”) Yes No
Custom status messages Yes Yes
Instant Messaging
Group chat Yes Yes
File transfer Yes Yes
Screen capture-to-IM Yes No
Conversation history in Outlook No Yes
IM History for compliance Yes Yes
Telephony and Video
PC-to-PC audio calling Yes[i] Yes
PC-to-PC video calling Yes[i] Yes
PC-to-PSTN audio calling Yes No
URI dialing (e.g. Yes Yes
Click-to-call support Limited[ii] Yes
Native iPhone/iPad client Yes Yes
Native Android client Yes Yes
Native Windows Phone client No Yes
Native BlackBerry client Limited[iii] Yes
AD integration: authentication Yes Yes
AD integration: directory search Yes Yes
WebEx integration (click-to-meet) Yes Yes
Desktop sharing Yes Yes
Remote control sharing Yes Yes
Skype federation No Yes
Federation with other standards-based clients Yes Yes
VPN-less connectivity Yes Yes

[i] CUCM-registered client only
[ii] Limited support (from MS Office applications only)
[iii] Limited support (IM-only; EOL)

Your comments, as always, are welcome.