We recently changed our Live Communication Server certificate from an externally provided CA (IPSCA) and began using a internally provided certificate from our internal PKI. We wanted to utilize Subject Alternate Names, without the cost of public Certificate Authorities. All Messenger and Office Communicator clients honored the new cert, except MACs. The problem is the fact that our internal trusted root CA is not in the X509Anchor trusted list. This is different than the "System" trusted list. By default, VeriSign and IPSCA are, as well as dozens more.
We were able to resolve the issue by adding the root cert to the local client. Below are the steps we followed……..
LCS 2005 & Messenger for the Mac on Leopard
One of the changes with OS X 10.5 Leopard is the lack of the X509Anchors keychain being installed by default. The problem this creates is that a lot of Microsoft applications for the Mac depend on this keychain for their certificate authentication. They check the X509 keychain for a certificate and when it doesn’t exist, they fail to authenticate. The annoying part here is that the application doesn’t even have appropriate error messages included. Instead of something logical like the "the certificate is not valid or trusted" the user gets an error that their sign-in name or password is incorrect. Fortunately there’s a workaround and you can add this keychain back to make it functional again.
Open Keychain Access (Using Spotlight to search for it is probably easiest)
Click File > Add Keychain
Browse to Machintosh HD | System | Library | Keychains and select the X509Anchors keychain. Press Open.
Now select the X509 keychain in the Keychain Access window and drag all of the certificates you need onto this window. You should be prompted for your admin credentials.
Now you’ll see a window asking which keychain you want to install the certificates to. Choose X509Anchors and press OK.
Once your certificates are installed, try signing in again. This time it should succeed!
Live communication server (LCS) 2005 SRV records can be a daunting task to setup properly. SIP is the communications protocol for LCS. SIP URIs are id’s given to contacts/users that use the SIP service. LCS uses SIP and when you enter in your user id/sign-in name for Communicator or Windows Messenger, you are giving the client application your SIP URI. If you want to use the automatic configuration for communicator or Windows Messenger, you have to rely on your DNS infrastructure. The client uses your SIP URI from the account information provided (email@example.com) then performs a DNS query to find a matching host record for that SIP URI. This is called a SIP Namespace. There are 4 different types of SRV records that can be used, depending on your environment and client specifications. Perusing Microsoft’s documentation on this subject is a bit challenging, but once you overcome the lack of documentation and incorrect syntax, it can be accomplished. If you have a mixed environment, such as Windows Messenger 5.0 and Office Communicator clients, it’s best to configure several types of SRV records within your DNS environment. Below is a list of SRV records and their purpose.
|LCS Client SRV record for internal use Windows |
(Local Windows Messenger clients (legacy))
|_sip._tls.domain (Should point at the LCS Pool)|
|LCS Access Proxy configuration per domain (off site)||
_sip._tls._tcp.domain (Should point at the Access Proxy FQDN)
|LCS Client SRV record for internal use clients|
(Local Office Communicator clients)
_sipinternaltls._tcp.domain (Should point at the LCS Pool)
|LCS Federated Services|
(Federated partnership with Microsoft)
_sipfederationtls._tcp.domain (Should point at the Access Proxy FQDN)
In my test lab, here is an example of an SRV record I created. This services automatic configurations for internal Office Communicator and Office 2007 Live Meeting clients. Here is a good blog that walks thru the creation steps. (Click here)