cURL update

[kwdamp]

Is there an easy way to update cURL to the latest version if we're using easyApache 4?

Problem I'm trying to solve: I'm running into an intermittent error trying to use cURL to connect to a website that uses cloudflare.
"SSL: no alternative certificate subject name matches target host name (redacted for privacy)"

Seems like the version of cURL on the server is 7.29 and the latest version is 7.77. Thought updating would be a logical first step to troubleshoot this as I know they have addressed a lot of SSL/TSL changes throughout version 7.

Other suggestions for solving the problem would also be appreciated. But I've played around a lot with the basic curl_setopt's and things like not verifying the peer/host don't fix the problem (one has no effect, the other results in a 404 file not found error). Restarting the server usually fixes the problem. So that makes me think it might be a caching / dns / cert.pem issue.

 

[cPRex]

Hey there! cPanel itself doesn't handle curl, as the version number you reference, 7.29, is from CentOS 7 directly:

]# rpm -qa | grep curl
curl-7.29.0-59.el7_9.1.x86_64

It's not recommended to try and update curl outside of what the operating system supports as you can run into odd dependency problems and unsupported behavior from other applications.

There are newer versions of curl with each PHP version. For example, here is the list of PHP curl versions I have installed on my personal machine:

ea-php56-php-curl-5.6.40-18.20.1.cpanel.x86_64
ea-php70-php-curl-7.0.33-20.22.1.cpanel.x86_64
ea-php71-php-curl-7.1.33-11.13.1.cpanel.x86_64
ea-php72-php-curl-7.2.34-5.7.1.cpanel.x86_64
ea-php73-php-curl-7.3.28-1.6.1.cpanel.x86_64
ea-php74-php-curl-7.4.20-1.3.1.cpanel.x86_64
ea-php80-php-curl-8.0.7-1.1.2.cpanel.x86_64

so I'm wondering if trying a newer version of PHP on that particular domain would provide better results.

 

[kwdamp]

Hey there! cPanel itself doesn't handle curl, as the version number you reference, 7.29, is from CentOS 7 directly:

]# rpm -qa | grep curl
curl-7.29.0-59.el7_9.1.x86_64

It's not recommended to try and update curl outside of what the operating system supports as you can run into odd dependency problems and unsupported behavior from other applications.

There are newer versions of curl with each PHP version. For example, here is the list of PHP curl versions I have installed on my personal machine:

ea-php56-php-curl-5.6.40-18.20.1.cpanel.x86_64
ea-php70-php-curl-7.0.33-20.22.1.cpanel.x86_64
ea-php71-php-curl-7.1.33-11.13.1.cpanel.x86_64
ea-php72-php-curl-7.2.34-5.7.1.cpanel.x86_64
ea-php73-php-curl-7.3.28-1.6.1.cpanel.x86_64
ea-php74-php-curl-7.4.20-1.3.1.cpanel.x86_64
ea-php80-php-curl-8.0.7-1.1.2.cpanel.x86_64

so I'm wondering if trying a newer version of PHP on that particular domain would provide better results.

Thanks for the response! I am running php 8.0 on that account. So I may need to attack this from a different direction.

Do you have any idea what would be "refreshing" with a server reboot that would be remedying the problem?

I'm wondering if there is a command I could use to refresh the dns / cache / or cert files.

 

[cPRex]

If it's an intermittent issue, it could be that the reboot isn't actually related to the problem at all - I wouldn't expect a reboot to change how a curl connection is handled.

Do you have a way to contact the system you are connecting to so they could check for errors on their end?

 

[kwdamp]

If it's an intermittent issue, it could be that the reboot isn't actually related to the problem at all - I wouldn't expect a reboot to change how a curl connection is handled.

Do you have a way to contact the system you are connecting to so they could check for errors on their end?

No, I don't.

I do know they use cloudflare though. And my best guess is some responses are cached and some aren't. The SSL cert also lists both the domain holder and cloudflare. So I don't know if curl honors responses from both domains or just one of them.

It's very strange and I've been trouble shooting it for dang near a month now.

 

[cPRex]

Here is perhaps a better test that would help isolate the issue. During the times when you get the SSL error, are you able to curl another https site? For example, just running this would let you connect to Google:

curl -v https://google.com

If that works at the same time the other site fails, you can be confident it's an issue with the remote system and not a problem with your server.

 

[rscalover]

Hello,

I had a similar issue in the past with cURL i fixed that by setting curl.cainfo in php.ini to= "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem" <<-- check if this actually exists on your server after that systemctl restart httpd.service.

 

[kwdamp]

Here is perhaps a better test that would help isolate the issue. During the times when you get the SSL error, are you able to curl another https site? For example, just running this would let you connect to Google:

curl -v https://google.com

If that works at the same time the other site fails, you can be confident it's an issue with the remote system and not a problem with your server.

This just keeps getting more strange. I was able to connect to another site via curl after it stopped working for the site in question. Yes.

Additionally, when I tried to access the site in question via the curl command line, it tried to connect to MY IP ADDRESS and use MY SERVER'S SSL certificate to authenticate.

What does that mean? Why would curl ever resolve another domain to my IP address?

And sorry for all the vague "my site" and "site in question" stuff. I'm just hesitant to post direct website IP's and related domain names in a public forum. I really appreciate you taking the time to talk me through this as well. I know it's well beyond basic cpanel help.

 

[kwdamp]

Hello,

I had a similar issue in the past with cURL i fixed that by setting curl.cainfo in php.ini to= "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem" <<-- check if this actually exists on your server after that systemctl restart httpd.service.

I think this may be my next step. So, is this pointing curl to an alternate list of SSL certificates and associated domains on the server?

What if my file isn't located there?

Edit: I dumped the default cert information in php/curl and got this back. Can you make heads or tails of it? Anything look out of place?

array(8) {
["default_cert_file"]=> string(45) "/opt/cpanel/ea-openssl11/etc/pki/tls/cert.pem"
["default_cert_file_env"]=> string(13) "SSL_CERT_FILE"
["default_cert_dir"]=> string(42) "/opt/cpanel/ea-openssl11/etc/pki/tls/certs"
["default_cert_dir_env"]=> string(12) "SSL_CERT_DIR"
["default_private_dir"]=> string(44) "/opt/cpanel/ea-openssl11/etc/pki/tls/private"
["default_default_cert_area"]=> string(36) "/opt/cpanel/ea-openssl11/etc/pki/tls"
["ini_cafile"]=> string(0) ""
["ini_capath"]=> string(0) ""
}

 

[rscalover]

I think this may be my next step. So, is this pointing curl to an alternate list of SSL certificates and associated domains on the server?

What if my file isn't located there?

Edit: I dumped the default cert information in php/curl and got this back. Can you make heads or tails of it? Anything look out of place?

array(8) {
["default_cert_file"]=> string(45) "/opt/cpanel/ea-openssl11/etc/pki/tls/cert.pem"
["default_cert_file_env"]=> string(13) "SSL_CERT_FILE"
["default_cert_dir"]=> string(42) "/opt/cpanel/ea-openssl11/etc/pki/tls/certs"
["default_cert_dir_env"]=> string(12) "SSL_CERT_DIR"
["default_private_dir"]=> string(44) "/opt/cpanel/ea-openssl11/etc/pki/tls/private"
["default_default_cert_area"]=> string(36) "/opt/cpanel/ea-openssl11/etc/pki/tls"
["ini_cafile"]=> string(0) ""
["ini_capath"]=> string(0) ""
}

There should be a file your server operating system trusts the path i mentioned is for centos if that path is no good for you try to google your server os + curl configuration.Do note that server administrators can restrict cURL requests or that website you are trying to reach is using CORS (Cross Origin Resource Sharing) or CSP (Content Security Policy) you can check if this is the case in the http headers.

This is a personal opinion but unless you are trying to reach some remote api service using cURL is seen as "suspicious" by most server administrators and thus blocked.

 

[cPRex]

We actually remove any personal details, like domains or IP addresses, if they get included in a public post, so good call on not including those.

What do you see in your /etc/resolv.conf file? Could you try commenting out whatever is in there and using the Google public resolvers instead to see if that changes the behavior?

nameserver 8.8.8.8
nameserver 8.8.4.4

 

[kwdamp]

We actually remove any personal details, like domains or IP addresses, if they get included in a public post, so good call on not including those.

What do you see in your /etc/resolv.conf file? Could you try commenting out whatever is in there and using the Google public resolvers instead to see if that changes the behavior?

nameserver 8.8.8.8
nameserver 8.8.4.4

the /etc/resolv.conf shows:

search mydomain.com
nameserver 216.xxx.xx.xxx
nameserver 216.xxx.xx.xx

(where my domain and the x's are actually my domain name and Providers IP addresses)

I have changed them to the nameservers you mentioned and will report back on any changes in behavior in the next few days.

Out of curiosity, are those nameservers considered stable and acceptable for production use? I'm only moderately experienced in server management (obviously) and I wasn't sure if there were additional issues or latency concerns using DNS servers outside the host facility.

 

[cPRex]

Yes - I've been using them for years on my own personal servers with no side effects.

 

[kwdamp]

It seems that may have fixed the issue! I did also find one spot where I had curl_close commented out. So I'm wondering if that might have also been causing issues with their use of cloudflare.

But either way, I'm back to 100% uptime. Thanks so much for your help guys.

 

[cPRex]

I'm glad things are working well!