Re: cannot compile openssl-0.9.7d into php-4.3.6 with apache-1.3.27 on Redhat 7.3
Well, several things may be going on here. To begin with, you have only built the static libraries for OpenSSL. To get shared libraries as well, you need to configure like this: ./config shared And that will only produce shared libraries where we support it. However, that SHOULDN'T make a difference, since you have given the correct OpenSSL path to the php configure script. This means there's something fishy in the PHP build that makes it link with the default OpenSSL libraries for your platform. Another point: is /usr/lib/apache/libphp4.so really the thing you bulit or did your build end up somewhere else? If what you installed ended up somewhere else, that answers all your questions :-) In message [EMAIL PROTECTED] on Tue, 20 Apr 2004 22:10:39 -0700 (PDT), Mike Ryerse [EMAIL PROTECTED] said: mikeryerse Command for installing openssl-0.9.7d.tar.gz: mikeryerse ./config mikeryerse make mikeryerse make install mikeryerse mikeryerse Command for php-4.3.6: mikeryerse ./configure --with-openssl=/usr/local/ssl mikeryerse make mikeryerse make install mikeryerse mikeryerse Then when starting apache I get the following: mikeryerse Syntax error on line 264 of /etc/httpd/conf/httpd.conf: mikeryerse Cannot load /usr/lib/apache/libphp4.so into server: mikeryerse /usr/lib/apache/libphp4.so: undefined symbol: mikeryerse OPENSSL_add_all_algorithms_noconf mikeryerse mikeryerse I checked an ldd on libphp4.so and this is what I get: mikeryerse # ldd libphp4.so mikeryerse libssl.so.2 = /lib/libssl.so.2 (0x40414000) mikeryerse mikeryerse There seems to be a link on this file: mikeryerse # ls -l libssl.so.2 mikeryerse lrwxrwxrwx1 root root 16 Mar 13 09:05 libssl.so.2 mikeryerse - libssl.so.0.9.6b mikeryerse mikeryerse Can anyone help me please? I've been working on this for ages. - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte \ Tunnlandsvägen 52 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-708-26 53 44 \ SWEDEN \ Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
openssl req SSL/SSH key merge
Are there any downstream problems using a cert based off of a ssh-keygen as opposed to an openssl genrsa? For example: ssh-keygen -trsa -b1024 -ftestid_rsa -N openssl req -new -key testid_rsa -out testid_rsa.csr The above is what I'm currently using based off OpenSSH's supported x.509 (Roumen Petrov) and it appears to look promising. In other words would authenticate, encryption, digital signatures, etc. certificate operations be normal without an OpenSSL based key? Just looking for a way to merge the environments if possible on a single key... Thx, cs __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cannot compile openssl-0.9.7d into php-4.3.6 with apache-1.3.27 on Redhat 7.3
I had tried building openssl with ./config shared before you suggested it, and after that I tried ./configure for php and it failed on db3 and imap (I have more to the ./configure command for php than I mentioned, just wanted to save email space for everyone). I ended up re-installing db3 and imap and re-building openssl and php and am back where I was with the undefined symbol: OPENSSL_add_all_algorithms_noconf. /usr/lib/apache/libphp4.so is where make install says that it copied to, and when I do a ls -l on it, it shows todays date, so I know that it's the correct one. It seems like php knows that there is a function called OPENSSL_add_all_algorithms_noconf in evp.h, but something is wrong when apache tries to load it, like libphp4.so is pointing to an old version of evp.h that doesn't have OPENSSL_add_all_algorithms_noconf in it. Or something like that. It looks like libssl.so.0.9.6b was last modified at the same time I built openssl so I'd think it would have the latest info in it. I was perplexed as to why it would still say 0.9.6b as I am compiling 0.9.7d, but I figure that maybe it just hasn't been updated by the openssl developers. If I search google for libssl.so.0.9.7d there are no results. Although this isn't working, I'm learning a lot about building applications! Gotta look at the bright side :) --- Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: Well, several things may be going on here. To begin with, you have only built the static libraries for OpenSSL. To get shared libraries as well, you need to configure like this: ./config shared And that will only produce shared libraries where we support it. However, that SHOULDN'T make a difference, since you have given the correct OpenSSL path to the php configure script. This means there's something fishy in the PHP build that makes it link with the default OpenSSL libraries for your platform. Another point: is /usr/lib/apache/libphp4.so really the thing you bulit or did your build end up somewhere else? If what you installed ended up somewhere else, that answers all your questions :-) In message [EMAIL PROTECTED] on Tue, 20 Apr 2004 22:10:39 -0700 (PDT), Mike Ryerse [EMAIL PROTECTED] said: mikeryerse Command for installing openssl-0.9.7d.tar.gz: mikeryerse ./config mikeryerse make mikeryerse make install mikeryerse mikeryerse Command for php-4.3.6: mikeryerse ./configure --with-openssl=/usr/local/ssl mikeryerse make mikeryerse make install mikeryerse mikeryerse Then when starting apache I get the following: mikeryerse Syntax error on line 264 of /etc/httpd/conf/httpd.conf: mikeryerse Cannot load /usr/lib/apache/libphp4.so into server: mikeryerse /usr/lib/apache/libphp4.so: undefined symbol: mikeryerse OPENSSL_add_all_algorithms_noconf mikeryerse mikeryerse I checked an ldd on libphp4.so and this is what I get: mikeryerse # ldd libphp4.so mikeryerse libssl.so.2 = /lib/libssl.so.2 (0x40414000) mikeryerse mikeryerse There seems to be a link on this file: mikeryerse # ls -l libssl.so.2 mikeryerse lrwxrwxrwx1 root root 16 Mar 13 09:05 libssl.so.2 mikeryerse - libssl.so.0.9.6b mikeryerse mikeryerse Can anyone help me please? I've been working on this for ages. - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte \ Tunnlandsvägen 52 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-708-26 53 44 \ SWEDEN \ Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cannot compile openssl-0.9.7d into php-4.3.6 with apache-1.3.27 on Redhat 7.3
OK, a few points: The way you configured OpenSSL, the library files ended up in /usr/local/ssl/lib. Also, they are named libcrypto.so.x.y.zt and libssl.so.x.y.zt with the symbolic links libcrypto.so.0 and libssl.so.0 (note, ending with 0, not 2) as well as libcrypto.so and libssl.so. This I know for sure. If PHP was linked with /lib/libssl.so.2, it did not link with the libssl.so that you imagine. Actually, the ending .2 makes me think you're running on RedHat or a derivate thereof, since they use that major library version. The symbol OPENSSL_add_all_algorithms_noconf exists in OpenSSL 0.9.7x but not in 0.9.6x. What I imagine happened is that PHP configuration specified correctly where to find OpenSSL header files (and therefore got /usr/local/ssl/include/openssl/evp.h) but not where to find the files to link with (and therefore hit /lib/libssl.so instead of /usr/local/ssl/lib/libssl.so). In message [EMAIL PROTECTED] on Wed, 21 Apr 2004 08:34:57 -0700 (PDT), Mike Ryerse [EMAIL PROTECTED] said: mikeryerse I had tried building openssl with ./config shared before you mikeryerse suggested it, and after that I tried ./configure for php and it mikeryerse failed on db3 and imap (I have more to the ./configure command for mikeryerse php than I mentioned, just wanted to save email space for everyone). mikeryerse I ended up re-installing db3 and imap and re-building openssl and php mikeryerse and am back where I was with the undefined symbol: mikeryerse OPENSSL_add_all_algorithms_noconf. mikeryerse /usr/lib/apache/libphp4.so is where make install says that it copied mikeryerse to, and when I do a ls -l on it, it shows todays date, so I know that mikeryerse it's the correct one. mikeryerse It seems like php knows that there is a function called mikeryerse OPENSSL_add_all_algorithms_noconf in evp.h, but something is wrong mikeryerse when apache tries to load it, like libphp4.so is pointing to an old mikeryerse version of evp.h that doesn't have OPENSSL_add_all_algorithms_noconf mikeryerse in it. Or something like that. mikeryerse It looks like libssl.so.0.9.6b was last modified at the same time I mikeryerse built openssl so I'd think it would have the latest info in it. I mikeryerse was perplexed as to why it would still say 0.9.6b as I am compiling mikeryerse 0.9.7d, but I figure that maybe it just hasn't been updated by the mikeryerse openssl developers. mikeryerse If I search google for libssl.so.0.9.7d there are no results. mikeryerse Although this isn't working, I'm learning a lot about building mikeryerse applications! Gotta look at the bright side :) mikeryerse mikeryerse --- Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: mikeryerse Well, several things may be going on here. mikeryerse mikeryerse To begin with, you have only built the static libraries for mikeryerse OpenSSL. mikeryerse To get shared libraries as well, you need to configure like this: mikeryerse mikeryerse ./config shared mikeryerse mikeryerse And that will only produce shared libraries where we support it. mikeryerse mikeryerse However, that SHOULDN'T make a difference, since you have given the mikeryerse correct OpenSSL path to the php configure script. This means mikeryerse there's mikeryerse something fishy in the PHP build that makes it link with the mikeryerse default mikeryerse OpenSSL libraries for your platform. mikeryerse mikeryerse Another point: is /usr/lib/apache/libphp4.so really the thing you mikeryerse bulit or did your build end up somewhere else? If what you mikeryerse installed mikeryerse ended up somewhere else, that answers all your questions :-) mikeryerse mikeryerse In message [EMAIL PROTECTED] on mikeryerse Tue, 20 Apr 2004 22:10:39 -0700 (PDT), Mike Ryerse mikeryerse [EMAIL PROTECTED] said: mikeryerse mikeryerse mikeryerse Command for installing openssl-0.9.7d.tar.gz: mikeryerse mikeryerse ./config mikeryerse mikeryerse make mikeryerse mikeryerse make install mikeryerse mikeryerse mikeryerse mikeryerse Command for php-4.3.6: mikeryerse mikeryerse ./configure --with-openssl=/usr/local/ssl mikeryerse mikeryerse make mikeryerse mikeryerse make install mikeryerse mikeryerse mikeryerse mikeryerse Then when starting apache I get the following: mikeryerse mikeryerse Syntax error on line 264 of /etc/httpd/conf/httpd.conf: mikeryerse mikeryerse Cannot load /usr/lib/apache/libphp4.so into server: mikeryerse mikeryerse /usr/lib/apache/libphp4.so: undefined symbol: mikeryerse mikeryerse OPENSSL_add_all_algorithms_noconf mikeryerse mikeryerse mikeryerse mikeryerse I checked an ldd on libphp4.so and this is what I get: mikeryerse mikeryerse # ldd libphp4.so mikeryerse mikeryerse libssl.so.2 = /lib/libssl.so.2 (0x40414000) mikeryerse mikeryerse mikeryerse mikeryerse There seems to be a link on this file: mikeryerse mikeryerse # ls -l libssl.so.2 mikeryerse mikeryerse lrwxrwxrwx1 root root 16 Mar 13 09:05 mikeryerse libssl.so.2
Re: Securing a CA
Rich Salz wrote: At the risk of being immodest, you might find this column useful: http://webservices.xml.com/pub/a/ws/2003/12/09/salz.html This is a verbatim quote from the text at that URL: The root will sign the Level 1 CA and then be taken offline. Anyone who wants to validate any identity within our organization only needs to have our root certificate. If the enterprise merges ... or joins a commercial PKI (such as Identrus), then we only need = to get the root certificate signed by our new super root. = Now, I've seen this (kind of) quote over and over again from the theoreticians of PKI, but as a practical implementor I've never really understood how things could be quite this simple. Perhaps it would be edifying if somebody who's been in this stuff more than just a few years could straighten me out. The example PKI from that article has only one intermediate certificate (called the Level 1 CA) so there would seem to be only two possible configurations for an SSL server operating under this example: either the server has a two-certificate chain (the L1 certificate and the end-user certificate for the server itself) or a three-certificate chain (above plus ROOT CA). Now, what has to happen at EACH server in the enterprise when doing a transition from this local CA to a commercial PKI (such as Identrus) If (without loss of generality) Identrus signs the pre-existing root certificate, that produces a new root certificate, although it contains the same public key as the pre-existing root. In the two-certificate case above, nothing needs to be done to the server, since it never had the root in the first place. In the three-certificate case, the new root certificate (signed by Identrus instead of signed by itself (self-signed)) must be installed on every server. I understand this. HOWEVER, what now happens at the client? In the two-certificate case, the client lacks the critical link from L1 to the Identrus root it already have (came installed in the browser) so in this case we need to visit every server and convert it from the two-certificate to the three-certificate configuration to get the missing link available to the client? In the three-certificate case do we need to replace the self-signed root in every server with the missing link certificate? In any case, it seems like we must do something explicit at every server in the enterprise. Am I missing something here? -- Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Securing a CA
Follow up to previous posting: I did try to do some experimentation in the context of trying to design a clean transition from the root we made in 1998 to the root I made in 2003. I did not have a great deal of success because the browsers I was working with at the time (Netscape 4.7x and IE 4 or 5) could not properly deal with what the PKI theoreticians call a branched certificate chain, which was what was really needed to address that problem. Could the PKI theoreticians acknowledge the fact that the real world certificate verifiers out there in fact cannot properly deal with a branched certificate chain, and that this deficiency severely limits the utility (e.g., truth :-) of statements such as If the enterprise merges or joins a commercial PKI (such as Identrus), then we only need to get the root certificate signed by our new super root? Needed added text: AND arrange for the NEW CERTIFICATE formed by getting our root certificate signed by our new super root to be available to the certificate chain validation software out there in the clients, AND make sure that in none of the four transition cases* is there any ambiguity in forming the certificate chain to be verified (this is the branch question) since the browsers don't deal well with trying to deal with branched certificate chains? Or am I living in the past, and up-to-date browsers have been fixed so this is no longer a problem??? N.B., the branched-certificate-chain case also occurs when you talk about so-called bridged PKIs. You have been warned. *Four transition cases I was considering: 1. unmodified client and unmodified server 2. unmodified clinet and updated server 3. updated client and as-yet unmodified server 4. updated client and server In all fairness my case was a bit harder since it was from one local root to another local root so it could not be assumed that the new local root was already in the client, while the present situation is that we can assume that the Identrus root is already present in the client, so the case of an unmodified client does not happen... -- Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Securing a CA
Actually, it might be as easy as changing the name of the root and issuing a new L1 certificate. The branch happens when an unmodified client (which still has the local root installed) needs to decide who has signed the L1 certificate. Its two choices are 1. the local root 2. the missing link that the server gave it, which has the same name (e.g., Subject Key Identifier, which is a hash of the Subject DN information) If you subtly change the Subject DN of the root (which in the new scheme of things becomes a first level down from the Identrus root), and then reinstall a L1 certificate in the server that has the new Issuer ID but the old Subject ID, then the end user certificate does not need to be redone (since its hash is based on the L1 name which was not modified), and when the verifying software is looking for the issuer of the L1 certificate, this hash HAS been modified, so the old root is no longer in contention... I'll do some gedanken-thinking about this... -- Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Problem with RSA encryption zero byte
Hello! I'am using RSA_public_encrypt() and RSA_private_decrypt(). I can't encrypt data with zero byte (for example hash data). My code like this: unsigned char *buf = null\x0null; . RSA_public_encrypt ( 9, buf, outbuf, rsa, RSA_PKCS1_PADDING); .. RSA_private_decrypt ( RSA_size(rsa), outbuf, mess, rsa, RSA_PKCS1_PADDING); After that mess will be null. Is it passible to encrypt data with zero bytes? If so, then how? Thanks so much! __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Securing a CA
I was envisioning something much simpler. Existing applications that know about the root CA work without configuration changes. New applications that need to know about the new larger PKI just add the new root to their list of trust anchors. I suppose that's really a bridge-CA. I don't think branched cert chains need to get involved, so I don't think I need to qualify or disclaim what I wrote. Yes, I ignored the details of distributing the new root certificate; there's a limit on the column length, ya know. In retrospect, adding (and get hte new root distirbuted and used) would probably have been worth adding. At any rate, the key point is that if you anchor everything you do under a single root, than moving your tree underneath something else is a lot eaiser if only one root has to move, rather than everything. okay? /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem with RSA encryption zero byte
On Wed, Apr 21, 2004 at 09:38:49PM +0400, Alexander Krizhanovskiy wrote: Hello! I'am using RSA_public_encrypt() and RSA_private_decrypt(). I can't encrypt data with zero byte (for example hash data). My code like this: unsigned char *buf = null\x0null; . RSA_public_encrypt ( 9, buf, outbuf, rsa, RSA_PKCS1_PADDING); .. RSA_private_decrypt ( RSA_size(rsa), outbuf, mess, rsa, RSA_PKCS1_PADDING); After that mess will be null. Is it passible to encrypt data with zero bytes? If so, then how? Please forgive me if I'm asking silly questions. 1. Have you checked the return value of RSA_private_decrypt? It is supposed to be the number of bytes of plaintext. (This is logical. How else would you know how many bytes are in the plaintext?) 2. How do you know that the mess is truncated? Of course, you're not just printfing the string. And, of course, you're not just examining the string in a debugger. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Securing a CA
Rich Salz wrote: I was envisioning something much simpler. Existing applications that know about the root CA work without configuration changes. New applications that need to know about the new larger PKI just add the new root to their list of trust anchors. I suppose that's really a bridge-CA. This is under some kind of assumption that the branched certificate chain does not totally confuse the verifier and cause it to crash or return I dunno so fail!. It seems, with some futher thought, that one might assume that if the chain will verify either way, it doesn't matter WHICH way the client chooses to go. However, this IS making an assumption about client software behaviour. However, I must ask the question: Have you actually DONE this before? If anybody on the list actually has experience with moving from a locally created root to being under one of the well-known PKI vendors a short note on successes, failures, and/or pitfalls would I think be greatly appreciated by the readership. Also, I guess I need to point out the vagueness of your reference above: New applications that need to know .. just add the new root to their list of trust anchors. This is not talking about servers or clients and could imply that explicit action is required AT THE CLIENT which I think we have determined is actually not necessary, at least as long as the old root doesn't interfere with the new chain validation. I don't think branched cert chains need to get involved, so I don't think I need to qualify or disclaim what I wrote. Yes, I ignored the details of distributing the new root certificate; there's a limit on the column length, ya know. In retrospect, adding (and get hte new root distirbuted and used) would probably have been worth adding. Yes, I understand there is a limit on column length, and that your real purpose was to publicise XKMS :-) So the comment I seized on was just a throw-away platitude, and maybe it was not appropriate for me to have made such a mountain out of that particular molehill. At any rate, the key point is that if you anchor everything you do under a single root, than moving your tree underneath something else is a lot eaiser if only one root has to move, rather than everything. This is quite true. One of the things we DID have to deal with during our old local root to new local root transition was people who decided to mark the end-user certificate as trusted in their browsers rather than take the risk of trusting our root. Of course that doesn't survive a transition at all... :-) Best regards -zben -- Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Encryption / Decryption with the EVP_Cipher interface
I have an application where an application may switch from reading to writing and back again at random. I've determined that either I need a ctx context each for decryption / encryption, or I use the same ctx in sequence on the file. I presume that I need to detect this change and call EVP_CipherInit_ex to alter the context ctx accordingly. However, do I need to call EVP_CipherFinal first to finalize the ctx for the prior mode? My next question involves the encryption of very short strings (less than the cipher block size)... does the ctx buffer these short strings until either another call to the Update function fills out the block and/or the Final function is called? I will have unpredictable string lengths being encrypted, and I do not want to introduce padding into the middle of the encrypted files. Thanks for your help... - Eric Morris NC State University __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cannot compile openssl-0.9.7d into php-4.3.6 with apache-1.3.27 on Redhat 7.3
I have a question about your reponse: If php is finding /usr/local/ssl/include/evp.h but using /lib/libssl.so instead of /usr/local/ssl/lib/libssl.so, how do I link php to the correct lib? I thought about moving/renaming /lib/libssl.so, but since it seems to be linked to /lib/libssl.so.x.y.z, I am concerned that there may be other applications dependant on it, and I am not sure how to check what applications are using this file. I suppose there may be an additional directive that I can pass to php in ./configure that defines the location of the correct libssl.so file to use. --- Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: OK, a few points: The way you configured OpenSSL, the library files ended up in /usr/local/ssl/lib. Also, they are named libcrypto.so.x.y.zt and libssl.so.x.y.zt with the symbolic links libcrypto.so.0 and libssl.so.0 (note, ending with 0, not 2) as well as libcrypto.so and libssl.so. This I know for sure. If PHP was linked with /lib/libssl.so.2, it did not link with the libssl.so that you imagine. Actually, the ending .2 makes me think you're running on RedHat or a derivate thereof, since they use that major library version. The symbol OPENSSL_add_all_algorithms_noconf exists in OpenSSL 0.9.7x but not in 0.9.6x. What I imagine happened is that PHP configuration specified correctly where to find OpenSSL header files (and therefore got /usr/local/ssl/include/openssl/evp.h) but not where to find the files to link with (and therefore hit /lib/libssl.so instead of /usr/local/ssl/lib/libssl.so). In message [EMAIL PROTECTED] on Wed, 21 Apr 2004 08:34:57 -0700 (PDT), Mike Ryerse [EMAIL PROTECTED] said: mikeryerse I had tried building openssl with ./config shared before you mikeryerse suggested it, and after that I tried ./configure for php and it mikeryerse failed on db3 and imap (I have more to the ./configure command for mikeryerse php than I mentioned, just wanted to save email space for everyone). mikeryerse I ended up re-installing db3 and imap and re-building openssl and php mikeryerse and am back where I was with the undefined symbol: mikeryerse OPENSSL_add_all_algorithms_noconf. mikeryerse /usr/lib/apache/libphp4.so is where make install says that it copied mikeryerse to, and when I do a ls -l on it, it shows todays date, so I know that mikeryerse it's the correct one. mikeryerse It seems like php knows that there is a function called mikeryerse OPENSSL_add_all_algorithms_noconf in evp.h, but something is wrong mikeryerse when apache tries to load it, like libphp4.so is pointing to an old mikeryerse version of evp.h that doesn't have OPENSSL_add_all_algorithms_noconf mikeryerse in it. Or something like that. mikeryerse It looks like libssl.so.0.9.6b was last modified at the same time I mikeryerse built openssl so I'd think it would have the latest info in it. I mikeryerse was perplexed as to why it would still say 0.9.6b as I am compiling mikeryerse 0.9.7d, but I figure that maybe it just hasn't been updated by the mikeryerse openssl developers. mikeryerse If I search google for libssl.so.0.9.7d there are no results. mikeryerse Although this isn't working, I'm learning a lot about building mikeryerse applications! Gotta look at the bright side :) mikeryerse mikeryerse --- Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: mikeryerse Well, several things may be going on here. mikeryerse mikeryerse To begin with, you have only built the static libraries for mikeryerse OpenSSL. mikeryerse To get shared libraries as well, you need to configure like this: mikeryerse mikeryerse ./config shared mikeryerse mikeryerse And that will only produce shared libraries where we support it. mikeryerse mikeryerse However, that SHOULDN'T make a difference, since you have given the mikeryerse correct OpenSSL path to the php configure script. This means mikeryerse there's mikeryerse something fishy in the PHP build that makes it link with the mikeryerse default mikeryerse OpenSSL libraries for your platform. mikeryerse mikeryerse Another point: is /usr/lib/apache/libphp4.so really the thing you mikeryerse bulit or did your build end up somewhere else? If what you mikeryerse installed mikeryerse ended up somewhere else, that answers all your questions :-) mikeryerse mikeryerse In message [EMAIL PROTECTED] on mikeryerse Tue, 20 Apr 2004 22:10:39 -0700 (PDT), Mike Ryerse mikeryerse [EMAIL PROTECTED] said: mikeryerse mikeryerse mikeryerse Command for installing openssl-0.9.7d.tar.gz: mikeryerse mikeryerse ./config mikeryerse mikeryerse make mikeryerse mikeryerse make install mikeryerse mikeryerse mikeryerse mikeryerse Command for php-4.3.6: mikeryerse mikeryerse ./configure --with-openssl=/usr/local/ssl mikeryerse mikeryerse make mikeryerse mikeryerse make install mikeryerse mikeryerse mikeryerse mikeryerse Then
Re: Securing a CA
However, I must ask the question: Have you actually DONE this before? Yup. But not with SSL and browsers. You're focused on that, but I was talking in general. In reality, of course, everyone just buys a commercial SSL cert rather than try to fight with the browsers's (sic!) trust issues. New applications that need to know .. just add the new root to their list of trust anchors. This is not talking about servers or clients and could imply that explicit action is required AT THE CLIENT which I think we have determined is actually not necessary, at least as long as the old root doesn't interfere with the new chain validation. By need to know I meant applications that need to know about *other* CA's that the new root has signed. Those clients will need to incorporate the new root into their list of trust anchors. Old clients don't. our old local root to new local root transition was people who decided to mark the end-user certificate as trusted in their browsers rather than take the risk of trusting our root. If you want PGP you know where to find it. /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cannot compile openssl-0.9.7d into php-4.3.6 with apache-1.3.27 on Redhat 7.3
I was looking at the install instructions for openssl-0.9.7d and it said that after running ./configure, and then make, that some *.a files are installed in /usr/local/ssl/lib, not *.so files. Also, It seems that when I build openssl-0.9.7d, it seems to show that /lib/libssl.so* was modified. Is there a way for me to check /lib/libssl.so* to see if it contains OPENSSL_add_all_algorithms_noconf or not? --- Mike Ryerse [EMAIL PROTECTED] wrote: I have a question about your reponse: If php is finding /usr/local/ssl/include/evp.h but using /lib/libssl.so instead of /usr/local/ssl/lib/libssl.so, how do I link php to the correct lib? I thought about moving/renaming /lib/libssl.so, but since it seems to be linked to /lib/libssl.so.x.y.z, I am concerned that there may be other applications dependant on it, and I am not sure how to check what applications are using this file. I suppose there may be an additional directive that I can pass to php in ./configure that defines the location of the correct libssl.so file to use. --- Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: OK, a few points: The way you configured OpenSSL, the library files ended up in /usr/local/ssl/lib. Also, they are named libcrypto.so.x.y.zt and libssl.so.x.y.zt with the symbolic links libcrypto.so.0 and libssl.so.0 (note, ending with 0, not 2) as well as libcrypto.so and libssl.so. This I know for sure. If PHP was linked with /lib/libssl.so.2, it did not link with the libssl.so that you imagine. Actually, the ending .2 makes me think you're running on RedHat or a derivate thereof, since they use that major library version. The symbol OPENSSL_add_all_algorithms_noconf exists in OpenSSL 0.9.7x but not in 0.9.6x. What I imagine happened is that PHP configuration specified correctly where to find OpenSSL header files (and therefore got /usr/local/ssl/include/openssl/evp.h) but not where to find the files to link with (and therefore hit /lib/libssl.so instead of /usr/local/ssl/lib/libssl.so). In message [EMAIL PROTECTED] on Wed, 21 Apr 2004 08:34:57 -0700 (PDT), Mike Ryerse [EMAIL PROTECTED] said: mikeryerse I had tried building openssl with ./config shared before you mikeryerse suggested it, and after that I tried ./configure for php and it mikeryerse failed on db3 and imap (I have more to the ./configure command for mikeryerse php than I mentioned, just wanted to save email space for everyone). mikeryerse I ended up re-installing db3 and imap and re-building openssl and php mikeryerse and am back where I was with the undefined symbol: mikeryerse OPENSSL_add_all_algorithms_noconf. mikeryerse /usr/lib/apache/libphp4.so is where make install says that it copied mikeryerse to, and when I do a ls -l on it, it shows todays date, so I know that mikeryerse it's the correct one. mikeryerse It seems like php knows that there is a function called mikeryerse OPENSSL_add_all_algorithms_noconf in evp.h, but something is wrong mikeryerse when apache tries to load it, like libphp4.so is pointing to an old mikeryerse version of evp.h that doesn't have OPENSSL_add_all_algorithms_noconf mikeryerse in it. Or something like that. mikeryerse It looks like libssl.so.0.9.6b was last modified at the same time I mikeryerse built openssl so I'd think it would have the latest info in it. I mikeryerse was perplexed as to why it would still say 0.9.6b as I am compiling mikeryerse 0.9.7d, but I figure that maybe it just hasn't been updated by the mikeryerse openssl developers. mikeryerse If I search google for libssl.so.0.9.7d there are no results. mikeryerse Although this isn't working, I'm learning a lot about building mikeryerse applications! Gotta look at the bright side :) mikeryerse mikeryerse --- Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: mikeryerse Well, several things may be going on here. mikeryerse mikeryerse To begin with, you have only built the static libraries for mikeryerse OpenSSL. mikeryerse To get shared libraries as well, you need to configure like this: mikeryerse mikeryerse ./config shared mikeryerse mikeryerse And that will only produce shared libraries where we support it. mikeryerse mikeryerse However, that SHOULDN'T make a difference, since you have given the mikeryerse correct OpenSSL path to the php configure script. This means mikeryerse there's mikeryerse something fishy in the PHP build that makes it link with the mikeryerse default mikeryerse OpenSSL libraries for your platform. mikeryerse mikeryerse Another point: is /usr/lib/apache/libphp4.so really the thing you mikeryerse bulit or did your build end up somewhere else? If what you mikeryerse installed mikeryerse ended up somewhere else, that answers all your questions :-) mikeryerse mikeryerse
Re: cannot compile openssl-0.9.7d into php-4.3.6 with apache-1.3.27 on Redhat 7.3
Try the following command: nm /lib/libssl.so | grep OPENSSL_add_all_algorithms_noconf 'nm' shows the symbolic names in an archive or library file, and 'grep' finds the symbol you want (assuming it's there...) - Eric Morris Mike Ryerse wrote: I was looking at the install instructions for openssl-0.9.7d and it said that after running ./configure, and then make, that some *.a files are installed in /usr/local/ssl/lib, not *.so files. Also, It seems that when I build openssl-0.9.7d, it seems to show that /lib/libssl.so* was modified. Is there a way for me to check /lib/libssl.so* to see if it contains OPENSSL_add_all_algorithms_noconf or not? --- Mike Ryerse [EMAIL PROTECTED] wrote: I have a question about your reponse: If php is finding /usr/local/ssl/include/evp.h but using /lib/libssl.so instead of /usr/local/ssl/lib/libssl.so, how do I link php to the correct lib? I thought about moving/renaming /lib/libssl.so, but since it seems to be linked to /lib/libssl.so.x.y.z, I am concerned that there may be other applications dependant on it, and I am not sure how to check what applications are using this file. I suppose there may be an additional directive that I can pass to php in ./configure that defines the location of the correct libssl.so file to use. --- Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: OK, a few points: The way you configured OpenSSL, the library files ended up in /usr/local/ssl/lib. Also, they are named libcrypto.so.x.y.zt and libssl.so.x.y.zt with the symbolic links libcrypto.so.0 and libssl.so.0 (note, ending with 0, not 2) as well as libcrypto.so and libssl.so. This I know for sure. If PHP was linked with /lib/libssl.so.2, it did not link with the libssl.so that you imagine. Actually, the ending .2 makes me think you're running on RedHat or a derivate thereof, since they use that major library version. The symbol OPENSSL_add_all_algorithms_noconf exists in OpenSSL 0.9.7x but not in 0.9.6x. What I imagine happened is that PHP configuration specified correctly where to find OpenSSL header files (and therefore got /usr/local/ssl/include/openssl/evp.h) but not where to find the files to link with (and therefore hit /lib/libssl.so instead of /usr/local/ssl/lib/libssl.so). In message [EMAIL PROTECTED] on Wed, 21 Apr 2004 08:34:57 -0700 (PDT), Mike Ryerse [EMAIL PROTECTED] said: mikeryerse I had tried building openssl with ./config shared before you mikeryerse suggested it, and after that I tried ./configure for php and it mikeryerse failed on db3 and imap (I have more to the ./configure command for mikeryerse php than I mentioned, just wanted to save email space for everyone). mikeryerse I ended up re-installing db3 and imap and re-building openssl and php mikeryerse and am back where I was with the undefined symbol: mikeryerse OPENSSL_add_all_algorithms_noconf. mikeryerse /usr/lib/apache/libphp4.so is where make install says that it copied mikeryerse to, and when I do a ls -l on it, it shows todays date, so I know that mikeryerse it's the correct one. mikeryerse It seems like php knows that there is a function called mikeryerse OPENSSL_add_all_algorithms_noconf in evp.h, but something is wrong mikeryerse when apache tries to load it, like libphp4.so is pointing to an old mikeryerse version of evp.h that doesn't have OPENSSL_add_all_algorithms_noconf mikeryerse in it. Or something like that. mikeryerse It looks like libssl.so.0.9.6b was last modified at the same time I mikeryerse built openssl so I'd think it would have the latest info in it. I mikeryerse was perplexed as to why it would still say 0.9.6b as I am compiling mikeryerse 0.9.7d, but I figure that maybe it just hasn't been updated by the mikeryerse openssl developers. mikeryerse If I search google for libssl.so.0.9.7d there are no results. mikeryerse Although this isn't working, I'm learning a lot about building mikeryerse applications! Gotta look at the bright side :) mikeryerse mikeryerse --- Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: mikeryerse Well, several things may be going on here. mikeryerse mikeryerse To begin with, you have only built the static libraries for mikeryerse OpenSSL. mikeryerse To get shared libraries as well, you need to configure like this: mikeryerse mikeryerse ./config shared mikeryerse mikeryerse And that will only produce shared libraries where we support it. mikeryerse mikeryerse However, that SHOULDN'T make a difference, since you have given the mikeryerse correct OpenSSL path to the php configure script. This means mikeryerse there's mikeryerse something fishy in the PHP build that makes it link with the mikeryerse default mikeryerse OpenSSL libraries for your platform. mikeryerse mikeryerse Another point: is /usr/lib/apache/libphp4.so really the thing you mikeryerse bulit or did your build end up somewhere else? If
Re: cannot compile openssl-0.9.7d into php-4.3.6 with apache-1.3.27 on Redhat 7.3
oh, you need to run that command on the ACTUAL library file, not a link so nm /lib/libssl.so.x.y.z ... - Eric Morris Eric Morris wrote: Try the following command: nm /lib/libssl.so | grep OPENSSL_add_all_algorithms_noconf 'nm' shows the symbolic names in an archive or library file, and 'grep' finds the symbol you want (assuming it's there...) - Eric Morris Mike Ryerse wrote: I was looking at the install instructions for openssl-0.9.7d and it said that after running ./configure, and then make, that some *.a files are installed in /usr/local/ssl/lib, not *.so files. Also, It seems that when I build openssl-0.9.7d, it seems to show that /lib/libssl.so* was modified. Is there a way for me to check /lib/libssl.so* to see if it contains OPENSSL_add_all_algorithms_noconf or not? --- Mike Ryerse [EMAIL PROTECTED] wrote: I have a question about your reponse: If php is finding /usr/local/ssl/include/evp.h but using /lib/libssl.so instead of /usr/local/ssl/lib/libssl.so, how do I link php to the correct lib? I thought about moving/renaming /lib/libssl.so, but since it seems to be linked to /lib/libssl.so.x.y.z, I am concerned that there may be other applications dependant on it, and I am not sure how to check what applications are using this file. I suppose there may be an additional directive that I can pass to php in ./configure that defines the location of the correct libssl.so file to use. --- Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: OK, a few points: The way you configured OpenSSL, the library files ended up in /usr/local/ssl/lib. Also, they are named libcrypto.so.x.y.zt and libssl.so.x.y.zt with the symbolic links libcrypto.so.0 and libssl.so.0 (note, ending with 0, not 2) as well as libcrypto.so and libssl.so. This I know for sure. If PHP was linked with /lib/libssl.so.2, it did not link with the libssl.so that you imagine. Actually, the ending .2 makes me think you're running on RedHat or a derivate thereof, since they use that major library version. The symbol OPENSSL_add_all_algorithms_noconf exists in OpenSSL 0.9.7x but not in 0.9.6x. What I imagine happened is that PHP configuration specified correctly where to find OpenSSL header files (and therefore got /usr/local/ssl/include/openssl/evp.h) but not where to find the files to link with (and therefore hit /lib/libssl.so instead of /usr/local/ssl/lib/libssl.so). In message [EMAIL PROTECTED] on Wed, 21 Apr 2004 08:34:57 -0700 (PDT), Mike Ryerse [EMAIL PROTECTED] said: mikeryerse I had tried building openssl with ./config shared before you mikeryerse suggested it, and after that I tried ./configure for php and it mikeryerse failed on db3 and imap (I have more to the ./configure command for mikeryerse php than I mentioned, just wanted to save email space for everyone). mikeryerse I ended up re-installing db3 and imap and re-building openssl and php mikeryerse and am back where I was with the undefined symbol: mikeryerse OPENSSL_add_all_algorithms_noconf. mikeryerse /usr/lib/apache/libphp4.so is where make install says that it copied mikeryerse to, and when I do a ls -l on it, it shows todays date, so I know that mikeryerse it's the correct one. mikeryerse It seems like php knows that there is a function called mikeryerse OPENSSL_add_all_algorithms_noconf in evp.h, but something is wrong mikeryerse when apache tries to load it, like libphp4.so is pointing to an old mikeryerse version of evp.h that doesn't have OPENSSL_add_all_algorithms_noconf mikeryerse in it. Or something like that. mikeryerse It looks like libssl.so.0.9.6b was last modified at the same time I mikeryerse built openssl so I'd think it would have the latest info in it. I mikeryerse was perplexed as to why it would still say 0.9.6b as I am compiling mikeryerse 0.9.7d, but I figure that maybe it just hasn't been updated by the mikeryerse openssl developers. mikeryerse If I search google for libssl.so.0.9.7d there are no results. mikeryerse Although this isn't working, I'm learning a lot about building mikeryerse applications! Gotta look at the bright side :) mikeryerse mikeryerse --- Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: mikeryerse Well, several things may be going on here. mikeryerse mikeryerse To begin with, you have only built the static libraries for mikeryerse OpenSSL. mikeryerse To get shared libraries as well, you need to configure like this: mikeryerse mikeryerse ./config shared mikeryerse mikeryerse And that will only produce shared libraries where we support it. mikeryerse mikeryerse However, that SHOULDN'T make a difference, since you have given the mikeryerse correct OpenSSL path to the php configure script. This means mikeryerse there's mikeryerse something fishy in the PHP build that makes it link with the mikeryerse default mikeryerse OpenSSL libraries for your platform. mikeryerse mikeryerse Another point: is
Re: cannot compile openssl-0.9.7d into php-4.3.6 with apache-1.3.27 on Redhat 7.3
In message [EMAIL PROTECTED] on Wed, 21 Apr 2004 13:23:44 -0700 (PDT), Mike Ryerse [EMAIL PROTECTED] said: mikeryerse I was looking at the install instructions for mikeryerse openssl-0.9.7d and it said that after running ./configure, mikeryerse and then make, that some *.a files are installed in mikeryerse /usr/local/ssl/lib, not *.so files. That's a documentation mistake. If you look in the top OpenSSL Makefile, you will see that install: installs both static (.a) and shared (.so*) file in $(INSTALL_PREFIX)$(INSTALLTOP)/lib ($(INSTALL_PREFIX)$(INSTALLTOP) become /usr/local/ssl in the default configuration). Have you looked in /usr/local/ssl/lib? - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte \ Tunnlandsvägen 52 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-708-26 53 44 \ SWEDEN \ Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cannot compile openssl-0.9.7d into php-4.3.6 with apache-1.3.27 on Redhat 7.3
In message [EMAIL PROTECTED] on Wed, 21 Apr 2004 12:57:40 -0700 (PDT), Mike Ryerse [EMAIL PROTECTED] said: mikeryerse I have a question about your reponse: mikeryerse If php is finding /usr/local/ssl/include/evp.h but using mikeryerse /lib/libssl.so instead of /usr/local/ssl/lib/libssl.so, mikeryerse how do I link php to the correct lib? When linking, you should have the following arguments: -L/usr/local/ssl/lib -lssl -lcrypto You should check that the relevant PHP build uses that. Also, a case I didn't think of: the process that starts apache should have the following line somewhere: LD_LIBRARY_PATH=/usr/local/ssl/lib; export LD_LIBRARY_PATH mikeryerse I thought about moving/renaming /lib/libssl.so, but since mikeryerse it seems to be linked to /lib/libssl.so.x.y.z, I am mikeryerse concerned that there may be other applications dependant mikeryerse on it, and I am not sure how to check what applications mikeryerse are using this file. It was probably a smart move to leave it be. - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte \ Tunnlandsvägen 52 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-708-26 53 44 \ SWEDEN \ Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
