Skip to main content

Netskope Help

Configuring CLI-based Tools and Development Frameworks to work with Netskope SSL Interception

If Netskope is deployed inline (for CASB or Web), some CLI tools will not work because they use certificate bundles distributed with those tools (i.e. Python distribution, for example), and they do not access system certificate store where Netskope client installs Netskope root CA. The guidance below will allow you to enable those tools to seamlessly work with Netskope SSL interception.

In order for these tools to trust Netskope-signed certificates, they need to be configured to trust Netskope Certificate Authority (CA). This is typically accomplished by setting certain environment variables to point to Netskope CA to allow for smooth SSL operation.

The variables need to be set to point to the following files that contain Netskope CA:

On a Mac:/Library/Application Support/Netskope/STAgent/data/nscacert.pem

On Windows:%ProgramData%\Netskope\STAgent\data\nscacert.pem

For example to set REQUESTS_CA_BUNDLE variable on a Mac to point to the Netskope root CA, you can run this command:

export REQUESTS_CA_BUNDLE='/Library/Application Support/Netskope/STAgent/data/nscacert.pem'

Combined Certificate Bundle

Some software allows one to specify additional certificate bundles to be trusted in addition to the standard certificates, but other software requires that you override the entire trusted certificate bundle. In order to ensure that clients/browsers trust both sites that have their traffic redirected and ones that don't have their traffic redirected, a combined certificate bundle may be required with the contents of both the standard certificate bundle and the Netskope certificate bundle.

A combined certificate bundle can be created from the operating system certificate store (which already contains both standard certificates and Netskope certificates) with the following commands:

Windows (Powershell)

((((gci Cert:\CurrentUser\Root) + (gci Cert:\LocalMachine\Root) + (gci Cert:\CurrentUser\CA) + (gci Cert:\LocalMachine\Root)) | Where-Object { $_.RawData -ne $null } `
| Sort-Object -Property Thumbprint -Unique `
| % { "-----BEGIN CERTIFICATE-----", [System.Convert]::ToBase64String($_.RawData, "InsertLineBreaks"), "-----END CERTIFICATE-----", "" }) `
-replace "`r","") -join "`n" `
| Out-File -Encoding ascii "$env:ProgramData\Netskope\STAgent\data\nscacert_combined.pem" -NoNewline

Mac

security find-certificate -a -p /System/Library/Keychains/System
RootCertificates.keychain \
/Library/Keychains/System.keychain > /tmp/nscacert_combined.pem
&& \
sudo cp /tmp/nscacert_combined.pem /Library/Application\ Support
/Netskope/STAgent/data/

The location of the generated certificate bundle file is as follows:

Windows

C:\ProgramData\Netskope\STAgent\data\nscacert_combined.pem
("$env:ProgramData\Netskope\STAgent\data\nscacert_combined.pem" or
%ProgramData%\Netskope\STAgent\data\nscacert_combined.pem)

Mac

/Library/Application Support/Netskope/STAgent/data/nscacert_combined.pem

Below is the list of tools/frameworks and instructions on how to make them compatible with Netskope SSL interception:

Tools/Framework

Instructions

Android Studio

https://support.netskope.com/s/article/Android-Studio-certificate-warning-Server-s-certificate-is-not-trusted

AWS CLI

Follow instructions in this article: Addressing SSL Error while Accessing AWS Services via the AWS CLI with the Netskope Client Enabled

Azure CLI

Azure CLI is Python-based, and it requires that the Netskope certificate bundle be available along with the default certs. We can either add the Netskope cert bundle to the default cert bundle located at C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\Lib\site-packages\certifi\cacert.pem on Windows and /opt/az/lib/python3.6/site-packages/certifi/cacert.pem on Linux ,or we can create another file that has all the certificates and point the REQUESTS_CA_BUNDLE variable to this file. Details about this can be found here: https://docs.microsoft.com/en-us/cli/azure/use-cli-effectively#work-behind-a-proxy

Boto

Boto is a Python library, but it uses AWS CLI config and environmental variables, so please use the same setup as AWS CLI in order to get Boto to work with Netskope

curl

  1. If you're using the curl command line tool, you can specify your own CA cert path by setting the environment variable CURL_CA_BUNDLE to the path of your choice.

If you're using the curl command line tool on Windows, curl will search for a CA cert file named curl-ca-bundle.crt in these directories and in this order:

  1. application's directory

  2. current working directory

  3. Windows System directory (e.g. C:\windows\system32)

  4. Windows Directory (e.g. C:\windows)

  5. all directories along %PATH%

  1. Get a better/different/newer CA cert bundle! One option is to extract the one a recent Firefox browser uses by running 'make ca-bundle' in the curl build tree root, or possibly download a version that was generated this way for you: CA Extract

Fastlane

Uses OpenSSL, so see OpenSSL instructions

Git

Git CLI can be configured to use a custom CA bundle as per instructions here: https://git-scm.com/docs/git-config#git-config-httpsslCert . Typically, the location of the CA bundle can be written into git config file or used as an environment variable GIT_SSL_CAPATH.  Please note that git is a toolset that is compatible with variety of SCMs (GitHub, GitLab, Azure DevOps, etc). 

Google Cloud SDK (gcloud CLI)

Google Cloud SDK/CLI can use custom CA bundle by using gcloud config file.  Instructions on how to configure gcloud to use custom CA bundle are here: https://cloud.google.com/sdk/gcloud/reference/config/set . 

Windows gcloud config set core/custom_ca_certs_file "%ProgramData%\Netskope\STAgent\data\nscacert.pem"

https://support.netskope.com/s/article/Deploy-the-Netskope-root-certificate-into-the-Google-Cloud-SDK-Certificate-Store.

MacOS gcloud config set core/custom_ca_certs_file "/Library/Application Support/Netskope/STAgent/data/nscacert.pem"

Java

https://support.netskope.com/s/article/JAVA-and-Eclipse-Unable-to-find-valid-certification-path-error

Node.JS

Node.js 7.3.0 (and the LTS versions 6.10.0 and 4.8.0) added NODE_EXTRA_CA_CERTS environment variable for you to pass the CA certificate file. It will be safer than disabling certificate verification using NODE_TLS_REJECT_UNAUTHORIZED.

$ export NODE_EXTRA_CA_CERTS=[your CA certificate file path]

The cafile configuration property works similarly: npm config set cafile [your CA certificate file path] 

The main difference between NODE_EXTRA_CA_CERTS and the cafile config property is that the former adds a cert, whereas the cafile config property replaces the certs. For those that just want to add a corporate cert to the chain, NODE_EXTRA_CA_CERTS is the easier option. –

OpenSSL

Netskope CA bundle needs to be added to the OpenSSL CA bundle.  This depends on your endpoint.  On a Mac, for example, OpenSSL CA bundle in the /usr/local/etc/openssl/cert.pem  netskope-mac-ca-bundle  script from GitHub automatically checks for presence of that file and adds Netskope CA cert to it if detected.  Otherwise, please find cert.pem for your OpenSSL installation and add Netskope CA certificates there manually.

Python-based apps and scripts

Python-based tools that uses requests library can leverage CA bundle referenced by the system variable REQUESTS_CA_BUNDLE .  Create your CA bundle that includes Netskope root CA for your tenant and set environment variable REQUESTS_CA_BUNDLE to point to that file

Salesforce Apex Dataloader

https://support.netskope.com/s/article/Salesforce-Apex-Dataloader-app-fails-to-connect-with-error-Failed-to-send-request-

Composer (Dependency manager for PHP)

The cafile configuration property allows for specifying a .pem file for SSL verification. This can be configured as follows:

composer config --global cafile '<location of cafile>'

For Windows:

composer config --global cafile "%ProgramData%\Netskope\STAgent\data\nscacert.pem"

For MacOS:

composer config --global cafile "/Library/Application Support/Netskope/STAgent/data/nscacert.pem"