Please whitelist cPanel in your adblocker so that you’re able to see our version release promotions, thanks!

The Community Forums

Interact with an entire community of cPanel & WHM users!

curl ssl issue - 443: connection refused

Discussion in 'General Discussion' started by morrow95, Jun 2, 2018.

Tags:
  1. morrow95

    morrow95 Well-Known Member

    Joined:
    Oct 8, 2006
    Messages:
    123
    Likes Received:
    3
    Trophy Points:
    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.
     
    #1 morrow95, Jun 2, 2018
    Last edited by a moderator: Jun 2, 2018
  2. morrow95

    morrow95 Well-Known Member

    Joined:
    Oct 8, 2006
    Messages:
    123
    Likes Received:
    3
    Trophy Points:
    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.
     
  3. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    44,323
    Likes Received:
    1,851
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  4. morrow95

    morrow95 Well-Known Member

    Joined:
    Oct 8, 2006
    Messages:
    123
    Likes Received:
    3
    Trophy Points:
    168
    For the first I get the following :
    Code:
    root@jupiter [~]# 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.
     
    #4 morrow95, Jun 4, 2018
    Last edited: Jun 4, 2018
  5. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    44,323
    Likes Received:
    1,851
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  6. morrow95

    morrow95 Well-Known Member

    Joined:
    Oct 8, 2006
    Messages:
    123
    Likes Received:
    3
    Trophy Points:
    168
    9686901
     
  7. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    44,323
    Likes Received:
    1,851
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
Loading...

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice