[Dv2Corn]

Summary

The tls option that adds extra trusted CA certificates is only read from the misspelled key custom-certifactes. A config that uses the correct spelling custom-certificates loads without any warning, but the certificates are never added to the trust store, so TLS connections that rely on them fail certificate verification, and nothing points back at the config key.

Root cause

The YAML/JSON tag of RawTLS.CustomTrustCert carries the typo (config/config.go#L401), and the example config documents the same spelling (docs/config.yaml#L61). The key was introduced in b6b6413, whose commit message already calls it custom-certificates. Unknown keys are ignored by the decoder, so the correct spelling is silently dropped.

Fix

• RawTLS.CustomTrustCert now reads custom-certificates.
• The old key is kept as CustomTrustCertDeprecated (custom-certifactes) so existing configs keep working. parseTLS (config/config.go#L869) logs a deprecation warning when it is used.
• If both keys are set, the certificates from both are trusted (new key first, then the old one). Nothing a user configured is dropped, and ca.AddCertificate in hub/executor/executor.go#L92 keeps working on the merged list unchanged.
• docs/config.yaml uses the correct spelling.

The JSON tag of the field changes in the same way as the YAML tag. If the old spelling should be removed in a future release, only the deprecated field and the warning need to go.

Tests

config/tls_test.go adds TestParseTLSCustomCertificates, which covers no key, the correct key, the deprecated key, and both keys together. Before the fix the "correct key" and "both keys" cases fail (the certificate under custom-certificates is missing); after the fix all cases pass. go test ./config/ ./hub/..., go vet ./config/ ./hub/executor/, go build ./... and gofmt -l are clean.

Fixes #3351