[users@httpd] mod_ssl env var to uniquely identify client certificate (sha1 fingerprint ?)
Right off the bat, I want to point out that this is NOT a bug report but rather a feature request/proposal (I don't know whether this is allowed or not ... my apologies if it isn't) In a nutshell what I would like to have is in the SSL environment variables a new variable that uniquely identifies the client certificate (certificate sha1 fingerprint maybe ?). Imagine a (corporate internal) service that does mTLS user authentication. Now (I presume for financial reasons) the company created its own CA and issued thousands of certificates. I can of course add the internal CA to my known CAs list, and I can check of course the SSL_CLIENT_S_DN_CN name, but I cannot guarantee that the CA plays nice (meaning that they might actually create certificates with the same DN or the same SN ... it actually happened). Now, I already have a small subset of certificates in an LDAP, so what I would like to do is to authorize access based on certificate fingerprint. If I would have the (sha1 ...) fingerprint in a environment variable (let us say SSL_CLIENT_CERT_SHA1) I could do something like : SSLUserName SSL_CLIENT_CERT_SHA1 AuthType Basic AuthBasicProvider ldap AuthLDAPURL "ldaps://ldaphost/ou=accounts,dc=test,dc=com?uid" Where of course the ldap uids would be the fingerprints. I hope this would make sense to more people... Rgards
Re: [users@httpd] nod_session SessionMaxAge
Eric,
I'm not sure I understand your last comment. Isn't a "Directory" a
"protected space" ?
For the sake of completeness here is my full config (I hope this doesn't
make my post too long):
ServerAdmin webmaster@localhost
DocumentRoot /opt/webroot/public/doc
ErrorLog ${APACHE_LOG_DIR}/https_error.log
#CustomLog ${APACHE_LOG_DIR}/https_access.log combined
CustomLog ${APACHE_LOG_DIR}/https_access.log vhost_ssl_combined
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/server/https.crt
SSLCertificateKeyFile /etc/apache2/ssl/server/https.key
#SSLCACertificatePath /etc/apache2/ssl/ca/
SSLCACertificateFile /etc/apache2/ssl/ca/users_chain.crt
Options None
AllowOverride None
Require all granted
Options Indexes
AllowOverride None
AuthFormProvider file
AuthUserFile "conf/passwd"
Require valid-user
AuthType Form
AuthName FormProtected
AuthFormUsername fauser
AuthFormPassword fapass
Session On
SessionCookieName fasession path=/
SessionMaxAge 120
ErrorDocument 401 /webdoc1/login.html
SSLOptions +StdEnvVars +ExportCertData
Alias /webdoc1 /opt/webroot/public/doc
ScriptAlias /webscr1 /opt/webroot/private_form/scr
In the "/opt/webroot/public/doc" folder I have a simple static html asking
for username/pass (obviously with the right field names fauser/fapass)
whereas in the "/opt/webroot/private_form/scr" I have a simple shell
script which just displays the environment.
Now if I point my browser to "https://172.17.0.3:13443/webscr1/testscript.sh;
I am redirected to the login page (as expected).
Once I provide the username/pass I am redirected to the script and it
correctly lists all environment variables.
The problem I have is that it seems that the browser caches the provided
username/pass and in case I refresh the page after 120 secs of inactivity
it just simply logs me in again.
I know it does authenticate again from the cache 'cos (as a test) I've
tried to change the password in the meanwhile and the authentication has
failed.
In practical terms, what this means is that if the user forgets the
browser window open the next one (even after 120 secs) would be able to
use the session without re-authenticating.
So then what's the point of the "SessionMaxAge" setting ?
On Sun, Jun 5, 2022 at 12:54 PM Eric Covener wrote:
> I'm not sure why your initial redirect works, but it looks like the
> mod_auth_form config seems to be in the wrong scope.
>
> It should be attached to the protected space, not a config section
> representing the form itself.
>
> On Sun, Jun 5, 2022 at 6:18 AM Eric Covener wrote:
> >
> > It looks to me like you don't actually have an authentication
> requirement, so when your session expires it doesn't trigger a redirect to
> your login form. Try protecting the cgi or some larger scope with e.g.
> 'require valid-user'
> >
> > On Sun, Jun 5, 2022, 6:00 AM Thomas Fazekas
> wrote:
> >>
> >> Dear all,
> >>
> >> either I misunderstood how the SessionMaxAge setting is supposed to
> work or I made a fundamental mistake in my setup, but, in a nutshell, it
> seems that the users can access the form protected (form_auth) folder even
> after the session has expired.
> >>
> >> I have the following related setup :
> >>
> >>
> >> Options None
> >> AllowOverride None
> >> Require all granted
> >>
> >>
> >>
> >> AuthFormProvider file
> >> AuthUserFile "conf/passwd"
> >> AuthType Form
> >> AuthName FormProtected
> >> AuthFormUsername fauser
> >> AuthFormPassword fapass
> >> Session On
> >> SessionCookieName fasession path=/
> >> SessionMaxAge 120
> >>
> >> ErrorDocument 401 /webdoc/login.html
> >>
> >>
> >>
> >> Alias /webdoc /opt/webroot/public/doc
> >> ScriptAlias /webscr
> /opt/webroot/private_form/scr
> >>
> >>
> >> (all this goes on via SSL, just in case that makes any difference)
> >> Now, when the first time I point my browser to "
> https://localhost/webscr/testscript; I am correctly redirected to the
> login page and required to provide a username and pass.
> >> The problem is that, after successfully logging in, even though I can
> see the session cookie e
Re: [users@httpd] nod_session SessionMaxAge
Thx for the quick reply ... and my apologies for the incomplete setup (copy-paste typo) I do have in fact an authentication requirement via "Require valid-user" (as a point proving that, when the first time I try to access the script I am redirected to the login page) I think I know what is happening : whenever my session expires and I refresh the page the browser simply resubmits the form so it logs me in again : [image: image.png] So if I'm right, the question would be, how do I protect the site against that ? On Sun, Jun 5, 2022 at 12:19 PM Eric Covener wrote: > It looks to me like you don't actually have an authentication requirement, > so when your session expires it doesn't trigger a redirect to your login > form. Try protecting the cgi or some larger scope with e.g. 'require > valid-user' > > On Sun, Jun 5, 2022, 6:00 AM Thomas Fazekas > wrote: > >> Dear all, >> >> either I misunderstood how the SessionMaxAge setting is supposed to work >> or I made a fundamental mistake in my setup, but, in a nutshell, it seems >> that the users can access the form protected (form_auth) folder even after >> the session has expired. >> >> I have the following related setup : >> >> >> Options None >> AllowOverride None >> Require all granted >> >> >> >> AuthFormProvider file >> AuthUserFile "conf/passwd" >> AuthType Form >> AuthName FormProtected >> AuthFormUsername fauser >> AuthFormPassword fapass >> Session On >> SessionCookieName fasession path=/ >> SessionMaxAge 120 >> >> ErrorDocument 401 /webdoc/login.html >> >> >> >> Alias /webdoc /opt/webroot/public/doc >> ScriptAlias /webscr /opt/webroot/private_form/scr >> >> >> (all this goes on via SSL, just in case that makes any difference) >> Now, when the first time I point my browser to " >> https://localhost/webscr/testscript; I am correctly redirected to the >> login page and required to provide a username and pass. >> The problem is that, after successfully logging in, even though I can see >> the session cookie expiration set to 2 mins, if I wait longer than that >> without closing my browser, >> in case of a simple refresh of the page I'm being allowed back in without >> needing to re-authenticate. >> >> The "https://localhost/webscr/testscript; it's just a simple shell >> script that returns all environment variables. >> >> Now, even though I keep the browser open, if I refresh the page after the >> expiration period shouldn't I be forced to the login page again ? What am I >> missing ? >> >> Thanks in advance, >> Thomas >> >> >>
[users@httpd] nod_session SessionMaxAge
Dear all, either I misunderstood how the SessionMaxAge setting is supposed to work or I made a fundamental mistake in my setup, but, in a nutshell, it seems that the users can access the form protected (form_auth) folder even after the session has expired. I have the following related setup : Options None AllowOverride None Require all granted AuthFormProvider file AuthUserFile "conf/passwd" AuthType Form AuthName FormProtected AuthFormUsername fauser AuthFormPassword fapass Session On SessionCookieName fasession path=/ SessionMaxAge 120 ErrorDocument 401 /webdoc/login.html Alias /webdoc /opt/webroot/public/doc ScriptAlias /webscr /opt/webroot/private_form/scr (all this goes on via SSL, just in case that makes any difference) Now, when the first time I point my browser to " https://localhost/webscr/testscript; I am correctly redirected to the login page and required to provide a username and pass. The problem is that, after successfully logging in, even though I can see the session cookie expiration set to 2 mins, if I wait longer than that without closing my browser, in case of a simple refresh of the page I'm being allowed back in without needing to re-authenticate. The "https://localhost/webscr/testscript; it's just a simple shell script that returns all environment variables. Now, even though I keep the browser open, if I refresh the page after the expiration period shouldn't I be forced to the login page again ? What am I missing ? Thanks in advance, Thomas
[users@httpd] mod_ssl certificate (mutual) authentication
OS : Debian 10.9
Apache : 2.4.38 (from repo)
I presume I've missed something (obvious) in the doc, but the following
setup doesn't work for me and I believe it should :
Options Indexes
AllowOverride None
SSLVerifyClient require
SSLVerifyDepth 5
SSLOptions +StdEnvVars +ExportCertData +FakeBasicAuth
SSLRequireSSL
SSLRequire true
#SSLRequire %{SSL_CLIENT_S_DN_CN} eq "testuser"
ScriptAlias /scr2 /opt/wwwdoc/private2/script
I try to hit this folder with :
curl -v --cert testuser.cer --key testuser.rsa.key --data @test.txt
https://172.17.0.3:443/scr2/dropoff
According to my logic the above config should check whether the
certificates are valid and then let people in but instead no matter what I
try (and the certs are valid) I get an access denied (403)
I however I go with the following :
Options Indexes
AllowOverride None
SSLVerifyClient require
SSLVerifyDepth 5
SSLOptions +StdEnvVars +ExportCertData +FakeBasicAuth
SSLRequireSSL
Require all granted
After the certificate check the users are let in. What am I missing ?
Obliviously my ultimate goal is to check the certificate CN value (as you
can see in the first config). That doesn't work either.
Thomas
[users@httpd] Client certificate authentication against (Open)LDAP server
OS : Debian 10.7 Apache HTTPD : 2.4.38 (from standard repo) Dear, my setup is as follows : above mentioned Apache connecting to OpenLDAP. User basic authentication (username/password) already works (against LDAP inetOrgPerson structure) What I would like to achieve is to have user certificates in the inetOrgPerson->userCertificate attribute and the users would have to authenticate against that by presenting the corresponding private key. Like one would do by : curl -u test_01 --key priv.key https://test.com 2 questions : 1. is the above possible to achieve by any configuration/module or do I have to try to code this ? 2. if the above is true, I suspect I still need the username to be provided by the user, right ? (it would be like username/password authentication but instead of a password the user would provide a private key) Thanks in advance
Re: [EMAIL PROTECTED] svn access via apache with ntlm authentication
Thanks for all the hints, finally I got it working with LDAP authentication. For now, I'm happy with that although indeed seems a bit slow... For future references here is my config (although is staright forward and it can be found on many web resources) Location /svn/repos # Enable Subversion DAV svn SVNPath /mnt/data/rep/svn # LDAP Authentication Authorization is final; do not check other databases AuthLDAPAuthoritative on # Do basic password authentication in the clear AuthType Basic # The name of the protected area or realm AuthName domain authentication # Active Directory requires an authenticating DN to access records # This is the DN used to bind to the directory service # This is an Active Directory user account AuthLDAPBindDN CN=someuser,CN=Users,DC=your,DC=domain # This is the password for the AuthLDAPBindDN user in Active Directory AuthLDAPBindPassword # The LDAP query URL # Format: scheme://host:port/basedn?attribute?scope?filter # The URL below will search for all objects recursively below the basedn # and validate against the sAMAccountName attribute AuthLDAPURL ldap://pdc:389/DC=your,DC=domain?sAMAccountName?sub?(objectClass=*) # Require authentication for this Location Require valid-user /Location Thomas On 10/21/07, Krist van Besien [EMAIL PROTECTED] wrote: On 10/21/07, Joshua Slive [EMAIL PROTECTED] wrote: On 10/20/07, Thomas Fazekas [EMAIL PROTECTED] wrote: In coclusion, svn with NTLM authentication doesn't work... My problem is that I can't see any other solution how to bring together a linux based apache/svn with our NT4 based domain :( For the time being I'm just gonna go with win based NT server, it is dissapointing though that I didn't get any reply from the svn mailing list... If all you need is to share the user/password database, then the standard solution is use ldap access to the NT domain info. I've never done it myself, but I believe lots of people have success with this. I've set up an apache/svn server that authenticates against an AD server, but I didn't use the standard way with mod_auth_ldap. The problems with using mod_auth_ldap are: - AD normally does not allow anonymous binds, so you need a BindDN for your apache server. An other problem was our security policy, that requires passwords to be changed every month. - Subversion over http is not very efficient. A lot of seperate requests are generated for each subversion action. Basically subversion uses dozens of PROPFIND requests to figure out the properties of a file, and each of these requests gets authenticated. As LDAP binds aren't very fast our SVN server wasn't excrutciatingly slow when using ldap authentication. My solution was to use mod_perl (which I allready use for webserver configuration) and extend the authentication mechanism using perl modules. One of the interesting feature of perl authentication handlers is that you can stack them. This allows you to cache authentication requests, and this speeds up the server massively. To explain this, let me just show you haw it looks in my config file: AuthType Basic AuthName SVNServer PerlAuthenHandler Apache2::AuthenDBMCache Apache2::AuthenMSAD PerlSetVar MSADDomain ads.foo.com PerlSetVar MSADServer dc.ads.foo.com require valid-user require user joe mary tom For this to work you need to have an apache server configured for mod_perl, and the Apache2::AuthenDBMCache and Apache2::AuthenMSAD modules. You can find these on CPAN. The Apache2::AuthenMSAD uses a feature of MS Active Directory: You can bind with a DN of user@domain. With this you can set up AD authentication for your apache server without needing an BindDN for your apache server itself. The Apache2::AuthenDBMCache modules caches the authentication info, so that not every request requires a connection with the AD server. This has made my SVN server a lot faster. This works for me. More info about these modules can be found in CPAN. Krist -- [EMAIL PROTECTED] [EMAIL PROTECTED] Bremgarten b. Bern, Switzerland -- A: It reverses the normal flow of conversation. Q: What's wrong with top-posting? A: Top-posting. Q: What's the biggest scourge on plain text email discussions? - The official User-To-User support forum of the Apache HTTP Server Project. See URL:http://httpd.apache.org/userslist.html for more info. To unsubscribe, e-mail: [EMAIL PROTECTED] from the digest: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - The official User-To-User support forum of the Apache HTTP Server Project. See URL:http://httpd.apache.org/userslist.html for more info
Re: [EMAIL PROTECTED] svn access via apache with ntlm authentication
In coclusion, svn with NTLM authentication doesn't work... My problem is that I can't see any other solution how to bring together a linux based apache/svn with our NT4 based domain :( For the time being I'm just gonna go with win based NT server, it is dissapointing though that I didn't get any reply from the svn mailing list... Thomas On 10/18/07, Krist van Besien [EMAIL PROTECTED] wrote: On 10/18/07, Joshua Slive [EMAIL PROTECTED] wrote: On 10/18/07, Krist van Besien [EMAIL PROTECTED] wrote: The current version of Neon (the http library used in the command line subversion client) only supports basic authentication. That's not true. Neon supports digest and a couple others as well. I'm not sure if they are supported via subversion, however. According to the subversion site the svn command line client only supports basic authentication. I didn't check the neon project itself. Krist -- [EMAIL PROTECTED] [EMAIL PROTECTED] Bremgarten b. Bern, Switzerland -- A: It reverses the normal flow of conversation. Q: What's wrong with top-posting? A: Top-posting. Q: What's the biggest scourge on plain text email discussions? - The official User-To-User support forum of the Apache HTTP Server Project. See URL:http://httpd.apache.org/userslist.html for more info. To unsubscribe, e-mail: [EMAIL PROTECTED] from the digest: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - The official User-To-User support forum of the Apache HTTP Server Project. See URL:http://httpd.apache.org/userslist.html for more info. To unsubscribe, e-mail: [EMAIL PROTECTED] from the digest: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED] svn access via apache with ntlm authentication
My setup : Debian Etch i386 httpd-2.0.61 configured with the following command ./configure --prefix=/opt/httpd-2.0.61 --with-mpm=worker --enable-so --enable-dav=shared --enable-unique-id=shared --enable-version=shared --enable-ssl=shared --enable-info=shared --enable-cgi=shared --enable-rewrite=shared --enable-cache=shared -- enable-disk-cache=shared --enable-deflate=shared subversion-1.4.5 configured with the following ./configure --prefix=/opt/subversion-1.4.5 --with-apr=/opt/ httpd-2.0.61 --with-apr-util=/opt/httpd-2.0.61 --with-apxs=/opt/ httpd-2.0.61/bin/apxs mod_auth_ntlm_winbind AFAIK the latest version compiled with /opt/httpd-2.0.61/bin/apxs -DAPACHE2 -c -i mod_auth_ntlm_winbind.c Now, AFAIT everything is working well... separately ! Apache serves documents, svn works for anonymous access with the following config : Location /svn/repos DAV svn SVNPath /mnt/data/rep/svn /Location /svn/repos I can check out projects from the repository Then I've tested the NTLM authentication with Alias /ntlmtest/ /mnt/data/docuwiki/ Directory /mnt/data/docuwiki AuthName NTLM Authentication NTLMAuth on NTLMAuthHelper /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp NTLMBasicAuthoritative on AuthType NTLM require valid-user /Directory This works just fine, the browser prompts for the username and password, and ntlm authenticates against our PDC Now my problem is with the svn + NTLM combination If I have in my httpd.conf Location /svn/repos DAV svn SVNPath /mnt/data/rep/svn AuthName NTLM Authentication AuthType NTLM NTLMAuth on NTLMBasicAuthoritative on NTLMAuthHelper /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp require valid-user /Location and I do svn co http://svnhost/svn/repos/test; , it seems to me that the apache server doesn't even bother calling the ntlm_winbind module for authentication... There are no logs or any trace of related messages and all I get is svn: PROPFIND request failed on '/svn/repos/test' svn: PROPFIND of '/svn/repos/test': authorization failed (http:// svnhost) at the client side. Any ideas ? Thomas - The official User-To-User support forum of the Apache HTTP Server Project. See URL:http://httpd.apache.org/userslist.html for more info. To unsubscribe, e-mail: [EMAIL PROTECTED] from the digest: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
