fix(checkoutservice): Option 2 — Mutual TLS (mTLS) with custom certs

[mikecstone]

Summary

• Adds loadTLSCredentials() which reads a CA cert, client cert, and client key from environment variables (TLS_CA_CERT_PATH, TLS_CLIENT_CERT_PATH, TLS_CLIENT_KEY_PATH) and configures TLS 1.3 mTLS
• Stores credentials on the checkoutService struct and uses them for all 8 outbound service connections
• Removes grpc.WithInsecure() entirely
• Fixes context.TODO() → ctx in convertCurrency

Trade-offs

Pros:

• Full mutual TLS — both the server and this service authenticate each other, satisfying zero-trust requirements
• TLS 1.3 minimum enforced in code, not just policy
• Cert paths are configurable via env vars, making it easy to mount Kubernetes secrets or use cert-manager

Cons:

• Requires provisioning and rotating client certs for the checkoutservice itself
• Each downstream service must also be updated to require and validate client certs
• More operational overhead than Option 1

Required environment variables

Variable	Description
TLS_CA_CERT_PATH	Path to the CA cert PEM that signed the server certs
TLS_CLIENT_CERT_PATH	Path to this service's client certificate PEM
TLS_CLIENT_KEY_PATH	Path to this service's client private key PEM

When to use this

Best fit for production environments with a zero-trust posture, an internal PKI (e.g. cert-manager, Vault PKI), and where all microservices are being hardened together.

Test plan

• Mount valid cert/key/CA files and confirm service starts without error
• Confirm PlaceOrder end-to-end succeeds with valid mTLS certs
• Confirm connection is rejected when an invalid or expired client cert is presented
• Confirm connection is rejected when server cert is signed by an untrusted CA

🤖 Generated with Claude Code

[ox-security]

OX Security reviewed this pull request — nothing to fix.

✔ No issues found

Branch fix/grpc-mtls → master

View scan in OX Security →