Greetings. I recently upgraded from the secure web server 2.0 product to 3.2.1-1. I noticed that I was no longer getting the environment variable "HTTPS_SECRETKEYSIZE" in my cgi (perl) scripts. After some investigation, I found that the name of this variable changed to "SSL_CIPHER_ALGKEYSIZE". This didn't work either. I then printed out my entire environment in cgi and found that non of the SSL environment variables as documented here-->http://www.modssl.org/docs/2.6/ssl_compat.html are being exported to my scripts. According to the FAQ at www.modssl.org, I needed to add the set an SSLOption in my httpd.conf file to get these environment variables to export. Specifically, it says to add the line "SSLOptions +StdEnvVars" to the conf file withing the VirtualHost section for the secure server. So I did this. So here's the rub. I find that if I add "SSLOptions +StdEnvVars" to my httpd.conf file and restart my server every request to my secure server (even those that don't touch any cgi) result in a segmentation fault. Needless to say this is very bad and getting very frustrating. I currently have no way to access the SSL environment variables via cgi and our site needs to distinguish 128 bit key clients from 40 bit key clients. We've been very disappointed in the quality and breadth of the documentation and support available for the red had secure server. Hopefully a quick and meaningful response to this issue will change our minds. Thanks.
Created attachment 1227 [details] my conf file for Redhat Secure Web Server (The SSLOptions directive is currently commented out for obvious reasons)
I've traced this one down to a call into the BSAFE library's ASN1_UTCTIME_print function, which is not a supported API call. Without the library source, the best we can do is to try to find a workaround.
As long as the workaround gives access to the SSL environment variables I'll be happy. FYI, I tried using the mod_env package to make the variables I need accessible to my cgi progs, but this had no affect. I guess they simply aren't in the environment. Seems like the BSAFE code is causing problems in several areas (references in other bugs). Maybe a patch is in order?
Oh, and THANK YOU for your timely response.
Can we please get some kind of resolution to this bug? It's been over a month since the last update. I spending valuable resources working around it via silly cgi-based fixes.
Is anybody listening out there? Hello?
This fix is going into the security errata we're putting out.