[PATCH] Mail: added support for SSL client certificate

[Filipe Da Silva]

Hi,

>From the mail-auth-http module point of view, the Auth-Verify is a
trivial information.
Its value mostly depends of the current server configuration ( verify setting ).
IMHO, it could be discard.

About the various/duplicated headers related to the client
certificate, a smart solution
could be adding a   'auth_http_client_cert' setting.

It could be either a kind of bit-field allowing to select the wanted
headers one by one or a log level.

Bit-field doesn't seems to be a part of nginx configuration usages.
Instead, a short list of keywords could be defined, may be following
the OpenSSL display one:
   http://www.openssl.org/docs/apps/x509.html#DISPLAY_OPTIONS

Or, the auth_http_client_cert log levels could be :
- none
- basic -> just the Certificate Subject
- detailed : Subject, Issuer
- complete : Subject, Issuer, sha1 hash
- full -> whole certificate
IMHO, 'detailled' should be the default settings, if not configured.

Regards,
Filipe da Silva

2014-03-18 18:40 GMT+01:00 Franck Levionnois <flevionnois at gmail.com>:
> Hello,
>
> It doesn't seem to exist a standard for this header name. Apache and F5 let
> the user choose it, but this make the configuration more complicated. I
> don't think that the name is a problem, because it can be set on the
> authorization server.
>
> If the certificate is transmited, all other informations are duplicated
> (except Auth-Verify). Forwarding the certificate is the most usefull,
> because it can be used to make controls on its properties.
>
> Kind regards,
> Franck Levionnois.
>
>
>
> 2014-03-07 12:31 GMT+01:00 Maxim Dounin <mdounin at mdounin.ru>:
>
>> Hello!
>>
>> On Fri, Mar 07, 2014 at 09:40:11AM +0100, Franck Levionnois wrote:
>>
>> > Hello,
>> > I haven't seen any comment on this patch. Is it ok for you ?
>>
>> Sorry, I haven't yet had a time to look into it in detail.
>>
>> Most problematic part is still auth_http protocol changes - in
>> particular, headers send and names used for them.  I tend to think
>> there should be better names, and probably we can safely omit some
>> information as duplicate/unneeded.
>>
>> --
>> Maxim Dounin
>> http://nginx.org/
>>
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
>