You most likely have too old version of the pfpro SDK.
(old ones have some ssl funcs in it which clash with openssl)

I don't think that is the case.  I am using the following shared library from the sdk:
-rwxrwxr-x    1 501      501        690560 Jun 11  2002 libpfpro.so*

I went and redownloaded the SDK this morning, and the lib in their download is the same as this one.  Here are my configure statements.  (Also, in the meantime I have upgraded to openssl-0.9.7)

apache-1.3.27:  ./configure --prefix=/usr/local/apache --server-uid=daemon --server-gid=daemon --activate-module=src/modules/php4/libphp4.a:

php-4.3.1: ./configure --with-apache=../apache_1.3.27 --enable-bcmath --with-curl --with-gettext --with-mysql=/usr/local/mysql --with-mcrypt=../libmcrypt-2.5.0 --with-openssl=/usr/local/ssl --with-pear --disable-cgi --with-gd --with-zlib --with-jpeg-dir=/usr/lib --with-pfpro

With just the --with-pfpro  option I believe it uses the PHP internal pfpro extension, is this the issue, and should I be pointing it to the pfpro shared library instead?  

If so, will I need to recompile everything as shared?  I prefer static for the raw performance, but will switch to shared if that will solve this issue.

Thanks again.

One other note that I realized should probally be taken into account with this.  I am using apache-ssl Ben-SSL/1.48 and not mod_ssl.

Where are the pfpro libs and headers installed then?
And you're absolutely sure you don't have any older versions
laying around? (I somewhat remember there being some problems before with pfpro and openssl..)

On a quick side note, Payflow pro is working perfectly.  We use it for our signups, and the signup procedure is functioning perfectly.  Just cURL and fsockopen() are not happy..  :(

I placed them in /usr/lib and /usr/local/include respectfully.  /usr/local/lib/pfpro.h is a symlink to the header in /usr/local/include

~> locate pfpro | sort
/usr/lib/libpfpro.so
/usr/local/include/pfpro.h
/usr/local/lib/pfpro.h
/usr/local/src/php-4.3.1/ext/pfpro
/usr/local/src/php-4.3.1/ext/pfpro/CREDITS
/usr/local/src/php-4.3.1/ext/pfpro/TODO
/usr/local/src/php-4.3.1/ext/pfpro/config.m4
/usr/local/src/php-4.3.1/ext/pfpro/pfpro.c
/usr/local/src/php-4.3.1/ext/pfpro/pfpro.lo
/usr/local/src/php-4.3.1/ext/pfpro/pfpro.o
/usr/local/src/php-4.3.1/ext/pfpro/php_pfpro.h
/usr/local/src/php-4.3.1/tests/testpfpro.php

Well, I have now compiled in openssl-0.9.7a and cURL-7.10.3 and instead of just getting nothing, I get this in my logs:
[Fri Feb 28 18:19:46 2003] [notice] child pid 11916 exit signal Segmentation fault (11)
[Fri Feb 28 18:19:46 2003] [notice] child pid 11908 exit signal Segmentation fault (11)

That is with an attempted fsockopen("ssl://securehost.hre", 443, errorno, error);  call that works perfectly with out the -pfpro option ... 

I guess I can always have PHP shell out to a PERL script and manage the transaction .. 

Thanks for your help :)

Does compiling PHP as DSO for Apache fix this?
If so, you can bogus this, we already have a report about that one.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

I have verified, through VeriSign, that the SDK of PayflowPro (currently, v. 3.06) is statically linked against the openssl libraries.

They have no plans on changing this design, therefor we will be changing payment processors.

Good luck!

I've had the same problem with the old/deprecated pfpro sdk and PHP 4.4.7.

When the extension is built into the php binary (--with-pfpro=DIR), cURL breaks with https:// URLs.

When the extension is built as a shared module (--with-pfpro=shared,DIR), cURL works.

Hope this helps, though in the long run, I'd recommend moving away from any reliance on the pfpro SDK.