Mark McLoughlin wrote:
It may also check that the client's IP address is on a whitelist contained in the server configuration file, although by default this check is switched off.And this has nothing to do with TLS or X.509 certificates. It's no different from e.g. libwrap.
Sure, separate issue.
1) Validate the cert was issued by a trusted CA, deny if no 2) Ignore the IP address of client3) First check whether the cert fingerprint is on the list of allowed client fingerprints, allow if yes 4) Otherwise check whether the contents of the SubjectName name field is on the list of allowed client SubjectNames, allow if yes, deny if noPostfix does (3), but not (4). Apache does (4), in a fairly fancy way, but not (3).
My reading of: http://www.postfix.org/TLS_README.html#server_access <quote>The Postfix list manipulation routines give special treatment to whitespace and some other characters, making the use of certificate names impractical. Instead we use the certificate fingerprints as they are difficult to fake but easy to use for lookup.
</quote>... is that Postfix would do (4), but does (3) because of a shortcoming in its configuration file format. (I read "certificate name" to mean DN). We don't have that problem. Mark, what do you think?
Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature