Although I find it best practice to deploy two separate certificates on an OCS R2 Communicator Web Access server, there are times when using a single certificate for both server-based MTLS and client-based SSL communications are the best approach, mainly cost if an internal CA is unavailable and all certificates are being purchased. The problem is that getting a single certificate to work for both roles will typically fail if you follow the current guidelines.
The official OCS R2 documentation for Preparing Certificates for Communicator Web Access currently states the following:
“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 problem is that this statement is unfortunately incorrect. The remaining half of that page is correct in terms of the certificate configuration required for using two separate certificates for MTLS and SSL communications, but if the directions above are followed to create a single certificate it will not work.
Validation
Assuming we have a newly deployed CWA server called cwaserver.contoso.com I’ll request a new certificate using the following fields, matching the documented requirements. (Note that the server’s FQDN doesn’t necessarily have to be in the same domain as the published web address. The documentation assumes the same domain namespace, but the server FQDN could just as easily be in nwtraders.local, for example. This is common when the internal Active Directory namespace is different than a company’s public domain name which is used for SMTP and SIP services.)
Subject | CN = im.contoso.com |
Subject Alternative Name | DNS Name = im.contoso.com DNS Name = download.im.contoso.com DNS Name = as.im.contoso.com DNS Name = cwaserver.contoso.com |
When the Activate Communicator Web Access wizard is run and this certificate is selected, it will fail with the error “The subject of the certificate you selected doesn’t match the current computer’s FQDN.”
This is because the MTLS server-to-server communications in OCS are established by resolving the server’s hostname and if the certificate’s Subject Name is something other than the server name then communications will fail. The wizard looks for this requirement and blocks to assignment of a certificate that will not meet that requirement. The last section on the same page of the OCS documentation reflects that requirement in the MTLS certificate configuration example:
“The MTLS certificate should list the full qualified domain name (FQDN) of the Communications Web Access computer in the subject name of the certificate. If the fully qualified domain name (FQDN) of that computer is cwaserver.contoso.com then the MTLS certificate should include the following information (with no subject alternative name required)”
Subject Name |
CN = cwaserver.contoso.com |
Resolution
So if you have not figured it out by now, the correct configuration is to use the server’s FQDN in the Subject Name of the single certificate and then populate the SAN field with all names. This will meet the Activation wizard’s requirement for assigning an MTLS certificate, and the published URL in SAN field will suffice for SSL communications.
Subject | CN = cwaserver.contoso.com |
Subject Alternative Name | DNS Name = im.contoso.com DNS Name = download.im.contoso.com DNS Name = as.im.contoso.com DNS Name = cwaserver.contoso.com |
As I understand it, this portion of the deployment documentation is under review by the product team and I hope to see it corrected in the near future. I’ll update this blog when that happens to reflect any changes.