Managing Certification Authority Certificates for OCS
Add Comment 
Share It Typically in a basic deployment there are times when Windows workstations and servers which are not members of the internal Active Directory domain need to communicate with OCS servers. This could be attempting to sign-in to Office Communicator installed on a test workstation on the internal corporate network, as well as a perimeter-network server (like ISA or and OCS Edge server) attempting an MTLS connection to an internal OCS server. This also applies to external workstations trying to sign-in to an Access Edge service which has been configured with a private internal certificate instead of a publicly-trusted third-party cert.
By default, when a Windows computer (Workstation or Server OS) is a member of an Active Directory domain which has an internal Enterprise Certificate Authority installed in it that computer automatically trusts that certificate authority. If a multi-tier CA deployment exists, then the client will have already imported all Root and Subordinate CA certificates.
This topic has been covered many different times for other PKI-leveraging products, and is discussed in multiple places throughout the OCS product documentation. But it’s a pretty common stumbling-block (seen in the TechNet support forums very often) for users and administrators who are new to the idea of using certificates. So here’s a detailed walkthrough to show how to export certificates from certificate authorities into non-domain-joined workstations and servers.
Certificates Console
By default Windows does not include a published Administrative Tool for accessing the certificates store, you must first create the console by adding an MMC snap-in. This process is the same for all current Windows operating system types and versions, and lets you view and manage the certificates on the local computer. It’s important to note that the Computer Account (and not the logged on user’s account) is where certificates must be managed for all these processes. Putting certificates in the wrong stores and folders will prevent successful communications between hosts.
- From the Run command enter mmc.exe
- From the File menu select Add/Remove Snap In…
- Add the Certificates snap-in
- When prompted to select what store, select Computer Account
- When prompted to select what computer to manage, select Local Computer
Validating a Domain Member’s Certificates
To first see what the expected end-result would look like, and to understand why domain-joined computers can communicate with the OCS servers without issues let’s look at the trusted certificates currently setup on a domain workstation. Using the previous steps, open the Certificates console on any domain-joined computer.
Expand the tree out to the Trusted Root Certification Authorities\Certificates folder and locate the root certificate. If you aren’t sure of what the name is it can help to sort the Intended Purposes column and look at the few certificates listed with <All> purposes. In the screenshot below we can see my lab’s Root Certificate Authority’s certificate is stored here. Unless some custom Group Policy change were made to prohibit certificate downloads to domain members, all domain computers should have the internal Enterprise CA root certificate stored in this location.
If there is more than one tier of Certificate Authorities deployed in the domain, then additional subordinate (Policy and/or Issuing) CAs would be found (along with a second instance of the Root CA’s certificate) in the Intermediate Certification Authorities\Certificates folder. This screenshot shows both my Root (SchertzLabRootCA) and Issuing CA (SchertzLabIssuingCA) certificates.
This is indicative of a more secure CA deployment utilizing and offline Root CA with an online issuing, subordinate CA. It’s important to identify which type (thus how many certificates) is used in your environment so that all are exported and imported correctly. If only the Root CA certificate is imported into a workgroup computer and not the Issuing CA cert (which most likely issued the certificates to the OCS servers) then communications will fail as the chain of trust will not be complete.
Failed Sign-In From Workgroup Computer
When attempting to sign-in to Office Communicator from a computer that doesn’t trust the CA that issued certificates to the OCS server, it’s pretty clear that it won’t work as sign-in immedataly fails with the following error: “There was a problem verifying the certificate from the server. Please contact your administrator.”
A quick look at the Application Event Log on the local computer shows a bit more details as to what happened:
Event Type: Error
Event Source: Communicator
Event ID: 5
Description:
Communicator could not connect securely to server pool1.schertz.lab because the certificate presented by the server was not trusted due to validation error 0x80090325. The issuing certificate authority (CA) for the server's certificate may not be locally trusted by the client, the certificate may be revoked, or the certificate may have expired.
Since the error description mentions a few different potential causes, let’s use the LCSerror.exe command from the OCS Resource Kit tools to lookup that specific error code for a more definitive description.
c:\>lcserror 0x80090325
0x80090325 -> (SEC_E_UNTRUSTED_ROOT) (kernel32.dll) The certificate chain was issued by an authority that is not trusted.
So based on those results, we have confirmed that the root cause is the lack of any trusted CA certificates on the local computer.
Exporting Certificates
Microsoft has a TechNet article (KB555252) that covers how to export the certificate from the Root CA, but the directions assume that you have console access to the Root CA. Except for testing environment, most users and even Administrators should neither have access nor be able to get to the Root CA as protecting the private key of that system is imperative to a solid PKI infrastructure. It is also unnecessary to access the CAs directly to get to their certificates, they are already installed on any domain-member. And since the private key is not needed (nor desired, you should never export the Root CA’s private key onto a less-secure server) there is even less of a reason to do it the way shown in that article.
So the simplest route is to just jump on the OCS Front-End server to export CA certificates. In order to validate that all certificates are exported, let’s look at the Certification Path on the certificate issued to the OCs services.
- Open up the Certificates console using the same instructions as shown in the beginning of this article.
- Expand the Personal\Certificates folder and locate the certificate assigned to the OCS Front-End services.
- Open the certificate (or Open from the right-click menu; not Properties).
- Select the Certification Path tab.
Here I’ve included screenshots of both potential scenarios, a single-tier CA deployment, and a multi-tier CA deployment.
Start with exporting the root certificate for either scenario:
- Highlight the top-level root certificate and click the View Certificate button.
- Select the Details tab and then click Copy to File.
- From the Certificate Export Wizard select DER Encoded binary X.509 (.CER)
- Save the file to local drive (e,g, c:\RootCert.cer)
For the second example where the OCS certificate was issued by a subordinate CA we’ll need to also export the Issuing certificate. Follow the exact same steps as shown above for the next certificate down the chain. If there a even more level’s then make sure all certificates in the chain are exported to a .CER file.
Importing Certificates
Now that we have the certificate files exported as that is left to do is move them over to the desired computer and import them into the proper location. If there is only a single Root CA then that single file is imported into just the Trusted Root Certification Authorities folder, but if there are multiple CA certificates then in addition to placing the Root there, all certificates (root and all subordinates) in the chain are placed into the Intermediate Certification Authorities folder as well.
Importing the Root CA certificate:
- Copy the RootCert.cer file to over to the workgroup computer.
- Open the Certificates console as shown in the beginning of this article.
- Expand and highlight the Trusted Root Certification Authorities\Certificates folder.
- From the Action menu select All Tasks > Import.
- In the Certificate Import Wizard:
- Select the previously exported file (RootCert.cer).
- The Certificate Store should automatically display the location you started the Import wizard from. Make sure that it is the "Trusted Root Certification Authorities” and finish the wizard.
Importing Subordinate CA certificates:
If there are any remaining subordinate certification authority certificates to import, follow the same steps as above for each certificate (including the root) but instead import them all into the Intermediate Certification Authorities store.
The desired configuration would include the Root CA certificate in both the Root and Intermediate stores, with all other subordinate certificates in only the Intermediate store:
- Trusted Root Certification Authorities
- Root CA certificate
- Root CA certificate
- Intermediate Certification Authorities
- Root CA certificate
- Policy CA certificate
- Issuing CA certificate
- Issuing CA certificate
- etc…
At this point Office Communicator should be able to sign-in without the previous 0x80090325 error. The same steps can be used to configure the certificate chain for an OCS Edge server or to setup Federation with a peer who isn’t using public certificates on their Access Edge proxy. Basically any time two hosts need to communicate securely by negotiating a certificate-based network connection, if both parties do not already trust each other’s certificate issuers.
Comments