Problem: Apache 2.0.42 mod_ssl fails to generate StdEnvVars on call to a perl script and gives the error messages [Wed Sep 25 17:39:08 2002] [error] [client 127.0.0.1] (22)Invalid argument: couldn't create child process: 22: printenv_.cgi [Wed Sep 25 17:39:08 2002] [error] [client 127.0.0.1] (22)Invalid argument: couldn't spawn child process: E:/Web/cgi-bin/tool/printenv_.cgi Probable reason: The server certificate was generated with openssl on WinNT and contains in its attributes a non-US-ASCII-character, in this case "u Umlaut", which is 0x81 in DOS-charset used in WinNT command line window. Apache 1.3.26 mod_ssl 2.8.10 openssl0.9.6g transscribes this character as follows in L= SSL_SERVER_I_DN="/C=de/ST=Some-State/L=m\x81nchen/O=private/CN=localhost/Email=wolf-dietrich.moeller@mchp.siemens.de" and works fine. NB: The same installation of 2.0.42 works fine with a server certificate without "Umlaut". Question: Is it a feature to block these characters (then the error message is very misleading), or is it a bug (handling should be as in Apache 1.3.26)?
It's mod_cgi failing here, some Win32 environment variable charset issue. Can you confirm whether it still fails like this in 2.0.49? (I don't want to offer you hope that anyone will fix it even if you do confirm that, though)
The behaviour is still the same for this version: Server version: Apache/2.0.49 Server built: Mar 20 2004 13:28:19 Server's Module Magic Number: 20020903:7 Architecture: 32-bit Server compiled with.... -D APACHE_MPM_DIR="server/mpm/winnt" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/apache" -D SUEXEC_BIN="/apache/bin/suexec" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_ERRORLOG="logs/error.log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" as downloaded from <http://hunter.campbus.com/>
OK, thanks.
*** Bug 27442 has been marked as a duplicate of this bug. ***
*** Bug 16635 has been marked as a duplicate of this bug. ***
Still on 2.0.54
New status for Apache 2.0.54 (on WinNT SP6a and WinXP SP2): The character 0x81 is still rejected, but the error message in error.log has changed, e.g.: "[Wed Sep 07 18:15:55 2005] [error] [client 127.0.0.1] script not found or unable to stat: D:/Web/cgi/printenv.cgi (22)Invalid argument: utf8 to ucs2 conversion failed on this string: SSL_SERVER_S_DN_L=M\x81nchen [Wed Sep 07 18:16:21 2005] [error] [client 127.0.0.1] (22)Invalid argument: couldn't create child process: 22: printenv.cgi [Wed Sep 07 18:16:21 2005] [error] [client 127.0.0.1] (22)Invalid argument: couldn't spawn child process: D:/Web/cgi/tool/printenv.cgi" As all characters from 0x80 to 0x9f are control characters in Latin-1 and UTF-8. Thus this behaviour seems adequate to me, and the error message now gives the correct reason for failure. I think it is not necessary to support proprietary code pages like MS-DOS or WIN-1252 with printable characters in the range 0x80 to 0x9f. To my impression (as reporter of the bug) the bug may be treated as fixed.
With a certificate containing valid UTF-8 characters, like '\xC3\x9F', they are also encoded in StdEnvVars as a 8-bytes string instead of a 2-bytes string. How could we fix that ?
"With a certificate containing valid UTF-8 characters, like '\xC3\x9F', they are also encoded in StdEnvVars as a 8-bytes string instead of a 2-bytes string." They are? Or do they just look that way to your CGI? We are creating the proper unicode ENVVAR, perhaps your CGI script isn't internationalized? What shows up if you go to log this using the envvar logging option in mod_log_config? A two-byte or one-byte sequence?
With the directive CustomLog dn.log "SSL_CLIENT_S_DN=\"%{SSL_CLIENT_S_DN}x\"" here is what I get in the log: SSL_CLIENT_S_DN="/C=BE/CN=Davina.../GN=Davina...\xC3\x9F\xC3\xA7.../serialNumber=83737300064"
*** Bug 41094 has been marked as a duplicate of this bug. ***
*** Bug 39105 has been marked as a duplicate of this bug. ***
*** Bug 34985 has been marked as a duplicate of this bug. ***
*** Bug 33724 has been marked as a duplicate of this bug. ***
*** Bug 32730 has been marked as a duplicate of this bug. ***
*** Bug 14227 has been marked as a duplicate of this bug. ***
*** Bug 42624 has been marked as a duplicate of this bug. ***
Sorry for the noise, tagging important issues as FAQ
should be fixed in 2.2.22