Certificate url forward domain to ip adress with ports


Hi All,

it seems we have a pretty special configuration, although i was not thinking that this could be that tricky.

We have a fixed ip address with a normal router and behind a server. This server hosts several virtual machines with different web services (owncloud, openproject etc.)

To grant remote access with make a port forwarding to the local ip address and port 80 + 443.

For more comfort we also have a domain which has several subdomains which forward to each of these ports:


owncloud.our-company-url.net --> XXX.XXX.XXX.XXX:19000
openproject.our-company-url.net --> XXX.XXX.XXX.XXX.:19001

so we would like to have for each subdomain a lets encrypt certificate to get rid of the browser messages and, e.g. to use npm install from different ssl git url.

Unfortunately this seems not to work.

We tried url forwarding, an A record at the dns server but all the scripts from lets encrypt fail.

Is usage of lets encrypt in our scenario possible and if yes how could we achieve it.

Thanks in advance


Let’s Encrypt should be able to issue certificates for the names you mentioned such as “our-company-url.net” if you are able to demonstrate control over those names

It can be helpful to show the output from a failed attempt, so that people can give you more specific advice, but while I’m here let me give you an overview of your three ways to demonstrate control, so that you can consider which will be easiest for you, both initially and then every few months for renewal.

In every case, these challenges will be performed by Let’s Encrypt which is out on the public Internet, so it’s not enough to be able to pass them from inside your office, it must work from outside too. You probably knew that, but just to be sure.

  1. HTTP access of a URL chosen by Let’s Encrypt which should give a response only you (the subscriber) and Let’s Encrypt will know. You can automate this if you can arrange for a file created by certbot (or other client software) to be accessible via HTTP (note not HTTPS, although it’s OK if there’s an HTTP redirect to an HTTPS server before the actual answer is given)

  2. TLS-SNI - here Let’s Encrypt connects to your HTTPS server, but rather than asking for the real name of your server it asks for a fake name ending .invalid and the server needs to know how to answer. The certbot “standalone” mode can do this, but probably your setup makes it tricky to arrange

  3. DNS. You need to provision a DNS TXT record in your public DNS system with contents chosen by Let’s Encrypt. This option is easiest if the rest of your systems are complicated to mess with but you have an easy, programmatic way to modify DNS records.


Hi, thanks for the answer and explanations. I think a TXT DNS record seems to be best for our setting. Does this need to be updated every three month or can this still be automated?


Just digged a little bit deeper into the problem. It seems that the lets encrypt scripts does only works with ports 80 & 443, while i am using other ports. Is there any way to get around this?


The certificates can be used with any port you like, but in order to perform the domain ownership validation and get the certificate in the first place, you need either port 80, 443 or the DNS-based challenge. Relevant section from the FAQs:

Can I issue a certificate if my web server doesn’t listen on port 80?

Yes, using the TLS-SNI-01 challenge, for example with Certbot’s apache or standalone plugin. In order to solve a HTTP-01 challenge, your web server must listen on port 80.

Can I issue a certificate without exposing any ports?

Yes, using the DNS-01 challenge. Certbot currently doesn’t support this challenge type, but many other clients do.


The DNS challenge will need to be passed fresh periodically, maybe about once per year and between those passes a client can rely on saying basically “Hey, this subscriber already passed a challenge for this name recently” to get its renewal certificates (every 2-3 months) but you may need to check the Let’s Encrypt client software you’re considering knows how to do that and won’t just start fresh every time you renew.

Nevertheless it makes sense to try to automate everything if you have the option. I think plenty of people who used SSL certificates before Let’s Encrypt came along would be able to say that if you need to do manual steps, somebody will be sure to forget what they are, which is a pain.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.