[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