Category Archives: Certificate Authority

Skype for Business Services won’t start

Immediately after installing Skype for Business Server 2015 (Standard Edition) the front-end services would not start.

Tom Rimala’s blog article that suggested there is a problem when the internal Certificate Authority uses MD5 as the signature signing method.

Also, the Microsoft Certificate Requirements says “The default digest, or hash signing, algorithm is RSA.” (no mention of MD5).

I changed the CA Authority’s certificate from MD5 to SHA1. Here is the registry key to change on the Root CA signing information (we changed these three values). Note: the guidance was to change this on the Root and Subordinate but in our case the Root was also the issuing CA, so there was no subordinate to change in our case.

image

The next step is to restart the Root CA services. Then issue a new Root Certificate. Then copy the new root CA cert to the Skype for Business front-end, and finally re-issued the Front End Cert and OATH cert. Then the services should start up.

There was a false negative warning about Event ID 32174 “Server startup is being delayed because fabric pool manager has not finished initial placement of users.” This is clearly a bogus error because a Front-End server doesn’t have additional servers to place users into.

SNAGHTML253351b

There was a clue about the Certificate problem because the System Event log contained a ton of Schannel events such as 36888, “A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205.” And Event ID 36874 “An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.” I am adding these details in the event that a search engine might index these errors to point people to this fix.

Lync Phone edition tls handshake fail with usb tethering out of box

Leave a reply

MSFT support engineers have identified a bug with the USB tethering on Lync Phone Edition. They compared the packet traces of the PIN authentication successful TLS handshake and compared it with the failed USB tethering TLS handshake.

They observed that during PIN authentication, the Lync phone connects to the Lync server over port 80 to download the intermediary certificate whereas during USB authentication, the phone skips that step and immediately attempts to handshake on SSL 443. The problem is the handshake fails because the phone does not yet have the intermediate certificate.

Quick conceptual background: A certificate chain is commonly composed of a Root certificate, followed by an intermediate certificate, and finally the issued certificate.

So in summary, there is a bug in the Lync Phone Edition firmware that is preventing the intermediate cert download from occurring during the USB tethering.

This is why the USB tethering works successfully following the PIN authentication, because during the PIN authentication, it successfully downloads the intermediate certificate.

MSFT is going to document this issue into a Knowledge Base Article and then inform the product engineering team. There is no guarantee that the product group will fix this behavior since there is a reasonable work-around to use PIN authentication.

Another potential fix is to find a different certificate authority that may skip the intermediate authority and issue device certs directly from the root authorities that come pre-loaded on each phone as described at the bottom of (this) MS Technet article.

This is not very practical because you would first have to purchase the certificate from Comodo, Verisign, Entrust, etc to find out whether they issue certs directly from the root and skip the intermediate. Also, it is highly unlikely that we would find a CA provider that does not have an intermediate authority because best practice is to mask/shield the root from direct contact by issuing certs from the intermediate rather than the root.

Offline Root CA’s require periodic maintenance

Leave a reply

In most environments where an offline Root CA is used, it must come back online once every 7 months to provide the Subordinate CA’s with an update CRL list. If this does not happen, the Subordinate CA will stop issuing certificates. The actual CA service on the Subordinate will no longer startup and the error message will be “The revocation function was unable to check revocation because the revocation server was offline”

I recommend performing the following steps every 6 months (to allow for a 30 day cushion)

1. Power up the Offline Root CA

2. On the Offline Root, run this command:
c:\windows\system32\certsrv\certenroll\certutil –crl

3. The command above will re-issue the CRL. Now copy the CRL from the c:\windows\system32\certsrv\certenroll directory to the Subordinate Issuing CA

4. The next step is to install the CRL into the Subordinate CA with this command:

Certutil –addstore CA <name of file>

CA best practices and maintenance procedures are located here:
http://technet.microsoft.com/en-us/library/cc782041(v=ws.10).aspx