How TLSMCP Works
From Install to Enforced mTLS in Minutes

TLS handshake adds 5-15ms per new connection (typical for TLS 1.3). Per-request latency is negligible — TLSMCP decrypts and forwards in < 1ms. With connection pooling, the handshake cost is amortized. For reference, a 1000 req/s service with 10-minute connection lifetime sees the handshake cost on only ~1.7 requests, or < 0.02% overhead.

TLSMCP supports TLS 1.3 only. Default cipher suites are TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256. Both offer 256-bit symmetric encryption and modern AEAD construction. No legacy ciphers (3DES, RC4, MD5) are supported or negotiated. You can restrict ciphers further in config if needed for compliance.

Yes. TLSMCP watches the config file for changes and hot-reloads. Send SIGHUP to the process or use tlsmcp reload --config /path/to/config.yaml. Changes to TLS policies, service definitions, and certificate settings take effect in < 500ms without dropping active connections.

All TLSMCP instances connect to a single Cyphers Hub (which can be deployed for high availability in your primary region or a dedicated control plane). Certificate issuance and revocation are managed centrally. Each TLSMCP instance caches the revocation list locally, so revocation propagates in < 1 second across regions. Certificate CNs can include region/zone info for geospatial identity if needed.

TLSMCP continues operating with cached data. Existing connections stay alive. New connections are allowed if the client certificate is already cached and not revoked. TLSMCP will attempt to re-sync with the Hub every 30 seconds. Once Hub is reachable, it downloads the latest revocation list and policy updates. Typical downtime: minutes without impact to traffic.

Yes. TLSMCP can trust multiple CAs. You can configure it to accept client certs signed by Cyphers Hub, your internal CA, or both. Set trusted_roots in the config to point to CA certificates. TLSMCP validates the full chain and checks against revocation lists for each CA independently.

Private keys are generated by the service requesting the certificate (e.g., your app, a CI job) and never sent to Cyphers Hub. The Hub issues only the certificate (public key + metadata). You store the private key securely on the client side — in a secret manager (HashiCorp Vault, AWS Secrets Manager), environment variables, or mounted volumes. TLSMCP only reads and uses the certificates and keys you provide; it doesn't manage the private key lifecycle.

TLSMCP maintains an overlap window (default 5 days). Old and new certificates are both valid during this window. Existing connections using the old certificate continue uninterrupted. New TLS connections use the new certificate. Once the old cert's overlap window closes, it becomes invalid (and any remaining old connections are terminated gracefully). Zero-downtime rotation is guaranteed.

Yes. TLSMCP operates at the TLS layer, below the application protocol. It works with HTTP/1.1, HTTP/2 (h2), gRPC, WebSockets, raw TCP, or any protocol that runs over TLS. The backend receives plaintext data regardless of protocol. Just point TLSMCP at your service's backend address and port, and it handles the rest.

TLSMCP uses TLS 1.3 with modern ciphers, which meets PCI-DSS, HIPAA, SOC 2, and ISO 27001 requirements. Audit logging (enabled by default) tracks every certificate issuance, validation decision, and revocation. You can export audit logs for compliance reporting. Short-lived certificates and auto-rotation support zero-trust and modern security frameworks.