curl ssl issue - 443: connection refused

morrow95

Well-Known Member
Oct 8, 2006
189
12
168
Having an issue using curl and ssl all of a sudden. I think this 'might' be related to switching from EA3 to EA4 awhile back and/or using autossl certs through WHM.

I am testing using the following script from the site in question and curlopt_url set to itself :

Code:
<?php
$ch = curl_init();
curl_setopt($ch, CURLOPT_TIMEOUT, 30);
curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
//Uncomment this for Windows.
//curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($ch, CURLOPT_URL, "https://www.site.com");
$result = curl_exec($ch);
echo '<pre>';
print_r(curl_getinfo($ch));
echo '</pre>';
echo 'Errors: ' . curl_errno($ch) . ' ' . curl_error($ch) . '<br><br>';
curl_close ($ch);
echo $result . 'EOF';
?>
which when viewed in the browser returns :
Code:
Array
(
   => https://www.site.com/ [content_type] => [http_code] => 0 [header_size] => 0 [request_size] => 0 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 0 [total_time] => 0.004557 [namelookup_time] => 0.00443 [connect_time] => 0 [pretransfer_time] => 0 [size_upload] => 0 [size_download] => 0 [speed_download] => 0 [speed_upload] => 0 [download_content_length] => -1 [upload_content_length] => -1 [starttransfer_time] => 0 [redirect_time] => 0 [redirect_url] => [primary_ip] => [certinfo] => Array ( ) [primary_port] => 0 [local_ip] => [local_port] => 0 ) Errors: 7 Failed to connect to www.site.com port 443: Connection refused EOF
The cert for this domain is fine. All other ssl works fine for this domain. The nat firewall looks fine and so on. I double checked EA4 in WHM and php72-php-curl is installed as it has been (7.2.6-1.1.4.cpanel). The only thing I could find which may be related is in the MultiPHP INI Editor where these values are commented out :
Code:
[curl] ; A default value for the CURLOPT_CAINFO option. This is required to be an ; absolute path. ;curl.cainfo = [openssl] ; The location of a Certificate Authority (CA) file on the local filesystem ; to use when verifying the identity of SSL/TLS peers. Most users should ; not specify a value for this directive as PHP will attempt to use the ; OS-managed cert stores in its absence. If specified, this value may still ; be overridden on a per-stream basis via the "cafile" SSL stream context ; option. ;openssl.cafile= ; If openssl.cafile is not specified or if the CA file is not found, the ; directory pointed to by openssl.capath is searched for a suitable ; certificate. This value must be a correctly hashed certificate directory. ; Most users should not specify a value for this directive as PHP will ; attempt to use the OS-managed cert stores in its absence. If specified, ; this value may still be overridden on a per-stream basis via the "capath" ; SSL stream context option. ;openssl.capath=
Any ideas as to what I should be looking for and checking to get this working properly? If I change curlopt_url to something like Google then the script runs fine and returns no errors.
 
Last edited by a moderator:

morrow95

Well-Known Member
Oct 8, 2006
189
12
168
I did some more searching and found selinux could be a problem, but sestatus returns disabled from cli. This is a VPC so it has NAT and its own firewall which is the primary, but I did review the iptables rules. To my knowledge these have never been manually changed other than what cpanel does automatically :

# Generated by iptables-save v1.4.7 on Sat Sep 26 10:56:27 2015
*nat
:PREROUTING ACCEPT [54:3240]
:POSTROUTING ACCEPT [500:31356]
:OUTPUT ACCEPT [500:31356]
COMMIT
# Completed on Sat Sep 26 10:56:27 2015
# Generated by iptables-save v1.4.7 on Sat Sep 26 10:56:27 2015
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1:136]
:acctboth - [0:0]
:cP-Firewall-1-INPUT - [0:0]
-A INPUT -j cP-Firewall-1-INPUT
-A INPUT -j acctboth
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j cP-Firewall-1-INPUT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -j acctboth
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 993 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2082 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2078 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2077 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 26 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 8080 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 143 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 995 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 110 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2086 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2079 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2080 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2087 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2095 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 465 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2096 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 3306 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2083 -j ACCEPT
-A cP-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
iptables -I INPUT 2 -p tcp --dport 30000:55000 -j ACCEPT
COMMIT
# Completed on Sat Sep 26 10:56:27 2015

I also looked in the VPC firewall. Which has the following related :

source / destination / protocol

any:any / my public ips :443 / tcp
internal:any / any:443 / tcp
internal:any / internal:any / tcp

What am I missing? There has to be something stupid that is blocking this and it would have had to been something done auto during an update because none of this stuff has been changed manually in a long time.
 

morrow95

Well-Known Member
Oct 8, 2006
189
12
168
Hello @morrow95,

Can you review the following posts and let us know if any of these solutions help?

Cronjob SSL problem
SOLVED - Easyapache enable custom CURL
cPanel + pfSense + Let's Encrypt + Curl

Thank you.
For the first I get the following :
Code:
[email protected] [~]# rndc flush
WARNING: key file (/etc/rndc.key) exists, but using default configuration file (/etc/rndc.conf)
Number two - there are no AAAA entries in any zones.

Number three - We are not using pfSense. We have a VPC with VMWare and that is the 'main' firewall. There is one VM (out of two) that uses cpanel/whm and has all the domains and apache running. I included rules I saw related in the original post.

I just wanted to make things clear that curl itself works from our end if retrieving outside locations (like Google), but when we test retrieving something from one of our own domains it gives the can't connect error. We had a third party trying to retrieve on of our page's response and it would fail which brought up all of this. This is what made me think it could be related to the ssl certs since the firewall stuff looks correct, however, browsing any of our websites though https works fine and the certs show correctly. How could browsing https://ourdomain.com/ourpage.php show correctly in the browser and the certs work fine, but when retrieving the same page in curl it can't connect?

I'll also add that is looks like the /etc/sysconfig/iptables was certainly changed at some point through some automated script or something with an upgrade. Comparing the current file (listed in the original post) to the .old and .save of the same file it is quite different. There are none of the acctboth or cP-Firewall-1-INPUT references in them.
 
Last edited:

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,880
2,258
463
WARNING: key file (/etc/rndc.key) exists, but using default configuration file (/etc/rndc.conf)
You can safely ignore that warning message. It's due to the existence of the /etc/rndc.conf file, which isn't needed because the entries it uses are already defined in the /etc/named.conf file. Internal case CPANEL-20503 will address this false warning message in cPanel & WHM version 74.

I just wanted to make things clear that curl itself works from our end if retrieving outside locations (like Google), but when we test retrieving something from one of our own domains it gives the can't connect error. We had a third party trying to retrieve on of our page's response and it would fail which brought up all of this. This is what made me think it could be related to the ssl certs since the firewall stuff looks correct, however, browsing any of our websites though https works fine and the certs show correctly. How could browsing https://ourdomain.com/ourpage.php show correctly in the browser and the certs work fine, but when retrieving the same page in curl it can't connect?

I'll also add that is looks like the /etc/sysconfig/iptables was certainly changed at some point through some automated script or something with an upgrade. Comparing the current file (listed in the original post) to the .old and .save of the same file it is quite different. There are none of the acctboth or cP-Firewall-1-INPUT references in them.
Could you open a support ticket so we can take a closer look at the system to see if we notice anything that could be leading to the issue you described? You can post the ticket number here and I'll link this thread to it.

Thank you.
 

morrow95

Well-Known Member
Oct 8, 2006
189
12
168
You can safely ignore that warning message. It's due to the existence of the /etc/rndc.conf file, which isn't needed because the entries it uses are already defined in the /etc/named.conf file. Internal case CPANEL-20503 will address this false warning message in cPanel & WHM version 74.



Could you open a support ticket so we can take a closer look at the system to see if we notice anything that could be leading to the issue you described? You can post the ticket number here and I'll link this thread to it.

Thank you.
9686901
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,880
2,258
463
Hello,

To update, it looks like our Technical Analysts determined this was the result of the NAT setup on this server lacking support for NAT reflection.

Thank you.