Run into this issue (Skype for Business phones showing “Connecting to Lync Server…”) with Microsoft certified phones and devices connected to Skype for Business Server 2015 environment after replacing the Default certificate of the pool.
In this specific case, there are two Certificate Authority (CA) in the environment – an old Root CA, a single CA server with SHA1 algorithm and a new Root CA with two tire PKI, an offline Root CA + Issuing CA with SHA256 algorithm. Basically, the old Root CA is getting replaced with new Root CA certificate chain.
After assigning the new Default Certificate to Skype for Business Server 2015 environment, all Microsoft certified phones and devices in the network disconnected from the Skype for Business Server 2015 pool and showed the message “Connecting to Lync Server …”. Phones will not sign-in to the Skype for Business Server 2015 environment with appropriate and correct credentials.
This is a production environment and there are about 1500 Microsoft certified phones and devices. These Microsoft certified phones include Lync Phone Edition – e.g. Polycom CX500, CX600 and CX3000 phones – also known as LPE, Polycom VVX series new Microsoft certified media phones and other Microsoft certified devices. All devices show the same message. However, on new media phones and other Microsoft certified devices, the provisioning access download new Root CA chain to the devices. After the download, these new media phones and other Microsoft certified devices showed same error. The device logs indicated that there is an error with certificate.
Exported the default certificate without private key and executed the certutil command as follows:
certutil -f -urlfetch -verify C:temppool.crt
and got the following output –
Issuer:
CN=IssuingCA
DC=custdom
DC=com
Name Hash(sha1): <value>
Name Hash(md5): <value>
Subject:
CN=SFBPOOL.custdom.com
…
—————- Certificate AIA —————-
Verified “Certificate (0)” Time: 0
[0.0] ldap:///CN= IssuingCA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=custdom,DC=com? cACertificate?base?objectClass=certificationAuthority
Verified “Certificate (0)” Time: 0
[1.0] http://IssuingCA.custdom.com/CertEnroll/IssuingCA.custdom.com _IssuingCA.crt
—————- Certificate CDP —————-
Verified “Base CRL (1e)” Time: 0
[0.0] ldap:///CN= IssuingCA,CN= IssuingCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=custdom,DC=com?
certificateRevocationList?base?objectClass=cRLDistributionPoint
Verified “Delta CRL (1e)” Time: 0
[0.0.0] http://IssuingCA.custdom.com/CertEnroll/IssuingCA +.crl
Verified “Base CRL (1e)” Time: 0
[1.0] http://IssuingCA.custdom.com/CertEnroll/IssuingCA.crl
Verified “Delta CRL (1e)” Time: 0
[1.0.0] http://IssuingCA.custdom.com /CertEnroll/IssuingCA +.crl
—————- Base CRL CDP —————-
OK “Delta CRL (24)” Time: 0
[0.0] http://IssuingCA.custdom.com/CertEnroll/IssuingCA+.crl
—————- Certificate OCSP —————-
…
——————————–
CRL 1e:
Issuer: CN=IssuingCA, DC=custdom, DC=com
…
Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=RootCA, DC=custdom, DC=com
…
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
—————- Certificate AIA —————-
Failed “AIA” Time: 0
Error retrieving URL: The server name or address could not be resolved 0x80072ee7 (WIN32: 12007)
http://RootCA.custdom.com/CertEnroll/RootCA.custdom.com_RootCA.crt
—————- Certificate CDP —————-
Verified “Base CRL (07)” Time: 0
[0.0] ldap:///CN=RootCA,CN=RootCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=custdom,DC=com?
certificateRevocationList?base?objectClass=cRLDistributionPoint
Verified “Base CRL (07)” Time: 0
[1.0] http://IssuingCA.custdom.com/CertEnroll/RootCA.crl
—————- Base CRL CDP —————-
…
——————————–
CRL 07:
Issuer: CN=RootCA, DC=custdom, DC=com
…
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
—————- Certificate AIA —————-
No URLs “None” Time: 0
—————- Certificate CDP —————-
No URLs “None” Time: 0
—————- Certificate OCSP —————-
No URLs “None” Time: 0
——————————–
Additionally, RootCA.custdom.com was not published in DNS. The missing DNS entry pointed to the issue with the RootCA certificate as it was incorrect.
Usually, in two tire PKI with offline Root CA, the AIA and CDP in the RootCA should be pointed to an online CA server as a Microsoft recommendation. While in above RootCA certificate case, the Microsoft recommendation was violated. When this Root CA downloaded to the new media phones and other Microsoft certified devices, the RootCA certificate could not be verified as these devices cannot access the RootCA URL and marking the RootCA certificate as untrusted. The untrusted RootCA also make Skype for Business pool certificate untrusted as well and cause the problem.
Because two tire PKI is already in use, it will be impractical to create new Root CA and Issuing CA certificates.
The issue got resolved by adding DNS CNAME record of RootCA.custdom.com in the internal DNS and point it to Issuing CA. This CNAME allow everyone to trust the Root CA certificate as a valid copy of Root CA cert and crl exist at the Issuing CA location as well it is accessible by the devices.
With CNAME change, the new media phones and other Microsoft certified device able to sign-in and working fine. However, this fix does not fix the issue with LPE. After this change, the LPE remain in the same state.
While researching this LPE issue, the blog by Kevin Peters – Lync Phone Edition: Connection to Microsoft Exchange is unavailable provided some direction. Even though the blog is specific to LPE and Exchange issue, the following line pointed me to the issue –
“The root of the problem is the Lync Phone Edition devices will not trust a CA other than the one that issued the certificate to the Lync pool it is connecting to”. The blog refers to command New-CsWebTrustedCACertificate. The detail description in command states “Note that the certification authority that signs the default server certificate used when installing Skype for Business Server is automatically trusted and does not need to be added to the TrustedCACerts property of a collection of Web Services configuration settings”.
Based on the above read, the WireShark traces from a text CX600 phone shows that Root CA chain was not downloading to the phone. Therefore, the phone remains in “Connecting to Lync Server …” state.
To resolve this issue with LPE, additional changes are required in the existing environment by adding appropriate Trusted Root CA and update Web Service configuration. The following set of commands executed:
$OldRootCA = New-CsWebTrustedCACertificate -Thumbprint “<Thumbprint>” -CAStore TrustedRootCA
$NewRootCA = New-CsWebTrustedCACertificate -Thumbprint “<Thumbprint>” -CAStore TrustedRootCA
$IssuingCA = New-CsWebTrustedCACertificate -Thumbprint “<Thumbprint>” -CAStore IntermediateCA
Set-CsWebServiceConfiguration -Identity Global -TrustedCACerts -InferCertChainFromSSL $False @{Add=$OldRootCA,$NewRootCA,$IssuingCA}
Please note that default value of collection “InferCertChainFromSSL” is “$True” and command Set-CsWebServiceConfiguration states the following –
“-TrustedCACerts
Collection of certificates representing certificate chains trusted by the Web Server. New certificates added to the collection must be created by using the New-CsWebTrustedCACertificate cmdlet.
This collection is not used if the InferCertChainFromSSL property is set to True”.
Therefore, the “InferCertChainFromSSL” is set to value “$False”.
Note: In above New-CsWebTrustedCACertificate command, <Thumbprint> is the actual thumbprint of the appropriate certificate.
After CMS replication, all LPE devices signed in with no errors.
Would you like to know more? Get in touch with us here!
