Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Easy HTTPS for your private networks

getlocalcert.net

Post reply on HN
Print view View original

31–40 of 126 posts

Re: Easy HTTPS for your private networks

#31

Post by 8organicbits »

esbeeb wrote: post #25
Humphrey wrote: post #21

Or, it's super easy to roll your own using letsencrypt. 1. Buy your own public domain (such as companyname.dev) 2. Setup a LetsEncrypt wildcard certificate with DNS validation 3. Update your /etc/hosts to something like `127.0.0.1 companyname.dev` We have this working with multiple developers, each renewing their certificates themselves. Works great, it's simple, and don't need to trust an extra third party.

Last time I checked, those wildcard LetsEncrypt certs take more work to get, like passing a DNS-based TXT record challenge. Then once you have the wildcard certs, they only last 3 months. Once obtained, they can manually be copied into the LAN using a tool like wormhole. There's a lot of manual steps here which are far harder than how certbot will auto-renew certs when in the cloud - usually requiring no manual inter…

One of my inspirations for getlocalcert is a tool to make DNS-01 easier.

acme-dns let's you add a CNAME to another DNS zone, which let's you issue certificates for the former domain name using a convenient API for the latter zone. Seriously read about it, it's awesome.

https://github.com/joohoi/acme-dns/

That tool is open source and self-hostable. getlocalcert also provides this feature, but as a hosted service. Choose the method you prefer.

https://docs.getlocalcert.net/tips/validation-domain/

Once DNS-01 is easy, wildcard certs are easy. Here's the docs for setting up a wildcard cert via getlocalcert: https://docs.getlocalcert.net/acme-clients/lego/

Re: Easy HTTPS for your private networks

#32

Post by octagons »

My preferred solution for this is a combination of Traefik and Smallstep StepCA. I run a collection of tools via Docker compose, and new certificates are issued automatically based on the hostname.

The only problem is that I have to maintain a list of DNS entries for the StepCA container as extra hosts. I haven’t found an elegant solution for this part.

Re: Easy HTTPS for your private networks

#33

Post by mthoms »

tandav wrote: post #26

Side question: Does anyone know a simple caddy-like solution, but for non-HTTP traffic? For example, I want automatic SSL certificates for redis, mongodb, postgresql.

Caddy can act as a proxy for those services. It's ridiculously easy to set-up.

  mongo.mydomain.com {
    reverse_proxy 127.0.0.1:27017
  }

Re: Easy HTTPS for your private networks

#34

Post by seiferteric »

Cool, but as others said fairly easy to do on your own already. Sort of related but a problem I have been trying to solve is, how to create a trusted certificate for a new device on a private network automatically without any configuration? For example, imagine you are turning up a new router or switch with a Web UI for management. Traditionally this is served on http initially and you can optionally install a cert and enable https. It would be nice to have a way to have this happen automatically to obviate the need for http at all. Also consider that this private network may not be connected to the internet at all and so can't rely on outside servers.

I was kicking around the idea for an rfc that would be something like this. Your DHCP server would have an option to act as a CA (or point at one), with ACME protocol enabled. Then, you add DHCP option fields telling clients to trust this new CA certificate, but only for hosts on this local network (to avoid being able to MITM outside connections). Then clients on this network would be able to request certificates from the CA using ACME automatically and others on the network would automatically trust them assuming support for this standard was added the OS or browsers etc.

Re: Easy HTTPS for your private networks

#35

Post by smarkov »

housemusicfan wrote: post #15
abound wrote: post #9

Earlier quoted context omitted.

Doesn't that require being able to add your root CA on each device you access the application from? That can be a chore in some cases, esp when you want to share the application with others. For services I host on my Tailscale/Headscale network, I just use DNS challenges. With Cloudflare and Caddy, it's as straightforward as adding: tls { dns cloudflare {env.CLOUDFLARE_AUTH_TOKEN} } to the site's configuration in the…

This is a poor solution to a non-problem. 99% of "private networks" don't need HTTPS for most things, full-stop. Those that do, the correct solution is to deploy a private CA and use internal DNS. The implication being you do not trust your network. So the solution is to.....use public DNS and Let's Encrypt garbageware and leak details of your internal network so you can pretend you're now more secure because the caf…

> use public DNS and Let's Encrypt garbageware and leak details of your internal network

Wildcard letsencrypt + internal DNS means you don't leak anything and you don't have to deal with the awkwardness of installing certificates.

Re: Easy HTTPS for your private networks

#36

Post by attentive »

worik wrote: post #16

This is unnecessary It is straightforward to create your own Root CA and use it to sign certificates for your private network, using openssl. Ensure that you implement the V3 extensions with @altnames, for the certificates you issue, with a "DNS => " (or you can use an IP address instead of FDN. I have not experimented with that). .local domain names work fine If you do not implement "@altnames" the certificate will…

What is often not straightforward is trusting this CA on every existing and future client.

Re: Easy HTTPS for your private networks

#37

Post by 8organicbits »

seiferteric wrote: post #34

Cool, but as others said fairly easy to do on your own already. Sort of related but a problem I have been trying to solve is, how to create a trusted certificate for a new device on a private network automatically without any configuration? For example, imagine you are turning up a new router or switch with a Web UI for management. Traditionally this is served on http initially and you can optionally install a cert a…

You can get somewhat close to that with getlocalcert. When the device first boots, it calls the getlocalcert API to register a free, anonymous domain name (negative: its a UUID domain, ugly). You'd need outbound connections to api.getlocalcert.net and an ACME certificate authority (Let's Encrypt) to issue a ccertificate. When the user connects to " rel="nofollow noreferrer">http:// it redirects to .localcert.net" rel="nofollow noreferrer">https://.localcert.net, which the browser trusts since the cert is from a public CA. No need to manually trust a cert. The user would bookmark it and all future use is HTTPS-only.

If I see usage like this, there's ways I can make this cleaner.

Re: Easy HTTPS for your private networks

#38

Post by byteknight »

seiferteric wrote: post #34

Cool, but as others said fairly easy to do on your own already. Sort of related but a problem I have been trying to solve is, how to create a trusted certificate for a new device on a private network automatically without any configuration? For example, imagine you are turning up a new router or switch with a Web UI for management. Traditionally this is served on http initially and you can optionally install a cert a…

Sounds like you're describing a process similar to SCP over HTTPs. That is available (albeit windows hosted) and fully functional across any client OS.

Re: Easy HTTPS for your private networks

#39

Post by selcuka »

mthoms wrote: post #33
tandav wrote: post #26

Side question: Does anyone know a simple caddy-like solution, but for non-HTTP traffic? For example, I want automatic SSL certificates for redis, mongodb, postgresql.

Caddy can act as a proxy for those services. It's ridiculously easy to set-up. mongo.mydomain.com { reverse_proxy 127.0.0.1:27017 }

> but for non-HTTP traffic?

Doesn't this only work for HTTP too? It may work with MongoDB because it talks HTTP through TCP 27017, but PostgreSQL, for example, has a proprietary protocol on TCP 5432.

Re: Easy HTTPS for your private networks

#40

Post by linsomniac »

schlarpc wrote: post #13

Somewhat related - I made a bridge server [1] that lets ACME clients use standard RFC2136 to solve DNS-01 challenges for internal names without them needing credentials for the actual DNS backend (Route 53 in my case). [1] https://github.com/schlarpc/rfc2136_bridge/blob/main/src/rfc...

Interesting idea.

I have a workflow for creating AWS credentials that are restricted to doing the LetsEncrypt DNS challenges for just a single sub-domain, and that seems to be working well. https://linsomniac.gitlab.io/post/2019-09-10-letsencrypt-wit...

Post reply on HN