Is this even possible?

So we've got domain and webhosting package that is secured with LetsEncrypt. And we've also got internal websites running on the LAMP stack that are only available to our local network. We have been using local host entries on our machines or the direct IP address of the server to access the local site.

I have set up a subdomain on our public domain (internal.domain.com) and that points to an internal IP address in our network (192.168.0.200), I have copied over the site.conf file so that it receives the request properly, this is working just fine, but even though it's probably unnecessary to secure the internal site with HTTPS I feel like I want it that way.

My experience with LetsEncrypt is minimal, but I have used their script wizard thing to set it up before, but never in this kind of situation. What would my internal subdomain.conf file need in it in order to use LetsEncrypt in this manner?

Can I somehow re-use the certificate on our public domain even though the IP addresses are way different? Or should I just get a new cert through LetsEncrypt for our local traffic?

Any suggestions or tips in the right direction mucho appreciated.

I'd assume someone here knows how to use a certificate locally but I do know there is a way to make and use/import self signed certificates that might also work.

1 members found this post helpful.

The Let's Encrypt servers need to be able to resolve your domain and access a temporary verification file - that obviously doesn't work for non-public domains.

Surprised to find this was NOT listed in the Let's Encrypt FAQ, but they do have documentation on generating self-signed certificates.

1 members found this post helpful.

LetsEncrypt now supports wildcard sub-domain names which will work on your internal network if generated for an externally visible parent domain.

I recently considered (but did not actualy try) setting up a temporary DNS record for a sub-domain just to generate and renew the certs, then use internal DNS or hosts file for internal machines to resolve the internal address.

Either way LE must be able to validate signing requests against a publicly visible domain.

1 members found this post helpful.

Oh yeah, I'd forgotten about wildcard certs - however the wildcard validation is DNS-based and not as simple as the HTTP-based method, so a self-signed certificate may or not still be preferred.

1 members found this post helpful.

There's a way to use a txt record for verification but that's kind of harder to automate. There's ways using dynamic DNS but that's a pain to setup as well, and imo also opens up an attack surface as someone could try to guess the key and change records.

I had a similar situation where I wanted a subdomain on a different host and I ended up just giving up and not using https for that one as it proved too complicated to try to get it to work properly.

1 members found this post helpful.