PHP SOAP cannot connect to an SSL WSDL source

Question

Trying to make Soap connection to a https:// WSDL source via PHP/Win32, but keep getting the error:

Warning: SoapClient::SoapClient() [soapclient.soapclient]: I/O warning : failed to load external entity "https://...

If I try to save the WSDL locally and access it then, the SoapFault->faultstring property has the message "SSL support is not available in this build".

After some Googling, seems like PHP SOAP cannot connect to a HTTPS source. HTTP is OK, though.

Is there a workaround for this? Or is there an alternative SOAP version/module I can install?

Answer 1

HTTPS support for SOAP in PHP5

If you’re seeing error messages about missing https wrappers when trying to use SOAP (”Unable to find the wrapper “https” – did you forget to enable it when you configured PHP?” or “[HTTP] SSL support is not available in this build”), you haven’t installed the SSL libraries to support secure transactions.

1. Uncomment extension=php_soap.dll in your php.ini

2. Uncomment extension=php_openssl.dll in your php.ini

3. Copy ssleay32.dll and libeay32.dll to your windows system32 directory

4. Reboot apache, et voila!

I originally found this answer at: http://webponce.com/rants/2008/04/https-support-for-soap-in-php5-under-windows/

Answer 2

I had the same problem. openSSL, cURL were enabled, initiated a SoapClient with option of location to stored certificated, etc, etc.. tried everything.

Turns out it does work in CLI mode. Thus php_sapi = CLI. As we almost always run our webservices calls as a cronjob, scheduled task in Windows, this is not really a bad thing. I was really glad to get it working!

Update: Okay, turns out when PHP is running as an Apache module, it uses the by opensll required libraries libeay32.dll and ssleay32.dll from the Apache install. When using PHP in CLI is uses the libraries from the PHP directory/install. Overwriting the 2 Apache dlls with the dlls from the PHP directory did the trick. It now also runs under Apache. So your PHP version should match with the working dlls for the specific version. When it still doesn't work in the web interface. Please check that Apache isn't loading these dlls from a Windows System directory, specified earlier in your system defined path, which is picked up by Apache.