Make WordPress Core

Opened 9 years ago

Closed 9 years ago

#35637 closed defect (bug) (fixed)

SSL Certificate Problems not fixed with 4.4.1

Reported by: jaroat's profile jaroat Owned by: dd32's profile dd32
Milestone: 4.5 Priority: normal
Severity: normal Version: 4.4.1
Component: HTTP API Keywords:
Focuses: Cc:

Description

This is a follow-up to #30434.

Bug #30434 doesn't seem to be fixed with WP 4.4.1.

I do have multiple 4.4.1 installations having the exact same behavior when trying to do an update:

Runterladen der Aktualisierung von https://downloads.wordpress.org/plugin/woocommerce.2.5.1.zip

Beim Aktualisieren von WooCommerce ist ein Fehler aufgetreten: Download fehlgeschlagen. SSL certificate problem: unable to get local issuer certificate

Abschalten des Wartungsmodus…

Change History (14)

#1 @dd32
9 years ago

Hi @jaroat

Can you please let us know details about your environment which might point to a culprit?
Ideally, we'd need to know your cURL version, cURL SSL version (&provider), OpenSSL extension version, and PHP version.

Did the issue start with the 4.4 update? What version were you previously running that was fine?

#2 @jaroat
9 years ago

  • Keywords reporter-feedback added

Hi @dd32,

Those are the versions i could discover over bash:

# curl -V
curl 7.16.1 (i686-pc-linux-gnu) libcurl/7.35.0 OpenSSL/0.9.8e zlib/1.2.8 libidn/1.27

# openssl version
OpenSSL 0.9.8e 23 Feb 2007

# php -version
PHP 5.3.9 (cli) (built: Jan 17 2012 13:44:16)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with eAccelerator v0.9.6.1, Copyright (c) 2004-2010 eAccelerator, by eAccelerator
with the ionCube PHP Loader v4.0.12, Copyright (c) 2002-2011, by ionCube Ltd.

I contacted the hoster and he claims that openssl was installed in version "1.0.1e-2+deb7u17" and that he updated to "1.0.1e-2+deb7u19" yesterday. But i can't verify that via a bash call to "openssl version". Additionally, curl reports to be compiled with the same old 0.9.8e version.

Please don't hesitate to ask for more information if needed.

br from Salzburg, Austria!

#3 @dd32
9 years ago

@jaroat Would it be possible for you to provide those versions from the output of <?php phpinfo(); ?> instead?

Occasionally the versions which PHP is using is different to the CLI php and CLI tools installed.

#4 @jaroat
9 years ago

@dd32 -

Sure, no problem!

You'll find the info here:
https://jarolim.com/external/wordpress-trac/phpinfo.png

Can't see no openssl > 0.9.8e there ... Maybe PHP and curl need to be recompiled too? Unfortunately, i'm coming from the windows-side and don't have administrator-depth *nix know-how.

#5 @dd32
9 years ago

@jaroat Thanks!

For the record, the versions from the phpinfo show the same as the CLI (you can remove the image if you'd prefer)

  • PHP 5.3.9 w/ OpenSSL/0.9.8e
  • cURL 7.35.0 w/ OpenSSL/0.9.8e

#6 @ctalkington
9 years ago

@dd32 some additional info for you.

Debian 8.3

PHP 5.6.17-0+deb8u1 (cli) (built: Jan 13 2016 09:10:12) 

curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1k zlib/1.2.8 libidn/1.29 libssh2/1.4.3 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL libz TLS-SRP

I'm seeing SSL issues (mainly mailchimp api) after the latest batch of curl and openssl patches released through debian-security. Debian 7.9 fully patched works fine.

curl 7.26.0 (i486-pc-linux-gnu) libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp 
Features: Debug GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP


WP version doesn't appear to impact it.

cert seems fine from a glance but I'm guessing some security fix is causing this as I get the same error via CLI.
https://us1.api.mailchimp.com/3.0/?apikey=test

I don't think WP will be able to fix this particular issue but you might see additional reports as servers are patched.

#7 @ctalkington
9 years ago

This appears related to CyberTrust having a 1024 bit and the push to remove these from the trusted cacerts.

After some testing, it became clear that the issue I was experiencing was related to system cacerts and a plugin that didn't use WP's local cabundle therefore what appeared to be a WP issue based on client reports was really a PHP and system cacerts issue that was easily resolved by forcing PHP to use the WP's cabundle globally.

#8 @dd32
9 years ago

For the record, I tried a stock-standard Centos 5.11 install and didn't encounter any issues, using either the cURL or fsockopen handlers.

Centos 5.11 comes with PHP 5.3.3 (cURL 7.15.5 compiled with OpenSSL/0.9.8b) & OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008, no updates are available in the official repo's for it.

(Please note, I'm simply recording a failure to reproduce with that configuration, not that it's not a legitimate issue).

#9 @dd32
9 years ago

  • Keywords reporter-feedback removed
  • Milestone changed from Awaiting Review to 4.5

@jaroat has allowed me access to a server which is experiencing the problem.

It looks like the fix we used for this last time needs to be reverted/changed [25569] - The behaviour of these certain old OpenSSL versions changed again when we updated the certificate file.

  • If the EE Certification Centre Root CA certificate is moved to the bottom of the file, then HTTPS communications work again.
  • Alternatively if the TDC Internet Root CA certificate is added back in, then it works again without the EE Certification Centre Root CA cert being moved. I can see no link between those certificates so have no idea why that fixes it.
  • The EE Certification Centre Root CA certificate must be added after the TeliaSonera Root CA v1 (The fact it exists before that certificate is what causes the GoDaddy certs to fail to be parsed currently), once again, I can see no link between those two certificates.

This appears to mostly affect HTTPS communication with WordPress.org, accessing non-WordPress.org domains signed with Verisign and Lets Encrypt succeed, just GoDaddy signed domains fail (A bunch of others will fail too obviously).

I've verified that this server was also affected by #comment:46:ticket:25007 which [25569] fixed.

The main problem here I have is that I have no way to verify that this won't break HTTPS communication for other OpenSSL client versions, which is a possible outcome, but given nothing broke last time.. I don't think will happen this time.

I expect that this breakage is something we're going to experience every single time we update the SSL certificate bundles. I don't have the ability to keep multiple test OpenSSL's around personally (and even then, I can't duplicate this problem with a local VM and the exact OpenSSL version on the affected server). It's probably possible to setup a few hundred different variants to be tested via Travis somehow, I don't really know how to achieve that though, nor what variants are needed to be tested to trigger these failures. Some kind of fuzzy testing would probably achieve it.

Marking for 4.5 inclusion, this can be backported into a 4.4.3 release if tested enough.

#10 @dd32
9 years ago

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

#11 @jorbin
9 years ago

  • Owner set to dd32
  • Status changed from new to assigned

This ticket was mentioned in Slack in #core by chriscct7. View the logs.


9 years ago

This ticket was mentioned in Slack in #core by chriscct7. View the logs.


9 years ago

#14 @dd32
9 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

Marking as fixed for 4.5, reports have suggested that this fix fixed the issues for 4.4.x, so should be all good..

Note: See TracTickets for help on using tickets.