2.2.5-1.3.4 on FreeBSD-3.1
The new version of mod_ssl appears to have some problems compiling on FreeBSD-3.1. I've not had this problem with previous versions, and the directions were followed over and over to the T, and from fresh source archives (just for paranoia). The errors are below. Forrest ===> src ===> src/os/unix <=== src/os/unix ===> src/ap <=== src/ap ===> src/main <=== src/main ===> src/modules ===> src/modules/standard <=== src/modules/standard ===> src/modules/ssl <=== src/modules/ssl <=== src/modules gcc -c -I./os/unix -I./include -funsigned-char -DMOD_SSL=202105 -DEAPI `./apaci` modules.c gcc -c -I./os/unix -I./include -funsigned-char -DMOD_SSL=202105 -DEAPI `./apaci` buildmark.c gcc -funsigned-char -DMOD_SSL=202105 -DEAPI `./apaci` -L/local2/src/openssl-0.9.1c-o httpd buildmark.o modules.o modules/standard/libstandard.a modules/ssl/libssl.a main/libmain.a ./os/unix/libos.a ap/libap.a -lcrypt -lssl -lcrypto modules/ssl/libssl.a(ssl_engine_init.o): In function `ssl_init_Module': ssl_engine_init.o(.text+0x227): undefined reference to `RSA_generate_key' modules/ssl/libssl.a(ssl_engine_init.o): In function `ssl_init_SSLLibrary': ssl_engine_init.o(.text+0x3dc): undefined reference to `SSL_load_error_strings' ssl_engine_init.o(.text+0x3e1): undefined reference to `SSLeay_add_ssl_algorithms' modules/ssl/libssl.a(ssl_engine_init.o): In function `ssl_init_GetCertAndKey': ssl_engine_init.o(.text+0x535): undefined reference to `SSLv2_server_method' ssl_engine_init.o(.text+0x53d): undefined reference to `SSL_CTX_new' ssl_engine_init.o(.text+0x54d): undefined reference to `SSLv23_server_method' ssl_engine_init.o(.text+0x555): undefined reference to `SSL_CTX_new' ssl_engine_init.o(.text+0x5c9): undefined reference to `SSL_CTX_set_ex_data' ssl_engine_init.o(.text+0x616): undefined reference to `SSL_CTX_set_verify' ssl_engine_init.o(.text+0x649): undefined reference to `SSL_CTX_ctrl' ssl_engine_init.o(.text+0x689): undefined reference to `SSL_CTX_set_cipher_list' ssl_engine_init.o(.text+0x6f9): undefined reference to `SSL_CTX_load_verify_locations' ssl_engine_init.o(.text+0x776): undefined reference to `SSL_CTX_set_client_CA_list' ssl_engine_init.o(.text+0x78e): undefined reference to `SSL_CTX_get_client_CA_list' ssl_engine_init.o(.text+0x81c): undefined reference to `d2i_X509' ssl_engine_init.o(.text+0x8b4): undefined reference to `d2i_RSAPrivateKey' modules/ssl/libssl.a(ssl_engine_init.o): In function `ssl_init_FindCAList_X509NameCmp': ssl_engine_init.o(.text+0x8fc): undefined reference to `X509_NAME_cmp' modules/ssl/libssl.a(ssl_engine_init.o): In function `ssl_init_FindCAList': ssl_engine_init.o(.text+0x92d): undefined reference to `sk_new' ssl_engine_init.o(.text+0x948): undefined reference to `SSL_load_client_CA_file' ssl_engine_init.o(.text+0x993): undefined reference to `X509_NAME_oneline' ssl_engine_init.o(.text+0x9cb): undefined reference to `sk_find' ssl_engine_init.o(.text+0x9f3): undefined reference to `sk_push' ssl_engine_init.o(.text+0xa68): undefined reference to `SSL_load_client_CA_file' ssl_engine_init.o(.text+0xab3): undefined reference to `X509_NAME_oneline' ssl_engine_init.o(.text+0xaeb): undefined reference to `sk_find' ssl_engine_init.o(.text+0xb13): undefined reference to `sk_push' ssl_engine_init.o(.text+0xb43): undefined reference to `sk_set_cmp_func' modules/ssl/libssl.a(ssl_engine_kernel.o): In function `ssl_hook_NewConnection': ssl_engine_kernel.o(.text+0xd1): undefined reference to `SSL_new' ssl_engine_kernel.o(.text+0xe8): undefined reference to `SSL_set_ex_data' ssl_engine_kernel.o(.text+0x109): undefined reference to `SSL_set_fd' ssl_engine_kernel.o(.text+0x136): undefined reference to `SSL_get_rbio' ssl_engine_kernel.o(.text+0x14b): undefined reference to `SSL_get_rbio' ssl_engine_kernel.o(.text+0x166): undefined reference to `SSL_use_certificate' ssl_engine_kernel.o(.text+0x191): undefined reference to `SSL_free' ssl_engine_kernel.o(.text+0x1d8): undefined reference to `SSL_use_RSAPrivateKey' ssl_engine_kernel.o(.text+0x203): undefined reference to `SSL_free' ssl_engine_kernel.o(.text+0x296): undefined reference to `SSL_state' ssl_engine_kernel.o(.text+0x2b1): undefined reference to `SSL_accept' ssl_engine_kernel.o(.text+0x2d0): undefined reference to `SSL_get_error' ssl_engine_kernel.o(.text+0x2f8): undefined reference to `SSL_set_shutdown' ssl_engine_kernel.o(.text+0x310): undefined reference to `SSL_free' ssl_engine_kernel.o(.text+0x355): undefined reference to `ERR_peek_error' ssl_engine_kernel.o(.text+0x435): undefined reference to `SSL_set_shutdown' ssl_engine_kernel.o(.text+0x44d): undefined reference to `SSL_free' ssl_engine_kernel.o(.text+0x4b7): undefined reference to `SSL_set_shutdown' ssl_engine_kernel.o(.text+0x4cf): undefined reference to `SSL_free' ssl_engine_kernel.o(.text+0x519): undefined reference to `SSL_get_error' ssl_engine_kernel.o(.text+0x559): undefined reference to `SSL_set_shutdown' ssl_engine_kernel.o(.text+0x571): undefined reference to `SSL_f
Re: POST problem
> > On Sun, Mar 21, 1999, [EMAIL PROTECTED] wrote: > > > I just did the following: > > > > cd apache_1.3.4 > > make clean > > cd ../mod_ssl-2.2.5-1.3.4 > > ./configure ... > > cd ../apache_1.3.4 > > ./configure ... > > make > > make install > > > > which would seem to COMPLETELY rebuild the apache and mod_ssl source > > trees, and I'm still having the POST problem, using mod_ssl with DSO. > > Hmmm... I've yesterday evening tried it again myself with a little POST > cgi-script and all worked fine. So, you've to give me more details on your > particular "POST problem" or I cannot help you. Perhaps it's something > different this time. What exact URLs you request, what scripts/pages are on > the filesystem and how are they configured? > > BTW, Apache doesn't allow POSTs to all things per default and Netscape doesn't > like Apache's non-200/OK response in these cases. So, are you sure your "POST > problem" works at least with plain HTTP? I have four scripts that I call using HTTPS. Two are C programs, one is a PHP3.0.7 script, and one is a shell script. All of these scripts work over HTTP with POST. All work over HTTPS with GET. One of the C programs and the shell script work over HTTPS with POST. The other C program and the PHP script do not. The scripts that work both do some processing and send output to the browser. The scripts that don't work do some processing then send a "Location: " header to send to another page. The problem appears to be in the redirection, then. This is the error I get: "An I/O error occured during security authorization. Please try your connection again" I'm using: Apache 1.3.4 mod_ssl 2.2.5-1.3.4 openssl 0.9.1c (upgrading shortly) PHP 3.0.7 Netscape 4.07 Linux 2.0.36 glibc 2.0.7 -mike > >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com > __ > Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ > Official Support Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: GSID, mod_ssl and Apache...
On Tue, Mar 23, 1999, Patrik Carlsson wrote: > How does this stepup really works? I'm surprised that the README.GlobalID document isn't detailed enough... > The server has this special GSID certificate, but is he otherwise "modified" > (he must be able to use strong ciphers) in some way to be able to handle the > stepup? The server is not modified except that he has to accept the stepup, i.e. renegotiations forced by the client. The strong ciphers are always supported, of course. mod_ssl and OpenSSL are not export-crippled. > Isn't it actually just a client issue, i.e. the client sees the GSID and, in > the Netscape case, finishes the 40 bit negotiation and then starts a new 128 > bit SSL negotiation, and in the IE case, it drops the current negotiation > and starts a new with a stronger cipher. Correct, it's a client issue and works exactly as you said. > The following is from the README-GSID.GlobalID file: "First you should > recognize that Apache+mod_ssl+SSLeay allow such renegotiations since version > 2.1.3" What does these renegotiations look like and what changes were made > and where? They are just SSL renegotiations forced by the client which start a new handshake phase where the cipher suite is changed to use stronger ciphers. The actual changes are adjusted I/O routines, see ssl_engine_io.c for more details. > Is there something called session renegotiations in the SSL spec? Looking > at http://microsoft.com/security/tech/sgc/TechnicalDetails.asp it seems like > the client justs starts a new handshake... Don't look at Microsoft papers when you want to understand anything, please. Instead look inside the SSLv3 spec or the TLSv1 RFC. Yes, the stuff is called renegotation of parameters and is nothing more than a new SSL handshake, of course. The interesting point is just that an SSL handshake can occur at any time and not only at startup of a new connection ;-) > I would be really happy if someone could shed some light in the fog on this > (interesting) topic! I doesn't look that there is such a lot of fog around you. The whole SGC stuff isn't complicated in general on the server-side, it's just a matter of client forced renegotiations which the server has to accept at any stage to support SGC. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: 2.2.5-1.3.4 on FreeBSD-3.1
On Mon, Mar 22, 1999, Forrest Aldrich wrote: > The new version of mod_ssl appears to have some problems compiling on > FreeBSD-3.1. I've not had this problem with previous versions, and the > directions were followed over and over to the T, and from fresh source > archives (just for paranoia). The errors are below. > modules/ssl/libssl.a(ssl_engine_init.o): In function `ssl_init_GetCertAndKey': >[...] > ssl_engine_init.o(.text+0x535): undefined reference to `SSLv2_server_method' > ssl_engine_init.o(.text+0x53d): undefined reference to `SSL_CTX_new' > ssl_engine_init.o(.text+0x54d): undefined reference to `SSLv23_server_method' > ssl_engine_init.o(.text+0x555): undefined reference to `SSL_CTX_new' > ssl_engine_init.o(.text+0x5c9): undefined reference to `SSL_CTX_set_ex_data' > ssl_engine_init.o(.text+0x616): undefined reference to `SSL_CTX_set_verify' No, don't blame mod_ssl for this. It's not mod_ssl's problem. It's a problem of OpenSSL's libraries on your platform, but again it should be not OpenSSL's problem. Instead I guess you've not built OpenSSL with the "FreeBSD-elf" platform id. Instead I guess you used just "FreeBSD" and this way got a.out stuff which confused something. At least you can be sure that both Apache, mod_ssl and OpenSSL all work fine under FreeBSD 3.1, because that's the platform I use myself for development... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [BugDB] PRIVATE: SSLeay (PR#131)
On Mon, Mar 22, 1999, [EMAIL PROTECTED] wrote: > Full_Name: Sean Proske > Version: 2.2.5 > OS: FreeBSD > Submission from: d190-qe101h1-abfd-pdi.attcanada.net (142.194.53.190) > > I installed apache1.3.4+mod_ssl2.2.5, the intention was to install openssl, but > it looks like it installed ssleay instead... > named. openssl doesn't appear to exist anywhere on the system but when I type > the command > > # ssleay version > > it tells me it's OpenSSL 0.9.1c 23-Dec-1998 > > I mention this because it is a US installation, and I understand that openssl is > ok, but ssleay is not. Furthermore, the documentation says to type openssl at > the command line when running any type of operation supported by that package, > but of course openssl doesn't exist and ssleay has to be substituted for it to > work. > > What exactly did I install? Is it openssl or ssleay? Is this a problem at your > end, or is it with FreeBSD? (I installed it from the FreeBSD ports collection by > cd'ing into the /usr/ports/www/apache13-modssl directory and running make. > > Whoever is responsible for how it is installed, whether it's the FreeBSD > developers or your team it does need to be fixed, otherwise there may be a lot > of people in North America who at worst will not know if they're infringing upon > patents and leaving themselves open to potential liability and at best, will be > confused by much of the documentation. > > On another note, I would suggest that you implement a feature that will preserve > existing configuration files if apache+modssl is installed over an existing > apache installation. It would be even better if it would make a backup and > create a new httpd.conf file with all the additional directives necessary for > ssl support, i.e. keep all the old settings, virtual servers, etc. When I > installed the port, it overwrote my existing httpd.conf (luckily I had enough > sense to keep a backup readily available) if it is not practical or even > possible to implement such a feature, I would suggest at the very least that you > make a note in a prominent place in the documentation that will alert people of > the fact that their httpd.conf file will be overwritten when they install and > that they should ensure that they have a backup on hand. It should't be too > tough to put a few lines of code in the Makefile that will check for an existing > httpd.conf in the destination directory and mv it to httpd.conf.backup though A few points: 1. First, you're installing the FreeBSD port and this always is a special case, because the FreeBSD port has special requirements from the FreeBSD area, of course. The apache13-mod-ssl port doesn't contain OpenSSL, it just has a reference to the openssl port. And this still installs OpenSSL 0.9.1c. That's correct, it's binary is called "ssleay". That will change when someone has updated the openssl port to OpenSSL 0.9.2b. Then the binary name will be openssl. 2. You're totally misinformed when you think OpenSSL is ok to use in the USA while SSLeay wasn't. Totally incorrect. Anything which applied to SSLeay also applies to OpenSSL. Both copyrights on the code and the use-restrictions because of contained algorithms and patents on it. 3. That your httpd.conf files was killed is a side-effectof the FreeBSD port. Ports usually remove all installed things! When you are installing Apache+mod_ssl+OpenSSL on your own, this doesn't happen, of course. Then Apache correctly preserves installed config files, of course. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: POST problem
On Mon, Mar 22, 1999, [EMAIL PROTECTED] wrote: >[...] > I have four scripts that I call using HTTPS. Two are C programs, one is > a PHP3.0.7 script, and one is a shell script. All of these scripts work > over HTTP with POST. All work over HTTPS with GET. One of the C programs > and the shell script work over HTTPS with POST. The other C program and > the PHP script do not. The scripts that work both do some processing and > send output to the browser. The scripts that don't work do some processing > then send a "Location: " header to send to another page. The problem > appears to be in the redirection, then. This is the error I get: > > "An I/O error occured during security authorization. Please try >your connection again" Ok, then I've to check now POST+keepalive+redirection, too. What a nice thing that the HTTP protocol makes has such a lot of esoteric combinations possibleI'll investigate when I find time. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSLRequire to reject users based on email
Hi,
I'm trying to reject users who have certifcates but have abused their
privalegue. From within my virtualhost I have:
# Reject Banned Users
SSLRequire (!( %{SSL_CLIENT_S_DN_Email} in {
file("/home/www/virtual/secure/secure/ssl/BannedUsers") } ))
This file is just a list of email addresses. This has no effect even if I
remove the '!'. I have switched trace (or debug) logging on but I don't
see anything related to SSLRequire.
Any ideas?
Thanks in advance,
Owen.
o--o
| Owen Williams| Systems Manager |
| [EMAIL PROTECTED] | Software Engineer |
| Work: (0116) 2506349 | |
| Home: (0116) 2259109 |I do web consultancy |
|--|
| World Wide Web Home Page : http://www.cse.dmu.ac.uk/~williams|
| Short CV : http://www.cse.dmu.ac.uk/~williams/CV |
o--o
__
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: SSLRequire to reject users based on email
On Tue, Mar 23, 1999, Owen Williams wrote:
> I'm trying to reject users who have certifcates but have abused their
> privalegue. From within my virtualhost I have:
>
>
> # Reject Banned Users
> SSLRequire (!( %{SSL_CLIENT_S_DN_Email} in {
>file("/home/www/virtual/secure/secure/ssl/BannedUsers") } ))
>
>
> This file is just a list of email addresses. This has no effect even if I
> remove the '!'. I have switched trace (or debug) logging on but I don't
> see anything related to SSLRequire.
>
> Any ideas?
Hmmm... yes, although the above construct is syntacically correct, it's not
exactly what you want. The file() construct expands to a single word in the
"in {}" list. So, the expression actually tests nother more than whether
%{SSL_CLIENT_S_DN_Email} is equal the file's contents
(which obviously never is because in this a list exists, I addresses one per
line). So what you've to inline the email-addresses until I implement some
sort of a real map lookup as in mod_rewrite:
SSLRequire not ( %{SSL_CLIENT_S_DN_Email} in { \
"foo1@bar", "baz1@quux" \
"foo2@bar", "baz2@quux" \
"foo3@bar", "baz3@quux" \
} )
Currently the file() stuff is very rudimentary and actually useful only to
check a while certificiate against a file containing the PEM version of it.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Can't be my own CA
Hi! I just bought a Brazilian RH Linux distribution with Apache 1.3.3 and mod_ssl 2.0.something. When I follow the instructions to create my own CA and sign the server certificate I just created, I get this in the verification phase: CA verifying: server.crt <-> CA cert server.crt: /C=BR/ST=RIO/O=PCShop/CN=secure.pcshop.com.br/Email=webmaster@pcshop .com.br error 7 at 0 depth lookup:certificate signature failure All of the ssleay commands are being run in a private directory (/root). I got the latest 2.0 distribution in order to get the ca.sign script. What am I doing wrong? Thanx, -- ___THE___ One man alone cannot fight the future. USE LINUX! \ \ / / ___ \ V / |Juan Carlos Castro y Castro| \ /|[EMAIL PROTECTED] | / \|Linuxeiro, alvinegro, X-Phile e Carioca Folgado| / ^ \ |Diretor de Informática e Eventos Sobrenaturais | / / \ \ |da E-RACE CORPORATION | ~~~ ~~~ --- RACER __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Basic auth with SSL - again
"Ralf S. Engelschall" ha scritto: > > On Mon, Mar 22, 1999, Achille M. Luongo wrote: > > > I installed Apache/1.3.3 (Win32) mod_ssl/mod_ssl/2.1b8 SSLeay/0.9.0b. > > 2.1b8? Oh, that's really _OLD_, I hope you now this. I've no clue on your > problem, but this is the first version which ran on Win32, so I strongly > suggest that you upgrade to 2.2.5. Because the chance is high that this was > implicitly solved by the changes since 2.1b8. Thanks for the answer, Ralf. My problem is that I can't build applications under Win32 platform. Is anybody able to build and uplownload on ftp://contrib:[EMAIL PROTECTED]/sw/mod_ssl/ (read/write access). an update version of Apache (Win32) with mod_ssl/mod_ssl/2.2.5 ? Bye, Achille. __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: GSID, mod_ssl and Apache...
Ralf S. Engelschall wrote: > Don't look at Microsoft papers when you want to understand anything, please. > Instead look inside the SSLv3 spec or the TLSv1 RFC. Yes, the stuff is called > renegotation of parameters and is nothing more than a new SSL handshake, of > course. The interesting point is just that an SSL handshake can occur at any > time and not only at startup of a new connection ;-) > I've some experience with another web server and IE clients. IE seems to renegotiate very often which is, maybe good when looking at security, but performance suffers and if you plan to use the SSL session id for logging or just tracking sessions, you can just forget it... ;-( A couple of weeks ago I managed to tag my CA certificate according to your instructions in the README.GlobalID document - which is really a very good and well written document! But it didn't work when I put the pieces together using Apache/1.3.4 and mod_ssl/2.1.8. It went quite fast and I should try it again this easter, but do you (or any one else) have any other tips/experiences which isn't mentioned in the documents? --Patrik __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Can't be my own CA
Juan Carlos Castro y Castro wrote: > > Hi! I just bought a Brazilian RH Linux distribution with Apache 1.3.3 > and mod_ssl 2.0.something. When I follow the instructions to create my > own CA and sign the server certificate I just created, I get this in the > verification phase: > > CA verifying: server.crt <-> CA cert > server.crt: > /C=BR/ST=RIO/O=PCShop/CN=secure.pcshop.com.br/Email=webmaster@pcshop > .com.br > error 7 at 0 depth lookup:certificate signature failure there is not a problem wit your distribution.. there is a strange "bug" on ssleay/openssl which doesn't allow the same values for a server.crt and a ca.crt so if you wan't to selfsigned your certify you need to change the values you are putting on both certicates i've learned this the difficult way.., should be on the FAQ, you could get a clue if you check the list archives HTH Carlo __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[BugDB] Mod_SSL and PHP 3.0.7? (PR#132)
Full_Name: John Hoffmann Version: 2.2.5-1.3.4 OS: Solaris 2.6 Submission from: stargate.trytel.com (209.167.85.20) I'm trying to switch from StrongHold 2.4 to Apache 1.3.4 with mod_ssl, and I must say the installation went 200 times easier. One thing I am having a problem with however is getting PHP 3 to work at all. I recently compiled StrongHold with mod_auth_mysql-2.20, php 2.01 and php 3.0.7 and it worked fine, but when I compile these same modules into Apache 1.3.4 with mod_ssl the php3 engine seems to die. When accessing a .php3 page I simply get a "The document contains no data". PHP 2 pages work fine. I've checked my configuration: srm.conf:AddType application/x-httpd-php3 .php3 But no PHP 3 pages will return any data. Any ideas at all? __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
