mTLS for Zero Trust
Mutual TLS (mTLS) requires both client and server to present certificates during the TLS handshake. This provides strong, cryptographic authentication for service-to-service communication in zero trust architectures.
How mTLS Works
Standard TLS (One-Way)
Client Server
|--- ClientHello -------->|
|<-- ServerHello + Cert --|
|--- Verify Cert -------->|
|--- Encrypted Data ----->|
Mutual TLS (Two-Way)
Client Server
|--- ClientHello -------->|
|<-- ServerHello + Cert --|
|<-- CertificateRequest --|
|--- Client Certificate ->|
|--- Verify Server Cert ->|
|<-- Verify Client Cert --|
|--- Encrypted Data ----->|
Implementation
PKI Infrastructure
- Deploy a Certificate Authority (internal CA or managed service)
- Issue unique certificates per service/workload
- Implement certificate lifecycle management
- Configure Certificate Revocation Lists (CRL) or OCSP
Service Mesh Integration
Most service meshes handle mTLS automatically:Istio:
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
spec:
mtls:
mode: STRICT
Linkerd: mTLS enabled by default for all meshed services.
Certificate Rotation
- Automate certificate issuance and renewal
- Short certificate lifetimes (24 hours for workloads)
- Zero-downtime rotation with overlapping validity
- Monitor for expired or about-to-expire certificates
Benefits
- Strong authentication: Cryptographic proof of identity
- Encryption: All traffic encrypted by default
- No shared secrets: No passwords or API keys to manage
- Scalable: Works across thousands of microservices
- Auditable: Certificate issuance creates audit trail
Challenges
- PKI complexity and management overhead
- Certificate rotation automation
- Debugging encrypted traffic
- Legacy system compatibility
Where SuperClue Fits
SuperClue does not inspect service-to-service traffic or mTLS setups. Its DAST scanner checks the TLS certificate and configuration of the public endpoints you scan.