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

61–70 of 126 posts

Re: Easy HTTPS for your private networks

#61

Post by skrebbel »

bruce511 wrote: post #53
8organicbits wrote: post #43

Earlier quoted context omitted.

I've been pretty frustrated with how private CAs are supported. Your private root CA can be maliciously used to MITM every domain on the Internet, even though you intend to use it for only a couple domain names. Most people forget to set Name Constraints when they create these and many helper tools lack support [1][2]. Worse, browser support for Name Constraints has been slow [3] and support isn't well tracked [4]. P…

Let me put it this way; You might get away with installing your RootCA on your in-office PCs that you own. Good luck though getting me to install it on my (external contractor) laptop or my (employee) phone, or my (hosted) VMS machines. -you- may plan to only use the CA for good, but I don't trust you (and by extension all your IT staff, present, past, and future) to be angels.

Kinda nuts actually that you can’t install a Root CA and tell the OS “but only ever use it for these and these domains”. That would solve this elegantly.

Re: Easy HTTPS for your private networks

#63

Post by Humphrey »

8organicbits wrote: post #24
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.

Correct, a distinction with this service is that the domain names are free. One part of my decision to build this service was the fall of freenom (free domain names). Typically free domain name services are full of spam, malware, and other junk. getlocalcert seeks to avoid that as it only permits private network usage. My hope is that this model can serve that niche while avoiding abuse.

Yeah nice! Good to know

Re: Easy HTTPS for your private networks

#64

Post by hartmel »

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…

There is SCEP (https://en.m.wikipedia.org/wiki/Simple_Certificate_Enrollmen...) which allows that and is often found on network devices. You need a PKI which exposes a SCEP endpoint (ejbca or dogtag supports this). That the certificate is used as certificate for the HTTPS is up to the device implementation of the scep client or something else in the client though.

On servers, certmonger can do scep iirc. On private infrastructure, FreeIPA provides a packaged dogtag and you can create your own certificate profiles. Clients enrolled in freeipa have certmonger installed to refresh certificates.

Re: Easy HTTPS for your private networks

#65

Post by Humphrey »

klysm wrote: post #23
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.

Just at the whole domain or does each dev make their own subdomain?

We setup each project with it's own subdomain... so a /etc/hosts file would be something like

127.0.0.1 client7.companyname.dev our-amazing-product.companyname.dev postgres2.companyname.dev

So, then we can use the same settings, etc across devs.

Then each dev just runs the script to renew the script as they are needed (no need to share certs between devs)

Re: Easy HTTPS for your private networks

#66

Post by Humphrey »

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…

> Once obtained, they can manually be copied into the LAN using a tool like wormhole.

We haven't needed to copy the certs around the LAN. It works fine with dev's just individually running certbot renew as needed.

Yes, it tooks us a fair bit of fiddling around to work out how to do it, but final result is super simple. So I definitely would have considered a project like this in the past, but now we've got the scripts for it, it's pretty simple.

Re: Easy HTTPS for your private networks

#67

Post by KronisLV »

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…

> It is straightforward to create your own Root CA and use it to sign certificates for your private network, using openssl.

I guess I'll be the one to say it: many people, myself included, get intimidated by using OpenSSL. The CLI has a bunch of different options and dealing with the inherent complexity of a PKI makes it all a bit of a mess: where you try to find the right invocations for whatever you need to do online and even then aren't sure whether everything is done correctly.

At least that mirrors my own experience in the past and that of most folks I've talked to, both in private and prod projects. That's why I personally find software like Keystore Explorer actually decent for even things like running your own CA (probably for a small homelab, where you don't need automation): https://blog.kronis.dev/tutorials/lets-run-our-own-ca

And yet, even then I don't have the confidence that I've done things the "right" way, frankly probably not. That's even before you get into things like staying on top of CVEs and keeping everything updated - overall staying safe is very challenging. There's probably also the need to configure a web server, like Apache with SSLCACertificateFile and just plenty of things to go wrong along the way, especially if you need mTLS as well.

> Using this service means you really do not have a private network

That's a fair point, though!

Re: Easy HTTPS for your private networks

#68

Post by mgaunard »

The web/cloud world is so much nonsense. First, why do you even need HTTPS on a trusted network. Also if you want a trusted network, why not just use IPSec? HTTPS was specifically built to work over the Internet because it was too hard to switch from IPv4.

Second, if it's private, surely you can just use your own Certificate Authority, instead of paying a tax to be listed on someone else's Certificate Authority.

Re: Easy HTTPS for your private networks

#69

Post by worik »

KronisLV wrote: post #67
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…

> It is straightforward to create your own Root CA and use it to sign certificates for your private network, using openssl. I guess I'll be the one to say it: many people, myself included, get intimidated by using OpenSSL. The CLI has a bunch of different options and dealing with the inherent complexity of a PKI makes it all a bit of a mess: where you try to find the right invocations for whatever you need to do onli…

> many people, myself included, get intimidated by using OpenSSL

Unsurprising. It is intimidating. I think a bit old fashioned in that sense. Once was a time when men were men because they could configure sendmail. All a bit silly really.

There are other alternatives. Too few, tho. It took me a week to work it all out using OpenSSL.

Re: Easy HTTPS for your private networks

#70

Post by pravus »

mgaunard wrote: post #68

The web/cloud world is so much nonsense. First, why do you even need HTTPS on a trusted network. Also if you want a trusted network, why not just use IPSec? HTTPS was specifically built to work over the Internet because it was too hard to switch from IPv4. Second, if it's private, surely you can just use your own Certificate Authority, instead of paying a tax to be listed on someone else's Certificate Authority.

> First, why do you even need HTTPS on a trusted network.

PCI compliance among many other regulatory issues. You will be required to show that data is not only encrypted at rest but is encrypted through your entire transport chain regardless of any physical security. The threat model assumes that an attacker is able to temporarily access network resources undetected and can use simple sniffing tools to egress sensitive data. This will not be optional.

Post reply on HN