OCS R2 CWA Single Certificate Configuration

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”

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

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

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.)

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)”

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.

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.