I can add the patch to v2.1, but probably not to earlier versions.
On 11.4.2012, at 0.07, Бранко Мајић wrote:
Another solution could be having another property that specifies whether the information should be pulled in from subject or subjectAltName.
But I think what you've proposed would be ok as well, and it'd allow for future expansion too (if anyone decides to use some other SAN). I can get working on adding the support for this (might take a couple of days until I sort it out - getting quite busy here :).
Would a patch both against the 1.x and 2.x be welcome?
Дана Tue, 10 Apr 2012 19:10:04 +0300 Timo Sirainen tss@iki.fi написа:
On 9.4.2012, at 16.51, Бранко Мајић wrote:
I'm looking into adding support for extracting the username from client certificate's rfc822Name (from the subjectAltName extension).
The question I have is what would be the best approach to do this? Current implementation has a kind of clean code since it just goes through the subject name, extracting the values with X509_NAME_get_text_by_NID (while NID is obtained with OBJ_txt2nid). If I were to add this, it's bound to make the code a little bit more complicated since SAN's can't be retrieved in the same way.
So far in terms of options I have, I can see the following:
- Create a distinct configuration option for the ssl_cert_username_field (i.e. specify something like "sanrfc822Name" to have Dovecot extract the username from the designated alternative name).
I'm not sure if this is a good idea, but what about:
ssl_cert_username_field = subjectAltName:rfc822Name
- Make the current code fail-over to rfc822Name SAN if emailAddress is provided for ssl_cert_username (less invasion in code, but less flexibility as well).
Automatic failover seems dangerous.
-- Branko Majic Jabber: branko@majic.rs Please use only Free formats when sending attachments to me.
Бранко Мајић Џабер: branko@majic.rs Молим вас да додатке шаљете искључиво у слободним форматима.