Convoy supports custom Certificate Authority (CA) certificates for TLS verification, enabling secure connections to endpoints with certificates signed by private or internal Certificate Authorities.
Note:
- The Custom Certificate Authority functionality is available only for licensed users.
- This feature requires a valid license with Custom Certificate Authority access enabled.
Overview
When connecting to HTTPS endpoints that use certificates signed by private or internal Certificate Authorities, Convoy needs to trust those CA certificates to perform proper TLS verification. The Custom Certificate Authority feature allows you to configure Convoy with your internal CA certificates.
Architecture
With custom CA certificates configured, Convoy can verify TLS connections to endpoints using certificates signed by your internal Certificate Authorities, while maintaining security and proper certificate validation.
Custom CA certificates are loaded alongside system CA certificates, providing trust for both public and private certificate authorities.
Configuration
JSON Configuration
You can configure custom CA certificates by adding the dispatcher object to your configuration JSON:
{
"dispatcher": {
"ca_cert_path": "/path/to/ca-certificate.crt"
}
}
Environment Variables
Alternatively, you can use environment variables to configure custom CA certificates:
CONVOY_DISPATCHER_CACERT_PATH="/path/to/ca-certificate.crt"
Helm Chart Configuration
If you’re using the Helm chart, you can configure CA certificates through the values:
global:
convoy:
cacert_content: |
-----BEGIN CERTIFICATE-----
# Your CA certificate content
-----END CERTIFICATE-----
# OR
cacert_secret_name: "my-ca-cert-secret"
Creating Kubernetes Secret
If using cacert_secret_name, create the secret separately:
kubectl create secret generic my-ca-cert-secret \
--from-file=ca.crt=/path/to/your/ca-certificate.crt
Certificate Requirements
- Content structure: Must be in PEM format with BEGIN/END markers
- Certificate type: CA certificate (not endpoint certificate)
Example Certificate Structure
-----BEGIN CERTIFICATE-----
MIIFtzCCA5+gAwIBAgIUIYdQv74LF6tTl3VXgrlOtmP4ISIwDQYJKoZIhvcNAQEL
... (base64 encoded certificate content) ...
-----END CERTIFICATE-----
Implementation Details
How It Works
- Certificate Loading: Convoy loads your custom CA certificate during startup
- Trust Store: The certificate is added to the TLS trust store
- TLS Verification: All HTTPS connections use the combined trust store
- Security: Maintains proper certificate validation while supporting custom CAs
Component Coverage
The Custom Certificate Authority configuration applies to all Convoy components:
- Server: Validates endpoints during creation/update
- Agent: Delivers webhooks to endpoints
- Worker: Processes webhook delivery tasks
Troubleshooting
Common Issues
”x509: certificate signed by unknown authority” Error
If you’re getting this error after configuring a custom CA certificate:
- Check License: Ensure your license includes Custom Certificate Authority feature
- Verify Configuration: Confirm CA certificate path and format
- Restart Services: Restart Convoy after adding CA certificate
- Check Logs: Look for CA certificate loading messages
Feature Not Available
If you see “Custom Certificate Authority feature unavailable” errors:
- Contact sales to upgrade your license
- Verify license key is properly configured
- Verify certificate is in PEM format
- Check certificate content starts with
-----BEGIN CERTIFICATE-----
- Ensure the file is readable by the Convoy process
Debug Commands
# Verify certificate format
openssl x509 -in ca-certificate.crt -text -noout
# Check if certificate is properly mounted (Kubernetes)
kubectl exec convoy-server-<pod-id> -- ls -la /etc/convoy/
# Verify environment variable
kubectl exec convoy-server-<pod-id> -- env | grep CONVOY_DISPATCHER_CACERT_PATH
# Check Convoy logs for CA loading
kubectl logs convoy-server-<pod-id> | grep -i "ca\|cert\|tls"
Best Practices
Security
- Use Kubernetes secrets for certificate storage
- Rotate certificates regularly
- Monitor certificate expiration dates
- Limit access to certificate secrets
Configuration
- Use
cacert_secret_name for production (more control)
- Use
cacert_content for development/testing (easier)
- Document which certificates are trusted
- Version control your configuration
Maintenance
- Plan certificate rotation procedures
- Test certificate updates in non-production first
- Keep backup of original certificates
- Monitor for certificate-related errors