Certificate Authfile

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, /etc/ssl.global).

The auth file format is:

key[,key[,...]]:[-e] cert[:domain[,domain[,...]]]
where:

cert: 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 system administrator.
key: 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 explicitly listed.
domain: 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 from. 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.

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.