Registry Security
How the registry connection is encrypted, and how it proves who is asking.
These are the registry's own settings, set on its connection form. The broker's security (see Security) says nothing about the registry: it is a separate server with its own gatekeeping, often stricter.
Credentials
A refusal carries the server's own reason, not a bare status: a gateway's "401 Authorization Required" and a registry's "a valid bearer token is required" are fixed differently, and the message keeps them apart.
A 403 on connect counts as success. Under Confluent Cloud's role bindings, a key that may read schemas can be forbidden the endpoint the connect probes; the read path this connection exists for still works, so it is not reported as a failure.
TLS & verification
Trust says where the authority signing the registry's certificate comes from: the system trust store, a CA file, or a pasted CA. A private CA is added to the system roots, not swapped for them, so a private registry can live alongside public hosts.
Verification is the broker's same three-rung ladder (Full,Certificate only, Insecure), with the consequence of a lowered rung spelled out where it is chosen. When no certificate is checked at all, the trust controls are disabled rather than left looking like they still matter.
Client identity (mutual TLS)
For a registry that asks you to prove who you are with a certificate: a certificate and its private key, each a file path or a pasted PEM, with a key password when the key is encrypted. The two halves only exist together, so Connect stays closed until both are filled. Unlike the broker there is no PKCS#12 keystore here; the registry identity is PEM.
In a real deployment mTLS often ends at a gateway in front of the registry, and that gateway answers a missing or wrong certificate with a refusal of its own. That refusal reaches you in the gateway's words ("No required SSL certificate was sent") rather than as unreachable, since the server did answer and the network is not the thing to debug.