We have been helping a client recently move all of their certificate services from an old Public Key Infrastructure (PKI) issuing SHA1 certificates to a newer one issuing SHA2 certificates. One of the applications that used certificates from the old PKI was Skype, for server to server communications.
We were able to identify by querying the issued certificates in the old PKI certificate consoles and the certificate templates used which Skype servers in the infrastructure required their certificates updating. The client also had a telephony system where users had a Hewlett Packard phone at their desk with a fairly old version of the Lync client on (showing their name and availability status on the phone display when they were signed in).
I was working with a Skype person, and we went about the process of putting the new certificates in place in preparation in the servers local computer certificate store, ensuring these new contained the correct common name and subject alternate name attributes.
We then tested the process of updating the default certificates on a pair of older and little used Skype servers using the Skype Administration tool, and ensuring we had downtime approved so we were able to restart the Skype services after this change. This worked well. We also updated some OAuth certificates and this went without issue.
There were a couple of potential gotchas out there captured by our testing:
HP Phone firmware
During our testing we found that the phone handsets on the users desks were on a really old firmware version, e.g. one that was not compatible communicating with a server back end that was configured to use SHA2 certificates. Therefore a firmware update had to be downloaded pushed out via the skype console to all the handsets to ensure a smooth transition (in our case the HP one in this article).
Front end web servers
All went well with the updating of the default and OAuth certificates and the continued functioning of Skype and the phones until we got to updating the final two front end web servers; assigning the new SHA2 certificates via the admin tool resulted in killing the phone system after the second front end server was rebooted. Phones signed out and were not able to sign back in.
Upon further investigation, it appeared the front end (cswebservice) on the front end servers has a list of certificate authorities it trusts. From the Skype Management Shell, the following command was run:
Get-cswebserviceconfiguration
This dumps a list of the service configuration, including a section called “Trusted CA Certs” which in our case listed the thumbprints of two certificates; this matched the thumbprints of the old SHA1 root CA certificate, and one of the old issuing CA certificates. It was clear from this that the service did not trust any of the new CA certificates and certificate chain.
I used PowerShell to extract the thumbprint values of the new root and new issuing CA certificates:
Get-Childitem cert:\LocalMachine\root -Recurse (for the Root CA certificates)
Get-Childitem cert:\LocalMachine\CA -Recurse (for the Issuing CA certificates)
In the Skype management shell I defined these new certificates using their thumbprints:
$NewRootCA = New-CsWebTrustedCACertificate -Thumbprint “Thumbprint of root CA certificate” -CAStore TrustedRootCA
$NewIssuingCA1 = New-CsWebTrustedCACertificate -Thumbprint “Thumbprint of Issuing CA1 Certificate” -CAStore IntermediateCA
$NewIssuingCA2 = New-CsWebTrustedCACertificate -Thumbprint “Thumbprint of Issuing CA2 Certificate” -CAStore IntermediateCA
I then used the following commands to add these so that the cswebservice trusted them:
set-cswebserviceConfiguration -trustedCACerts @{Add=$NewRootCA}
set-cswebserviceConfiguration -trustedCACerts @{Add=$NewIssuingCA1}
set-cswebserviceConfiguration -trustedCACerts @{Add=$NewIssuingCA2}
Running the configuration dump again:
Get-cswebserviceconfiguration
This confirmed the cswebservice was now trusting the new as well as the old CA certificates. We did have a backout where we expanded the cswebservice property and would have been able to remove the new certificates from being trusted, but didn’t have to action this. This fixed the issue in our testing and live environment, but would be need to again be thoroughly tested before implementing in production.
When we applied the new SHA2 certificates to the front end Skype servers, rebooting the 2nd front end server resulted in a short outage, but then we watched the phone system returning back to normal and phones signing back in. We did also do a power reset on a selection of handsets to ensure that they could log on after a total phone reboot.
