One server has public name and private name; one cert?

I have an Apache server running on Ubuntu 18.04. The server listens on a public address where I can get a LE cert just fine, but the same server is also listening on a private address where it has a different name.

Can I add the private name to the public name’s certificate?

I don’t want to set up a vhost that only listens on the private address but is otherwise identical to the public server because of the risk that it will get out of sync with the public server.

Thanks!

1 Like

If it is the same server and the vhosts are “otherwise identical”…
If the two names provide the same content, you could just use the one single name and one single vhost config with one single cert.

That will require outsmarting the internal systems that want to reach the outside IP.
For that you can use split DNS.
[where the Internet resolves the name to one IP, while your internal systems resolve the same name to another (internal) IP].
OR
A NAT trick called “hair pinning”.
[where the outbound NAT router hides your “outbound” connection to that “outside IP” but actually also translates the destination IP and forwards the connection to the “inside IP” of the server (never reaching the Internet - never leaving you local network).

But to answer your question…:

That depends entirely on what you mean by “private name”.
If you mean NOT even close to a real domain (like: server.internal-zone), then that won’t be possible using LE as your CA. [and probably not from any other CA either]
If you mean that the name is NOT resolvable via Internet DNS but it is in a real domain format of a domain you control (like: internal-server.myreal.zone), then you could get a cert for it.
[but you will have to use DNS authentication - HTTP auth will fail as there is no Internet HTTP site reachable]

3 Likes

Thanks for your detailed answer.

I have found a simpler way to make the TLS connection to the private side of the server. There are some compromises involved, but it’s still got TLS so it’s good enough.

2 Likes

That sounds… compromising!
[A word a security person doesn’t like to hear.]

As for the “solution”, there are 20 ways to skin a cat.
[never could grasp how that saying ever came about]

Like:
Using the local hosts file entries to “force” the IP of the “external” name to the “internal” IP.
[but that requires making a modification to each internal system that will be connecting to it - tedious!]

Perhaps you would care to share the “simpler way” (for the benefit of any/all future readers).
[at least in general terms]

This application has to be audited so I don’t want to get into the details. I do want to offer some help for the next person who needs a solution like this though. That person might even be future-me…

The hosts file is built automatically when the server is provisioned, so that’s where most of the magic happens. Originally I wanted to go through a reverse proxy (the public server) to the server that is providing the service I want. That service is using a self-signed certificate that includes the proxy’s domain name and the internal name.

Because the client and the service are on the same private network, the client is now connecting to the service directly. But since the service is using a self-signed cert, the client has to skip validation (that’s the compromise). In practical terms, if an attacker is on the private net, an unvalidated certificate is the least of our problems.

1 Like

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