Importing the self-signed certificate itself into the root certificate store is actually an okay solution for this, assuming it's done properly (no CA bit set).
(obviously, that's not what they did)
(obviously, that's not what they did)
Had the same story 3 days ago on the front page for a different software: https://news.ycombinator.com/item?id=15982161
The problem was what they did before: They had a publicly trusted cert for their local webserver.
Why ask users to import the certificate into the root certificate store instead of packaging the self-signed certificate with and specially loading it from the application. That seems easier from the users' perspective and more secure as you aren't touching the global certificate store.
The problem in this case is not the cert in itself, the local webserver needs the private key. It also uses a non-local domain (bealocalhost.de or something akin to that) which resolved to 127.0.0.1. This is another design brainfart - it assumes that no webserver is running locally, the DNS is in no way protected, making it trivial for anyone who controls DNS to reroute that domain and since they have access to the key, MiTM is trivial. :sigh:
The real problem is they embedded and distributed secrets, instead of generating them. It's funny a game company can do security better than a software firm working for a government. It's sad that I'm not surprised.
I'd bet money that people developing this software knew this was a problem, but government regulation required they use an external CA instead of a self-signed cert because "self-signed certs are always less secure", and nobody was empowered to make this issue known or do something better.
PKI is complex, and certificate expiry is a major source of outages.