As certificates have become common in deploying of Live Communication Server 2005 I put together a list of common issues one can experience with certificates and LCS 2005.
My certificate has expired. How should I replace it?
When a certificate expires on the LCS 2005 frontend system(s) you will notice that users are not able to login anymore with TLS. If LCS 2005 Enterprise Edition is deployed the nodes will be unable to communicate with each other using MTLS. This will cause messages to be undelivered between servers. Usually the certificate is replaced before this causes a bad day for administrators however I have noticed that many times the certificate is not being replaced successfully.
In order to replace the certificate successfully a new one should be issued to the same FQDN (fully qualified name) as the server or the pool name (in the case of Enterprise Edition). If using Enterprise Edition it should also have a subject alternative name listing both the pool and the FQDN of the server. The intended purpose (Enhanced Key Usage) of the certificate should have “Server Authentication (1.3.6.1.5.5.7.3.1)”. In addition to “Server Authentication” I would recommend also requesting a certificate with the intended purpose of “Client Authentication (1.3.6.1.5.5.7.3.2)” as this is required by some public IM servers. The “Client Authentication, Server Authentication” certificate needs to be installed on the Access Proxy external interface.
To install the certificate, you need to determine if the certificate has a 2-tier certificate chain. Most issued certificates use 2-tier chains for security purposes today. When viewing the certificate the “Certificate Path” tab will determine whether any issues exist by displaying a red X. This is a simple check that will use any method to validate whether the complete chain exists. It is best to ensure that all tiers of the chain are installed in the appropriate stores. For example the Intermediate tier should be installed into the “Intermediate Certification Authority”, and the root tier should be installed into the “Trusted Root Certification Authority”. If they already exist the expiry date should be validated along with the serial number to ensure they are matching.
Once installed successfully into the Local Computer stores the certificate can be assigned to the LCS 2005 server. To successfully assign the certificate, open the LCS 2005 server properties. The “Security” tab will specify the default certificate used for MTLS communication. In addition to updating the certificate on the “Security” tab any certificate assigned to the listener on the “General” tab needs to be updated. For example, the “General” tab may list the bindings 5060 and 5061 (TLS). The 5061 (TLS) binding will require a certificate and this is independent of the certificate on the “Security” tab. In my troubleshooting I have seen the certificate changed on the “Security” tab followed by deletion of the prior expired certificate. If the expired certificate is deleted but still assigned to the TLS binding on the “General” tab, the LCS server will fail to start looking for the missing certificate.
Communicator Mobile clients
When deploying Communicator mobile and using private certificates the mobile clients will require the trusted root and any other certificates in the certificate chain to be installed on the mobile device. The recommended practice is to assign a publicly issued certificate on the access proxy external interface since it will not require deploying certificates to the mobile clients. In my troubleshooting I have come across mobile clients being unable to connect to the Access Proxy due to 2-tier certificate chains (both public and privately issued). In many cases (especially privately issued certificates) both the trusted root and any intermediate authorities will need to be installed on the mobile device. In most mobile devices the trusted root and intermediate certificates may be installed in the same default store since they will not have separate stores for these certificates. If other clients can successfully connect remotely you may want to try to setting the DisableCRLCheck registry value on the mobile client. This value will disable the validation of the server certificate thereby not requiring any trusted root or intermediate certificates to be installed on the mobile device. The Microsoft Office Communicator Mobile Planning and Deployment Guide can be an excellent resource in deploying mobile clients.
Microsoft Office Communicator Mobile Planning and Deployment Guide
http://www.microsoft.com/downloads/details.aspx?familyid=7877b140-e76a-47f9-8866-bce5dec024ed&displaylang=en
Public IM connectivity
Setting up Public IM connectivity (PIC) with certificates is very similar to that of enabling remote access. As stated prior the certificate will require both “Client Authentication” and “Server Authentication” as some public providers require “Client Authentication”. The certificate is required to be publicly issued and should be installed using the same procedure as I’ve outlined above. The important step here is to make sure that all the tiers of the certificate are in the proper stores and that they are not expired. The LCS 2005 Access Proxy will look for all the tiers in the chain and provide these during MTLS negotiation. If they are not found the receiving party may not be able to validate the certificate. A simple network trace can tell you if you are having certificate problems. For example, after the 3-way handshake in TCP communication there will be approximately 5-10 packets exchanged for MTLS setup. These 5-10 packets should be assumed to be certificate exchange. If followed by a packet with the reset flag set the negotiation is assumed to have failed.
Other Certificate Issues
Certificates can be responsible for many intermittent communication problems in LCS 2005. The use of machine names that do not match the certificate “Subject” is not recommended. When deploying certificates it is best to deploy a certificate matching the FQDN of the machine when possible. Machines that are not part of the domain should have the primary domain suffix added via the “Computer Name Changes” dialog box in System Properties. If matching the certificate is not possible the certificate should have the “Subject Alternative Name” field filled to list all alternative names including the true FQDN of the machine.
- David Lebar
Escalation Support Engineer