Reverse proxy with apache and letsencrypt

[Cadencia]

SYSTEM INFORMATION
OS type and version:	Ubuntu Linux 20.04.3
Webmin version:	1.981
**Virtualmin version:**6.17-3
Related products version:	Apache version 2.4.4

---

Creating a reverse proxy worked flawlessly whilst everything was http://

But then we’ve got into a catch 22. If we allow the target server to contact letsencrypt for a cert, the proxy must pass through to .well-known transparently. Which it does. But then, to get a letsencrypt for the proxy, you need to stop it forwarding trffic to .well-known. Easy - just add a couple of lines to the proxy conf thus:
ProxyPass /.well-known/acme-challenge/ !
ProxyPassReverse /.well-known/acme-challenge/ !
and you can generate a letsencrypt cert for the proxy. Now - come refresh time, you have to tinker with the conf again.

I thought I’d be smart and create a little script to do all this, calling it from cron. Then I found the command I was dreaming of (generate-letsencrypt-cert) doesn’t exist, although the documentation and the virtualmin list-commands both insist it does exist.

So - I’m stumped. I don’t really want to re-invent the wheel. Any suggestions?

[unborn]

why complicated like this, you can have second server within your LAN and no SSL need it as it won’t leave your internal network…keep it in mind to block outside traffic to second server. or if that is not on your LAN network then use let’s encrypt request directly from second server

[Cadencia]

Needed because the target server performs other functions than serving http requests via apache, and these functions require the certificate - not a self-signed one. In these cases the server is reached by port forwarding from the router.
It would be helpful if, when getting a letsencrypt certificate, Virtualmin would check if the server was a reverse proxy and temporarily suspend the function, as I would do with my script. At least, provide the command line command as mentioned in the documentation. I’m sure it’s an oversight that could easily be fixed.