Is the API currently down?


Hi there.

My players are complaining the log-in system has suddenly stopped working.

This is my game’s link:

In the log-in page, there’s a visible error message:
stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed stream_socket_client(): Failed to enable crypto stream_socket_client(): unable to connect to ssl:// (Unknown error)

If I try to log-in anyway, after the “ALLOW” button, I get this error:
Fatal error: Cannot use object of type WP_Error as array in /var/www/html/play/wp-content/plugins/patreon-wordpress/classes/patreon_oauth.php on line 46

There is something I need to do on my end to fix this, or is that the API offline?


You can run a test against a service using SSL Labs to help identify issues, running a test appears to show no issues with the Patreon SSL configuration:

The error message you’re receiving is most likely due to bad certificates on your machine. Although not related to Patreon, check out this error documentation from PHP mailer that covers the same error and some fixes that may be worth trying:

Have you upgraded the PHP version on your server recently, or maybe any changes elsewhere on the machine that involve certificates?


PHP version was probably updated some days ago (ubuntu 14), but nothing that I manually did, just the default security updates.

Running a SSL test on the server show no issues:

Any idea of how could I check the certificates of the server to see if everything is fine?


I solved it.

sudo apt-get install php5-curl
sudo service apache2 reload
sudo ntpdate -u

I have absolute NO idea why it was working and suddenly stopped. Maybe a recent security updated messed up with the server config…


That’s good news! For future reference, the issue you were experiencing wouldn’t have been identified by SSL Labs. SSL Labs is a good way to inspect the external SSL configuration of a service (i.e: you’re a consumer, you want to know if is configured properly for you to communicate with it) however it’s not a good way to identify if there are internal issues on a system (i.e: you’re a developer, you want to know if your machine has issues validating third party certificates).

Regarding your issue: certificates have a fixed period of validity (i.e: January 1st 2018 to January 1st 2019), when your local machine receives the certificate it determines if the current time is within that period of validity. For whatever reason it seems like your server’s time was not synchronised correctly, so when it received the certificate it determined that it was not valid and the error was thrown, which is why the issue was resolved by running ntpdate -u as that synchronised your servers time.

^ Just in case anybody else has the same issue and finds this thread in their search for the fix.