You could do that. After decrypting it, write the decrypted key through the webui in the "Server Key" field. The PEM header should NOT mention "encrypted".
Your error message complains about server.key. That's your RSA (certificate) Server key, not your tls-crypt-v2 key (which is called secret.key). Your issue is unrelated to tls-crypt.
You cannot use encrypted key/certificates, since you have no way of typing a password to decrypt them as the...
The tls-crypt-keys are not password-protected. They must also be generated by OpenVPN --genkey (which is what the router does automatically), not by EasyRSA.
Those CSRF security flaws are not trivial to exploit. There is no real need to panic over them. You would need to be actively logged into the router webui at the same time that you access a malicious link that would then inject code into your logged webui.
CIsco and Juniper also had their share of security issues over the years, so it`s not fair to single out Ubiquiti here as if they were suddenly worse than everyone else. pfsense? They also have quite a list of past CVEs of severity up to 9.x...
Yes.
Up to you. TLS Crypt V2 helps protect against bots trying to port scan your OpenVPN server by requiring TLS encryption even to connect with that port, but it will also be more complex to manage as you need to generate a key for every client that you intend to connect with.
SHA1. HMAC is...
No need to if the difference is just the presence of an additional device and the rest is unchanged. The firmware can detect if the sensor is present, and if so and if the country code matches, enable its use. Just like some models have different switch models based on the hardware revision...
While doing some OpenVPN maintenance, removing deprecated/legacy features, I figured might as well knock another item off my ToDo list, and implement full tls-crypt-v2 support on the server.
This includes the ability to generate client keys for the clients you will connect to it: