WP_HTTP_Fsockopen does not verify SSL certificates

[rmccue]

mdawaffe's talk at WCSF mentioned that fsockopen doesn't verify SSL certificates. The talk lead me to investigate ​Requests and see if I could fix that.

It turns out it is possible to do this with stream context options, but requires using ​stream_context_create rather than fsockopen. (We can also allow passing in a custom certificate file this way, which neither the cURL nor fsockopen transports allow at the moment.)

Example fix ​has been committed to Requests, I can port over if you'd like.

[rmccue]

Note: this most likely also requires including a root certificate bundle (such as ​the one built by cURL), as it appears fsockopen and cURL ​don't share certificate bundles.

[dd32]

WordPress has two transports - Streams and Fsockopen, where as Requests has cURL/Fsockopen (Well, now cURL/Streams) so it doesn't map 1:1.

#16606 covers SSL a few SSL issues, @rmccue perhaps you can take a look and see if this is a duplicate?

[rmccue]

Worth pointing out that using the HTTP stream is dangerous, since in some environments the broken cURL Streams will take over. Usually, we'd be able to use cURL in those places, but not always. IMO, it should be removed.

(Requests' transport is now closer to streams, but uses a TCP stream rather than a higher level HTTP stream, so it's safe from that.)

Also, I've been working on ​full common name validation, which will land in 1.6 pending review. This is an arguably more important feature than the above patch.

[rmccue]

(Also, duplicate of the signing issue in #16606, but that issue was originally about testing for support, hence the separate ticket.)

[rmccue]

I've been performing some PHP archeology with dd32 today to check on stream_context_create and stream_socket_client. Both of the functions have been part of ext/standard (read: not disableable via ./configure) since ​4.3 and ​5.0 respectively. I've also done a bug sweep of both on bugs.php.net and there's nothing major in 5.2+.

Long story short: anywhere we can use fsockopen, we can use stream_socket_client. I'd recommend switching the existing fsockopen transport to use streams, as it's a one-line change for that. We can then also pass in the context.

Note: We have to use the lower-level tcp:// or ssl:// rather than http:// to avoid cURL wrappers.

Note 2: These are still disableable via disable_functions, but I suspect systems that allow fsockopen will allow the stream_socket_* family.

[rmccue]

Also, after a check of disable_functions via a search over all files on GitHub, there seem to be many cases where fsockopen is disabled, but stream_socket_client is not, probably because of its relative obscurity. This is really a fringe case, but we may gain a little more compatibility with it.

(Conversely, hardly anyone blocks stream_socket_client.)

[dd32]

Attachment 25007.diff​ added

At this point, it looks like it's time to merge WP_HTTP_Fsockopen and WP_HTTP_Streams, at an internal PHP level they're both using streams, and based on rmccue's investigations above should always be available.

The attached patch was a first shot at bundling a root CA file for maximum support and fixing things such as comment:17:ticket:18577 and some of #16606

[rmccue]

Looks good but for two things:

1. cURL needs to be given the same cacert for consistency. There are systems on which cURL doesn't have this, and it makes sense to use the same certs for both.
2. The cacert path isn't changeable via the options passed into WP HTTP. For people using self-signed certificates or non-standard stacks (e.g. intranets), this should be possible.

The way I did it in Requests was to set the path in the higher level options, then each transport uses the same option. I'd recommend similar here.

[dd32]

cURL needs to be given the same cacert for consistency.

It does.

The cacert path isn't changeable via the options passed into WP HTTP. For people using self-signed certificates or non-standard stacks (e.g. intranets), this should be possible.

This did cross my mind as well, however, my primary motivation here was to get it in a state that we could verify SSL certs from Root CA's, not even taking into account non-root-signed certs, which we can look at once we have the core stack working 100%

[rmccue]

Replying to dd32:

cURL needs to be given the same cacert for consistency.

It does.

Whoops, missed that.

This did cross my mind as well, however, my primary motivation here was to get it in a state that we could verify SSL certs from Root CA's, not even taking into account non-root-signed certs, which we can look at once we have the core stack working 100%

It'll probably never quite get to 100% :)

[dd32]

Attachment attachment:25007.2.diff​​ added

Final run through:

• Switches from using fsockopen to stream_socket_client - Some hosts appear to block the latter function, however appear to block fsockopen too.
• Renames the Fsockopen class to WP_HTTP_Streams, and removes the old Streams class - Yes, this brings us down to TWO transports, cURL and Streams (For those keeping tabs at home, WP_HTTP originally started with FIVE, PHP HTTP Extension, cURL, PHP4 fopen(), PHP5 Streams, and fsockopen()).
• Bundles a root CA file with WordPress so that hosts without a valid SSL certificate bundle can make outgoing HTTPS requests (We'll need to keep this updated in the future, probably a grunt task to rebuild it)
• Enforces SSL certificate validation, self-signed certificates are a no-go unless the caller specifies that the certificate doesn't need verification
• Keeps a WP_HTTP_fsockopen class around as a compatibility layer, it simply extends the new Streams class, just for anyone who was using it directly (Plugins do things like this)
• When WP_DEBUG is enabled, the errors that stream_socket_client() make is a bit more verbose than the previous errors, this was because fsockopen() and fopen() were both disabling error reporting to a degree. No warnings visible when WP_DEBUG is disabled

This patch should also fix #16606, and, #13841

Needs testing, Passes all unit tests, works fine when the local SSL bundle is malformed or removed

[rmccue]

Note that the above patch does not do common name checking, so it's possible to use MITM attacks as long as you have a valid certificate for any domain. PHP's built-in checking for this is almost completely broken, which is why no one does it. ​Requests will have support soon, I just need to add some more tests to assure myself, but no other general HTTP library does this level of checking.

IMO, it's a bit too vulnerable without that to rely on.

[dd32]

Note that the above patch does not do common name checking

Well pointed out, Added in attachment:25007.3.diff​ through WP_HTTP_Streams::verify_ssl_certficate(). The more you take out of PHP's hands, the more you can rely upon it it seems.

It appears that that change means it now supports the same as Requests does. I've skipped IP support as I question if anyone else does that.. (plus it's a bit too low-level for a PHP library to handle)

[rmccue]

Replying to dd32:

Well pointed out, Added in attachment:25007.3.diff​ through WP_HTTP_Streams::verify_ssl_certficate(). The more you take out of PHP's hands, the more you can rely upon it it seems.

(For the record, although dd32 already knows:)

Looks good to me, except that it's not strict enough. If subjectAltName is set, it's authoritative to the exclusion of CN (and you're not allowed to use CN based on my reading of the spec).

It appears that that change means it now supports the same as Requests does.

I guess you'll just need to switch to Requests then ;)

[dd32]

more strict CN check - only check CN when subjectAltName doesn't contain a DNS entry

[rmccue]

Looks good to me with the stricter check.

[dd32]

re-enable curl which wasn't included in .4

[rmccue]

Misses IP addresses (which can only be specified in subjectAltName), so could be vulnerable with CN = google.com, subjectAltName = IP: 127.0.0.1.

[dd32]

Some Test domains with various certificates & SNI status are available on ​http://testssl.disig.sk/index.en.html

The script (from cURL) to create wp-includes/certificates/ca-bundle.crt is available in the cURL sources here: ​https://github.com/bagder/curl/blob/master/lib/mk-ca-bundle.pl?source=cc

This commit differs partially from previously uploaded patches, so please review.

[dd32]

In 25224:

WP_HTTP: Replacing the Fsockopen & Streams Transports with a new Streams transport which fully supports HTTPS communication.
This changeset also bundles ca-bundle.crt from the Mozilla project to allow for us to verify SSL certificates on hosts which have an incomplete, outdated, or invalid local SSL configuration.
Props rmccue for major assistance getting this this far. See #25007 for discussion, also Fixes #16606

[dd32]

In 25225:

WP_HTTP: Re-enable curl, it was accidentally left out of [25224]. See #25007 See #16606

[dd32]

I've also bumped the @since tags from 2.7.0 to 3.7.0 due to the significant alteration in functionality, despite same naming. I'm not sure if that's the proper thing to do or not.

[jamescollins]

​As per IRC, I'm wondering if we should add a new WP_Http_Fsockopen::request() function that calls _doing_it_wrong(), and then calls the parent WP_HTTP_Streams::request() method?

That way we are notifying/warning developers who are currently calling the deprecatedWP_Http_Fsockopen class directly.

[mdawaffe]

Replying to dd32:

This changeset also bundles ca-bundle.crt from the Mozilla project to allow for us to verify SSL certificates on hosts which have an incomplete, outdated, or invalid local SSL configuration.

Are we going to be able to update this quickly enough when it changes?

[dd32]

Are we going to be able to update this quickly enough when it changes?

Answer is potentially yes, no, maybe.
The certificate will only be able to be updated as fast as core updates, in the event that a CA included on the list is compromised, core would have to be updated to reflect that.

We'll have to ensure that the file is re-built for each release (or at least checked), and we may also want to consider allowing it to be updated in a faster manner than with the core build (say through Auto-Updates)

[dd32]

There are two alternate solutions I can think of instead of the action taken here

1. Only use our local CA bundle when the systems CA bundle has been proven not to work - ie. set a transient and disable system CA if ​https://api.wordpress.org/ failed to validate
2. Only ship the certificate chain needed for WordPress.org domains, and forcibly set the CA file to that when we're requesting one of our own URL's.

Some downsides exist though:

• If we ship the entire CA chain, but only use it when *.wordpress.org fails, other requests could pass, or fail, if the systems CA is out of date. (This could also mean that *.wordpress.org passes because the system still trusts a compromised CA)
• If we ship only a .org chain, it fixes issues for us mostly, but doesn't help plugins.

Personally I'm not against #2 above, but I don't really like fixing requests just for us when we could fix everything at once.

[mdawaffe]

Replying to dd32:

There are two alternate solutions I can think of instead of the action taken here

I don't know how or when Auto-Updates will work, but the another solution would be to include it in an auto-activated plugin (!) than can update independently.

[rmccue]

Replying to dd32:

1. Only use our local CA bundle when the systems CA bundle has been proven not to work - ie. set a transient and disable system CA if ​https://api.wordpress.org/ failed to validate

I don't like this at all, since it relies on a third party (which happens to be us anyway, but still) having valid certificates.

I'm definitely in favour of having this in a plugin. I think the solution here is:

1. Ensure trunk is kept up to date
2. Include the latest cacert with a plugin like Hotfix and use that as the default if installed.

I've split the certificate pinning issue (point 2 from above) into #25252.

[dd32]

Replying to mdawaffe:

I don't know how or when Auto-Updates will work, but the another solution would be to include it in an auto-activated plugin (!) than can update independently.

If we were to go the plugin route it'd most likely be an entirely optional installable plugin, not bundled with core at all.

Worth noting, that plugins are able to replace the bundle with their own certificate bundle with ease, for example, the HotFix plugin could roll out a update to use a newer certificate bundle.

[nacin]

Replying to dd32:

I've also bumped the @since tags from 2.7.0 to 3.7.0 due to the significant alteration in functionality, despite same naming. I'm not sure if that's the proper thing to do or not.

We can do this:

 * @since 2.7.0
 * @since 3.7.0 Combined with the fsockopen transport.

We don't do this anywhere else yet, but it is allowed, and is something we've been considering anyway as part of the 3.7 inline documentation efforts. It'd be used for documenting when new function parameters or arguments passed to filters were added, but this is also a pretty good case for it.

[dd32]

We can do this:

That sounds good to me, It certainly would make it a lot more clear as to the history of the functionality.

[dd32]

In 25309:

WP_HTTP: Correct the @since, and, @deprecated PHPDoc tags to reflect the class history. See #25007

[pavelevap]

I am not sure, if it is related, but after [25308] there are problems with localhost installation (xampp on Win). It is not possible to search and install themes and plugins.

Request:

object(WP_Error)#4234 (2) { ["errors"]=> array(1) { ["http_request_failed"]=> array(1) { [0]=> string(146) "SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed" } } ["error_data"]=> array(0) { } }

[dd32]

In 25426:

WP_HTTP: correct the SSL root certificates property, set svn:eol-style to native, and remove the svn:executable property. See #25007

[dd32]

SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Hm, svn up and see if you have the problem after [25426], completely guessing here as I don't have access to a windows install, but maybe, just maybe, the windows version didn't like the unix line endings of the certificate file (seems unlikely to me..)

[pavelevap]

Sorry, no change, same errror. Using Windows Vista, TortoiseSVN and xampp.

[kpdesign]

Replying to pavelevap:

Sorry, no change, same errror. Using Windows Vista, TortoiseSVN and xampp.

I just tested with r25343, Win7, TortoiseSVN, XAMPP, no plugins. Can search for, and install plugins just fine. @pavelevap, what plugins do you have installed/activated?

[dd32]

@pavelevap Can you do some debugging to try to narrow down the issue at all?

• Does the file exist in wp-includes?
• Are the permissions on the file open enough to allow the file to be read? (What does var_dump( is_readable( ABSPATH . WPINC . '/certificates/ca-bundle.crt' ) ); return?)
• Do you have any anti-virus running on that PC, is it locking the file?
• Are you using cURL or Streams for outgoing connections? (You can install my Core Control plugin and use it's 'HTTP Access' module to find out)

---

Separate from the above - What should we do when the sslcertificate passed in isn't readable?

• sslcertificate => false|null|true|anything not a file
• sslcertificate => file that's not readable

options:

1. if ( sslcertificate && ! is_readable( sslcertificate ) return new WP_ERROR( "Unreadable certificate" );
2. if ( ! sslcertificate || ! is_readable( sslcertificate ) ) sslcertificate = core certificate
3. if ( ! sslcertificate ) Do not specify CA path/file in Streams/cURL setup

#1 and #3 go together well, #2 seems like it'd be not-advised.

[dd32]

Another thing to test:

• Will this cause issues for users with self-signed certificates and loopback cron requests.

[pavelevap]

Debugging:

• No plugins active.
• File exists and is_readable (true).
• I am using Avast, but I tried to disable it and no change.
• Tested cURL and Streams, no change. I tried to disable some transports, but no change.

Install Plugins - Popular Tags - there is the same error on this page: 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 support forums.

All HTTP Related Constants are Undefined

Filter	Default Value	Current Value
http_request_timeout	5	5
http_request_redirection_count	5	5
http_request_version	'1.0'	'1.0'
http_headers_useragent	'WordPress/3.7-alpha-25343; http://localhost.cz/Wordpress'	'WordPress/3.7-alpha-25343; http://localhost.cz/Wordpress'
block_local_requests	false	false
use_fsockopen_transport	true	true
use_streams_transport	true	true
use_curl_transport	true	true
https_local_ssl_verify	true	true
https_ssl_verify	true	true

Strange, I am not sure where could be hidden problem. I did not have any problem with this install before...

[dd32]

pavelevap can you apply attachment:25007.lets-see-the-cert.diff​​ and let us know what the output is when you try one of those pages which make a HTTPS connection?

[pavelevap]

Sure, thank you!

array(12) { ["name"]=> string(65) "/O=*.wordpress.org/OU=Domain Control Validated/CN=*.wordpress.org" ["subject"]=> array(3) { ["O"]=> string(15) "*.wordpress.org" ["OU"]=> string(24) "Domain Control Validated" ["CN"]=> string(15) "*.wordpress.org" } ["hash"]=> string(8) "216a3758" ["issuer"]=> array(7) { ["C"]=> string(2) "US" ["ST"]=> string(7) "Arizona" ["L"]=> string(10) "Scottsdale" ["O"]=> string(17) "GoDaddy.com, Inc." ["OU"]=> string(42) "http://certificates.godaddy.com/repository" ["CN"]=> string(39) "Go Daddy Secure Certification Authority" ["serialNumber"]=> string(8) "07969287" } ["version"]=> int(2) ["serialNumber"]=> string(16) "1143028390712482" ["validFrom"]=> string(13) "111117211312Z" ["validTo"]=> string(13) "141215201121Z" ["validFrom_time_t"]=> int(1321560792) ["validTo_time_t"]=> int(1418670681) ["purposes"]=> array(8) { [1]=> array(3) { [0]=> bool(true) [1]=> bool(false) [2]=> string(9) "sslclient" } [2]=> array(3) { [0]=> bool(true) [1]=> bool(false) [2]=> string(9) "sslserver" } [3]=> array(3) { [0]=> bool(true) [1]=> bool(false) [2]=> string(11) "nssslserver" } [4]=> array(3) { [0]=> bool(false) [1]=> bool(false) [2]=> string(9) "smimesign" } [5]=> array(3) { [0]=> bool(false) [1]=> bool(false) [2]=> string(12) "smimeencrypt" } [6]=> array(3) { [0]=> bool(false) [1]=> bool(false) [2]=> string(7) "crlsign" } [7]=> array(3) { [0]=> bool(true) [1]=> bool(true) [2]=> string(3) "any" } [8]=> array(3) { [0]=> bool(true) [1]=> bool(false) [2]=> string(10) "ocsphelper" } } ["extensions"]=> array(9) { ["basicConstraints"]=> string(8) "CA:FALSE" ["extendedKeyUsage"]=> string(60) "TLS Web Server Authentication, TLS Web Client Authentication" ["keyUsage"]=> string(35) "Digital Signature, Key Encipherment" ["crlDistributionPoints"]=> string(39) "URI:http://crl.godaddy.com/gds1-60.crl " ["certificatePolicies"]=> string(86) "Policy: 2.16.840.1.114413.1.7.23.1 CPS: http://certificates.godaddy.com/repository/ " ["authorityInfoAccess"]=> string(116) "OCSP - URI:http://ocsp.godaddy.com/ CA Issuers - URI:http://certificates.godaddy.com/repository/gd_intermediate.crt " ["authorityKeyIdentifier"]=> string(66) "keyid:FD:AC:61:32:93:6C:45:D6:E2:EE:85:5F:9A:BA:E7:76:99:68:CC:E7 " ["subjectAltName"]=> string(38) "DNS:*.wordpress.org, DNS:wordpress.org" ["subjectKeyIdentifier"]=> string(59) "FB:C6:85:AC:23:97:89:7E:B6:30:34:23:93:BE:30:5E:68:4B:84:1A" } } bool(true)

Now it works well for me and I can install plugins...

[dd32]

pavelevap: That all looks correct.. Not sure what to think
What PHP/OpenSSL versions are you using? (You can get the OpenSSL version from phpinfo() )

Worksforme on
PHP 5.4.19/OpenSSL/0.9.8b
PHP 5.4.17/OpenSSL 1.0.0-fips 29 Mar 2010

[pavelevap]

Yeah, me too...

I have a little bit outdated PHP version 5.2.6 (for testing purposes). I will try another computer with newest version later today.

PHP Version 5.2.6
OpenSSL Version	OpenSSL 0.9.8g 19 Oct 2007
cURL Information libcurl/7.16.0 OpenSSL/0.9.8i zlib/1.2.3

[SergeyBiryukov]

[25224] had a typo in WP_Http_Streams::verify_ssl_certificate() name, 25007.typo-fix.diff​ fixes that.

[dd32]

• ~Requests to an IP address, but with a Host header, fail SSL verification since IP !== Certificate hostname.~ - Streams uses the Host Header, cURL doesn't.

[dd32]

In 25473:

WP_HTTP: Fix a typo in the naming of WP_HTTP_Streams::verify_ssl_certificate(). Props SergeyBiryukov See #25007

[dd32]

Replying to pavelevap:

SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

I have tracked down this issue by re-creating the environment. It seems that OpenSSL/0.9.8i (at least, I haven't tested other 0.9.8 builds yet) can't handle the 'EE Certification Centre Root CA' certificate (It's the last certificate in ca-bundle.crt, and the latest addition). It's not specific to the newly bundled file though, my testbed system also has that cert in the chain and it also fails with the system certs.

I'm not entirely sure what's causing the issue with that certificate, all I can say is if it's present, things break on PHP 5.2 (and some PHP 5.3's it looks like).

[dd32]

Replying to dd32:

Replying to pavelevap:

SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

I have tracked down this issue by re-creating the environment. It seems that OpenSSL/0.9.8i (at least, I haven't tested other 0.9.8 builds yet) can't handle the 'EE Certification Centre Root CA' certificate (It's the last certificate in ca-bundle.crt, and the latest addition). It's not specific to the newly bundled file though, my testbed system also has that cert in the chain and it also fails with the system certs.

I'm not entirely sure what's causing the issue with that certificate, all I can say is if it's present, things break on PHP 5.2 (and some PHP 5.3's it looks like).

The only options I can come up with here is to just remove the Certificate, which means we won't be able to make requests to any domains signed by that Authority, otherwise this breaks HTTPS requests for PHP 5.2.x users.

The alternative, is to set a transient, if a HTTPS request fails with the above error, we disable HTTPS support for a week, at least that way the user can still access Manual updates and theme/plugin installations.

[godhulii_1985]

Hi,
I am a plugin author (automatic login to wp site via google oauth) and I am facing some error. After reading the discussion of this trac, I think my problem is related to this.

I cannot fetch data from google unless I provide .pem file. I downloaded the standard .pem file from haxx.se and used. I noticed that facebook also provide this file in their sdk.

//$go... = Person's google+ id from https://plus.google.com/NNN url where NNN = id
$apiurl = "https://www.googleapis.com/plus/v1/people/$googlePersonID?alt=json&access_token=" . $token;

Using verify ssl / this code fragment doesn't work:

curl_setopt($tuCurl, CURLOPT_SSLVERSION, 3);
curl_setopt($tuCurl, CURLOPT_SSL_VERIFYHOST, 2);

This works:

curl_setopt($tuCurl, CURLOPT_SSLVERSION, 3);
curl_setopt($tuCurl, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($tuCurl, CURLOPT_CAINFO, plugin_dir_path( __FILE__ ).'cacert.pem');

So, it will be really nice if we are given an additional filter to include .pem file :-)

[dd32]

I downloaded the standard .pem file from haxx.se and used.

That's exactly what core is doing, so as long as you use WP_HTTP instead of cURL directly as you currently are, in 3.7+ it should just work on hosts that support HTTPS connections.

If you have to specify a custom certificate file (ie. one which contains a specific hosts certificate, not the one from curl/haxx.se) then there's a parameter you can pass to WP_HTTP to specify an alternative certificate file.

[rmccue]

Replying to dd32:

If you have to specify a custom certificate file (ie. one which contains a specific hosts certificate, not the one from curl/haxx.se) then there's a parameter you can pass to WP_HTTP to specify an alternative certificate file.

Additionally, if you have to use cURL manually (please, please don't), then the included certificate file should be available at ABSPATH . WPINC . '/certificates/ca-bundle.crt'

But again, please *please* don't do that, and use the WP HTTP API instead.

[godhulii_1985]

I tried with wp_remote_get() but cannot make it work. My code fragment was:

$response1 = wp_remote_get( $apiurl, array('sslverify' => true));
if( is_wp_error($response1) )
	throw new Exception($response1->get_error_message());
echo '<pre>';
print_r( $response1);
echo '</pre>';

===Result===
Caught exception: SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 

From dashboard: You are using WordPress 3.6.1.

[rmccue]

Replying to godhulii_1985:

I tried with wp_remote_get() but cannot make it work. My code fragment was:

What's the value of OPENSSL_VERSION_NUMBER on your system?

[godhulii_1985]

I found this line with phpinfo() function call: SSL Version OpenSSL/0.9.8k

[godhulii_1985]

Replying to godhulii_1985:

I found this line with phpinfo() function call: SSL Version OpenSSL/0.9.8k

Not sure relevant or not but this code works:

$data = json_decode(@file_get_contents($apiurl));
print_r($data);die;

[dd32]

In 25569:

Move a certificate higher in the file (end to start) so that PHP 5.2.x (OpenSSL 0.9.8j and earlier) can parse the file correctly. See #25007

[dd32]

[25569]: Move a certificate higher in the file (end to start) so that PHP 5.2.x (OpenSSL 0.9.8j and earlier) can parse the file correctly. See #25007

So that fixes the following error under PHP 5.2.x + OpenSSL 0.9.8

SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

pavelevap: Any chance you can confirm this commit fixes it for you?

I'm not entirely sure why it fixes it, but it's related to the ordering of the certificates.
Hopefully that should now mean this ticket is good to go.

[godhulii_1985]

Hi dd32 and rmccue,

There is no certificates folder in wordpress/wp-includes/. I checked into my installed files and redownloaded wordpress just to confirm. Have a look into the screenshot below of 3.6.1:

[rmccue]

Replying to godhulii_1985:

There is no certificates folder in wordpress/wp-includes/. I checked into my installed files and redownloaded wordpress just to confirm. Have a look into the screenshot below of 3.6.1:

To clarify: this is *not* in 3.6.1, you need to be using a nightly version. Try the ​WordPress Beta Tester plugin to upgrade.

[pavelevap]

pavelevap: Any chance you can confirm this commit fixes it for you?

Sure, I was on vacation :-) It works without problems now, good job! Thank you!

[nacin]

This appears to be done, with the only remaining issue being #25252. Closing as fixed! New tickets for further issues, please.

[dd32]

In 36570:

HTTP API: Certificate bundle: Attempt to move a certificate lower in the file to allow older OpenSSL versions to parse it & communicate with WordPress.org securely again.
The OpenSSL version which was failing in this case was OpenSSL 0.9.8e 23 Feb 2007.

See #35637 #30434 #25007