Opened 10 years ago
Closed 9 years ago
#591 closed defect (bug) (invalid)
Get Warning Notices in WordPress 4.0-RC1, because the Cert is invalid for 66.155.40.203
Reported by: | developwithconviction | Owned by: | |
---|---|---|---|
Milestone: | Priority: | high | |
Component: | SSL | Keywords: | |
Cc: |
Description (last modified by )
URL:
http://wp.dev/wp-admin/update-core.php
Message:
Warning: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the <a href="https://wordpress.org/support/">support forums</a>. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in /Library/WebServer/Documents/work/wp.dev/wp-admin/includes/plugin-install.php on line 77
Call Stack
# Time Memory Function Location 1 0.0015 427664 {main}( ) ../update-core.php:0 2 3.8270 21107312 list_plugin_updates( ) ../update-core.php:521 3 3.8331 21275712 plugins_api( ) ../update-core.php:243 4 4.2963 21284656 trigger_error ( ) ../plugin-install.php:77
Problem:
Certificate Common Name (CN) and Hostname does not match? The hostname (66.155.40.203) does NOT match the Common Name in the certificate (*.wordpress.org). This certificate is currently invalid for this host.
You can check it externally as well, see:
https://www.geocerts.com/ssl_checker
Type in: 66.155.40.203 :443
Solution:
Use correct SSL Cert for 66.155.40.203 (WordPress API Server)
Even if I accept the Cart manually in Keychain on Mac or via Safari 'always trust', it does not work. Curl doesn't accept it. Curl Version: 7.37.1
Check via Terminal, same result:
Usernames-MacBook-Air:apache2 username$ curl --cacert /Users/username/Desktop/\*.wordpress.org.cer https://66.155.40.203 curl: (51) SSL: certificate verification failed (result: 5)
Change History (7)
#1
@
10 years ago
- Description modified (diff)
- Summary changed from Get Warning Notices in Wordpress 4.0-RC1, because the Cert is invalid for 66.155.40.203 to Get Warning Notices in WordPress 4.0-RC1, because the Cert is invalid for 66.155.40.203
#3
@
10 years ago
Temporary fix seems to be:
wp-config.php
add_filter( 'http_api_transports', function() { return array( 'streams' ); });
As stated on another site:
This is a problem with changes in WordPress’ HTTP API. It isn’t fully compatible with cURL anymore. I am not sure, why exactly it happens (there is no context information given, when this error occurs), but you can add a temporary fix.
Source: http://wordpress.stackexchange.com/questions/121334/unexpected-error-on-update-requests
I can fully confirm this statement. It seems to be that Wordpress isn't fully compatible with cURL anymore. (Reasons take a look at the above two posts from me)
This is only a temporary fix for people coming from sites like Google.com searching for a solution here, until we get a real/official solution.
#4
@
10 years ago
At no point during WordPress should the IP address be used directly, and as such, the SSL certs do not list the IP address, you'll find this is insanely common amongst almost every SSL host as IP addresses change, and hosts have multiple SSL websites served from IP address, so you should instead always test with the full hostname, api.wordpress.org.
Back to the error at hand though, it sounds like either something in the cURL version you have installed isn't compatible with SSL connections, or, something else in PHP is preventing the SSL from working. The version of cURL installed in PHP will almost always be 100% different from the command line curl installed on the server.
Could you supply the exact message that WordPress is hitting?
This should return a WP_Error object with the error: (Note: You'll have to remove your streams-only filter first of course)
var_dump( wp_remote_get( 'https://api.wordpress.org/') );
Can you also post the output of:
var_dump( curl_version() );
#5
@
10 years ago
Ah, I missed that the raw error was present in comment:2
It looks like this is a cURL + DarwinSSL + wildcard subdomain issue in cURL 7.37.1, potentially related to OSX Yosemite.
It could also be being triggered by the format of our cacert.crt file, there might be a SSL cert in there that DarwinSSL doesn't like.
Upstream ref: http://curl.haxx.se/mail/tracker-2014-08/0007.html
Maybe helpful for further investigation, a log from the Core Tester Wordpress Plugin.
As you can see, its the SSL Cert that cause the failure, which curl doesn't accept.
Even if it gets the Cert manually or via 'curl.cainfo =' in php.ini (see Terminal result from the main post above)