Question
SSL Handshake Failure during Client Certificate Verification in Dovecot
Neel Atlas
0 reputation · 23 Sept 2024, 02:55 UTC
132.9K views
Loading…
0 reputation · 23 Sept 2024, 02:55 UTC
A Dovecot configuration requires mutual TLS (mTLS) to authenticate clients via certificates. While the ssl = yes and ssl_cert directives are configured for the server identity, the system must also validate the incoming client certificates against a trusted root.
The current uncertainty involves the behavior of the ssl_ca directive when managing a complex trust store. If the CA bundle is incomplete or the backend (OpenSSL vs GnuTLS) handles the chain verification differently, the handshake may fail without a clear indication of which certificate in the chain is missing.
ssl_ca directive points to a directory of certificates versus a single concatenated bundle?33275 reputation · 23 Sept 2024, 04:04 UTC
Use a single concatenated PEM bundle for ssl_ca, not a directory, unless your Dovecot version and SSL backend explicitly document directory or CApath support. ssl_ca provides the trusted anchor CAs for client certificates. Dovecot does not fetch missing intermediates. If the client sends only its leaf certificate and the issuing intermediate is not already a trusted anchor in ssl_ca, the handshake fails. The client must send the leaf plus any intermediates needed to build a chain to a root in ssl_ca.
dovecotssl_ca supplies trusted CA anchors when client-certificate verification is enabled.ssl_ca; OpenSSL builds may support hashed CApath semantics, while GnuTLS or older Dovecot versions may ignore or reject it.unknown_ca or bad_certificate and may not name the missing certificate./etc/dovecot/ca-client-root.pem.ssl_ca = /etc/dovecot/ca-client-root.pem in the relevant Dovecot service block.ssl_ca unless you intend to trust them directly as authorization anchors.dovecot --version dovecot -n | grep -i ssl
openssl s_client -connect host:port -cert client.pem -key client.key -CAfile server-ca-bundle.pem -showcerts
Repeat the openssl s_client test with the client intermediate omitted to confirm the expected failure.
Provide your Dovecot version and SSL backend (OpenSSL or GnuTLS). Directory-based ssl_ca handling differs between backends and versions, and this detail determines whether a hashed directory can be supported instead of a bundle.
Assumption: client-certificate verification is already enabled for the service. This answer covers trust-store configuration, not certificate authorization or username mapping.
Review note: this draft relies on general Dovecot and OpenSSL behavior and has not been verified against your running configuration. Confirm the version and backend before adopting directory-based trust storage.
Use comments to ask for clarification. Post a solution as an answer.
33,275 reputation · 23 Sept 2024, 13:32 UTC
When the ssl_ca directive points to a directory under the OpenSSL backend, Dovecot expects each PEM file to be hash‑indexed (e.g., xxxxxx.0) as produced by c_rehash. If the directory contains plain PEM files without the hash symlinks, Dovecot will read only the first certificate and ignore the rest, causing client‑certificate verification to fail even though the needed intermediate is present. The GnuTLS backend typically treats ssl_ca as a single file and ignores directory paths, so using a directory there will have no effect.