Configuration des outils CLI et des cadres de développement pour fonctionner avec l'inspection TLS de Cato

Vue d'ensemble

Cet article explique comment faire en sorte que les outils en ligne de commande et les cadres de développement fassent confiance au certificat d'inspection TLS de Cato Networks, afin que HTTPS fonctionne sans erreurs pendant que le trafic est inspecté. Il couvre comment installer le certificat Cato à l'échelle du système et comment diriger des outils spécifiques vers le certificat lorsqu'ils n'utilisent pas le magasin de confiance du système d'exploitation.

Dans tous les exemples ci-dessous, remplacez /path/to/CatoNetworksTrustedRootCA.pem par le chemin réel de votre environnement.

Installer le certificat à l'échelle du système (recommandé)

Installer le Cato Root CA dans le système d'exploitation hôte permet à la plupart des applications de faire confiance automatiquement au trafic inspecté. Vous pouvez installer le Cato Root CA comme décrit dans How to Install the Cato Certificate.

Si quelque chose ne fonctionne pas comme prévu, vous pouvez ajouter manuellement le Cato Root CA au magasin de confiance du système d'exploitation. Pour plus d'informations sur l'installation du certificat Cato, voir l'article pertinent :

Ensemble de certificats combinés (pour les outils qui substituent le bundle de confiance)

Certains outils substituent le bundle de confiance CA au lieu de l'étendre, ce qui signifie qu'ils suppriment en fait tous les certificats qui s'y trouvaient auparavant. Pour garantir que ces outils font confiance à la fois aux sites Web publics et au trafic inspecté par Cato, créez un bundle combiné qui inclut les certificats root de confiance du système d'exploitation plus le Cato Root CA.

Recommandation : Installer le Cato Root CA dans le magasin système. Utilisez un bundle combiné uniquement pour les outils qui nécessitent un fichier CA unique.

Conseil de maintenance : Reconstruisez le bundle combiné périodiquement (par exemple, mensuellement ou après les mises à jour de la confiance du système d'exploitation).

Windows (PowerShell)

# Exécuter dans PowerShell en mode administrateur
$dest="$env:ProgramData\CatoNetworks\TLS\cato_combined_ca.pem"; $destDir=Split-Path $dest; New-Item -ItemType Directory -Force -Path $destDir | Out-Null; Get-ChildItem Cert:\CurrentUser\Root, Cert:\LocalMachine\Root, Cert:\CurrentUser\CA, Cert:\LocalMachine\CA | Sort-Object Thumbprint -Unique | ForEach-Object { "-----BEGIN CERTIFICATE-----"; [System.Convert]::ToBase64String($_.RawData,'InsertLineBreaks'); "-----END CERTIFICATE-----"; "" } | Out-File -Encoding ascii $dest; Write-Host "Combined bundle written to: $dest"

Chemin de sortie : C:\ProgramData\CatoNetworks\TLS\cato_combined_ca.pem

macOS

sudo mkdir -p "/Library/Application Support/CatoNetworks/TLS"

security find-certificate -a -p \
  /System/Library/Keychains/SystemRootCertificates.keychain \
  /Library/Keychains/System.keychain \
  > /tmp/cato_combined_ca.pem && \
  sudo install -m 0644 /tmp/cato_combined_ca.pem \
  "/Library/Application Support/CatoNetworks/TLS/cato_combined_ca.pem"

Chemin de sortie : /Library/Application Support/CatoNetworks/TLS/cato_combined_ca.pem

Linux

Concaténez le bundle du système d'exploitation avec le Cato CA pour produire un fichier unique.

Debian/Ubuntu :

sudo bash -c 'cat /etc/ssl/certs/ca-certificates.crt > /etc/ssl/certs/cato_combined_ca.pem'

Chemin de sortie : /etc/ssl/certs/cato_combined_ca.pem

RHEL/CentOS/Alma/Rocky :

sudo bash -c 'cat /etc/pki/tls/certs/ca-bundle.crt > /etc/pki/tls/certs/cato_combined_ca.pem'

Chemin de sortie : /etc/pki/tls/certs/cato_combined_ca.pem

Configurations spécifiques aux outils

Certains outils ignorent le magasin de confiance du système d'exploitation ou fonctionnent dans des environnements où il n'est pas disponible. Dans ces cas, configurez-les explicitement pour utiliser le Cato CA ou le bundle combiné.

Syntaxe générale des variables de paramétrage

Linux/macOS :

exporter VARIABLE_NAME=/path/to/file

ou pour une solution permanente :

echo 'export VARIABLE_NAME=/path/to/file' >> ~/.zshrc ou ~/.bashrc 
source ~/.zshrc  ou  ~/.bashrc

Windows CMD

set VARIABLE_NAME=C:\path\to\file

ou pour une solution permanente :

Exécutez setx VARIABLE_NAME "C:\path\to\file" puis rouvrez la fenêtre CMD.

Windows PowerShell

$env:VARIABLE_NAME="C:\path\to\file"

Pour une solution permanente pour l'utilisateur actuel :

Exécutez setx VARIABLE_NAME "C:\path\to\file" puis rouvrez la fenêtre CMD.
Pour une solution permanente pour tous les utilisateurs de l'appareil :

Exécutez [System.Environment]::SetEnvironmentVariable("VARIABLE_NAME", "C:\path\to\file", "Machine")

Python (Requests, AWS CLI, Azure CLI, Gcloud CLI)

Les outils Python utilisent souvent certifi, qui embarque son propre bundle CA (séparé du magasin de confiance de l'OS).

Correction générale recommandée pour Python

macOS ou Linux – définissez la variable REQUESTS_CA_BUNDLE sur le bundle combiné (instructions ci-dessus Ensemble de certificats combinés (pour les outils qui substituent le bundle de confiance)).
Windows – exécutez pip install pip-system-certs pour que Python utilise directement le magasin de confiance de Windows.

Correction spécifique aux outils Python

Uniquement pour macOS/Linux, vous pouvez soit ajouter le Cato Root CA au bundle certifi de l'outil, soit pointer sa variable CA vers le bundle combiné.

Azure CLI (macOS/Linux)

Ajoutez le Cato Root CA au bundle certifi livré avec le CLI. Pour trouver l'emplacement du bundle certifi, exécutez la commande suivante :

$(az --version 2>&1 | awk -F"'" '/Python location/ {print $2}') -m certifi

AWS CLI / Boto (macOS/Linux)

Définissez la variable :

AWS_CA_BUNDLE=/path/to/cato_combined_ca.pem

Ou ajoutez cette ligne au fichier de configuration (~/.aws/config)

ca_bundle = /path/to/cato_combined_ca.pem

Gcloud CLI

Ajoutez le Cato Root CA au bundle certifi livré avec le SDK :

~/google-cloud-sdk/platform/bundledpython*/lib/python*/site-packages/certifi/cacert.pem

Remarque : Les chemins peuvent varier selon la façon dont vous avez installé l'outil. Si vous ne voyez pas certifi/cacert.pem à ces emplacements, cherchez dans le répertoire de l'outil.

OpenSSL (Curl, Composer, Ruby/Fastlane)

De nombreux outils (tels que Curl, Composer et Ruby/Fastlane) dépendent d'OpenSSL pour le TLS. Par défaut, OpenSSL lit le bundle CA du système sur Linux, mais sur macOS (Homebrew OpenSSL) et Windows, il utilise ses propres fichiers CA au lieu du magasin de confiance de l'OS.

Correction générale recommandée pour OpenSSL

Définissez la variable SSL_CERT_FILE sur le bundle combiné.

Correction spécifique aux outils OpenSSL

Si nécessaire, configurez chaque outil basé sur OpenSSL pour pointer vers le bundle combiné, ou ajoutez le Cato Root CA dans le répertoire des certificats d'OpenSSL et exécutez c_rehash.

Curl

Pour curl intégré sur macOS (SecureTransport), Windows (Schannel), et la plupart des builds Linux (OpenSSL/LibreSSL), aucune configuration supplémentaire n'est requise. Ces builds utilisent déjà le magasin de confiance de l'OS.

Pour confirmer quelle bibliothèque TLS curl utilise, exécutez : curl --version

Pour les builds OpenSSL/LibreSSL qui n'utilisent pas le magasin de l'OS, définissez explicitement la variable CURL_CA_BUNDLE pour pointer vers le fichier de bundle combiné (en utilisant la syntaxe expliquée ci-dessus).

Composer (PHP)

Configurez Composer pour utiliser le bundle combiné : composer config -g cafile /path/to/cato_combined_ca.pem

Ruby, Bundler, et Fastlane

Configurez Ruby/Fastlane pour faire confiance au bundle combiné : bundle config --global ssl_ca_cert /path/to/cato_combined_ca.pem

Node.js et npm

Node.js et npm gèrent les magasins de certificats différemment selon l'OS.

Windows - Node.js utilise souvent le magasin système, donc installer le Cato Root CA à l'échelle du système est généralement suffisant.
Linux/macOS - Node.js utilise généralement son propre ensemble de CA, qui n'inclut pas le CA racine de Cato.

Node.js

Si vous rencontrez des erreurs TLS, configurez Node.js pour faire confiance au CA racine de Cato :

Définissez la variable NODE_EXTRA_CA_CERTS pour pointer vers le fichier CA racine de Cato (et non l'ensemble combiné) :

export NODE_EXTRA_CA_CERTS=/path/to/CatoNetworksTrustedRootCA.pem

Cette variable indique à Node.js de faire confiance au CA supplémentaire en plus de ceux intégrés.

npm

npm nécessite l'ensemble combiné plutôt qu'un seul fichier CA. Configurez npm de la manière suivante :

npm config set cafile "/path/to/cato_combined_ca.pem"

Cela garantit que npm fait confiance à la fois au CA racine de Cato et aux CA racines publics.

Java (Maven, Gradle, JDBC, etc...)

Java utilise son propre fichier de magasin de confiance appelé cacerts. Pour activer l'inspection TLS, importez le CA racine de Cato dans ce magasin.

Le mot de passe par défaut pour cacerts est changeit.

Linux/macOS

sudo keytool -importcert -noprompt \
  -alias cato-root-ca \
  -file /path/to/CatoNetworksTrustedRootCA.pem \
  -keystore $JAVA_HOME/lib/security/cacerts \
  -storepass changeit

Windows (PowerShell)

keytool -importcert -noprompt `
  -alias cato-root-ca `
  -file "C:\path\to\CatoNetworksTrustedRootCA.pem" `
  -keystore "C:\Program Files\Java\jdk-17\lib\security\cacerts" `
  -storepass changeit

Toutes les outils basés sur Java (tels que Maven, Gradle, pilotes JDBC, Salesforce Apex Data Loader) feront confiance au CA de Cato une fois qu'il est ajouté au magasin cacerts.

Docker

Docker se compose de deux parties : le moteur/daemon sur l'hôte et les images/conteneurs.

Le moteur Docker utilise le magasin de confiance de l'OS hôte, donc l'installation du CA racine de Cato au niveau du système est suffisante.
Pour les images, vous devez importer le CA racine de Cato dans le conteneur.

Images basées sur Debian/Ubuntu :

COPY CatoNetworksTrustedRootCA.pem /usr/local/share/ca-certificates/cato-root-ca.crt
RUN update-ca-certificates

Images basées sur RHEL/CentOS :

COPY CatoNetworksTrustedRootCA.pem /etc/pki/ca-trust/source/anchors/
RUN update-ca-trust

Cela garantit que les applications à l'intérieur du conteneur peuvent faire confiance au trafic TLS inspecté par Cato.

Go

Go a sa propre implémentation TLS, mais par défaut, il dépend du magasin de confiance de l'OS. Installer le CA racine de Cato au niveau système est généralement suffisant.

Dans certains cas (par exemple, dans des pipelines CI/CD ou des conteneurs), vous devrez peut-être remplacer explicitement la configuration de confiance en définissant la variable SSL_CERT_FILE pour pointer vers le fichier ensemble combiné.

Android Studio

Android Studio utilise son propre magasin de confiance cacerts à l'intérieur du JDK inclus. Pour activer l'inspection TLS, importez le CA racine de Cato dans ce magasin. Le mot de passe par défaut est changeit.