I\'ve recently run into a problem posting data to a server whose SSL certificate was updated. I did some research and I found that when CURLOPT_SSL_VERIFYPEER is set to fals
I would like to clearify about relation between _VERIFYHOST and _VERIFYPEER from my testing.
_VERIFYHOST check common name(CN) as manual said that depend on option 1 or 2. This verification only checks and generates error message case failed. The verification itself has no effect on connection at all, even verification error occurs. It's result used by _VERIFYPEER to cut down or continue connection.
_VERIFYPEER (1) check 2 things. First, it checks certificate with CAINFO. if CAINFO specify in curl option then it check with that value, otherwise it check with value specify in php.ini. Second, it check result from _VERIFYHOST (case set _VERIFYHOST to 1 or 2). If verification pass both condition, the connection will be continued. Otherwise the connection will be cut down.
The connection will still be SSL encrypted. You just won't be doing it on a link that uses validated-as-correct certificates. Anyone can create themselves an SSL certificate which will do perfectly acceptable encryption at whatever level your browser and the webserver support.
However, what you will get is many complaints about not being able to verify the certificate's authenticity. This is to prevent Joe M. Alicious from creating themselves a certificate claiming to be "microsoft.com" and setting up their own Windows Update host. The cert will say it's microsoft.com, but it cannot be authenticated as actually being microsoft.com, as Verisign (or whoever) did not actually issue that cert and put their own stamp of authenticity (signing the cert) on it.
_VERIFYHOST is there to check that the hostname of the URL you're connecting to (e.g. "microsoft.com") is listed within the SSL cert. With this option set to false, url/cert hostname mismatches will be ignored (say, you've got a development box at testbox.develhost.com, but are using your client's real valid 'example.com' cert).
_VERIFYPEER disables validating the entire certificate. This allows self-signed certs to work. Otherwise the SSL library will barf saying that the cert's issuer isn't valid.
But regardless of either setting, if you force through a connection, it WILL be ssl encrypted.
If you disable CURLOPT_SSL_VERIFYPEER, no verification of the certificate is done (and the value of CURLOPT_SSL_VERIFYHOST is ignored). As a result, this leaves you insecure against man-in-the-middle attacks. This means you are no longer transmitting the data over a secure connection.
Yes, the data is encrypted, but it's still not secure. You know you are sending to someone, but you have no idea who; you might be sending it to the user's arch enemy (carefully encrypting it so no one other than the attacker can read the data). This is bad. All the encryption in the world isn't much good if you're encrypting it using the attacker's public key.
Bottom line: Don't disable CURLOPT_SSL_VERIFYPEER. It leaves you insecure.
See Security consequences of disabling CURLOPT_SSL_VERIFYHOST (libcurl/openssl) for more on what you need to do to use cURL's SSL support securely.