[Dovecot] Thunderbird SSL/TLS client authentication fails

[Roger Hunen]

Hi,

This is my first post to the list, so greetings to you all!

I am seeking your help with SSL/TLS client authentication.

I currently have the following setup:

* Server:
   - Debian Squeeze (fully patched)
   - OpenSSL 0.9.8o
   - Dovecot v2.1.10 (Debian backport package from Wheezy)
   - SSL listener on port 993 with the Dovecot selfsigned
     certificate that was created during installation
   - Virtual users (user at domain.net) with password in passwd
     style file

* Client:
   - Windows XP SP3 (fully patched)
   - Thunderbird 17.0
   - IMAP account using "Normal password" authentication
   - Roundcube webmail (to be added soon)

This works just fine :)

==> I now want to set Thunderbird to use "TLS certificate"
     authentication so that I can safely expose port 993 to
     the internet for mobile use.

The idea is that clients with a trusted client certificate
do not need a password so that I can change my password for
Roundcube without having to change passwords on other IMAP
clients (Roundcube will connect to localhost without SSL).

To do so I did the following:
- use XCA (v0.9.3, Windows version) to setup a private
   root CA with a CRL
- export root CA certificate and CRL in PEM format and
   join them into a ca.pem file (order: certificate, CRL)
- configure Dovecot to use the ca.pem file and require a
   client certificate
- use XCA to generate a private key and certificate for
   commonName=user at mydomain.net
- import certificate and private key into Thunderbird
- change IMAP account setting in Thunderbird to use
   "TLS Certificate" authentication
- When prompted, select the imported certificate to be
   used for authentication.

Unfortunately the authentication fails :(

Using "verbose_ssl=yes" I can see in the Dovecot logfile
that Thunderbird connects and that the SSL handshake completes
successfully. "Valid certificate" is logged for both client
certificate and root CA certificate. This looks "so far so
good" to me :)

The Dovecot log has the following lines at the point of failure:
imap-login: Warning: SSL alert: where=0x4004, ret=256: warning close notify [<IP>]
imap-login: Warning: SSL alert: where=0x4008, ret=256: warning close notify [<IP>]
imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=<IP>, lip=<IP>, TLS, session=<ID>

(IP address and TLS session ID removed)

The last log line ("user=<>") suggests that Dovecot does not try
to use the commonName from the client certificate as the username
even though (I think) I have configured Dovecot to do so.

The relevant lines in the Dovecot configuration are:

<config>

auth_mechanisms              = plain
auth_ssl_require_client_cert = yes
auth_ssl_username_from_cert  = yes
disable_plaintext_auth       = yes
protocols                    = imap
ssl                          = yes
ssl_ca                       = </etc/dovecot/ssl/ca.pem
ssl_cert                     = </etc/ssl/certs/dovecot.pem
ssl_cert_username_field      = commonName
ssl_key                      = </etc/ssl/private/dovecot.pem
ssl_parameters_regenerate    = 0
ssl_require_crl              = yes
ssl_verify_client_cert       = yes

service imap-login {
   chroot            = login
   process_min_avail = 1
   service_count     = 1

   inet_listener imap {
     port = 143
   }

   inet_listener imaps {
     port = 993
     ssl  = yes
   }
}

</config>

Observation: with "auth_ssl_require_client_cert = yes"
Dovecot requires Thunderbird to send the client certificate
even when Thunderbird uses "Normal password" authentication
(authentication only fails if I delete the certificate from
Thunderbird). So the SSL part looks OK to me.

It seems that Dovecot is waiting for the client to logon
over the established SSL/TLS connection instead of taking
the username from the commonName in the certificate.

==> What could be going wrong here?

I can post full config and logfile lines if you wnt to.
Except for some possible oversight on my behalf there is
nothing secret in there (I just didn't want to add too
many lines to this already long post).

Regards,
-Roger