I'm testing a plugin on HostGator, GoDaddy, DreamHost and DigitalOcean, developing locally with VVV. I'm running WordPress 4.4.2 across the board.

I'm using wp_remote_get() to retrieve weather data from NOAA's Text Data Server using 3 different endpoints. I ran into trouble when I extended testing to another host, Arvixe, where I was getting a 400 Bad Request error for my third endpoint. The others work fine.

I discovered setting the sslverify arg to false in the request "fixed" the issue on this host but I'm unclear as to why, and if that is actually a good thing. The plugin merely displays data pulled from NOAA but disabling verification like this seems unnecessary and wrong.

The odd thing is, I have written wp-cli commands for this plugin and they work as expected, using the same classes and method without errors. Command line PHP on this host is v5.5 and I've tested WordPress using PHP 5.3 - 7.0 with the same results.

Searching further I read an answer given by Otto that has me wondering if I'm looking in the wrong place for a solution.

I really appreciate any help figuring out what the real underlying problem could be.

Any thoughts or suggestions?

More details: The site on Arvixe is http The other testing sites are a mix of http/https, with no errors. The cert is valid

enter image description here

  • The cert screenshot above belongs to the site I'm pulling from. A typical URL, for example: https://aviationweather.gov/adds/dataserver_current/httpparam?dataSource=aircraftreports&requestType=retrieve&format=xml&radialDistance=100%3B-76.100000%2C43.120000&hoursBeforeNow=4 Another post(old) discussing this
    – Mark
    Commented Apr 12, 2016 at 3:57

1 Answer 1


This is probably the wrong place to get into the details of certificate verification, and I am not sure I understand all of it so this answer going to focus on the wordpress API.

The issue with certificate verification is that you need a list of root certificates of the issuer companies in order to verify a specific cert. That list changes and therefor servers need to be updates with the info. Obviously supporting "browser like functionality" is not one of the main things that server admins think of, and your software might end on a server in which it is not defined at all, or just being stale info.

Otto's answer details how wordpress core handles it, and it does it by providing its on bundle of root certs, and it is used by default by the wordpress http API (checked for 4.4, not sure when it is started). Still your plugin might be installed on earlier version which contains stale info (at this point in time, just a week or so before 4.5 is launched only about 50% of wordpress sites run 4.4).

So what can you do?

  1. easy option: Let the user decide. In the end it is his call how secure he wants his site to be. It might be that he can't or doesn't want to do the effort of updating his root certs.

  2. Supply your own root certificates with the plugin. This way you can push updates whenever the root certificates need to update. The relevant core api that handles it is WP_HTTP::request with the sslcertificates parameter in the $args parameter. Higher level HTTP API function probably pass that parameter in one way or another to it.

  • Thanks for the reply, Mark. What I got from Otto's answer is that since 3.7 the WP_HTTP API should handle verification using its own copy of the CA Root Certificates file and I can rely on wp_remote_get() for proper verification (assuming WP 3.7+). Is that not accurate? All I have to go on at this point is the wp_remote_get() response and the fact that setting sslverify to false appears to prevent the error.
    – Mark
    Commented Apr 12, 2016 at 5:26
  • No, since the data might need to be updated and you just don't know if it is. 3.7 was like 3 years ago, so the root certificate list on a 3.7 install is 3 years old and since then more root issuers might have been added or removed. In any case wordpress by default uses the certificates list that comes with it, for its HTTP API so if you are getting a verification error either the list is out of date on that specific install, or there is something that prevents its usage in that enviroment. Commented Apr 12, 2016 at 5:37
  • I meant to type 'assuming latest'. I completely follow you about older versions. All my test installs are running 4.4.2 so I figured I'd be good there. Like you say, must be something in that specific environment. Either way, need to add something to cover all bases. Thanks again.
    – Mark
    Commented Apr 12, 2016 at 6:23
  • @Mark Yes, I assume wordpress core updates the list every release (at least hope it does ;) ) Commented Apr 12, 2016 at 6:25
  • @NathanPowell, the root certificates list found at wp-includes/certificates/ca-bundle.crt Commented Apr 12, 2016 at 6:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.