The connection failed before the request even left the machine. The logs made it clear: the TLS handshake was never completed. For Open Policy Agent (OPA) running in production, a broken TLS configuration is not just an error — it’s a security gap.
OPA’s TLS support controls both encryption in transit and mutual authentication. To configure it, you define the tls section under the server configuration, typically in config.yaml. This includes the certificate, private key, and optional CA bundle for verifying clients.
Example OPA TLS Configuration:
services:
example:
url: https://policy.example.com
tls:
cert_file: /etc/opa/certs/server.crt
key_file: /etc/opa/certs/server.key
ca_cert_file: /etc/opa/certs/ca.crt
skip_verify: false
cert_filepoints to the server’s public certificate in PEM format.key_fileis the associated private key. Keep it secure with strict filesystem permissions.ca_cert_fileis required for validating client or upstream certificates when mutual TLS is enabled.skip_verify: falseenforces full certificate verification.
For mutual TLS (mTLS), OPA can authenticate connecting clients by requiring them to present valid certificates signed by a trusted CA. This is critical when OPA sits between sensitive microservices or policy distribution endpoints. To activate mTLS for the server API: