Re: [Dovecot] 1.0rc26: ssl_verify_client=yes ?
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 9 Mar 2007, Apostolis Papagiannakis wrote:
Maybe I should post a complete patch if Timo is interested.
Actually, I never thought in this direction, therefore, if it's working, how about you note down your "success story" in the Wiki? Along with your setup. ;-)
I wonder if I can use the certs of our OpenVPN framework ... .
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBRfEwuS9SORjhbDpvAQIa8ggAgwY36GG/zeSOjpfpzI6KeE4XXvUzxbBE z9qaQeb7cviIQfdMYhjyA7c+jCajSsdi3KQn6S961IkBhMOyUu+3+g8BvZVm5i8C Abo8obJvawaGEKC1X8KUuZ5e6sSH1XKP1Dgz0/L96OgV7N18RdKrV5vIH+/H/Tux rDDYnE7jsal3vZ2a3W2VP2xutJ5AVISJAKXxooTktuV5r80G6l23n8s/EiaHASU7 wZNkGuQHAjzaeTYIL4ByTouLrPZfEKWmCnaL6c57+sbX2lcSryJ7KXZLjL3jdXhy 6v+xFt96lZmJCUxO7YA2HybpWfPzwkb40VpSTa3t27bK/jo+iqTdPQ== =dOWp -----END PGP SIGNATURE-----
On 9.3.2007, at 11.40, Apostolis Papagiannakis wrote:
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.
Well, not for v1.0 and even then it would have to be optional so it
wouldn't break existing systems.. I guess if this is done it should
rather be a setting that specifies which field is used for the username.
participants (3)
-
Apostolis Papagiannakis
-
Steffen Kaiser
-
Timo Sirainen