Aleksandar Milivojevic wrote: > I've just started experimenting with new TLS feature. One thing that almost > immediattely popped out. > > It would be good to have "TLS Allowed DN" and "TLS Allowed Peer Certificate" > options (or something shorter for the second one). > > The first option (TLS Allowed DN) would be there since CN might not be unique > enough (actually, I was a bit surprised that initial implementation was > checking the CN, not DN). Especially on sites that already use TLS for other > things and have established nameing conventions. The CN field often contains > only host name, and it is common practice that it is shared by all > certificates > issued for services running on that host (for example, web server and bacula > file daemon running on same machine might have different certificates, signed > by same CA with same CN). On the other hand, DN is uniqe within single CA. > It > would be nice if the CA DN could also be specified (that would solve uniqeness > problem in case when there is several trusted CAs). > > It would be nice if it was possible to match only on part of DN (for example, > like in Apache configuration file). But I guess this would additionally > complicate things (although, I guess for some people it would be usefull > feature).
Adding support for matching the full DN wouldn't be a bad idea, but bear
in mind that TLS Allowed CN is only verified for incoming connections
from a client -- a client certificate must be presented. While normal
host certificates are certainly shared between services, I don't see any
reason for a client certificate to be.
I personally use separate client certificates for specific services,
borrowing from the Kerberos principal naming convention by replacing /
with @, eg:
[EMAIL PROTECTED]
Only the director and bconsole clients require client certificates --
when the file daemon connects to the storage daemon, it presents a
randomly generated magic cookie provided by the director.
Obviously other sites use different naming conventions, and it would be
valuable to support those more fully.
> The second option (TLS Allowed Peer Certificate) would allow usage of
> self-signed certificates for authentication. Setting up CA might be too much
> to ask for small sites. Using the "TLS Allowed Peer Certificate", server
> would
> check if the file pointed by that option contains same certificate (public
> key)
> as the one that client presented.
Setting up a small CA is relatively straight-forward, especially with
software like TinyCA available.
However, if you (or anyone else) would like to implement this feature,
I'd be happy to review the code for inclusion.
-landonf
signature.asc
Description: OpenPGP digital signature
