Why does HTTP/2 force encryption? The HTTP/2 RFC (RFC 7540) also defines how to run HTTP/2 over plaintext.

Terminating HTTP/2 over TLS on a web frontend and then HTTP/2 over plaintext to the application servers sounds like a viable model.

In practice HTTP/2 forces encryption. For example Amazons ALB docs say "Considerations for the HTTP/2 protocol version: The only supported listener protocol is HTTPS." [1]

[1]: https://docs.aws.amazon.com/elasticloadbalancing/latest/appl...

My Apache server is fine speaking HTTP/2 over port 80:

  curl -v --http2 --http2-prior-knowledge http://localhost
  * Connected to localhost (::1) port 80 (#0)
  * Using HTTP2, server supports multi-use
  * Connection state changed (HTTP/2 confirmed)
  * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
  * Using Stream ID: 1 (easy handle 0x559a7c6545c0)
  > GET / HTTP/2
  > Host: localhost
  > user-agent: curl/7.74.0
  > accept: */*
  > 
  * Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
  < HTTP/2 301 
  < date: Fri, 06 Aug 2021 11:16:05 GMT
  *snip*

Sadly none of the services that I reverse proxy through Apache support HTTP/2..

It make sense that internet facing clients and servers only support HTTP/2 over TLS. But that is different for internal connections or debug tools.

If you're running microservices, won't you be running them on a platform?

If on Kubernetes, just install cert-manager. Or if using FaaS, your platform will already do TLS termination, no?

That assumes your application can connect to the internet and can be accessed from the internet. There is a vast array of offline-only kubernetes clusters.

You can still of course use self-signed certificates (or setting up your own "CA"), but you'll hit other problems related to runtime certificate reloads and so on. It's still a lot of work to enable SSL for fully offline services.

On kubernetes, cert-manager might get certificates for you, but you'll still need to make sure the application correctly reloads those certs (many application frameworks have no way to reload a certificate at runtime).

Your reverse proxy can handle the TLS termination. Nginx or Traifik or whatever.

Besides, if you're doing microservices, whatever is managing them should be able to restart them gracefully. No need for reload as such.