Trusting the inspection CA

To inspect TLS traffic, the collector terminates each connection with a certificate it signs on the fly. For clients to accept that without warnings, they must trust the collector's CA. This is the one deployment step that touches devices — and the most common source of onboarding trouble — so it's worth doing carefully and first.

What the CA is

On first run, each collector generates its own CA (a private key + certificate, unique to that collector). Every intercepted connection gets a leaf certificate signed by it. You distribute the CA certificate (public, safe to share) to clients; the private key never leaves the collector.

Download the CA from the collector's detail panel in the dashboard (Collectors → your collector → CA certificate), or the Setup Network page. It's a standard PEM/DER cert.

Because each collector has its own CA, if you run multiple collectors you distribute multiple CAs — or scope each CA to the devices that use that collector. Plan device groups accordingly.

Do this on a pilot group first

Trust the CA on a handful of test machines and verify inspection works there before you route traffic for everyone. If you flip routing on before the CA is trusted, every AI call throws a certificate warning.

Distribution by platform

The mechanics are standard "add a trusted root CA" — the same thing you'd do for any inspection proxy. Use whatever fleet-management tool you already have.

Windows — Group Policy

1. Convert/keep the CA as .cer.
2. Group Policy Management → your GPO → Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities.
3. Import the CA cert. gpupdate /force on a test box, or wait for the refresh cycle.

Applications using the Windows cert store (Edge, Chrome, most .NET/native tools) will now trust it. Firefox and some tools use their own store — see below.

macOS — Jamf / Intune / MDM

• Package the CA in a Configuration Profile with a Certificate payload, and (importantly) set the trust setting so it's trusted for SSL.
• Push via Jamf (a Configuration Profile), Intune (Devices → Configuration → Trusted certificate profile), or your MDM of choice.
• On the client, the cert lands in the System keychain, trusted for SSL.

iOS / Android — MDM

• iOS: push the CA via an MDM Configuration Profile; on supervised devices trust is automatic, otherwise the user enables it under Settings → General → About → Certificate Trust Settings.
• Android: push via your EMM as a CA certificate for the managed profile. Note that Android app traffic only trusts user CAs if the app opts in; managed/system CA installation via EMM is the reliable path.

Linux hosts / servers

# Debian/Ubuntu
sudo cp kilasec-ca.crt /usr/local/share/ca-certificates/kilasec.crt
sudo update-ca-certificates

# RHEL/Fedora
sudo cp kilasec-ca.crt /etc/pki/ca-trust/source/anchors/kilasec.crt
sudo update-ca-trust

Containers / CI

Bake the CA into the image's trust store (the same update-ca-certificates step) or mount it and set NODE_EXTRA_CA_CERTS / REQUESTS_CA_BUNDLE / SSL_CERT_FILE as appropriate for the runtime.

Applications with their own trust store

Some tools ignore the OS store and need the CA added directly:

• Firefox — Settings → Privacy & Security → Certificates → View Certificates → Authorities → Import (or the security.enterprise_roots.enabled policy to honor the OS store).
• Node.js — NODE_EXTRA_CA_CERTS=/path/kilasec-ca.crt.
• Python requests — REQUESTS_CA_BUNDLE, or certifi bundle append.
• curl — --cacert or CURL_CA_BUNDLE.
• Java — import into the JVM's cacerts with keytool.

If a specific agent or SDK still fails after the OS trusts the CA, it almost always uses one of these private stores — check the tool's TLS/CA docs.

Certificate pinning

Tools that pin a certificate (some mobile apps, some SDKs) will refuse the intercepting cert no matter what you trust — that's pinning working as designed. For those destinations, Kilasec can be configured to pass through without interception (the traffic isn't decrypted, so it isn't inspected). Decide per-destination whether inspection or pass-through is the right call.

Verifying trust

On a client with the CA installed and routing applied:

curl -sS https://api.openai.com/v1/models -o /dev/null -w "%{http_code}\n"

A clean 200/401 (auth error is fine — it means TLS succeeded) confirms the CA is trusted and traffic is flowing through the collector. A certificate error means the CA isn't trusted in the store that curl/the app uses.

Rotating or removing

• To remove inspection from a device, pull the CA from its trust store and stop routing its traffic.
• If a collector is rebuilt it generates a new CA; you'll redistribute. Plan collector lifecycles with this in mind (a stable collector host avoids CA churn).