Hi,
For the past days we have tried to get a SSL webserver running that does
client authentication either by using client certificates or by using the
username/password combination. When no certificate or a wrong
username/password is given, the client should not be allowed to go in. Why
not only use certificates? Well, we are trying to get things smoothly
deployed here, and giving everyone a client certificate now won't work. So
both mechanisms should be working.
The howto (http://www.modssl.org/docs/2.5/ssl_howto.html#ToC10) describes
this in a fairly simple way :).
We noticed a problem though. The FakeBasicAuth way of client cert
verification uses the DN and a standard password ("password"). You can also
use a non-standard password, but then we would lose the advantage of client
certificates over username/password. We want people with client
certificates to not have to enter a username/password.
OK, using the configuration:
<Directory /usr/local/apache/htdocs/office-ca/secret2/>
# Allow client certs as alternative to basic auth.
SSLRequireSSL
SSLVerifyClient optional
SSLVerifyDepth 3
SSLOptions +FakeBasicAuth +StrictRequire
# Allow username/password authentication
AuthType basic
AuthName "Protected Area"
AuthUserFile /usr/local/apache/conf/users
Require valid-user
</Directory>
we can enter the page using either a client certificate (and the server does
not ask for a username/password) or using a username/password combination.
So far so good. Here comes our problem.
If we take the DN of one of the issued client certificates and put that in
the user field of the username/password box, and enter the password
"password", we *also* gain access. This is clearly *not* what we want. Is
what we want possible at all? Are we missing something here? Please help.
Jan
--
alive=true
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
