locked
CWA 2007 R2 Wildcard Certificate RRS feed

  • Question

  • I'm having some trouble figuring out why this is failing exactly. R2 SE Front-End with CWA collocated running on a different IP address, bound to the same NIC. Created a cert with the subject name of the server for MTLS during activation. Imported our public wildcard cert into the server and tried to assign it to the virtual server. Cert trust line is in place as well.

    This works fine in Firefox and Safari. No cert errors at any point.

    IE works OK for the login page and I can sign in just fine. Problem pops up when I try to initiate a chat in IE, the information bar comes in and says "To help protect your security, Internet Explorer has blocked this website from displaying content with security certificate errors."

    I got around this by creating a cert that had my CWA URL as the subject with the SAN having the AS FQDN, download FQDN, and the machine's FQDN. This works fine internally. So it seems like CWA for IE is making a call somewhere to the machine FQDN, regardless of the published CWA URL.

    My concern is that when I do a reverse proxy through ISA 2006 I see the same issue for IE users. This one absolutely needs to be a public cert and we'd like to reuse the wildcard if possible. Is it no longer possible to use a wildcard cert for the virtual server? Any suggestions?

    Thanks.
    Monday, February 16, 2009 10:15 PM

All replies

  • The OCS 2007 R2 documentation does not mention wildcard certificates for CWA, so I guess you might be out of luck.
    You must have the CWA Site URL in Subject Name or SAN

    Here is more explenation from the documentation

    Although Communicator Web Access uses two different protocols you can typically get by with installing a single certificate: in most cases the same certificate can be used both for MTLS and SSL. (The MTLS certificate is assigned when you activate Communicator Web Access, while the SSL certificate is assigned each time you create a virtual server). If you have just one Communicator Web Access server you can use a single certificate as long as that certificate meets the following criteria:

    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 name (SAN)

    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.

    - Belgian Exchange Community : http://www.pro-exchange.be -
    Monday, February 16, 2009 11:14 PM
  • Yep. Read the docs. Seen the requirements. For what it's worth, I have a bone to pick with the "in most cases the same certificate can be used both for MTLS and SSL" statement the technical writers used because I would argue opposite in almost every deployment I've seen. Clients typically like to see something more like "im", "chat", or "cwa" as the CWA site URL. The machine FQDN usually falls in line with some kind of corporate naming convention. As for my original question...

    I suppose I can see the wildcard not working directly on the virtual server, but in a reverse proxy scenario I can't see why the cert error would show up. I mean, ISA is terminating the SSL connection to the listener and then connecting to a site with a cert that matches the CWA requirements. Doesn't add up.

    I tried quite a few combinations as a workaround, but off the top of my head I believe the cert error did not disappear until I actually put the machine FQDN into the SAN field, as the documentation states. Which leads me think there is some sort of call-back to the actual machine FQDN at the virtual server level instead of the CWA URL as you would expect. Which seems...odd.

    Have yet to try on a Server 2003 x64 install to see if the result is any different. I guess that's my next step.
    Tuesday, February 17, 2009 6:50 AM
  •  When they are suggesting using one cert they are talking about using a UC cert. Unfortunately OCS does not support wildcard certs. ISA 2006 has a bug that requires the CWA server and the web componenets to have a cert that is listed as the CN or the cert being the first SAN. I agree its kind of a pain but what can we do :)


    Mark
    Tuesday, February 17, 2009 1:23 PM
  • Mark,  the ISA 'bug' was resolved back in ISA 2006 SP1 so now the entire SAN field is read and processed, not just the first value.
    http://blogs.technet.com/isablog/archive/2008/07/03/isa-server-2006-service-pack-1-released.aspx


    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Tuesday, February 17, 2009 1:46 PM
    Moderator
  • The documentation clearly states you need a SAN cert. For the MTLS we used a seperate internal cert (valid per the documentation)  However, for the Web Virtual server and on the ISA server we purchased a Cert without any SAN entries (the least expensive cert).  With the documentation requiring a cert with the name "download" and "as" in it we expected a failure when you went to a computer without the Desktop sharing add-in, expecting it would fail when it tried to download the install for the add-in.  However everything seems to work fine without the SAN cert (UC cert) or the CNAME DNS records for "as" and "download".   On a clean install computer with no OCS components on it, it downloaded and installed the Desktop Sharing component with no known issues. I have used fiddler2 to de-crypt the HTTPS traffic and do see URL request with the "as.sitename.domain.com" in it, but still have not found anything that does not work. It is as if it is failing back to another method, but I have not spent the time to step through the HTTP trace.  

    I wish there was documentation for the exact purpose of the SAN cert requirement and CNAME records.  It does not seem like they are needed. 
    Wednesday, February 18, 2009 4:04 AM