It's possible that they're now telling the firewall to block sites based on SNI or IP address, which is separate from the DNS mechanism.

If you know the correct IP address for a site, you can use curl or openssl to connect to the blocked site by IP address (but still sending SNI), like

  openssl s_client -connect 93.184.215.14:443 -servername example.com

You can also try not sending SNI, which will remove one means that the firewall might be using to block your connection, but will also likely make the connection not work for server-side reasons if it's hosted on a shared server or CDN.

  openssl s_client -connect 93.184.215.14:443 -noservername

Once you're connected, you can speak the HTTP protocol to the server manually:

  GET / HTTP/1.1
  Host: example.com
  Connection: close

and see what HTML home page content you get.

The output from the openssl s_client command will also show what certificate(s) were sent to you by the other end, and you can look at them using the openssl x509 command for more details about their contents. But you can see very quickly whether the purported issuer is Fortinet or a public certificate authority.

The curl version looks like

  curl -v --resolve example.com:443:93.184.215.14 https://example.com/

There you're telling it what IP address to use (rather than querying DNS for it).

> Is this some kind of MITM-Attack on me (I do not remember having had to install any special certificates, but I do not know how to check this)?

If the MITM attack were successful, you would not get a certificate error. The certificate error is the intended result of a failed attack, because it shows that you did not get a secure connection to the site you were trying to reach.

> Is there a convenient way to bypass this (i. e. not Tor et al.)?

If you have an account on a Unix server elsewhere, you can use ssh -D to create a local SOCKS proxy that forwards web requests through the remote server (assuming that the network doesn't also prevent you from making SSH connections to the server!).