Childsite keeps disconnecting

Hi,
I have a childsite where the childplugin is installed.
When I connect from MainWP-server, I can connect :slight_smile: But first time I try to ‘do anything’ it will disconnect, and tell me “Public key already set. Please deactivate & reactivate the MainWP Child plugin on the child site and try again.”
Then I deactivate, and reactivate… It will connect, but only until first time I try to ‘do anything’ (like syncing the site!).
This happens on and on…
I have tried deactivating all plugins but the childplugin. Still the same.
I have tried to uninstall, and reinstall, and reconnect. Still the same.
I have tried to change to a default WP-theme. Still the same.

I have made an ‘system report’ that I paste here under.

I really hope someone can help to spot what is the reason that it keeps failing.

All the best,
:slight_smile: Mads


Server configuration Required value Value Status

MAINWP CHILD
MainWP Child Version 4.4.1.1 4.4.1 Warning
WordPress
WordPress Version >=3.4 6.2.2 Pass
WordPress Memory Limit >=64M 1024M Pass
MultiSite Disabled =true true Pass
FileSystem Method = direct direct Pass
PHP SETTINGS
PHP Version >=7.4 8.0.27 Pass
PHP Safe Mode Disabled OFF
PHP Max Execution Time >=30 seconds 30 Pass
PHP Max Input Time >=30 seconds 60 Pass
PHP Memory Limit >=128M (256M+ best for big backups) 1024M Pass
PCRE Backtracking Limit >=10000 1000000 Pass
PHP Upload Max Filesize >=2M (2MB+ best for upload of big plugins) 1000M Pass
PHP Post Max Size >=2M (2MB+ best for upload of big plugins) 1024M Pass
SSL Extension Enabled =true true Pass
SSL Warnings = empty Pass
cURL Extension Enabled =true true Pass
cURL Timeout >=300 seconds 300 Pass
cURL Version >=7.18.1 7.76.1 Pass
cURL SSL Version >=OpenSSL/1.1.0 OpenSSL/3.0.1Pass
MySQL SETTINGS
MySQL Version >=5.0 8.0.30 Pass
BACKUP ARCHIVE INFORMATION
ZipArchive enabled in PHP =true true Pass
Tar GZip supported =true true Pass
Tar BZip2 supported =true true Pass
SERVER INFORMATION
WordPress Root Directory /web/skuret.dk/public_html/
Server Name skuret.dk
Server Software Apache
Operating System Linux
Architecture 64 bit
Server IP 185.93.193.73
Server Protocol HTTP/1.1
HTTP Host skuret.dk
HTTPS ON - on
Server self connect Not expected HTTP response body:
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36
Server Port 443
Gateway Interface CGI/1.1
Memory Usage 9.94 MB
Complete URL Log ind ‹ Safi Standard — WordPress
Request Time 1685711351
Accept Content text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Charset Content N/A
Currently Executing Script Pathname /web/skuret.dk/public_html/wp-admin/options-general.php
Current Page URI /wp-admin/options-general.php?page=mainwp_child_tab
Remote Address 85.129.89.14
Remote Host N/A
Remote Port 49927
PHP INFORMATION
PHP Allow URL fopen ON
PHP Exif Support YES ( V8.0.)
PHP IPTC Support YES
PHP XML Support YES
PHP Disabled Functions No functions disabled
PHP Loaded Extensions Core, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, bz2, calendar, cgi-fcgi, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, imagick, intl, json, libxml, mbstring, mysqli, mysqlnd, openssl, pcre, pdo_mysql, pdo_sqlite, session, sockets, sqlite3, standard, tokenizer, xml, xmlreader, xmlwriter, xsl, zip, zlib
MySQL INFORMATION
MySQL Mode NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
MySQL Client Encoding utf8mb4
WordPress PLUGINS
Admin and Site Enhancements 5.0.2 Inactive
Code Snippets 3.3.0 Inactive
Duplicator Pro 4.5.9.1 Inactive
Elementor 3.13.2 Inactive
Elementor Pro 3.13.1 Inactive
File Manager Advanced 5.0.4 Inactive
Health Check & Troubleshooting 1.6.0 Inactive
Independent Analytics 1.22.1 Inactive
Interlinks Manager 1.06 Inactive
MainWP Child 4.4.1 Active
Matomo Analytics - Ethical Stats. Powerful Insights. 4.14.2 Inactive
PhastPress 2.14 Inactive
Really Simple SSL 6.2.5 Inactive
Stream 3.9.3 Inactive
Sucuri Security - Auditing, Malware Scanner and Hardening1.8.39 Inactive
WP Force SSL 1.65 Inactive
WP Meteor 3.2.0 Inactive
WP Rocket 3.12.6.1 Inactive
WP Statistics 14.1 Inactive

Next due Schedule Hook

  1. juni 2023 15:52 To gange dagligt wp_stream_auto_purge
  2. juni 2023 16:07 En gang om dagen recovery_mode_clean_expired_keys
  3. juni 2023 16:07 To gange dagligt wp_https_detection
  4. juni 2023 16:07 To gange dagligt wp_version_check
  5. juni 2023 16:07 To gange dagligt wp_update_plugins
  6. juni 2023 16:07 To gange dagligt wp_update_themes
  7. juni 2023 16:07 En gang i timen wp_privacy_delete_old_export_files
  8. juni 2023 16:08 To gange dagligt wp_update_user_counts
  9. juni 2023 16:08 En gang om dagen wp_scheduled_delete
  10. juni 2023 16:08 En gang om dagen delete_expired_transients
  11. juni 2023 16:18 En gang om dagen wp_scheduled_auto_draft_delete
  12. juni 2023 16:51 upgrader_scheduled_cleanup
  13. juni 2023 19:56 En gang om dagen wp_statistics_add_visit_hook
  14. juni 2023 12:18 En gang om dagen elementor/tracker/send_event
  15. juni 2023 16:07 En gang ugentligt wp_site_health_scheduled_check

Time Error

Error logging disabled.
MainWP is unable to find your error logs, please contact your host for server error logs.


1 Like

Hi @MadsMain

Welcome to the MainWP community.

The MainWP Child plugin is slightly out of date so let’s try first bringing that up to date.

And make sure that MainWP Dashboard plugin is up to date as well.

If the issue persists, try temporarily deactivating security rules you may have on the child site and see if that helps as that is the most common cause for these frequent disconnects:

  1. Do you use some security plugins on your child site? If yes, can you try to temporarily disable them and see if that helps?

  2. Do you have any security rules present in the .htaccess file of the child site? If yes, can you try temporarily removing them and see if that helps?

  3. Do you use Cloudflare or any other cloud proxy firewall? If yes, can you try to whitelist your Dashboard IP or temporarily disable it to see if that helps?

  4. Do you use any kind of server-side security measures such as mod_security or server-side firewalls? If yes, can you try to temporarily disable them and see if that helps?

Hi Bojan,

Thank for your reply, and ‘looking intio it’.
I agree that the installed MainWP version is 4.4.1, and I am able to upgrade to 4.4.1.1
According to the changelog, the difference is this:
Fixed: Potential conflict with the Oxygen Builder 4.6
Fixed: WP Rocket plugin compatibility problems

Re.1:
Well, as I explained, I have deactivated ALL other plugins at the site.
The only plugin active is the MainWP Child.
So your suggestion to disable any ‘security plugins’ is already done…

Re. 2:
Regarding my .thaccess file I am not aware that it sghould contain any special code.
But here is the full content:
***** SNIP *****
#Begin Really Simple Security
Options -Indexes
#End Really Simple Security

BEGIN WordPress

Direktiverne (linjer) mellem ‘BEGIN WordPress’ og ‘END WordPress’ er

dynamisk genereret og bør kun ændres via WordPress-filtre.

Eventuelle ændringer i direktiverne mellem disse markører vil blive overskrevet.

RewriteEngine On RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] # END WordPress ***** SNAP *****

I can now see that there IS some code related to security, even all plugins are disabled.
You think that having this in the code can cause problems?:
#Begin Really Simple Security
Options -Indexes
#End Really Simple Security

Re. 3:
Regarding use of cloudflare or other cloud proxy firewall, the answer is “No I dont use”

Re. 4:
I am a bit unsure how to check whether I have any 'server-side security measures?
How can I test that?

So:
Only thing that I could change/try/take action on, was to upgrade the ChildPlugin from 4.4.1 to 4.4.1.1
But unfortunately the problem persist.
I keep getting the “ERROR: Authentication failed! Please deactivate and re-activate the MainWP Child plugin on this site”

Ans surprise: Deactivating and reactivating simply has no effect at all…

So I am still stuck here…
Hope you have more ideas to troubleshooting :slight_smile:

All the best,
:slight_smile: Mads

Thanks for the update @MadsMain .

Would you mind opening a private Help Desk ticket so we can collect some additional information & investigate further?

1 Like

Hereby done! :slight_smile:
:slight_smile: Mads

1 Like

Hi, I’ve got exactly the same problem just with one of my websites!

I’m using the latest version of MainWP Dashboard and MainWP Child.

I think that this issue could be related to OpenSSL 3.0: this is the only difference between the disconnected child website hosting and the others.

My hosting provider told me that the child site is installed on a RHEL 9 server with OpenSSL 3.0, and that SHA-1 (used by the openssl_sign() function by default in the dashboard, I see) is disabled and they cannot enabled it due for security reasons.

On my dashboard server I’ve got PHP 8.1, but OpenSSL 1.1.1 instead of 3.0.

Debugging the code I discovered also that the openssl_verify() function in class-mainwp-connect.php returns -1 (that means an error occured).

My provider also gave me this link about SHA-1 deprecation in RHEL 9: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/considerations_in_adopting_rhel_9/index#ref_considerations-security-crypto_changes-to-security

My suggestion: it could be possible to use a different (and supported) algorithm to sign?

Thank you!
Riccardo

1 Like

Hi @vertigofactory

Welcome to the MainWP Community.

Thanks for the detailed post. We will look into it and update you via this thread as soon as we can.

We have been looking into this and it seems that he problem is caused by disabled compatibility between OpenSSL 1 and OpenSSL 3.

To be precise, in OpenSSL 3, compatibility with the v1 can be disabled by host, but it should be possible to enable it.

This should be doable in the /etc/ssl/openssl.cnf file on the child site by setting it like this:

openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1

More info is available here:
And follow the openssl 3.0 link at OpenSSL 3.0 - OpenSSLWiki

1 Like

Hi Bogdan, thank you. Unfortunately, due to internal security policies, my hosting provider can’t enable the compatibility with the v1. :frowning_face:

What if we use instead of SHA-1 another algorithm that is used both from OpenSSL v3 and OpenSSL v1? I know that SHA-1 is used by default, but also you can specify the algorithm as a parameter in openssl_sign() and openssl_verify().

1 Like

Hi @vertigofactory, let me confirm with the dev team about this.

1 Like

Hi @bogdan and @vertigofactory

I have had my host to change childboard server settings (running 3.x), so it is now compatible with the dashboard server (running 1.x). My hostprovider was not happy to open this, since the V 1.x will soon not be continued… And that is why my childsite server runs V 3.x

BUT… even with enabled compatibility, this does unfortunately NOT fix the problem…

After changing the compatibility… well, everything is just a before… no change :frowning:
I have written this also in my private mail-dialogue with Bogdan and developers.

Now lets hope that they can find another way to solve the issue…

:slight_smile: Mads

2 Likes

Hi Mads,

Thanks for verifying that.

We are working on a version where users will be able to select the preferred OpenSSL algorithm. I believe we will have the version ready soon.

2 Likes

Hi all,

We made an update to the MainWP Dashboard plugin and the MainWP Child plugin. In the new version, there is a new option added to the site Edit page, where users can select alternative Signature Algorithms. We added two additional options, OPENSSL_ALGO_SHA256 and OPENSSL_ALGO_SHA512.

However, since we could not confirm the fix due to the inability to duplicate the problem even though we tested and tried to do it on multiple different OpenSSL v3 versions, the only way to confirm the fix is if users that experience this problem can test updates and let us know how it goes.

If you are interested in trying out the new version, please open a helpdesk ticket where we will provide further instructions and test versions.

Also, it is important to say that we tested the updates internally to confirm that there are not any kind of issues introduced with this addition and both plugins are still fully backward compatible.

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.