When this is OK, the client logs in pretty fast, however, if we are unable to reach the CRL, then the client tries several times before giving up and continuing with the login process. Here we can see when checking an external certificate (because I am logging in externally) that it is checking OSCP/CRL. When a client logs in we can see using fiddler that every time, even when NTLM authentication is not used, the client checks for a valid CRL distribution point.

The problem is that Skype for Business only checks for web hosted CRLs that come from HTTP (80) sources.

Skype for Business doesn’t “break” with just an LDAP CRL, it just lags in performance on certain processes such as client login.

This means that the CRLs are stored in Active Directory.įor most applications, this perhaps is OK, for Skype for Business however, it has some serious performance impacts. This CA comes configured with a CRL that is LDAP based. When deploying a CA from the Server Manager install wizard, you get a basic CA. This is mainly down to the large portion of SME businesses failing to understand what is required when not only deploying Skype for Business but a Certificate Authority. This is by far the single most common problem I come across in deployments. No or Incorrect Certificate Revocation Lists (CRLs) for Internal Certificates This post is a collection of a few of these that I have come across, and hopefully will help you not make the same mistakes. I am not sure the reason why so many fall foul to these common mistakes, but they seriously impact the performance of Skype for Business. The most common problems I see in deployments that where either PoC’s come production or just bad habits. I wanted to share with you some notes from the field as it where.

Skype for business login server logs