Device Certificate Troubleshooting

Overview

When configuring device authentication for SDP clients, certificate-related issues may occur. This article covers basic device certificate troubleshooting. For more information about the feature see Controlling Certified Corporate Devices

 

Troubleshooting

The following are possible troubleshooting steps that can be taken while investigating Device Certificate issues.

1. First, we will verify the configuration in the CMA under Access -> Client Access -> Device Authentication and confirm that the interesting OS is listed as required and not as blocked.



cma-cert.png

As per Use the Client Connectivity Policy to Manage your Device Authentication Requirements, the device certificate per OS configuration should be done via the CCP - Check the Configuring the Client Connectivity Policy for more information.

2. At the bottom of the same page, all the uploaded certificates are listed. These certificates are Certificate Authority certificates, which signed the client certificate. Clicking on the "Show details" icon lists the certificate details in a readable form.



devauth2.png

Note: Under Device Posture, you can create Device Checks for certificates (supported only on WVPN v5.5 and higher) that are installed on the end-user device. The check validates that there is a certificate installed on the device that matches one of the signing certificates defined for the account. For more information see Creating a Device Certificate Device Check

 

3. It's important to confirm that the CA certificate isn't expired. If it is, the PoP allows the connection only if the authority signed the device certificate before it has expired. For the device certificates, Cato doesn’t allow a Client to connect with an expired certificate. For more information see: Handling Expired Certificates

 

4. One way to make sure that the necessary CA certificates are uploaded to CMA is to look at the client certificate chain (certification path). In this example, the client cert was signed by the intermediate certificate with CN= "Issuing CA Client" which in turn was signed by the root certificate with CN= "Root CA". These have to match the certificates installed in CMA.

cert-chain__1_.png

 

5. As per RFC3280, the Authority Key Identifier of the client certificate has to match the Subject Key Identifier of the issuer (in this case the Intermediate Certificate). This is another way to confirm that the correct intermediate and root CA certificates are uploaded to CMA.


key_identifier__1_.png

 

6. After we make sure that the configuration looks good and that the certificate is valid, we will verify that the certificate is present on the client's OS.

Note: For more information about certificate distribution see Distributing Certificates for Device Authentication


Windows:

In Windows, device certificates must be installed on the Local Computer and not under the Current User. There are two ways to verify the existence of the device certificate:

  • Open the command prompt and type certutil -store My to list all the available user certificates on the device. In the example below, the first certificate issuer matches the subject of the CA certificate installed in step #2. If this isn't the case it means the client doesn't have the necessary certificate on the device.
    Certutil is a very powerful tool that can be used to list, revoke or renew certificates. You may find more information about it here.

  • certutil can also be used to install the PFX (p12) certificate file on the device by running the command below, which is the recommended way to install the certificate on Windows devices as explained in Distributing Device Certificates to Windows Devices.

    /certutil -csp "Microsoft Software Key Storage Provider" -importpfx My <path-to-p12-file> NoExport

  • Alternatively, you can verify installed certificates on the device by typing certlm.msc from the Windows Start Menu. This will show all certificates installed on the Local Computer. The device certificate must be installed under the Local Computer's Personal/Certificates Folder and include a private key that the PFX file should have installed.

 

MacOS:

Verify that the MacOS client contains the configuration profile previously distributed via MDM or Apple Configurator. The profile can be found in Privacy & Security settings for macOS 13. To locate the profile in older macOS versions see macOS user guide.

Note: From macOS Client v5.4, the certificate can be installed directly to the device without MDM distribution. The certificate and private key can be found in Keychain Access. See Distributing Device Certificates 


 

Client certificate deployment can be achieved via Microsoft Active Directory using a Windows Enterprise CA. An MDM solution would still be needed for certificate distribution. See: How to Create and Deploy a Client Certificate for Mac Computers Independently from Configuration Manager

The user certificate can also be found under the login section in Keychain Access:

 

 

Make sure that the VPN profile is correctly configured. The VPN payload must be configured as per the device type (macOS or iOS):

  • Connection Type: Custom SSL

  • Identifier:

    • For macOS:  com.catonetworks.mac.CatoClient 

    • For iOS:  CatoNetworks.CatoVPN 

  • Server: vpn.catonetworks.net

  • Account: add your account name. For example: CatoNetworksAccount.

  • ProviderBundle Identifier:

    • For macOS: com.catonetworks.mac.CatoClient.CatoClientSysExtension

    • For iOS:  CatoNetworks.CatoVPN.CatoVPNNEExtenstion 

  • Provider Designated Requirement: empty

  • User Authentications: Certificate

  • Provider Type: Packet Tunnel

  • Credentials: Choose the certificate from the ‘Certificates’ payload

  • Proxy Setup: None

For detailed information on VPN profile configuration see Distributing Device Certificates.

Was this article helpful?

0 out of 2 found this helpful

0 comments

Add your comment