-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Client Certificate Support #80
Comments
You would need to remove the SSL Client cert requirement to the /cas/*Validate endpoints. |
If you feel comfortable modifying source and just want to test to see if this works, look at mod_auth_cas.c and add the following lines in getResponseFromServer():
You'll have to hardcode the paths and use a PEM cert/key. Please note that I haven't even compiled this, but it may get you where you want to be. I can whip up a patch with config options in the near future. |
I believe you just want to exclude the validation endpoints from the SSL On Fri Oct 31 2014 at 8:45:43 PM David Hawes [email protected]
|
Or, instead, are you hoping to use client certs to prevent validation
|
I don't know if that's what the original poster wants, but I consider it to We use client certificates for purposes like this at the institution I work On Fri, Oct 31, 2014 at 9:33 PM, Steve Maresca [email protected]
|
Yep that's why I asked to be sure; it sounds like an entirely reasonable Doug, definitely interested in your testing of David's proposal. Steve
|
Yes, the reasoning is that due to security requirements at my institution, all web servers require client certificate authentication - even if only to verify that all clients connecting to them have "trusted" certificates. I will go ahead and attempt David's proposal when I get back to the office on Monday. Thanks, |
Just an update. I went ahead and added the 3 lines of code that David suggested above, and it works perfectly! |
So at this point, I have two questions:
|
I'm glad that it works, thanks for testing that. I should have time in the next couple of days to make a patch. Would you be willing to test it out for me? As for (2), my personal testing has shown that master is ready for production use, but I don't know if that's the official recommendation. |
That sounds excellent. I will definitely be willing to test it out whenever - just let me know. My only hesitation with using the master is just traceability for my current project - that I can't point to a specific version and say that's what I used to configure the system. But that shouldn't matter too much as long as I keep the source I used to build the module with my system configuration files. Thanks again, |
A quick patch against master is available at: https://github.com/dhawes/mod_auth_cas/commit/ae4b4f731dff9e6a683be579380f2926f73f4d1d.diff The commit log has the config options: It should be easy enough to make a 1.0.9.1 patch if you really need it. |
I apologize, as I have probably done something stupid. I went ahead and grabbed the master and built it. Then, when I installed it in Apache, the service will not start, stating that "ap_requires" is an undefined symbol. A quick google search tells me that this is an incompatibility with Apache 2.4 (which I am using). Is there a different configuration I need to enable? Or should I stick with the 1.0.9.1 release for now (which didn't give me this issue)? |
No, you've just come across another issue: Here's a patch for v1.0.9.1 if you want to try it. It compiles, but I have not tested it: https://github.com/dhawes/mod_auth_cas/commit/0a7b4a99beab7eb0c02c23ff7d873e882f2e822a.diff |
Excellent. Thank you for putting that together. As you, say, it does compile, and I was able to test it successfully for the case of "PEM" certificate files. However, for completeness, I converted my PEM files to DER format and gave that a go (updating the CASClientCert and CASClientKey paths as well as changing the CASClientCertType configuration to "DER"), and it doesn't seem to work. Looking in my Apache logs, I see the following line:
To convert my PEM files I used the following OpenSSL commands:
Assuming it's not an issue with my cert files, could this be a libcurl or NSS issue? Fortunately for me, my use case is to always use PEM-encoded certificates, so my configuration is working great. |
I'm glad it works for PEM certs. I just tested with DER certs and they seem to load fine for me. I don't currently have a CAS server that requires client auth to test this, so they are not actually being used, but they are being loaded. I'm fairly sure my libcurl is compiled against OpenSSL, which is interesting because the cURL docs claim:
Needless to say, there is a fair amount of testing needed to make sure this works with all the SSL/TLS libraries that cURL can be built against. |
I am using the 1.0.9.1 release version of mod_auth_cas (dated 13 DEC 2010).
I have been able to successfully configure mod_auth_cas to trust the CAS server's SSL certificate using the CASCertificatePath directive. However, in the case where the CAS server requires a client certificate, mod_auth_cas is failing to validate the service ticket. I cannot find any configuration options to specify a certificate for the outbound connection.
After enabling "debug" logging on the Apache server and enabling the CASDebug option, I was able to find the following in Apache's "ssl_error_log":
I attempted to install the appropriate certificate into my NSS certificate db (CentOS 7: /etc/pki/nssdb), but that did not seem to help. I also attempted to set the Apache SSLProxyMachineCertificateFile directive, but that had no effect either.
My specific configuration is such that both Apache and CAS (Tomcat) run on the same server, with Apache proxying requests to CAS via AJP/mod_proxy. Therefore, in this specific instance, when mod_auth_cas attempts to validate the service ticket, it is sending a request back to the Apache web server, which then proxies it to CAS. This works great until I configure Apache to require a client certificate, at which point I see the above log output and receive a 401 error in the browser.
The text was updated successfully, but these errors were encountered: