Our SSL base servers like SSLrshd(8) use a
set of auth files when determining whether to grant access to a resource.
The file format is backwards compatible with the /etc/ssl.users
from Tim Hudson's SSLtelnet and
/etc/ssl.users is included in the default auth file list
(/etc/ssl.deny, /etc/ssl.root, /etc/ssl.local, /etc/ssl.users,
The auth file format is:
If a match is found in ssl.deny it means the certificate should
be denied access. Matches found in any other auth file, mean that
access should be granted - unless key is deny.
- is the one line distinguished name of the
certificate presented by the client. If it is preceeded by -e,
then cert is a regular expression that can match multiple
certificates. The -e is used to ensure that use of regular
expressions in matching certificates is a conscious decision of the
- is a resource that a remote client wishes to
access. In the case of ssl_rcmd(3) it is a local user-id. If
key is ``root'' a matching certificate may access any resource
(or user-id). Generally, when cert is a regexp, it is useful
to list key as a field to extract from the client certificate.
For example, /CN= would cause any remote user to be able to access a
local resource with the same name as the CommonName field from their
certificate, any field can be selected, though the value is truncated
at the first ``@'' so that an e-mail address can be extracted as a
user-id. Note that a field value of ``root'' will never match,
any certificate which is to be granted root privileges must be
- if present, identifies a host or domain from
which a certificate which maches cert will be accepted.
Normally servers like SSLrshd, do not care where a cert is presented
The exception is a host certificate, which will only be accepted from
a client whoes IP address resolves to a name which matches the domain
specified in the certificate.
See domaincmp(3) for
details. Trusting host based certificates should be avoided as they
re-introduce the possibility of IP address and DNS spoofing which make
the r* commands risky. In the real world however, host to host
transactions are a necessary evil.
When the host certficate contains a wildcard
like /CN=*.crufty.net. The domain
check can be used to limit the matches that will be accepted.
Note that we recommed against ever placing trust in a wildcard host certificate.
$Id: authfile.html,v 1.2 2002/11/27 06:11:51 sjg Exp $