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.

This task has always been more of a pain that it ever should have, regardless of application. After trying a few of the usual hacks like requiring SSL and using a custom error page or an HTTP to HTTPS module I found I still wasn’t having any luck. From what I can tell this is because there actually isn’t any kind of default web page in the CWA virtual directory so when you browse to the HTTP version of the site you actually get a 404 “Page not Found” error before anything else happens.

I ended up keying off that idea and changed the 404 error page to be a redirect to the HTTPS page. I’m still testing this out, but I haven’t run into any issues yet with this approach. To change your site the same way:

1. Open IIS 7 Manager.
2. Click on the CWA virtual web site you want to redirect.
3. Double-click on Error Pages.
4. Highlight 404 and press Edit in the right pane.
5. Select the Respond with a 302 redirect, enter https://My-CWA-URL and click OK.
6. Run a iisreset /noforce for good measure.

I’m curious how this works for everyone and if you see any issues with this method.

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.

Ran into this bug today while trying to deploy Communicator Web Access 2007 R2 on Windows Server 2008. Apparently the SPN isn’t registered properly during the installation process which causes integrated authentication to fail. After you try to sign in you’ll see this error:

Cannot sign in because your computer clock is not set correctly or your account is invalid.(Error code: 0-1-492)

Jason Shave ran across this same issue a few weeks ago and has a nice explanation on how to add the SPN to your CWAService account.

I had to restart the CWA virtual server before the SPN change took effect, but after that CWA logged in just fine: