client certificate authentication

[Matt Lutz]

Hello,

I'm using modwsgi in a dockerized Django application.  Based on the environment I work in, I am requiring a client certificate to authenticate to the web server.  

I use the 'python manage.py runmodwsgi --setup-only' command with some variables.  HTTP works just fine, but I have to manually tweak the HTTPS directives for the site to work properly.  Hopefully someone can point me in the right direction.

The script I use to generate the httpd.conf file is as follows:

python3 manage.py runmodwsgi --setup-only \

--port=8000 \

--reload-on-changes \

--user apache \

--group apache \

--https-port=8443 \

--server-name=xxx.lab.net \

--ssl-certificate-file=/etc/pki/tls/certs/localhost.crt \

--ssl-certificate-key-file=/etc/pki/tls/private/localhost.key \

--ssl-ca-certificate-file=/etc/pki/tls/certs/ca-bundle.crt 

As mentioned, this works just fine for HTTP.  But I get a 'Forbidden' when I use SSL, with a post-handshake error:

[Thu May 13 21:17:47.362027 2021] [ssl:error] [pid 42909:tid 139855358154496] [client 172.18.0.1:55846] AH10158: cannot perform post-handshake authentication

This is curious, as I don't have client auth configured yet from the script.  However, when I look at the generated httpd.conf file, at the end I see this:

<IfDefine MOD_WSGI_VERIFY_CLIENT>

<Location '/'>

SSLVerifyClient require

SSLVerifyDepth 10

</Location>

</IfDefine>

If I comment these lines out, it works without issue to the virtual server on port 8443.  I don't understand why those lines are at the end of the file.  However,  just removing these will not work, as I *do* need to require client cert auth.  

Inside the client verify part of the  '<VirtualHost *:8443>' configuration is this:

<IfDefine MOD_WSGI_VERIFY_CLIENT>

SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt

SSLVerifyClient none

</IfDefine>

If I change that to the following:

<IfDefine MOD_WSGI_VERIFY_CLIENT>

SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt

SSLVerifyClient require

SSLVerifyDepth 10

</IfDefine>

Then everything works as I need.  Messing around with the --ssl-verify-client parameter in the runmodwsgi command did not help, but it's possible I wasn't specifying right.  I also need that 'SSLVerifyDepth' set properly due to the type of client certificates that are being used.

Thanks you for any assistance you can provide.  Sorry if the answer is in the docs... I did not see it.

thanks,

Matt

[Graham Dumpleton]

When you say "This is curious, as I don't have client auth configured yet from the script" wouldn't getting an error be what is expected given that you set up mod_wsgi to expect a client certificate by passing the --ssl-ca-certificate-file option but then didn't supply one from the client.

In other words, it is the presence of --ssl-ca-certificate-file which enables verification of the client. The --ssl-verify-client option only overrides what sub URL paths of the site verification is enabled for. By default the whole site is set to require client verification as soon as you provide --ssl-ca-certificate-file.

So if using the original generated configuration you had:

   --ssl-ca-certificate-file=/etc/pki/tls/certs/ca-bundle.crt --ssl-verify-client=/suburl

accessing the root of the site wouldn't required client verification, but access /suburl would.

Use just:

    --ssl-ca-certificate-file=/etc/pki/tls/certs/ca-bundle.crt

and accessing any part of the site requires client verification.

Graham

--
You received this message because you are subscribed to the Google Groups "modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/78b77aa0-45c0-4563-8f01-df64602a31d0n%40googlegroups.com.

[Matt Lutz]

Graham,

Thanks for the reply, and clearing up the ssl-ca-certificate-file piece.  I didn't realize that it's presence would require a client cert, but that makes more sense, especially why the --ssl-verify-client parameters would be needed on sites that just have portions requiring the cert.

Sorry if I'm being dense on this, but I still don't get why I get the 'post-handshake authentication' error with the generated file, but if I move the client cert directives into the Virtual Host portion of the configuration, it works.  It's the same CA file... any ideas?  The 'Forbidden' error comes through without even prompting the client for a certificate.

I'm sure I'm doing something wrong, and very much appreciate the assistance.

thanks again.

Matt

You received this message because you are subscribed to a topic in the Google Groups "modwsgi" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/modwsgi/dKFTKoXvK04/unsubscribe.
To unsubscribe from this group and all its topics, send an email to modwsgi+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/16DF0F7C-78F6-4D54-8737-D18538140098%40gmail.com.

[Graham Dumpleton]

To be honest, client certificate verification and even SSL as a whole to a degree, is black magic to me.

So I don't know what happens at the protocol level. I don't know if the protocol actually has a process whereby it connects first and only sends the client certificate when asked for it or whether a client sends it up front when told to use it.

When the feature was added to mod_wsgi-express it is likely only the person who asked for it used it in the end if that was why it got added in the first place and it wasn't just me playing with things. It could also well be that you are the first person to ever actually use it in full anger, am not sure, and how it is done is actually broken.

I am a bit hesitant to try and test it as when I did so last time and tried to use a client certificate with a web browser, it well and truly screwed things up as the browser would then try and use the client certificate always with my test host, even when I didn't want it used, as it got cached. Can't remember how I expunged it from the cache so my browser worked properly again.

So all I can ask is as you test it you can keep a good record of the test variations you run and I can look at it. If you can use curl to do testing and show the variations with the exact curl and mod_wsgi-express commands used together, and any errors etc.

Graham

To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/CAHfH%3Duw2jTDxaV81Wi6UsjnaVjU%3DL62aZPmQhekN46RzP6u74Q%40mail.gmail.com.

[Matt Lutz]

Graham,

No problem, I understand that this is definitely a bit of a niche use case.

I'm happy to help if I can.  It seems to me that the problem lies in the conflicting SSLVerifyClient directives ('require' in the '/' Location at the bottom, and 'none' in the 'VirtualHost *:8443' portion of the configuration).  Let me play around with that and I'll see if I can propose a change that will account for this.  In my case I also need to be able to set 'VerifyDepth' to a value different than 1, but one thing at a time.

Thanks,

Matt

To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/9C251D02-55BD-435D-BCCA-70990FA725C2%40gmail.com.

[Graham Dumpleton]

On 14 May 2021, at 9:45 pm, Matt Lutz <matt...@gmail.com> wrote:

Graham,

No problem, I understand that this is definitely a bit of a niche use case.

I'm happy to help if I can.  It seems to me that the problem lies in the conflicting SSLVerifyClient directives ('require' in the '/' Location at the bottom, and 'none' in the 'VirtualHost *:8443' portion of the configuration).  Let me play around with that and I'll see if I can propose a change that will account for this.  In my case I also need to be able to set 'VerifyDepth' to a value different than 1, but one thing at a time.

With the way that Apache handles configuration processing, I would expect that the SSLVerifyClient defined in the Location directive would take precedence over that in the VirtualHost. So it isn't a conflict, that defined in the Location would override the first as Location should trump VirtualHost settings.

Instead of trying to modify the defaults, I would suggest you use --include-file to include a configuration file snippet which attempts to override the prior default values and see what happens.

Graham

To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/CAHfH%3DuwtYKUDAW%3DfzFuzK_d6%2BBLyrJcC%2Bku7gsfBEeD0uGL%2BCw%40mail.gmail.com.