For a self-hosted Docker registry, require a trusted certificate, keep minimumtls at its default of tls1.2 or move it to tls1.3 if all clients support it, and consider client certificates through clientcas for machine to machine access. The registry docs define each key.
The settings in http.tls
From the configuration reference:
| Key | Meaning | Default |
|---|---|---|
certificate and key | Required paths to your cert and key | none |
minimumtls | Lowest TLS version accepted, tls1.0 to tls1.3 | tls1.2 |
ciphersuites | Optional list of suites | docs give a default set |
clientcas | List of CA files used to verify client certificates | none |
clientauth | How strictly to demand client certificates | require-and-verify-client-cert |
letsencrypt | Automatic certificates; needs cachefile and email | off |
Note that clientauth is ignored if clientcas is not set. So setting only clientauth does nothing.
Minimum version
The default is TLS 1.2, which is a reasonable floor. The configuration allows tls1.0 and tls1.1 as values, but you should not choose them. Check what your oldest client speaks before you move to tls1.3. Build hosts running old Docker engines or custom tooling are the usual blockers.
Client certificates
Client certificates let the registry verify the machine connecting, not just a password. When you set clientcas, the default clientauth demands a valid client certificate. The other allowed values range from request-client-cert to verify-client-cert-if-given, which accepts clients without a certificate but checks one if sent.
Where this helps: CI runners and cluster nodes that you manage. Issue each a certificate from an internal CA, and revoke by retiring the CA or reissuing. Where it hurts: laptops of many developers, where certificate handling creates support work.
Client certificates add to passwords or tokens. They do not replace authorisation, because a valid certificate says who connected, not what they may do.
The certificate itself
The deployment guide says to place a CA issued certificate and key in a directory and point REGISTRY_HTTP_TLS_CERTIFICATE and REGISTRY_HTTP_TLS_KEY at them. If the CA issued an intermediate, concatenate your certificate and the intermediate into one bundle, or clients will fail to build the chain. Let's Encrypt can supply browser trusted certificates automatically.
Where TLS ends
If a proxy or load balancer terminates TLS in front of the registry, these keys live there instead. Then check the proxy's own minimum version and the hop between proxy and registry. A clear text hop inside a network is still a hop someone can reach.
Checklist
- Trusted certificate with the full chain.
minimumtlsattls1.2or higher.- Client certificates for machine clients where practical, with
clientcasset. - Certificate expiry tracked, with an alert well ahead.
- Test with a client that should fail, such as one forced to TLS 1.1.
Safeguard can scan container images and generate SBOMs for what your registry stores, with a free scan at gold.safeguard.sh/scan.
Quick check
What is the default minimum TLS version?
tls1.2, according to the configuration reference.
Why did setting clientauth change nothing?
The docs say it is ignored unless clientcas is also set.
Sources
Last reviewed: 19 October 2026.
