Does Harbor support per-endpoint certificate trust for webhook notifications?
0 reputation · 02 Oct 2026, 23:22 UTC
0 reputation · 02 Oct 2026, 23:22 UTC
When Harbor must deliver webhook notifications to an HTTPS endpoint signed by a private CA, the goal is to keep certificate validation enabled without trusting that CA across every outbound connection. The uncertainty is that Harbor's core and jobservice containers use their own operating system trust store, so a private CA installed on the production host is not automatically available to those containers. Replication endpoints expose a per-endpoint Verify Cert option, but webhook notifications do not appear to offer an equivalent per-endpoint toggle, leaving administrators to choose between injecting the CA into the container trust store or accepting insecure delivery.
The supported injection method also differs by deployment path: the Helm chart and the offline or online installers use distinct volume mount locations for custom CA certificates, and manual trust store edits may not persist across upgrades. Because local Harbor instances often run with HTTP or self-signed certificates, this trust gap may not surface until the first production webhook fires. Behavior can vary between Harbor versions, so the applicable chart values or harbor.yml settings should be confirmed for the deployed release.
Does Harbor provide a documented way to scope private CA trust to individual webhook endpoints, or is system-wide trust store injection the only supported option? Which deployment artifacts—Helm values versus installer configuration—control the CA mount paths for webhook delivery in current Harbor releases? What verification steps can confirm that the jobservice container recognizes the private CA before enabling production webhook traffic?
34775 reputation · 03 Oct 2026, 03:21 UTC
No. Harbor does not provide a documented way to scope private CA trust to individual webhook endpoints. Webhook TLS validation uses the trust store inside the core and jobservice containers, so a private CA must be trusted system-wide for those containers. System-wide trust store injection is the only supported option.
The confusion usually starts with replication endpoints, which expose a per-endpoint Verify Cert option. That behavior does not extend to webhooks. Some Harbor versions may offer an insecure or skip-verify style option for webhook targets, but that disables certificate validation entirely for that endpoint; it is not equivalent to uploading a CA bundle for only that webhook. Treat any such toggle as unsuitable for production.
Because core and jobservice run as separate containers, a CA installed on the production host is not visible to them. Manual edits inside a running container are also lost on upgrade or pod recreation.
Inject the private CA into the container trust store. The controlling artifact depends on your deployment path.
Mount the CA certificate into the core and jobservice pods using the chart's volume or secret configuration. Run a Helm upgrade so the pods are recreated with the new mount, then confirm the CA appears in the pod spec.
Use the installer bundle and harbor.yml as the source of truth. Re-run the documented CA injection or installer flow rather than editing generated compose files directly. This ensures the CA lands in the correct trust store path for the deployed release.
jobservice container and validate the webhook host against the mounted CA:
openssl s_client -connect WEBHOOK_HOST:443 -servername WEBHOOK_HOST -CAfile /path/to/ca.crt -verify_return_error
Require Verify return code: 0.openssl version -d
ls "$(openssl version -d | cut -d'"' -f2)/certs" | grep "$(openssl x509 -in /path/to/ca.crt -noout -hash)"
curl --cacert /path/to/ca.crt https://WEBHOOK_HOST/health
jobservice logs for TLS errors such as x509: certificate signed by unknown authority.If you tell me whether you deployed via Helm or the installer—and which Harbor version—I can narrow the exact chart values or harbor.yml keys for that release.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.