Viewed   644 times

I’ve been trying to access this particular REST service from a PHP page I’ve created on our server. I narrowed the problem down to these two lines. So my PHP page looks like this:

$response = file_get_contents("*&outSR=102100&searchExtent=&f=json");

echo $response; ?>

The page dies on line 2 with the following errors:

  • Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in ...php on line 2
    • Warning: file_get_contents(): Failed to enable crypto in ...php on line 2
    • Warning: file_get_contents(*&outSR=102100&searchExtent=&f=json): failed to open stream: operation failed in ...php on line 2

We’re using a Gentoo server. We recently upgraded to PHP version 5.6. It was after the upgrade when this problem appeared.

I found when I replace the REST service with an address like; my page works just fine.

In an earlier attempt I set “verify_peer”=>false, and passed that in as an argument to file_get_contents, as described here: file_get_contents ignoring verify_peer=>false? But like the writer noted; it made no difference.

I’ve asked one of our server administrators if these lines in our php.ini file exist:

  • extension=php_openssl.dll
  • allow_url_fopen = On

He told me that since we’re on Gentoo, openssl is compiled when we build; and it’s not set in the php.ini file.

I also confirmed that allow_url_fopen is working. Due to the specialized nature of this problem; I’m not finding a lot of information for help. Have any of you come across something like this? Thanks.



This was an enormously helpful link to find:

An official document describing the changes made to open ssl in PHP 5.6 From here I learned of one more parameter I should have set to false: "verify_peer_name"=>false

Note: This has very significant security implications. Disabling verification potentially permits a MITM attacker to use an invalid certificate to eavesdrop on the requests. While it may be useful to do this in local development, other approaches should be used in production.

So my working code looks like this:


$response = file_get_contents("*&outSR=102100&searchExtent=&f=json", false, stream_context_create($arrContextOptions));

echo $response; ?>
Thursday, October 27, 2022
... error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small

The error number you are interested in is the OpenSSL error 0x14082174.

The SSL3_CHECK_CERT_AND_ALGORITHM is usually seen when enabling export grade ciphers. It may be showing up again in non-export grade negotiations due to Logjam (see below).

I'm assuming DH Key is too small is the main problem, but I have no idea what that means. I've googled Diffie–Hellman key exchange, along with the message "key too small" but I haven't had much luck.

That's due to the recent Logjam attack from the paper Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice.

You should use 2048-bit Diffie-Hellman groups or larger. You should not be using 512-bit or 1024-bit Diffie-Hellman groups.

The first thing to check for is your cipher list string. It should be similar to:


It will avoid the export grade ciphers, and use modern ciphers. But you will also need to ensure your DH callback is not using a weak/small field size. For that, you need to check the server configuration.

Some folks are "solving" the issue with kRSA. kRSA is a key transport scheme, not a key agreement scheme. The RSA key transport scheme does not provide forward secrecy, and its use is usually discouraged. In fact, its going to be removed from TLS 1.3.

I can only say "usually discouraged" because it depends on the data being protected. If you have SSL/TLS to guard downloads of a publicly available file, then its probably OK to use. If your website has a login, then its probably a little risky to use it because the password is secret data (unlike the publicly downloadable file).

To avoid key transport and pass those Qualsys SSL Labs tests for web server configurations and forward secrecy, use:


In your Apache configuration file, it would look like so:

# cat /etc/httpd/conf.d/ssl.conf | grep SSLCipherSuite
SSLCipherSuite HIGH:!aNULL:!kRSA:!MD5:!RC4

I seem to recall wget rejected small groups quite some time before the paper was released. It might make a good test case for your site.

There's also an improved sslscan, which tests for lots of things. That might make a good QA tool, too.

Tuesday, August 30, 2022

A few years ago I benchmarked the two and CURL was faster. With CURL you create one CURL instance which can be used for every request, and it maps directly to the very fast libcurl library. Using file_get_contents you have the overhead of protocol wrappers and the initialization code getting executed for every single request.

I will dig out my benchmark script and run on PHP 5.3 but I suspect that CURL will still be faster.

Friday, December 16, 2022

In your url try:


(append whatever the rest of the URL for your API should be)

Friday, November 4, 2022

Twilio developer evangelist here.

I found this happened when you don't have the curl bindings for PHP. Try recompiling PHP with curl or installing the php5-curl package.

Let me know if that helps at all.

Thursday, October 13, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :