[SOLVED:] Migration Toolkit resulted in sites giving PR_END_OF_FILE_ERROR when accessing them

This version of Migration Toolkit is WONDERFUL! Everything is migrated over to the target server AND with the same IDs as the source server. Fantastic!

...but...

After migration I set the DNS for a few test sites to the target server's IP address, then I generated new certificates and THIS happens:

Code:

Secure Connection Failed

An error occurred during a connection to www.<theSite>.com. PR_END_OF_FILE_ERROR

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.

Is there a setting that I need to do after a full migration? I don't find "PR_END_OF_FILE_ERROR" in the forums and for migration toolkit.

 

There is no "/root/.acme.sh/acme.sh.log" . There are certificates in the proper subdirectories for the domains I generated certs for.

 

I can access ISPC3 as such and that uses the same IP so that shouldn't be a problem with the DNS records (only IPv4), or?
The error log in empty: /var/www/<theSite>/log/error.log

Accessing the site without SSL works like it should, with SSL it does not.

When I try to disable Let's Encrypt cert in ISPC3 that works, but enabling it again fails.

 

Read the part about failing LE on the Read before posting:
https://www.howtoforge.com/community/threads/please-read-before-posting.58408/

 

Thanks, yes, I found that through a search here before.

Still the same though.

The strange thing is that last week I migrated the server myself. Almost everything was done, then I rebooted the new server and -ta-da- read error on the disk. That disk is not swapped out.
The thing is that it worked flawlessly then, but now after running the migration tool to do the migration, it doesn't work.

 

One thing I have in the log is this:

Code:

PHP Warning:  PHP Startup: Unable to load dynamic library 'memcache.so' (tried: /usr/lib/php/20180731/memcache.so (/usr/lib/php/20180731/memcache.so: cannot open shared object file: No such file or directory), /usr/lib/php/20180731/memcache.so.so (/usr/lib/php/20180731/memcache.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
finished server.php.

 

I disabled the /usr/local/ispconfig/server/server.sh in crontab to run it manually, which resulted in this:

/root/.acme.sh/acme.sh: line 5568: /var/www/clients/client3/web68/ssl/<theSite>-le.key: No such file or directory

That key file points to (not a symbolic link) to

/etc/letsencrypt/live/<theSite>/privkey.pem

and that IS correct, that directory does not exist:

/etc/letsencrypt/live/<theSite>/

Isn't this a remain from certbot? (from the source server, while the target server runs acme)

 

Why does acme point out a certificate generated by certbot? I mean, isn't it so that certificates generated from certbot are stored under /etc/letsencrypt , while certificates generated by acme is stored under /root/.acme* or is there a mix?
A bug?

[EDIT: For clarity: The migration script on the source server gave a statement that no certificates would be migrated, but the setting "Let's Encrypt" was still enabled in ISPC3.]

 

Disable LE in the settings per site?

 

YES! It was the old certificates that had been migrated over.

All works now, so I will delete all the certs in the SSL directories for each website and re-generate the certificates from within ISPC3.

Is this by any chance a bug in the Migration Toolkit? If so, I am "happy" to have caused a problem that made it even better.

THANK YOU ALL! @till , @Th0m and @Taleman for your help! You ROCK!

 

Hey... It's me again.

It worked for the first domain, but not for the remaining ones. Ouch.

 

Disabling the ISPC3 cronjob /usr/local/ispconfig/server/server.sh to run it manually, gives no errors