You install it wherever the TLS connection is terminated; it's not fundamentally different from the "static website" case.
So if your app servers themselves speak HTTPS (perhaps behind a TCP-level load balancer), then they need to have the server's certificate/key (and they will perform validation of client certificates as well). For example, Gunicorn in the Python (WSGI) world can handle TLS all by itself.
At the same time, it's also common for the load-balancer or reverse-proxy to perform TLS termination on behalf of an HTTP-only app server. So if your app is behind Nginx, then you can allow Nginx to handle TLS. (If an HTTP-level reverse proxy is used, then it unavoidably has to do TLS as well, otherwise it couldn't do its job of handling the HTTP requests.)
And plenty of websites hosted via Apache or Nginx are not static – millions of sites and APIs use dynamic interpreters hosted directly within the webserver, such as mod_php for Apache or ASP.NET for IIS, and just as many use Apache/Nginx as a frontend for FastCGI-based applications such as php-fpm. So if you have a dynamic site hosted via Apache using PHP, it's still Apache that does everything, TLS included.