[exim-dev] [Bug 1003] New: Extended (client) certificate ver…

Etusivu
Poista viesti
Vastaa
Lähettäjä: Matthew Cox
Päiväys:  
Vastaanottaja: exim-dev
Aihe: [exim-dev] [Bug 1003] New: Extended (client) certificate verification in ACL
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1003
           Summary: Extended (client) certificate verification in ACL
           Product: Exim
           Version: N/A
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: wishlist
          Priority: medium
         Component: TLS
        AssignedTo: nigel@???
        ReportedBy: matt@???
                CC: exim-dev@???



The only information about client certificates is the distinguished name
available in $tls_peerdn and the verification output which can be checked using
verify = certificate in an ACL. It would be extremely useful to be able to
check the particular (root) certificate which verified the client certificate.

One particular use would be to have a certificate authority which signs
certificates on behalf of clients which are allowed relay access. It is not
sufficient to merely check that a valid certificate is presented, otherwise any
client which can present a certificate signed by any authority (e.g., verisign,
cacert, etc.) would be allowed access. Setting only the permitted-relay
certificate authority's root certificate as the verification certificate
disables the opportunity to check certificates from clients which aren't
relaying for validity and adding a header warning about possible spoofing,
i.e., something like:
X-Warning: Mail recieved from server claiming to be mail.paypal.com, but
server did not present a certificate signed by any recognized authority. This
may indicate a forgery attempt.

I propose that an option to specify a particular certificate by added to the
certificate verification condition. An example would be:

verify = certificate/cert=/etc/mail/valid_relay.pem

The condition would be true only if the client's certificate successfully
verifies against this and only this certificate. It appears that anywhere a
certificate is expected, a directory of certificates may be provided if OpenSSL
is used. This should be the case here for consistency.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email