I would like to authenticate my clients accessing apache2 with mod_ssl. (In mozilla I did import the client certificate). I does work without a problem but as soon I also activate mod_php in /etc/conf.d/apache by "APACHE2_OPTS="-D PERL -D SSL -D PHP4", the client authentication stops working. So client authentication only works without mod_php. I found a discussion at google-groups about this issue: http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&oe=UTF-8&threadm=bbg4jf%241vkr%241%40FreeBSD.csie.NCTU.edu.tw&rnum=2&prev=/groups%3Fq%3Dmod_ssl%2Bmod_php%2Bclient%2Bauthentication%2Bapache%2B2%26hl%3Dde%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dbbg4jf%25241vkr%25241%2540FreeBSD.csie.NCTU.edu.tw%26rnum%3D2 I then reemerged mod_php(4.3.2-r4) and apache (2.0.47) but it didn't help. Reproducible: Always Steps to Reproduce: 1. configure client auth. in apache (SSLVerifyClient require, ...) 2. import client certificate in mozilla (1.4-r1) 3. connect with mozilla to https://localhost Actual Results: Mozilla gives the following error message: "The connection to localhost has been terminated unexpectedly ..." In /var/log/apache2/errr_log the following line appears: "[Fri Jul 25 15:20:15 2003] [notice] child pid 7489 exit signal Segmentation fault (11) " Internet Explorer couldn't connect neither to the webserver when mod_php is activated. Expected Results: Connect to the webserver over a ssl-connection with a client certificate.
post `emerge info`
Here my "emerge info": Portage 2.0.48-r6 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1) ================================================================= System uname: 2.6.0-test1 i686 Mobile AMD Athlon(tm) XP 2000+ GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 3dnow avi crypt cups encode foomaticdb gif jpeg libg++ mad mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gtkhtml alsa gdbm berkdb slang readline arts bonobo svga java guile mysql X sdl gpm tcpd pam libwww ssl perl python imlib oggvorbis gtk qt kde motif opengl mozilla gphoto2 cdr acpi apache2 curl doc dvd gd gtk2 maildir mcal memlimit pcmcia pda sse tiff xml -oss -apm -esd -gnome" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O3 -pipe" CXXFLAGS="-march=athlon-xp -O3 -pipe" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" FEATURES="sandbox ccache buildpkg userpriv usersandbox"
In that thread, they appear to think they've figured it out: [2003-06-14 15:40:21] alextxm at tin dot it finally, i've found the problem: compiling php 4.3.2 with --with-mysql=/path-to-mysql staically linked is the culprit. The problem can be avoided using --with-mysql and so using PHP's built-in (but obsolete) mysql interface or using: --with-mysql=shared,/path-to-mysql and then enabling php_mysql.so in php.ini Tests had been accomplished on three machines: a) gentoo linux 1.2: glibc 2.2.5, php 4.3.2, apache 2.0.45/46, mysql 4.0.12, openssl 0.9.6j b) gentoo linux 1.4rc4: glibc 2.3.1, php 4.3.2, apache 2.0.46, mysql 4.0.13, openssl 0.9.7b c) redhat 9: php 4.2.2, apache 2.0.40, openssl 0.9.7a, mysql-4.0.10 alessandro --- Does that information still not help you? If not, perhaps this can be looked at by our PHP guys as it really looks like a MySQL/PHP thing according to that thread. For what its worth using mod_ssl and mod_php and doing X.509 Certificate authentication appears to work properly here but I'll test again to be sure.
I have now tried the following: emerge mod_php without mysql-support (USE="-mysql" emerge mod_php) But the problem remains. It would be good if someone else would confirm that problem. Maybe I should post instructions how to setup client authentication?
eeek! my setup is working ok until i try to authenticate with a client certificate. doesnt matter if i turn off -D PHP or not now. when i connect to the webserver, i get a dialog box in IE prompting to choose the client certificate to use. i select it and get this in my error_log: [Tue Aug 05 22:55:31 2003] [notice] Digest: generating secret for digest authentication ... [Tue Aug 05 22:55:35 2003] [notice] Digest: done [Tue Aug 05 22:55:37 2003] [notice] Apache/2.0.47 (Gentoo/Linux) mod_ssl/2.0.47 OpenSSL/0.9.7b PHP/4.3.1 configured -- resuming normal operations [Tue Aug 05 22:55:55 2003] [notice] child pid 2163 exit signal Segmentation fault (11) [Tue Aug 05 22:55:55 2003] [notice] child pid 2161 exit signal Segmentation fault (11) [Tue Aug 05 22:55:56 2003] [notice] child pid 2162 exit signal Segmentation fault (11) [Tue Aug 05 22:55:56 2003] [notice] child pid 2160 exit signal Segmentation fault (11) but you say you *can* get client cert authentication working _without_ -D PHP? hmmm now im not sure whats going on. it works here with -D PHP and -D SSL as long as I dont do "SSLVerifyClient require". as soon as i turn that on i get the segfault in the log and IE naturally doesnt work... :( basically what im gathering so far indicates a problem with possibly openssl? mod_php doesnt appear to be factoring into my equation here so any more ideas are appreciated. are you using openssl-0.9.7? i wonder if openssl-0.9.6 would work.
Yes, client authentication works here with mozilla (mozilla-1.4-r3) when I don't set "-D PHP4". The openssl version I use: * dev-libs/openssl Latest version available: 0.9.6j Latest version installed: 0.9.6j
Hmm looks like some link borkage.... Please, take this patch: http://dev.gentoo.org/~woodchip/apache-2.0.47-gentoo.diff and edit your apache-2.0.47.ebuild to apply *it* rather than the apache-2.0.46-gentoo.diff that it applies now, and let me know if you're working ok then. I'm still using OpenSSL-0.9.7 by the way, and have a PHP-based LDAP administration package working properly with the "SSLVerifyClient require" option configured. Seems ok here...
Great, with this diff-file it works now with php enabled :-) thank you very much
donny: are you going to update the 2.0.47 ebuild to use this new patch?
robin: i think so but i think drake/suse still use the pieces i ripped out of the new patch, so it makes me wonder whats going on. i'll try to update either tonight or tomorrow with a couple more bugs at the same time, thanks for reminding me.
should be fixed with the patch in 2.0.47-r1
I can confirm that client authentication works fine with 2.0.47-r1