Does the old v17.x instance still exist? If so, you might be best apply the fix I'll detail here (below in the middle section of my post) first and then work on migrating your data to a newer TurnKey instance as a separate process. Doing that now is just introducing more changes and potential issues.

FYI as noted on the TKLBAM docs page:

A backup might restore ok on a server of a single newer major version (e.g. v15.2 -> v16.1) although it may require some tweaking.

So doing that whilst there is already an issue is generally a bad idea. The first thing to try would have been trying restoring your backup either to the same server, or to another server of the same version. Although seeing as you have customised things a bit, even just migrating to another server of the same version may not have worked. That's why we always recommend that you test a backup before you need it. That way you can be confident that it will "just work" when you need it.

Anyway, if your old v17.x server still exists, and/or for future reference, and/or for the benefit of anyone else experiencing this issue I'll cover the issue in your first post:

That page you're seeing is provided by our "init fence". The idea is that it doesn't allow access to any web interfaces, until the firstboot scripts (i.e. inthooks) have been completed.

It sounds like you ran through them long ago, so why that has appeared again is a mystery!? Once the scripts have been run through, it should never run again, unless something explicit has been tweaked. The only way you should see that is if the firstboot scripts (i.e. inithooks) are running (again - for some unknown reason) or the service was explicitly started. I.e.:

systemctl start turnkey-init-fence

I'm assuming you didn't do that, but that page can be disabled by stopping the service:

systemctl stop turnkey-init-fence

Putting that aside (as I'm 99% sure that's not what is going on), to ensure the firstboot scripts are disabled, either log into your server's terminal (e.g. SSH, the PVE NoVNC window, etc).

Then ensure that the firstboot scripts are disabled. To do that, check the defaults file:

grep RUN_FIRSTBOOT /etc/default/inithooks

If it's not false, then edit the file and set it to false.

Then reboot and hopefully you should be all good.

Now your new issue...

TBH, that seems like a very strange issue! I'm not familiar with Portainer or HAProxy. Regardless, the fact that your server is using a cert for docker.mylocal and Portainer (I assume running on a separate host) is erroring because of a certificate with the same name, suggests to me that there is certainly something weird going on in your network - somehow related to Docker. Do you have a caching proxy on your network? Perhaps that just needs it's cache cleared?

If it was only occurring on your new server, then it could be something specific to that. But assuming Portainer is running on an alternate host, then that complaining about the same cert name suggests something common to both servers.

To confirm it's not directly related to your new server, try connecting directly to it (e.g. via IP address). If that has an expected certificate and not the 'docker.mylocal' one then you can rule that out a the specific cause. (Note you'll still get a SSL warning for self signed cert when testing your new Bitwarden server). It must be something else within your network). Perhaps an IP issue or some caching proxy issue?

What would might help is working out where this 'docker.mylocal' certficate is coming from. Given the name, I'm guessing a Docker instance somewhere on your network. Perhaps HAProxy is playing a part too?

I'm happy to try to assist more, but I'd need much more info about your network and what is running on it.