Add HTTPS support for an application running its own web server, under a non standard HTTP port

I have a server running Debian 10. It runs Apache 2.4 for a a web services accessible under https://example.com, thanks to a LetsEncrypt certificate.

But it also runs an app (Subsonic) which serves a web UI on port 4040, under its own webserver, as I have no vhost for it and as it is still accessible when Apache is stopped. So for now the app is accessible under HTTP on http://example.com:4040.

I know how to add SSL support for an Apache vhost, but how can I add HTTPS support for it this app, so that it is accessible on https://example.com:4040 or https://example.com:1234?

Also, should I use a different SSL certificate than the one I already have for this domain?

Add a reverse proxy in front of the app and configure HTTPS on this proxy. Conveniently, you have Apache running which can happily reverse proxy for you.

As it currently stands, you can't use port 4040 as that's already taken by the app, so unless you can change the app's port or get it to bind to localhost (127.0.0.1 etc) only, then you'll have to run this app on a different port. On that note, if you want to run this app over HTTPS there's no point leaving it still accessible by the insecure HTTP, so it would be better to configure this app to bind to localhost and have it accessible only through the reverse proxy.

You need the ProxyPass family of configuration options to create a reverse proxy. Here's an incomplete example:

Listen <Public IP address of server>:4040

<VirtualHost *:4040>

  Protocols h2 h2c http/1.1
  ServerName example.com

  SSLEngine On

  # LetsEncrypt certificates (if not configured in another file)
  #  SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
  #  SSLCertificateKeyFile /etc/letsencrypt/live/eample.com/privkey.pem
  #  Include               /etc/letsencrypt/options-ssl-apache.conf

  ProxyPreserveHost On
  ProxyRequests Off
  ProxyPass / http://127.0.0.1:4040/
  ProxyPassReverse / http://127.0.0.1:4040/

</VirtualHost>

Certificates need to have the hostname that the client uses to connect embedded within their Subject Alternative Names extension, therefore as you don't seem to be proposing a different host (example.com in both cases) you won't need a new certificate.