• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved Seeking Assistance with API Communication Issues via SSL on Plesk

Lenny

New Pleskian
Server operating system version
Ubuntu 22.04.3 LTS
Plesk version and microupdate number
18.0.57 #5
Hello Everyone,

Firstly, I would like to extend my gratitude to all of you for taking the time to read about my issue and for any assistance you might offer in resolving it.

I have extensively researched and tried most of the suggested solutions for my problem. However, before considering a fresh reinstall, I thought it prudent to reach out on this forum.

System Overview:
  • Hostname: subdomain.domain.tld*
  • IP Address: Private address (Public IP)
  • Operating System: Ubuntu 22.04.3 LTS
  • Plesk Product: Plesk Obsidian
  • Plesk Version: 18.0.57 Update #5, last updated on Dec 20, 2023, at 06:27 AM
*Both my domain and subdomain are registered on the same IP address/Plesk instance. My domain has a valid wildward certificate from let's encrypt while my subdomain uses it. My DNS are hosted on AWS Route 53, I don't have any issues with them.

I am encountering three interconnected issues related to API communication through an SSL connection on Plesk. Below are the logs from the Log Browser > Plesk:
2023-12-30 18:37:21 ERR extension/monitoring [464758:6590555149788] Http client exception: Unable to Connect to ssl://api.monitoring360.io:443. Error #110: Connection timed out
2023-12-30 18:37:02 ERR extension/xovi [464230:6590553e295ef] Sorry, currently not able to connect to API.
2023-12-30 18:36:54 ERR extension/wp-toolkit [464172:659055271ef84] Unable to retrieve data by "https://api.wordpress.org/core/stable-check/1.0/"
The symptoms are as follows:
  • Accessing the 'Monitoring' page with Platform 360 connected results in an 'An unexpected error occurred' message. Both my AWS private network security rules and my Plesk firewall are correctly configured (ports 80 and 443 are open), with Platform 360 IP addresses whitelisted. The Monitoring extension and agent360 have already been uninstalled and reinstalled. The error in the Log Browser provides a bit more detail: /opt/psa/admin/plib/modules/monitoring/library/Http/HttpClient.php(122): Unable to Connect to ssl://api.monitoring360.io:443. Error #110: Connection timed out. Interestingly, Platform 360 displays statistics correctly for my server and websites on their site.
  • Accessing the SEO Toolkit (XOVI) page takes more than two minutes to load, but eventually, the page does load. Even tried to uninstall then reinstall SEO Toolkit extension.
  • On the WordPress Toolkit page, most actions work except for 'Install', which returns the disclaimer 'Your hosting plan does not allow you to create any more databases. This WordPress installation will use an existing database instead of creating a new one.' This is perplexing as all my hosting plans are fully enabled (unlimited + wp toolkit authorization), and I have a valid web host license. Additionally, I get a notification: 'Failed to get installation parameters of a WordPress website: No versions available'. Selecting any field results in 'No options', making it impossible to create WordPress instances using the tool because I can't select any domain which is mandatory. Also uninstalled then reinstalled WP Toolkit extension.
I have done my due diligence in trying to resolve these issues but to no avail. Any insights or suggestions from this community would be greatly appreciated.

I have gone through various threads on the Plesk forum, including:
Based on suggestions in these threads, I have taken the following measures:
  • Reinstalled the openssl and ca-certificates package:
mv /usr/lib/ssl /root/ssl.saved
apt-get install --reinstall openssl ca-certificates
  • Signed a new Let's Encrypt certificate for the Plesk host, verified with CLI that it is correctly signed, and checked that Apache2 and Nginx configuration files correctly point to the new certificates. An external site check confirms the certificate is valid, not outdated.
  • update-ca-certificates
  • Conducted various network tests on the APIs using dig, nslookup, curl, and curl -i, traceroute, and wget:
    • dig works as expected
    • nslookup provides correct responses
    • curl successfully retrieves data
    • traceroute completes successfully
    • wget initially attempts to connect via IPv6 and times out after over two minutes, then switches to IPv4 and successfully connects
Despite these measures, the issues persist. If anyone has further insights or has encountered similar issues, your input would be invaluable to me.

Thank you in advance for your time and assistance.

Best Regards,
Lenny
 
I'd guess this is caused by an incorrect IP address or network interface configuration. Maybe there is an additional IP address assigned in DNS that resolves to another server or is not correct at all? Maybe it's an IPv6 address, but the server does not run on IPv6?
 
Hello @Peter Debik ,

I appreciate the suggestion regarding the potential IP address or network interface configuration issue. Following this, I have taken several steps to investigate and resolve the issue, but unfortunately, the problems persist.

To address your points:
  • IP Address Verification: I can confirm that the IP addresses assigned to my server are as mentioned in my system overview. However, I will double-check to ensure there are no incorrect or additional IP addresses that might cause conflict.
  • IPv6 Consideration: As for IPv6, it is a possibility that the server is not properly configured for IPv6. I am considering disabling IPv6 to see if that resolves the issue.
  1. System Overview and AWS Configuration:
    • I'm using an official Plesk AMI for an EC2 instance (Gravitron > ARM): 'Plesk Obsidian Ubuntu for WordPress & Website Hosting (ARM), BYOL'. This setup automatically creates the appropriate security group and pre-configured VPC. I've verified that these settings align with Plesk's documentation, and my AWS security rules and Plesk firewall are correctly configured.
    • I temporarily disabled my Load Balancer and its security group to minimize intermediaries.
  2. Plesk IP Address Configuration:
    • In 'Home > Tools & Settings > IP Addresses', both my private IPv4/IPv6 and public IPv4 addresses are listed, but no public IPv6 address is available without the Load Balancer to translates IPv6 to IPv4.
    • After migrating from OVHCloud to AWS, I mapped the new public IPv4 address in Plesk and corrected the DNS configuration, which was initially set to the private AWS IPv4. This resolved web access issues, but API communication problems began shortly after.
  3. IPv6 Disabling Efforts:
    • Modified /etc/sysctl.conf to disable IPv6 and applied the changes with sudo sysctl -p. Verified the absence of AAAA records and restarted the server.
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
  • Attempted to update Plesk's DNS Settings to remove the IPv6 configuration (removing 'listen-on-v6 { any; };' line), but encountered the error: dnsmng failed: Could not start named-checkconf System error 2: No such file or directory.
4. DNS and BIND Verification:​
  • which named-checkconf confirms the presence of the utility, but the file seems corrupted and cannot be opened (? symbol everywhere).
  • The BIND service is active and running, but it does not list the zone for the parent domain of the Plesk host. Is this normal?
  • Ran plesk repair dns -y which returned [OK] but was followed by multiple errors similar to: proc_close() failed ['/opt/psa/admin/bin/dnsmng' '--update' 'domain.tld'] with exit code [1].
PHP Fatal error: Uncaught PleskMultipleException: Error during domain.tld updateZone: dnsmng failed: in /opt/psa/admin/plib/Service/Dns/Connector/Plesk.php:14
Stack trace:
#0 /opt/psa/admin/plib/Service/Dns/Connector/Proxy.php(207): Service_Dns_Connector_Plesk->commitChanges()
#1 [internal function]: Service_Dns_Connector_Proxy->commitChanges()
#2 {main}
thrown in /opt/psa/admin/plib/Service/Dns/Connector/Plesk.php on line 14
exit status 255
The error encountered with plesk repair dns -y occurred after an attempt to delete hosted zones through the Route 53 extension in Plesk. One of these zones had DNSSEC enabled. My objective was to ensure that all hosted zones were under the same Delegation Set for simplified management. This process, however, seems to have led to complications, especially with the DNS management in Plesk. The intention was to streamline DNS management, but it appears to have inadvertently contributed to the current issues (not related to the main topic issue with API communication, it was timing out before any issue related to DNS management).
  • Manually checking DNS configuration syntax with sudo named-checkconf -zj did not reveal any issues.
5. Network Interface Check:​
  • Commands ip -4 addr and ip -6 addr only show private addresses for connected interfaces, including Docker-related ones.
Regarding the DNSSEC issues with Amazon Route 53, I'm in the process of manually resolving them and waiting for the TTL (2 days, should expires today) to expire to validate the DNSSEC deactivation and reinstall my hosted zones.

Given these developments, I'm still at an impasse with the API communication issues. Any further insights would be greatly appreciated.

Thank you again for your assistance.

Best regards,
Lenny
 
I wanted to update you on the progress of the issues I was facing with Monitoring, SEO Toolkit, and WordPress Toolkit on my Plesk server.

Following your advice, I referred to the article on disabling IPv6 addresses on a Plesk server. After implementing the steps outlined in the article, I'm delighted to report that all three problems related to Monitoring, SEO Toolkit, and WordPress Toolkit have been resolved. It appears that the IPv6 configuration was indeed contributing to the communication issues I was experiencing.

Additionally, I agree with your assessment regarding the other ancillary issues. These seem to stem more from my personal configuration rather than from Plesk itself, and I believe it's within my scope to resolve these separately.

I cannot thank you enough for your guidance. Your suggestion has been instrumental in resolving these critical issues, and everything is now functioning smoothly. Your expertise and willingness to help are greatly appreciated.

Best regards,
Lenny
 
Back
Top