Why You Can’t Use a Wildcard Certificate for CWA 2007 R2

A few weeks ago I had posted an issue we were seeing internally after deploying Communicator Web Access R2 where we saw a certificate error only when IE was the user’s browser, even when going through a reverse proxy. After a lot of searching, debugging and help requests I finally got an answer back from someone at Microsoft as to why this was happening.

The problem occurs because Internet Explorer only recognizes 1 level of a wildcard certificate. So, my initial logon and connection were completely valid to im.confusedamused.com using a wildcard certificate of *.confusedamused.com. The problem manifested itself whenever I would try and initiate a chat session with someone and the information bar would drop in complaining of a certificate mismatch. Doing some logging shows that the as.im.confusedamused.com and download.im.confusedamused.com URLs are contacted when you open a chat. Since IE won’t consider  the *.confusedamused.com certificate valid for either of those URLs because they are technically 1 level deeper than my wildcard certificate is issued for, it generates a certificate warning.

I didn’t bother testing, but I imagine if you generated a SAN certificate with a subject name of *.confusedamused.com and a SAN of *.im.confusedamused.com IE would have allowed the connection with no warning. We ended up just going with a named SAN cert of the following:

Subject Name: im.confusedamused.com

Subject Alternative Names: im.confusedamused.com, as.im.confusedamused.com, download.im.confusedamused.com

For what it’s worth Firefox and Safari seem to accept multiple levels of a wildcard certificate just fine so the issue seems to be constrained to just IE. It would be great to say that CWA was just for other browsers anyway, but the desktop sharing features makes a strong case to include support for IE in your deployment.

For the next wave of OCS I’d hope the product team does away with the domain prefixes and just key off of suffixes instead using something like im.confusedamused.com/as or im.confusedamused.com/download so this is isn’t an issue. They did this for the /join and /dialin pieces, so I would think it’s possible. Oh well, maybe in 2010.

CWA 2007 R2 Certificate Requirements

Just finished banging my head against the wall on this one. With the original release of OCS 2007 I would typically place a wildcard certificate on the internal Communicator Web Access virtual server. I’ve found that most of my clients don’t have their internal Root CA certificates installed on Linux or Mac machines so using the wildcard avoided any kind of certificate trust errors. No dice in R2. Using a wildcard seems to break pieces of CWA (at least for an implementation collocated on a Front-End server).

The R2 documentation (as if I would read that first…) lays out that you actually need the machine FQDN on the virtual server certificate.

Subject Name: Matches the URL of the Communicator Web Access site. For example, if the URL is https://im.contoso.com then the certificate should have im.contoso.com as subject name.

Subject Alternative Names: Includes the following: The URL of the Communicator Web Access site. The as URL. The download URL. The fully qualified domain name (FQDN) of the Communicator Web Access server.

This doesn’t really lay out what to do if you have a differing internal and SIP domains. So in my case, internal domain is ptown.local, SIP domain is confusedamused.com. CWA server FQDN is cwa.ptown.local and my published CWA url is im.confusedamused.com. My virtual server cert looks like this:

Subject Name: im.confusedamused.com

Subject Alternative Names: im.confusedamused.com,as.im.confusedamused.com,download.im.confusedamused.com,cwa.ptown.local

Without that last SAN entry you can sign in, but you’ll see the IE information bar indicate a certificate error when you try to initiate a chat with someone. It must be trying to reach the machine FQDN and when it doesn’t see the name on the cert it throws an error. This is probably the part that doesn’t work with the wildcard as well.

The error you’ll see in IE is this:

To help protect your security, Internet Explorer has blocked this website from displaying content with security certificate errors.

So what’s this mean? Better start getting those Root CA certs out to your Linux and Mac clients.