Server behind firewall, no DNS control

Trying to get a certificate for a server (A) behind a company firewall. Need a certificate in order to create internal https services:

  • Server A has public name/IP address
  • Server A is accesible (from outside the company) only through port 23
  • Have root access on server A
  • Have no access to firewall/DNS

In order to acomplish any challenge, I could use another server (B) with slightly more openness:

  • Server B has public name/IP address
  • Server B is accesible (from outside the company) through ports 23 & 80
  • Have root access to server B

Is there any challenge that can be

Thanks!

1 Like

But does server B have "access" one way or the other for the hostname of server A?

Because if you want a certificate for server A, you'd either need port 80 open to server a or access to the DNS zone of that hostname. You can use CNAMEs for the dns-01 challenge, so that access could also be once. You could "redirect" the ACME challenge for the hostname of server A to a different hostname on for example, server B (or C) where you do have access to the DNS zone.

1 Like

One variant of the CNAME option is to permanently delegate _acme-challenge.servera.example.com to a completely external DNS zone which you can programmatically access.

You can see the general pattern in action here, but there's certainly multiple client options if you want to try that approach.

Downside is that it requires you to delegate a zone from your domain to an external DNS host, just for the purpose of the ACME DNS challenge.

There's an even more specific version of this: acme-dns. There's a hosted auth.acme-dns.io service if you want to give it a trial run without setting up an external DNS zone.

1 Like

Given that constraint... and:

The only thing left is obtaining a cert via http auth for any other name that resolves to the external IP of Server B.

This of course may be difficult to use as Server A will then be using a cert issued to Server B.
But...
ANY name means ANY name.
So... any FQDN (even via a DDNS system) could be used to obtain cert via an alias name and that cert could be then used within the internal network without causing name/IP confusion on Server A with Server B.