تكوين أدوات CLI والأطر التطويرية للعمل مع فحص TLS من كاتو

نظرة عامة

توضح هذه المقالة كيفية جعل أدوات السطر الأوامر وإطارات عمل المطورين تثق بشهادة فحص TLS من شبكات Cato، بحيث يعمل HTTPS بدون أخطاء أثناء فحص حركة المرور. يغطي كيفية تثبيت شهادة كاتو على مستوى النظام وكيفية توجيه الأدوات المحددة نحو الشهادة عندما لا تستخدم متجر الثقة في نظام التشغيل.

في جميع الأمثلة أدناه، استبدل /path/to/CatoNetworksTrustedRootCA.pem بالمسار الفعلي لبيئتك.

تثبيت الشهادة على مستوى النظام (موصى به)

يتيح تثبيت شهادة الجذر من كاتو في نظام التشغيل المضيف لمعظم التطبيقات الثقة التلقائية في حركة المرور المفحوصة. يمكنك تثبيت شهادة الجذر من كاتو كما هو موصوف في كيفية تثبيت شهادة كاتو.

إذا لم يعمل شيء كما هو متوقع، يمكنك إضافة شهادة الجذر من كاتو يدويًا إلى متجر الثقة في نظام التشغيل. لمزيد من المعلومات حول تثبيت شهادة كاتو، راجع المقالة ذات الصلة:

حزمة الشهادات المدمجة (للأدوات التي تتجاوز حزمة الثقة)

بعض الأدوات تتجاوز حزمة الثقة لـ CA بدلاً من تمديدها، مما يعني أنها تزيل فعليًا جميع الشهادات التي كانت موجودة من قبل. لضمان ثقة هذه الأدوات في كلا الموقعين العامين وحركة المرور المفحوصة من قبل كاتو، أنشئ حزمة مدمجة تتضمن شهادات الجذر الموثوقة لنظام التشغيل بالإضافة إلى شهادة الجذر من كاتو.

توصية: قم بتثبيت شهادة الجذر من كاتو في متجر النظام. استخدم حزمة مدمجة فقط للأدوات التي تتطلب ملف CA واحد.

نصيحة صيانة: أعد بناء الحزمة المدمجة بشكل دوري (مثلاً، شهريًا أو بعد تحديثات ثقة نظام التشغيل).

Windows (PowerShell)

# قم بالتشغيل في PowerShell مرفوع الامتياز
$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 "تم كتابة الحزمة المدمجة إلى: $dest"

مسار الخرج: C:\ProgramData\CatoNetworks\TLS\cato_combined_ca.pem

ماك

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"

مسار الخرج: /Library/Application Support/CatoNetworks/TLS/cato_combined_ca.pem

لِينُكس

دمج حزمة نظام التشغيل مع شهادة كاتو لإنتاج ملف واحد.

Debian/Ubuntu:

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

مسار الخرج: /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'

مسار الخرج: /etc/pki/tls/certs/cato_combined_ca.pem

تكوينات مخصصة للأدوات

بعض الأدوات تتجاهل متجر الثقة لنظام التشغيل أو تعمل في بيئات لا يتوفر فيها متجر الثقة. في هذه الحالات، قُم بتكوينها صراحة لاستخدام شهادة كاتو أو الحزمة المدمجة.

صيغة ضبط المتغيرات العامة

لينكس/macOS:

export VARIABLE_NAME=/path/to/file

أو للحل الدائم:

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

Windows CMD

set VARIABLE_NAME=C:\path\to\file

أو للحل الدائم:

شغّل setx VARIABLE_NAME "C:\path\to\file" ثم أعد فتح نافذة CMD.

Windows PowerShell

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

للحل الدائم للمستخدم الحالي:
شغّل setx VARIABLE_NAME "C:\path\to\file" ثم أعد فتح نافذة CMD.
للحل الدائم لجميع المستخدمين على الجهاز:
شغّل [System.Environment]::SetEnvironmentVariable("VARIABLE_NAME", "C:\path\to\file", "Machine")

بايثون (Requests, AWS CLI, Azure CLI, Gcloud CLI)

غالبًا ما تستخدم أدوات بايثون certifi، التي تحتوي على حزمة CA الخاصة بها (منفصلة عن متجر الثقة لنظام التشغيل).

الإصلاح العام الموصى به لبايثون

macOS أو Linux – عيّن المتغير REQUESTS_CA_BUNDLE على الحزمة المدمجة (التعليمات مذكورة أعلاه في حزمة الشهادات المدمجة (للأدوات التي تتجاوز حزمة الثقة)).
ويندوز – شغل pip install pip-system-certs لجعل بايثون يستخدم متجر الثقة الخاص بويندوز مباشرة.

الإصلاح المخصص لأدوات بايثون

فقط لـ macOS/Linux، يمكنك إما ربط شهادة الجذر من كاتو بحزمة certifi للأداة، أو توجيه متغير CA الخاص بها إلى الحزمة المدمجة.

Azure CLI (macOS/Linux)

أضف شهادة الجذر من كاتو إلى حزمة certifi المرفقة بالواجهة. لعثور على موقع حزمة Cerifi، شغّل الأمر التالي:

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

AWS CLI / Boto (MacOS/Linux)

عيّن المتغير:

AWS_CA_BUNDLE=/path/to/cato_combined_ca.pem

أو أضف هذا السطر إلى ملف الإعدادات (~/.aws/config)

ca_bundle = /path/to/cato_combined_ca.pem

Gcloud CLI

أضف شهادة الجذر من كاتو إلى حزمة certifi المرفقة مع SDK:

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

ملاحظة: قد تختلف المسارات بناءً على كيفية تثبيت الأداة. إذا لم ترَ certifi/cacert.pem في هذه المواقع، ابحث داخل دليل الأداة.

OpenSSL (Curl, Composer, Ruby/Fastlane)

تعتمد العديد من الأدوات (مثل Curl وComposer وRuby/Fastlane) على OpenSSL للحصول على TLS. بشكل افتراضي، يقرأ OpenSSL حزمة CA الخاصة بالنظام على Linux، ولكن على macOS (Homebrew OpenSSL) وWindows، يستخدم ملفات CA الخاصة به بدلاً من متجر الثقة لأنظمة التشغيل.

الإصلاح العام الموصى به لـ OpenSSL

عيّن المتغير SSL_CERT_FILE إلى الحزمة المدمجة.

الإصلاح المخصص لبرنامج OpenSSL

إذا لزم الأمر، قم بتكوين كل أداة تعتمد على OpenSSL للإشارة إلى الحزمة المدمجة، أو أضف شهادة الجذر من كاتو إلى دليل شهادات OpenSSL وشغّل c_rehash.

Curl

لـ curl المدمج في macOS (SecureTransport)، Windows (Schannel)، ومعظم إصدارات Linux (OpenSSL/LibreSSL)، لا يلزم تكوين إضافي. تستخدم هذه الإصدارات بالفعل متجر الثقة لأنظمة التشغيل.

لتأكيد أياً من مكتبة TLS يستخدمها curl، شغّل: curl --version

بالنسبة إلى إصدارات OpenSSL/LibreSSL التي لا تستخدم متجر نظام التشغيل، قم بتعيين المتغير CURL_CA_BUNDLE صراحةً للإشارة إلى ملف الحزمة المدمجة (باستخدام الصيغة الموضحة أعلاه).

Composer (PHP)

قم بتكوين Composer لاستخدام الحزمة المدمجة: composer config -g cafile /path/to/cato_combined_ca.pem

روبي، Bundler، وFastlane

قم بتكوين Ruby/Fastlane للثقة في الحزمة المدمجة: bundle config --global ssl_ca_cert /path/to/cato_combined_ca.pem

Node.js و npm

يتعامل Node.js و npm مع متاجر الشهادات بشكل مختلف يعتمد على نظام التشغيل.

ويندوز - غالباً ما يستخدم Node.js متجر النظام، لذا فإن تثبيت شهادة الجذر من كاتو على مستوى النظام عادةً ما يكون كافياً.
Linux/macOS - عادةً ما يستخدم Node.js حزمه CA الخاصة به، والتي لا تتضمن Cato Root CA.

Node.js

إذا واجهت أخطاء TLS، قم بتكوين Node.js للثقة في Cato Root CA:

اضبط المتغير NODE_EXTRA_CA_CERTS للإشارة إلى ملف Cato Root CA (ليس الحزمة المدمجة):
export NODE_EXTRA_CA_CERTS=/path/to/CatoNetworksTrustedRootCA.pem

هذا المتغير يخبر Node.js بالثقة في CA الإضافية بالإضافة إلى تلك المدمجة.

npm

يتطلب npm الحزمة المدمجة بدلاً من ملف CA واحد. قم بتكوين npm كما يلي:

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

يضمن ذلك أن npm يثق في كل من Cato Root CA وCAs العامة الجذرية.

Java (Maven, Gradle, JDBC, إلخ...)

تستخدم Java ملف محفوظات الثقة الخاص بها المسمى cacerts. لتمكين فحص TLS، قم باستيراد Cato Root CA إلى هذا المستودع.

كلمة المرور الافتراضية لـ cacerts هي 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

ستثق جميع الأدوات المعتمدة على Java (مثل Maven، Gradle، JDBC، Salesforce Apex Data Loader) في Cato CA بمجرد إضافتها إلى مخزن cacerts.

Docker

يتكون Docker من جزئين: المحرك/الخادم على المضيف وأي صور/حاويات.

يستخدم محرك Docker المحرك مستودع الثقة للنظام المضيف، لذا فإن تثبيت Cato Root CA على مستوى النظام يكفي.
بالنسبة لـ الصور، يجب استيراد Cato Root CA إلى الحاوية.

الصور المبنية على Debian/Ubuntu:

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

الصور المبنية على RHEL/CentOS:

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

يضمن ذلك أن التطبيقات داخل الحاوية تستطيع أن تثق في حركة TLS المفحوصة من Cato.

Go

لـ Go تطبيق TLS الخاص به، ولكن بشكل افتراضي، يعتمد على مستودع الثقة بالنظام. عادةً ما يكون تثبيت Cato Root CA على مستوى النظام كافيًا.

في بعض الحالات (على سبيل المثال، في خطوط CI/CD أو الحاويات)، قد تحتاج إلى تعديل تكوين الثقة بشكل صريح من خلال إعداد المتغير SSL_CERT_FILE للإشارة إلى ملف الحزمة المدمجة.

Android Studio

يستخدم Android Studio مستودع الثقة الخاص به داخل JDK المضمّن. لتمكين فحص TLS، قم باستيراد Cato Root CA إلى هذا المخزن. كلمة المرور الافتراضية هي changeit.

Linux/macOS

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

Windows (PowerShell)

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

Git

عادةً ما يستخدم Git مستودع الثقة بالنظام. إذا تم تثبيت Cato Root CA على مستوى النظام، فلا يوجد حاجة لإعداد إضافي.

إذا فشل Git في الثقة بـ Cato Root CA، قم بتكوينها بشكل صريح لاستخدام الحزمة المدمجة:

git config --global http.sslCAInfo /path/to/cato_combined_ca.pem