Give users of your intranet client certificates to authenticate with.
Advantages: No passwords to mess around with.
Disadvantages: Certificate management is hard.
OpenSSL will do that. So will a variety of commercial products.
A typical client certificate (human-readable form):
Subject:
C=US
SP=NY
L=Cold Spring Harbor
O=Cold Spring Harbor Laboratory
OU=Sales
CN=Wanda Smith
Email=wanda@cshl.org
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 866229881 (0x33a19e79)
Signature Algorithm: md5WithRSAEncryption
Issuer:
C=US
SP=NY
L=Cold Spring Harbor
O=Cold Spring Harbor Laboratory
OU=Information Services
CN=Cold Spring Harbor Laboratory Root CA
Email=lstein@cshl.org
Validity:
Not Before: Jun 13 19:24:41 2000 GMT
Not After : Jun 13 19:24:41 2001 GMT |
SSLCACertificateFile conf/ssl.crt/ca.crt # or ca-bundle.crt SSLVerifyClient optional |
Insists that client present a valid signed certificate -- any certificate.
<Location>
SSLRequireSSL
SSLVerifyClient require
</Location> |
"Any certificate is OK as long as it is valid and I recognize the CA that signed it."
In addition to presenting a valid signed certificate, certificate must meet conditions:
<Location>
SSLRequireSSL
SSLRequire %{SSL_CLIENT_S_DN_CN} in {"Wanda Smith","Joe Blow"} \
and %{SSL_CLIENT_S_DN_O} eq "Cold Spring Harbor Laboratory"
</Location> |
"Only allow certificates whose Common Name (CN) field is 'Wanda Smith' or 'Joe Blow', and the Organization (O) is "Cold Spring Harbor Laboratory."
|
| Contents | Next |