In some configurations, SSLProxyMachineCertificateFile causes Apache to seg-fault on startup. The following small configuration works as expected: Listen 80 Listen 443 LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule ssl_module modules/mod_ssl.so User nobody Group #-1 TypesConfig conf/mime.types #<VirtualHost *> #</VirtualHost> <VirtualHost _default_:443> SSLEngine on SSLCertificateFile server.cert </VirtualHost> SSLProxyEngine on SSLProxyMachineCertificateFile server.cert ProxyPass /foo https://www2.metnet.navy.mil/ Requests for /foo on either 80 or 443 will be reverse-proxied to an HTTPS server, using a client cert. However, if you uncomment the commented VirtualHost lines, Apache seg-faults on startup. I haven't investigated the reason. This does not seem to be related to bug 24030 (which should be fixed in apache 2.0.55).
Oh, server.cert is just a dummy self-signed cert plus key. For ease of reproducing, here it is: -----BEGIN RSA PRIVATE KEY----- MIICXwIBAAKBgQCsxmVAUyU3wCtyCE75p2imqRkv2t43Nw6jTe+me2sCAUYoE+ls n39/WnUGk299Yg30W1DQDixD1Q15Kv9qlvL+2FylQqH3teS21MDjWYWi2zwS/u53 ShhrUkKJ98Oj1Cqo26wijLCA3+eEpQO+ydj0uk+m2We4HkNnWXAyOq+OGQIDAQAB AoGBAIUOeRVzstrfhNXZ7jA3q9GFsp73GGE/Zmd/csssivlNT+E3jHGZ18+VM0Cw NJFD/WktFexUreRDZI/m/DLzMwip4Cq3ySkzIXsOAaMOtz9KGET/K9LcRpYh1byO FCV+z+43L7Q+Uh8TeKe/Hj+Sh9kA79JamYPtcMKUfUeBbWB9AkEA3hYrwBUf5/xP pWwc17YtChAox1e/hCE07rAiW5CxtJNI4z2QEFysISGBtFzHSaiIFQEhrJnOI+9p MYLtyP/ACwJBAMcoh8NdFUIDNsC7o8QBonS48UPqRwcKPH0bKj4HmcvFTb7P2aIw knAqY71Lx65UOfr8z3NRqtLojEDAQF4VTOsCQQDZ4nSP4enIpsDZMaVmeMPdUJdB Y7RwhEezOTisDtxZpfpnf1mcw97YLlBbTH70pBTGTrLj7I3SsarJuYNipI+bAkEA vSnaCc3X6yNyVg3jtsB2tbcUMhXL8PvgCFRNAy3k/o8hESQK6uqHrNIWei4IM6T8 jVCjGj1vq3QGA1qXyMUikQJBAMn5Yj6xh2piPSEvfFifLlerpqNbrKrhMov1oTWN boMMQpjW3tnXiqd04nTXjQCxN+4CWNcIdCfuO4OqCfQ5Lrs= -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIICJTCCAY4CCQDEZpgxQTJ07DANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJV UzETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMITW9udGVyZXkxDzANBgNV BAoTBkFuZHJldzEPMA0GA1UEAxMGQW5kcmV3MB4XDTA2MDYyODA0NDUxMFoXDTA2 MDcyODA0NDUxMFowVzELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWEx ETAPBgNVBAcTCE1vbnRlcmV5MQ8wDQYDVQQKEwZBbmRyZXcxDzANBgNVBAMTBkFu ZHJldzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArMZlQFMlN8ArcghO+ado pqkZL9reNzcOo03vpntrAgFGKBPpbJ9/f1p1BpNvfWIN9FtQ0A4sQ9UNeSr/apby /thcpUKh97XkttTA41mFots8Ev7ud0oYa1JCiffDo9QqqNusIoywgN/nhKUDvsnY 9LpPptlnuB5DZ1lwMjqvjhkCAwEAATANBgkqhkiG9w0BAQUFAAOBgQCKe9Mjaeut lA6cM6vxhfOsbtc1L1Lz2fA3arXM9dv15jAQGpCDAPzC81ortnQpfohJv1wymIN4 VSDjmbsZi4R6AqK5Pjh/JoCKppdtHmBUaA2EFAkld9CDJAa02vfQAQfupqurN9zf A+kd+smwWefqu0Ea/I6WAX6wad7omNiKBQ== -----END CERTIFICATE----- You should be able to run my config (from the initial report) with something like apache2 -X -d $PWD -f httpd.conf if you put the config in httpd.conf and the cert in server.cert in the same directory. You'll have to create a few other files, but you're smart, you'll figure it out.
Can you get a backtrace? gdb /path/to/httpd ... (gdb) run -X ... (gdb) bt
Hmm, I didn't realize I'd get a reasonable backtrace without recompiling everything with debugging. Here it is: #0 0xa7e19c61 in CRYPTO_add_lock () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #1 0xa7e9dcae in X509_INFO_free () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #2 0xa7e83660 in sk_pop_free () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #3 0xa7989008 in ssl_init_ModuleKill () from /home/andrew/u/modules/mod_ssl.so #4 0xa7c7ee4d in apr_pool_tag () from /usr/lib/libapr-0.so.0 #5 0xa7c7fd27 in apr_pool_clear () from /usr/lib/libapr-0.so.0 #6 0x0807e64d in main ()
That doesn't ring any bells. What version of OpenSSL, what distribution? Is this reproducible with 2.2.2? What is the error_log output with "LogLevel debug"?
Never mind, I can reproduce this.
Fixed on the trunk: http://svn.apache.org/viewvc?view=rev&revision=417988 and will propose for 2.2.x. Thanks for the report.
Thanks so much for figuring this out. Sorry for forgetting all my version details; somehow the mind just goes when filing bug reports.
*** Bug 48824 has been marked as a duplicate of this bug. ***