[wp-trac] [WordPress Trac] #35637: SSL Certificate Problems not fixed with 4.4.1

WordPress Trac noreply at wordpress.org
Thu Feb 18 08:17:18 UTC 2016


#35637: SSL Certificate Problems not fixed with 4.4.1
--------------------------+--------------------
 Reporter:  jaroat        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  4.5
Component:  HTTP API      |     Version:  4.4.1
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+--------------------
Changes (by dd32):

 * keywords:  reporter-feedback =>
 * milestone:  Awaiting Review => 4.5


Comment:

 @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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/35637#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list