Skype for Business cannot log on or connect to meetings through ProxySG or Advanced Secure Gateway
search cancel

Skype for Business cannot log on or connect to meetings through ProxySG or Advanced Secure Gateway


Article ID: 169283


Updated On:


Advanced Secure Gateway Software - ASG ProxySG Software - SGOS


Attempting to log into Skype for Business (Skype) or join meetings fails when the following conditions are true:

  • If ProxySG or Advanced Secure Gateway is deployed transparently:
    • Skype's direct Internet access is blocked or dropped
    • HTTPS Service that is set to intercept, and proxy type is SSL proxy
    • SSL interception policy is installed
  • If ProxySG or Advanced Secure Gateway is deployed explicitly:
    • Skype's direct Internet access is blocked or dropped
    • Protocol detection is enabled on the HTTP Explicit service or through policy
    • SSL interception policy is installed 


Various Microsoft clients, such as Skype for Business, now strictly enforce the Online Certificate Status Protocol (OCSP) or Certificate Revocation List (CRL) checks. OCSP, CRL checks are performed during the SSL handshake between a client and server. ProxySG and Advanced Secure Gateway appliance did not include a CRL Distribution point extension or Authority Information Access (for OCSP) extension on the emulated certificates. This lack caused these Microsoft clients to abruptly conclude SSL or TLS handshakes and generate exceptions.

In addition to having a requirement for OCSP or CRL, Skype also uses Session Initiation Protocol (SIP) as part of the meeting join process. SIP uses SSL as its transport but after the appliance decrypts the traffic, the underlying SIP protocol is not understood, and an error occurs.


A new feature has been added to ProxySG and ASG. The feature allows for proper OCSP or CRL check processing by clients and servers. It also includes processing of SIP when SSL interception occurs. With this feature logging into Skype and joining meetings work when a ProxySG or Advanced Secure Gateway appliance processes the traffic. This feature is available starting in SGOS


Step 1: Enable CRL on emulated certificates

After upgrading the appliance to a release with the new feature, configure the appliance to process client and server OCSPor CRL checks correctly.  

  1. In the management console, select Configuration > Proxy Settings > SSL Proxy.
  2. In the General Settings section, select Enable CRL on emulated certificates.
  3. Click Apply to save the changes. The following example shows this configuration:

    User-added image

Step 2: Enable protocol detection

Next, modify services to enable protocol detection. This modification is needed so that SIPS and MS-TURN traffic passing through those services can be detected. 

  1. In the management console, select Configuration > Services > Proxy Services.
  2. If the appliance is intercepting traffic explicitly, enable protocol detection for the explicit proxy service. If the appliance is intercepting traffic transparently, enable protocol detection for the HTTPS service (port 443). The following is an example showing the HTTPS service with protocol detection enabled:
User-added image

Step 3: Trigger protocol detection for SSL interception

Add and modify a policy that triggers protocol detection for SSL interception. Optionally, block unknown protocols using SSL. 

  1. Create a new SSL Interception layer. If an SSL Interception layer exists, proceed to the next step,
  2. Do one of the following:
    • Add a rule with an SSL Interception object with Action set to "Enable SSL Interception with proxy handoff". 
    • If there are rules in a previously created SSL Interception layer that include SSL Interception objects, select "Enable SSL Interception with proxy handoff."

User-added image

Step 4 (Recommended): Add CPL to deny unknown protocols using SSL

When a policy includes the object that was configured in Step 2, the appliance STunnels unknown protocols using SSL. This behavior is different from using the HTTPS interception object which responds with an error when an unknown protocol uses SSL. To emulate the HTTPS interception object behavior while still being able to use SSL interception with automatic protocol detection, add the CPL in this step.

  1. Create a new CPL layer or modify an existing CPL layer.
  2.  Add the following CPL to the end of the CPL layer:

    DENY client.protocol=!ssl tunneled=yes

This CPL ensures that unknown protocols using SSL are denied. The only caveat to using the previous steps is for explicit transactions with protocol detection disabled. If an explicit proxy is used and certain traffic has protocol detection disabled, ensure that the rules to disable protocol detection occur within the CPL. Example if has protocol detection disabled: detect_protocol(none)
DENY client.protocol=!ssl tunneled=yes

With a supported release installed and policy configured, users should be able to log into Skype and join meetings.


If you are running a release that does not support CRL Distribution point extension, or Authority Information Access (for OCSP) extension on the emulated certificates. Refer to the following workaround:

Install SNI-based bypass policy with SSL intercept (SGOS and later): ssl.forward_proxy(no)

Where url_substring is:

  • Office 365-hosted Lync server.
  • Local domain-For on-premises Lync server.