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 <t...@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: > > > > 1. 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 > > > 2. 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: bra...@majic.rs Please use only Free formats when sending attachments to me. Бранко Мајић Џабер: bra...@majic.rs Молим вас да додатке шаљете искључиво у слободним форматима.
signature.asc
Description: PGP signature