Date: Thu, 08 Mar 2007 18:13:48 +0200 From: Timo Sirainen <tss@iki.fi> Subject: Re: [Dovecot] 1.0rc26: ssl_verify_client=yes ?

On Thu, 2007-03-08 at 16:40 +0100, Steffen Kaiser wrote:

...

...

On Thu, 8 Mar 2007, Timo Sirainen wrote:

...

...

...

...

> Q2) > The next step, if dovecot blocks the client because > of the verify_client_cert, how to create certs for OE, > Evolution and Thunderbird?

...

I don't think most clients support SSL client certificates at all, although I know some people are using them with some clients.. Maybe someone could add a list of the clients supporting them into wiki.

Er, a dummy question, I guess: Can you use client certs to login into Dovecot? Aka can use the certs as "passdb"?

Yes. It will still need some passdb, but you could use null password and ssl_username_from_cert=yes settings in which case it doesn't matter what user/password is used to log in.

But it circumvents Dovecot's login/auth process security model, so I don't recommend it that much. Maybe some day I'll make login process forward the client cert to dovecot-auth which does the actual verification.

I have successfully tested ssl_username_from_cert and found no real 

problem, apart from the fact that dovecot "username" takes the value of the certificate "CN" attribute , instead of the email attribute (in my case "Apostolos Papayanakis" instead of apap/ at /ccf.auth.gr). Everything else works as expected (eg, further userdb lookups based on certificate CN). Our University has issued a few thousand certificates with subjects such as "/C=GR/O=Aristotle University of Thessaloniki/OU=Network Operations Center/CN=Apostolos Papayanakis/emailAddress=apap/ at /ccf.auth.gr", that are used for administrative purposes. We would be very happy to use them as an alternative method of IMAP/POP3 authentication. However certificate CNs are not unique (e.g. "John Smith") and we would like to avoid constantly patching dovecot to use the email (or other) attribute from the certificate.

I think replacing NID_commonName with NID_pkcs9_emailAddress ( or NID_subject_key_identifier, or NID_subject_alt_name) in login-common/ssl-proxy-openssl.c, line 527 would suffice. (X509_NAME_get_text_by_NID(X509_get_subject_name(x509), NID_commonName, buf, sizeof(buf)) < 0).

Maybe I should post a complete patch if Timo is interested.

Apostolis