Why We Need Curlopt_Ssl_Verifypeer in Windows

Why we need CURLOPT_SSL_VERIFYPEER in windows

This cURL man page on SSL Certificates describes the process for Certificate Verification when connecting to SSL/TLS secured hosts.

The reason you are needing to set CURLOPT_SSL_VERIFYPEER to false on Windows is because the CA bundle it uses to verify the certificates is missing (or there is no default path compiled into cURL so you need to explicitly define it).

You can configure it in php.ini using the curl.cainfo directive, or specify it at runtime using:

curl_setopt($curl, CURLOPT_CAFILE, 'C:/path/to/ca-bundle.crt');

If you don't have a copy, grab a recent one here.

While disabling peer verification is a workaround, this can be unsafe because you're disabling the very check that ensures you are securely communicating with the site you think you are.

Anyone can generate a self signed certificate to impersonate a domain, but browsers or clients (like cURL) will fail if the certificate can't be verified unless you ignore or bypass this check (i.e. CURLOPT_SSL_VERIFYPEER = false).

Does turning off CURLOPT_SSL_VERIFYPEER in cURL make transmission insecure?

Yes it is insecure. If you don't check the certificate you can't be sure that the sender is truly the server you think you're talking to and it may be an impostor. A man in the middle.

Even impostors can run SSL and negotiate an encrypted connections with you. But they can (supposedly) not purchase a certificate for the forged site using the legitimate cert name.

If CURLOPT_SSL_VERIFYPEER is false, is the data transfer no longer secure?

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.

Security consequences of disabling CURLOPT_SSL_VERIFYPEER (libcurl/openssl)

If you disable CURLOPT_SSL_VERIFYPEER, curl will not check that the certificate is actually signed by a trusted authority. This is very dangerous! In a MITM situation, without VERIFYPEER, the attacker can simply substitute his own "self-signed" certificate for the real certificate, and as long as the host name matches (which he can always do, since he's making the certificate), your app will accept it.

Your code is likely failing because you don't have the CA certificate store set up, and the server you are talking to is signed by a CA not in curl's default repository. Consider using CURLOPT_CAINFO or CURLOPT_CAPATH to specify the certificates to verify against, and ensure that the certificates you are using for verification are accessible and match the target server's certificates.

Is it ever safe to set CURLOPT_SSL_VERIFYPEER to FALSE? Even if you control both servers?

Is it safe to leave this set to false, because I control the traffic on both ends? In fact, do I even need an SSL cert? As long as it goes over HTTPS it's secure, right?

No. You are only safe if you not only control both ends but also everything in between. If you have a single cable between two computers and control both computers than you are probably safe. If there is any cabling, router etc which might be accessed by somebody else you are not safe anymore.

Am I in danger of a man-in-the-middle attack?

Yes, unless you can control everything in between you cannot prevent a man in the middle. And unless you validate the certificates you can neither detect nor prevent the attack.

Why does cUrl fail to download via HTTPS unless CURLOPT_SSL_VERIFYPEER is set to false?

This happens because you have not configured curl with CA certificates that are considered trustworthy, so it has no way of verifying the signature on the remote server's certificate (although in all likelihood the signature is valid).

To verify the signature you should set either CURLOPT_CAINFO or CURLOPT_CAPATH appropriately.

PayPal cURL options (CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST) issue

Yes, it would be much safer to make sure clients use an updated CA cert bundle. (Which this question is about, they already have a certificate.)

Can't Get PHP cURL SSL To Work

The answer to this problem is that the root certificate displayed for https://www.google.com in IE11, "GeoTrust Global CA," is cross-rooted to an older GeoTrust root certificate named "Equifax Secure Certificate Authority." When the "GeoTrust Global CA" certificate that displays as the root in the 3-certificate chain showing in my IE11 is used by my PHP script as the root certificate for https://www.google.com my PHP script can't authenticate https://www.google.com's certificate BECAUSETHE REAL ROOT CERTIFICATE FOR https://www.google.com ISN'T THE "GeoTrust Global CA" CERTIFICATE BUT THE GeoTrust "Equifax Secure Certificate Authority" certificate. Once I figured this out, I used the "Equifax Secure Certificate Authority" in my PHP .PEM file and I successfully validated the https://www.google.com certificate.

You can see how the cross-rooting takes place by doing the following (I used IE11 for this):

1. Open a BLANK https://www.google.com Web page
2. Click the padlock icon in the URL window, then click "View certificates."
3. The Certificates window for https://www.google.com appears. Click the Certification Path tab. The certificate chain of three certificates will be displayed. The "GeoTrust Global CA" certificate shows as the root certificate - BUT THAT'S NOT TRUE.
4. Close the Certificate window. In the "Run" box in the Start Menu (I'm using Windows 7) type "certmgr.msc" and click the "OK" button. This will launch Windows' Certificate Manager.
5. Click the "Trusted Root Certification Authorities" entry in the left pane, then click "Certificates."
6. In the right pane, locate the "GeoTrust Global CA" certiticate. Double-click this entry to open it's certificate window.
7. Click the "Details" tab, then click the "Edit properties" button. NOTE THAT "Server Authentication," "Client Authentication," "Code Signing," "Secure Email," and "Time Stamping" are selected.
8. Click the "Disable all purposes for this certificate" button. THIS WILL DISABLE THIS CERTIFICATE FROM USE. NOTE ON THE "General" TAB THAT THE EXPIRATION DATE FOR THIS CERTIFICATE IS 5/20/2022 AND THE "Issued to:" and "Issued by:" ITEMS ARE BOTH SIGNED "GeoTrust Global CA," INDICATING THAT THIS IS A ROOT CERTIFICATE. Click the "OK" button to return to the Windows Certificate Manager. Minimize the Certificate Manager.
9. Move to your blank https://www.google.com Web page. Refresh the page, then view the certificates. NOW YOU WILL SEE FOUR CERTIFICATES, INSTEAD OF THE THREE THAT WERE DISPLAYED IN SETP #3!!
10. WHAT HAPPENED? Double-click the "GeoTrust Global CA" certificate. Look at the expiration date on the "General" tab. It's 8/20/2018, NOT THE 5/20/2022 displayed for the "GeoTrust Global CA" certificate in Step #3. Also look at the "Issued to:" and "Issued by:" items - THEY ARE DIFFERENT. The "Issued to:" is "GeoTrust Global CA" and the "Issued by" is "Equifax Secure Certificate Authority." THIS IS A DIFFERENT "GeoTrust Global CA" CERTIFICATE THAT THE ONE DISPLAYED IN STEP #3!! This version of the "GeoTrust Global CA" certificate is cross-rooted to "Equifax Security Certificate Authority" as evidenced in the "Issued by:" item!!
11. Double click the "GeoTrust" root certificate. Notice that this is a self-signed root certificate issued by "Equifax Secure Certificate Authority." THIS IS THE REAL ROOT CERTIFICATE USED BY https://www.google.com!! When I copied this certificate into my PHP .PEM file and used it to validate https://www.google.com's certificate everything work perfectly!!
12. Go back to the Windows Certificate Manager and reverse the disablement you performed in Steps 5 - 8. Click the "Enable only the following purposes" button and re-check the purposes listed in Step #7. This will restore your "GeoTrust Global CA" certificate dated 5/20/2022 to functioning status.

There's a link on the GeoTrust Website that describes the "GeoTrust Global CA" cross-root certificate that appeared in Step #9. You can download it as well. However, for my application the cross-root certificate didn't validate https://www.google.com's certificate - I NEEDED TO USE THE "GeoTrust" ROOT CERTIFICATE BECAUSE IT IS THE ONLY ONE THAT WORKS TO VALIDATE https://www.google.com. Here's the link:

https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=AR1426

You can also download the equivalent of the "GeoTrust" certificate from the GeoTrust Website. It's listed as the "Equifax Secure Certificate Authority" in the Resources > Root Certificates section of the Website. Here's the link:

https://www.geotrust.com/resources/root-certificates/

You can also find more details about the certificate chain for any Web page by visiting the following Symantec Web page:

https://cryptoreport.websecurity.symantec.com

I hope this helps you PHP developers who need to validate an HTTPS connection with Google.com. DREW010 - Thanks for hanging with me through this! I appreciate your help.

---

Related Topics