Note: This article was originally published in 2011. Some steps, commands, or software versions may have changed. While Lync 2010 has been superseded by Skype for Business and later Microsoft Teams, the certificate concepts described here apply to any Unified Communications deployment. Check the current Microsoft documentation for the latest information.

Certificate errors are among the most common issues when connecting mobile devices to Microsoft Lync (and its successor, Skype for Business). The “Can’t verify the certificate from the server. Please contact your support team.” error on the iPad and iPhone Lync app indicates that the iOS device does not trust one or more certificates in the TLS chain presented by the Lync infrastructure. This guide covers every scenario that causes this error and provides detailed solutions for each.

Understanding Certificate Validation on iOS

When the Lync mobile app connects to a server, a TLS handshake occurs. During this handshake, the server presents its SSL/TLS certificate. The iOS device validates the certificate by checking:

  1. Trust chain — The certificate must chain up to a root Certificate Authority (CA) that is in the iOS trust store. Apple maintains a list of pre-installed trusted root CAs. Any certificate issued by a CA not in this list (such as an enterprise internal CA) will fail validation.
  2. Certificate expiration — The certificate must be within its validity period.
  3. Subject name matching — The server’s hostname must match either the Subject Common Name (CN) or one of the Subject Alternative Name (SAN) entries in the certificate.
  4. Key usage — The certificate must have the appropriate Extended Key Usage attributes (Server Authentication OID: 1.3.6.1.5.5.7.3.1).
  5. Revocation status — iOS may check CRL Distribution Points or OCSP responders to verify the certificate has not been revoked.

If any of these checks fail, the Lync app displays the “Can’t verify the certificate” error. Unlike a web browser, the Lync app does not provide an option to bypass or accept the untrusted certificate.

Common Causes and Solutions

Cause 1: Internal Enterprise CA Not Trusted by iOS

This is the most common scenario. Many organizations use a Microsoft Active Directory Certificate Services (AD CS) or another private CA to issue certificates for internal infrastructure, including Lync servers. These certificates are automatically trusted by domain-joined Windows computers but are completely unknown to iOS devices.

Solution: Install the Root CA Certificate on the iPad/iPhone

Manual installation via Safari:

  1. On the iOS device, open Safari and navigate to your CA’s web enrollment page: 
    https://ca-server.contoso.com/certsrv
  2. Click Download a CA certificate, certificate chain, or CRL.
  3. Select the Base 64 encoding and click Download CA certificate.
  4. iOS will prompt you to review and install the configuration profile. Tap Allow.
  5. Go to Settings > General > VPN & Device Management (or Settings > General > Profile on older iOS versions).
  6. Tap the downloaded profile and tap Install. Enter your device passcode when prompted.
  7. Critical step for iOS 10.3 and later: Go to Settings > General > About > Certificate Trust Settings and enable full trust for the root CA certificate. Without this step, the certificate is installed but not trusted for TLS/SSL.

Automated deployment via MDM:

For enterprise environments with many devices, use a Mobile Device Management (MDM) solution:

<!-- Example: Apple Configuration Profile for Root CA deployment -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>PayloadContent</key>
    <array>
        <dict>
            <key>PayloadCertificateFileName</key>
            <string>ContosoRootCA.cer</string>
            <key>PayloadContent</key>
            <data>
                <!-- Base64-encoded certificate data goes here -->
            </data>
            <key>PayloadDescription</key>
            <string>Installs the Contoso Root CA certificate</string>
            <key>PayloadDisplayName</key>
            <string>Contoso Root CA</string>
            <key>PayloadIdentifier</key>
            <string>com.contoso.rootca</string>
            <key>PayloadType</key>
            <string>com.apple.security.root</string>
            <key>PayloadUUID</key>
            <string>A1B2C3D4-E5F6-7890-ABCD-EF1234567890</string>
            <key>PayloadVersion</key>
            <integer>1</integer>
        </dict>
    </array>
    <key>PayloadDisplayName</key>
    <string>Contoso Enterprise Certificates</string>
    <key>PayloadIdentifier</key>
    <string>com.contoso.certificates</string>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>12345678-ABCD-EF01-2345-678901234567</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
</dict>
</plist>

This profile can be deployed through Microsoft Intune, Jamf, Apple Business Manager, or any MDM solution that supports Apple configuration profiles.

Cause 2: Missing Intermediate CA Certificates

Even when using a public CA, the server may not be sending the complete certificate chain. If the server only presents the leaf (end-entity) certificate without the intermediate CA certificates, iOS may not be able to build the chain to the trusted root.

Solution: Configure the Full Certificate Chain on the Server

Verify what the server is presenting using OpenSSL from any computer with network access to the Lync Edge:

# Test the certificate chain on the Access Edge service (port 443)
openssl s_client -connect sip.contoso.com:443 -showcerts

# Test the certificate on the SIP TLS port
openssl s_client -connect sip.contoso.com:5061 -showcerts

The output will show each certificate in the chain. You should see:

  1. The server’s leaf certificate (Certificate 0)
  2. One or more intermediate CA certificates (Certificate 1, 2, etc.)
  3. The root CA certificate (usually not sent by the server since it must already be in the client’s trust store)

If intermediate certificates are missing, re-import the certificate on the Lync server with the full chain. In the Lync Server Management Shell:

# List current certificates assigned to Lync services
Get-CsCertificate

# Request and assign a new certificate with the full chain
# Or re-import the PFX with the full chain included
Import-CsCertificate -Path "C:\Certs\lync-edge-fullchain.pfx" -Password (ConvertTo-SecureString "PfxPassword" -AsPlainText -Force)

Cause 3: Subject Alternative Name (SAN) Mismatch

Lync’s certificate requirements are specific about which names must appear in the SAN field. If the hostname the mobile client connects to is not listed as a SAN entry, certificate validation fails.

Required SAN Entries for Lync 2010 External Access

For a typical Lync 2010 deployment with Edge Server and external access:

ServiceRequired SAN EntryExample
Access EdgeAccess Edge pool FQDNsip.contoso.com
Web Conferencing EdgeWeb conferencing FQDNwebconf.contoso.com
A/V EdgeA/V Edge FQDNav.contoso.com
Reverse Proxy (External Web Services)External web services URLlyncweb.contoso.com
Autodiscover (for mobile)Autodiscover URLlyncdiscover.contoso.com

The certificate Subject (CN) should be set to the primary external FQDN (typically sip.contoso.com), and all other names should be included as SAN entries.

Verifying SAN Entries

Check the current certificate’s SAN entries:

# On the Lync Edge Server
$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Subject -like "*sip.contoso.com*"}
$cert.Extensions | Where-Object {$_.Oid.FriendlyName -eq "Subject Alternative Name"} | ForEach-Object {$_.Format($true)}

Or using OpenSSL:

openssl x509 -in lync-cert.pem -text -noout | grep -A1 "Subject Alternative Name"

Cause 4: Port Forwarding Without an Edge Server

If you are forwarding SIP port 5061 directly to an internal Lync Front End or Director server without using an Edge Server, the certificate presented on port 5061 is the internal server certificate. This certificate typically:

  • Is issued by the internal enterprise CA (not trusted by iOS).
  • Has the internal server FQDN as the subject name, not the external FQDN the mobile client is connecting to.
  • May not have the correct SAN entries for external access.

Solution: Deploy a Lync Edge Server

Microsoft’s supported configuration for external access requires a Lync Edge Server. The Edge Server terminates TLS connections from external clients and uses certificates that can be configured with the correct external FQDNs. Direct port forwarding of SIP traffic to internal servers is not a supported configuration and will consistently cause certificate errors on mobile clients.

The Lync Edge Server roles include:

  • Access Edge — handles SIP signaling for remote users.
  • Web Conferencing Edge — handles web conferencing traffic for external participants.
  • A/V Edge — handles audio/video media relay.

Each role can have its own certificate, or a single certificate with all required SAN entries can be used.

Cause 5: Expired or Nearly Expired Certificate

iOS will reject certificates that have expired. Check the validity dates:

# Check certificate expiration dates on the Lync server
Get-CsCertificate | Select-Object Use, Thumbprint, NotBefore, NotAfter | Format-Table -AutoSize

Renew the certificate before it expires. For public CAs, allow time for the renewal and deployment process. For internal CAs, use auto-enrollment templates where possible.

Microsoft recommends using a publicly trusted CA for all externally facing Lync services. Public CA certificates are trusted by iOS (and all major platforms) without requiring any additional certificate installation on client devices.

Well-known public CAs include DigiCert, Sectigo (formerly Comodo), GlobalSign, and Let’s Encrypt (though Let’s Encrypt certificates require more frequent renewal at 90 days).

When ordering a public certificate for Lync, request a multi-SAN (UC) certificate that includes all required external FQDNs. Specify:

  • Subject (CN): sip.contoso.com
  • SAN entries: sip.contoso.com, webconf.contoso.com, av.contoso.com, lyncweb.contoso.com, lyncdiscover.contoso.com

Testing Certificate Connectivity

After making certificate changes, test from the iOS device’s network:

Using SSL Labs (for externally accessible servers)

Navigate to https://www.ssllabs.com/ssltest/ and enter your Lync external FQDN. The report will identify chain issues, missing intermediates, and SAN problems.

Using OpenSSL from the Command Line

# Test Access Edge
openssl s_client -connect sip.contoso.com:443 -servername sip.contoso.com

# Check certificate details
openssl s_client -connect sip.contoso.com:443 </dev/null 2>/dev/null | openssl x509 -text -noout

# Verify the complete chain
openssl s_client -connect sip.contoso.com:443 -verify 5

Using the Lync Remote Connectivity Analyzer

Microsoft provided a Remote Connectivity Analyzer (originally at https://testconnectivity.microsoft.com) that could test Lync external connectivity and certificate configuration. This tool validates DNS records, certificate chains, and SIP connectivity from the perspective of an external client.

Summary of Steps to Resolve the Error

  1. Identify the certificate being presented to the mobile client (use openssl s_client).
  2. Check the issuing CA — if it is a private/internal CA, either install the root CA certificate on the iOS device or switch to a public CA.
  3. Verify the SAN entries include all external FQDNs the mobile client may connect to.
  4. Ensure the full chain is being sent by the server (leaf + intermediates).
  5. Deploy a Lync Edge Server if you are currently using direct port forwarding.
  6. Test the configuration using OpenSSL and the Remote Connectivity Analyzer before testing on the device.