curl ssl issue - 443: connection refused
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 :
which when viewed in the browser returns :
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 :
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
';
print_r(curl_getinfo($ch));
echo '';
echo 'Errors: ' . curl_errno($ch) . ' ' . curl_error($ch) . '
';
curl_close ($ch);
echo $result . 'EOF';
?>
which when viewed in the browser returns :
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 :
[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
-
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. 0 -
Hello @morrow95, Can you review the following posts and let us know if any of these solutions help? Thank you. 0 -
Hello @morrow95, Can you review the following posts and let us know if any of these solutions help? 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.
0 -
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 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.
0 -
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
0 -
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. 0
Please sign in to leave a comment.
Comments
6 comments