I am currently in the same situation of Arand as he described it here “How to do the challenge with a different port?”
Currently, external ports 80 a and 443 are forwarded to a VM running an Apache webserver. The situation on this machine is a bit itchy and led to the creation of a new VM which I administer.
An external company which in turn administers the IT infrastructure and firewall forwarded to my VM two external ports (let’s say 8080 and 8081) that I can supposedly use for HTTP and HTTPS.
The VM I am running is a blank slate so I can run caddy and bind it to ports 80\443 of the VM.
Issue is that by default caddy, following the Let’s Encrypt procedures, tries to make the challange on external ports 80 and 443 which, in this scenario, are forwarded to the Apache VM.
I’d like to know if the situation changed from 2017 when the above post was made, if not I’d like to understand better how I could proceed.
What I have already tried
As of now I run a home server for my own personal purposes and to make an application live and running asap I made the following:
Caddyfile on my home server:
subdomain.mydomain.dev {
proxy / companyip:8080 {
transparent
}
}
Caddyfile on company VM I administer — remember, above I point to the company public IP port 8080 because that port is forwarded to port 80 on the VM, so here I listen to port 80:
:80
root /var/www/myapplication
Clear downside is that the application is reachable at subdomain.mydomain.dev
instead of subdomain.companydomain.tld
Notes
If you can have that one machine forwarding traffic from 443 to your Caddy host instead, you’re golden - just disable the HTTP challenge with
-disable-http-challenge
to force LetsEncrypt to use TLS-SNI.
As suggested in the mentioned post I can’t do this as that Apache machine is kinda locked down and it seems that dialogue with its administrator is a dead end.
I am fine in using the tls
directive and specifying the cert\perm files, I’ve also looked into certbot to obtain the certificates but also that tool needs port 80.