[wp-trac] [WordPress Trac] #34794: CURLOPT_SSL_VERIFYHOST should be set to 2 or not be set at all

[WordPress Trac]

#34794: CURLOPT_SSL_VERIFYHOST should be set to 2 or not be set at all
--------------------------+-----------------------------
 Reporter:  FriendlyGreg  |       Owner:  johnbillion
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  Future Release
Component:  HTTP API      |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+-----------------------------

Comment (by FriendlyGreg):

 @rmccue, the script you mentioned won't reveal the problem except in the
 case of connecting back locally to the same server, but in that specific
 case, yes, it replicates the issue exactly as described. Under both
 10.10.5 with Server 5.0.15 and 10.11.1 with Server 5.0.15 -- both plain
 vanilla, and running PHP 5.5.29 in both cases -- the behaviour is
 identical. Having already verified this with a plugin that makes test
 calls to {{{wp_remote_get()}}} and {{{wp_remote_post()}}} before
 submitting the report, I have now also verified the same using your script
 -- both dropped into a plugin to ensure the WP environment is up and
 running and simply calling the script directly. Again, the behaviour is as
 I have described, failing with {{{SSLRead() return error -9841}}}; comment
 out the {{{CURLOPT_SSL_VERIFYHOST}}}, and everything works as expected.

 As far as I can tell, here's the explanation for what's going on...

 Contrary to my suggestion earlier that {{{CURLOPT_SSL_VERIFYHOST}}} is not
 active unless set, you're exactly right that it is set by default. The
 reason that commenting out the {{{CURLOPT_SSL_VERIFYHOST}}} line makes the
 problem go away is ''not'' that it prevents {{{CURLOPT_SSL_VERIFYHOST}}}
 from being active; on the contrary, the reason it makes the problem go
 away is that it ''ensures'' {{{CURLOPT_SSL_VERIFYHOST}}} ''is'' active,
 with a value of 2. When I was testing on a live server using a trusted
 certificate, that is why everything went smoothly. It was only when I did
 a separate test with an untrusted certificate that the real problem was
 revealed (and the clue was your having looked up the specific meaning of
 the returned error code): on OS X, we receive that error message back, but
 apparently we don't receive back the rest of the results. Since the code
 appears to have been meant to be advisory rather than fatal, I'm not sure
 whether this is a PHP problem or an oversight in Darwin.

 So the bad news is that the original bug remains: if the user has shut off
 local verification in WordPress (e.g., because they're using a self-signed
 certificate) and the server has shut off RC4 support, then local
 connections will fail under Server 5 on either 10.10 or 10.11. (Whether
 it's ultimately 'blamed' on PHP or on Apple, from a WordPress user's
 perspective, it doesn't matter: the connection doesn't work.)

 The good news, however, is that restoring local verification will solve
 the problem. For those users like me who only shut it off in the first
 place because WordPress 4.3 introduced problems for Server 4 when it
 incorrectly set CAINFO, we can switch it back on when running Server 5,
 and bunnies are happy everywhere.

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