Mutual TLS

DevFlow can present a client certificate when checking your service. This is "mTLS" — the server authenticates DevFlow before accepting the request.

upload the cert pair

devflow certs put internal-api   --cert ./internal-api.crt   --key ./internal-api.key

The private key is encrypted at rest the same way variables-and-secrets are. You cannot export the key after upload.

reference in a monitor

url: https://internal-api.example.com/health
tls:
  client_cert_id: internal-api
  verify: true
  min_version: tls1.2

verify: true (the default) requires DevFlow to validate the server's cert against public CAs. For internal CAs, upload your CA bundle:

devflow certs put-ca corporate-ca --bundle ./corp-ca.pem

Then reference it:

tls:
  client_cert_id: internal-api
  verify: true
  ca_bundle_id: corporate-ca

ip allow-list

mTLS plus a server-side IP allow-list is a common combination. The 14 edge IPs are documented at /security and rotated quarterly with 30 days notice — subscribe to status-pages subscriptions for the rotation announcements.

debugging

devflow debug tls https://internal-api.example.com --client-cert internal-api

The debug command shows the full TLS handshake, including which client cert was offered, which CA chain was presented by the server, and any verification errors.

not supported

We do not support cert pinning by SHA-256 fingerprint. We considered it; the operational footgun outweighed the threat model on a service that already needs control-plane changes to add a probe. See troubleshooting-false-positives for what to do if you keep getting handshake failures.