4 ms·

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

by worik 3y ago

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 => <FQDN>" (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 work for tools like curl, wget "openssl s_client", but not for browsers. (In my notes some place I am too lazy to go and read there is a reference to the RFC that documents that you do not have to use the subject/CN, mēh) There are other tools (than openssl) that do this to. Using this service means you really do not have a private network

WirelessGigabit 3y ago
I love this idea. Except I have devices on my network that don't allow me to do that. Company lock downs etc. So I just pull in stuff from LetsEncrypt.
- lolinder 3y ago
  As a rule I don't connect to my local services from my company laptop—it sits in the guest network isolated from the rest of the network.
  - saladdressing 3y ago
    [dead]
lolinder 3y ago
Caddy will do this for you as long as you don't give it an ACME config. It handles the root CA creation as well as all of the certificates for any domains that you define in the Caddyfile, so all you have to do is find the root CA it generates and install it on your devices.
- e12e 3y ago
  > all you have to do is find the root CA it generates and install it on your devices. Unfortunately that's the hard part - getting Firefox/chrome/edge/safari and is/libc/curl to all trust the ca. It's a little easier on Linux, but still convoluted. And with an actual trusted CA the trust is way too wide (every domain). Not to mention revocation lists and certificate renewals (and revocation s) ... Dedicated letsencrypt "internal" domain is probably the sweetspot for most uses these days. Maybe a serviceN.int.example.com where int.example.com allows for dynamic DNS updates/DNS challenges. I've been thinking about setting up powerdns/coredns/knotdns with rfc dynamic updates for a dedicated internal domain - but for now tailscale with magic DNS mostly fills the need (unfortunately not with ssl for all k8s internal services, "only" VPN).
  - e12e 3y ago
    As mentioned in the excellent documentation from TFA - I should probably use acme-dns for this: https://github.com/joohoi/acme-dns/ https://github.com/joohoi/acme-dns/ https://docs.getlocalcert.net/tips/validation-domain/#self-hosting https://docs.getlocalcert.net/tips/validation-domain/#self-h...
attentive 3y ago
What is often not straightforward is trusting this CA on every existing and future client.
- throwanem 3y ago
  Especially if it's an iPhone.
  - worik 3y ago
    > Especially if it's an iPhone. That was my exact problem, an why I learnt this. It is easy to install and easy to remove from an iOS device.
    - throwanem 3y ago
      I would love to know how! I've never had success with local CAs and self-signed certs on iPhone, despite going through the whole rigamarole of creating and installing an MDM profile with the trust root. Even after doing that, apps and Safari behave as if the certificate was untrusted. Is there some documentation you've successfully used and wouldn't mind pointing to?
      - doubled112 3y ago
        This has changed recently, because I did a lot of fighting with this at one point. Download the certificate, import/install it, and then do this: https://support.apple.com/en-us/HT204477 https://support.apple.com/en-us/HT204477
        throwanem 3y ago
        Thank you! This is new since the last time I tried setting up a CA for my home network, and it looks like just the ticket.
jart 3y ago
If you use the Redbean web server, I put a lot of thought into making local network SSL easy. https://redbean.dev/#ssl https://redbean.dev/#ssl Basically all you have to do is create a single key signing key which is installed on all your client devices. Then whenever you want to spin up a web server on any given host, you just give Redbean access to the key signing key, and it'll create RSA/ECDSA serving certificates automatically, which list all of the local system's hostnames and network IPs in the correct manner (which is a nightmare to figure out how to get OpenSSL to do). In fact you can even embed the key-signing key inside your Redbean so that when you SCP it to another machine and run it via SSH, it'll just do the right thing there as well, and Chrome won't shut it down. Or you could email your redbean single-file executable to a coworker, who just has to double click on the thing, and it'll start up a valid HTTPS server on their workstation which you can access, for easy local web dev collaborations.
- 8organicbits 3y ago
  Redbean may work well for a domain auto-registration idea I mentioned elsewhere [1]. I've been looking for an excuse to play with redbean. [1] https://news.ycombinator.com/item?id=36675925 https://news.ycombinator.com/item?id=36675925
8organicbits 3y ago
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]. Public CAs give you certificate transparency and you can subscribe to events to detect mis-issuance. Some hosted private CAs like AWS's offer logs [5], but DIY setups don't. Even still, there are a lot of folks happily using private CAs, they aren't the target audience for this initial release. [1] https://github.com/FiloSottile/mkcert/issues/302 https://github.com/FiloSottile/mkcert/issues/302 [2] https://github.com/cert-manager/cert-manager/issues/3655 https://github.com/cert-manager/cert-manager/issues/3655 [3] https://alexsci.com/blog/name-non-constraint/ https://alexsci.com/blog/name-non-constraint/ [4] https://github.com/Netflix/bettertls/issues/19 https://github.com/Netflix/bettertls/issues/19 [5] https://docs.aws.amazon.com/privateca/latest/userguide/security-logging-and-monitoring.html https://docs.aws.amazon.com/privateca/latest/userguide/secur...
- jart 3y ago
  Your private root CA can only be used maliciously if it's compromised. If you use certificate transparency to publicly leak all your local network administrative activities, then you won't need to worry about someone compromising your network because you've already compromised yourself.
  - captn3m0 3y ago
    The risk in both of theses is vastly different. A root CA leak is hard to detect, has tremendous consequences, and adding limitations to the cert (TLD/domain) don’t work across every OS. OTOH, leaking the existence of your private services (which are likely inaccessible over the internet for the general attacker) is a much smaller risk, and can be contained with wildcard certs as a workaround.
  - 8organicbits 3y ago
    Compromise of private CAs isn't always difficult. People store unencrypted keys on SharePoint or send them in email along with the password. There's also cases of rogue IT department staff using the private CA intended to be used for `*.corp` to MITM employee Internet traffic, so "compromise" isn't needed for harm to occur. For companies that do it right, yeah, the concern is minimal. I think the risk of leaking internal domain names is real, but overblown. If you find a vulnerable internal service via CT logs you still need to connect to the private network to exploit it. If you're connected to the private network, you could have enumerated subdomains many other ways. Early knowledge of vulnerable subdomains can speed up an attack or target selection, but this is still a two step process. Most subdomains are pretty boring anyway; it's not surprising to learn that $corp has subdomains like webmail, wiki, etc. These names don't leak version or brand information. I was playing with the idea of doing CT log poisoning, where you register and renew certificates for decoy subdomains along side your real subdomain names. If you add enough noise, CT logs are no longer useful for enumerating private subdomains.
nine_k 3y ago
This sounds very much like the famous HN comment saying that Dropbox is unnecessary because you can construct an analog using rsync and half-dozen other tools. It's like saying that having a chair is unnecessary because you have a log, an axe, a saw, etc, and can build a sit to your liking when need be. The thing is that when the need actually comes to be, you want a seat right now and of a known working kind, and strongly prefer a comfortable one. So thank the carpenter.
- worik 3y ago
  The thing is when you build a private network you want it to be private. The thing is when you are securing a network you are building things with powerful tools. Thing is using powerful tools can backfire badly.
KronisLV 3y ago
> 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 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!
- worik 3y ago
  > 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.
kelnos 3y ago
I've considered doing that for my home network, but if my local CA was ever compromised, someone would be able to generate certs for any site (such as my bank), and my devices would trust those certs if they were able to MitM me. Browsers don't support name constraints, so I couldn't restrict the CA to signing just my local domain. Yes, I know, I'm small potatoes, and that would require a very targeted attack, but the idea still bothers me.
- BeefWellington 3y ago
  My local CA is on a raspberry pi that is offline. :) However, my paranoia level is high.

by worik 3y ago

WirelessGigabit 3y ago

I love this idea. Except I have devices on my network that don't allow me to do that. Company lock downs etc. So I just pull in stuff from LetsEncrypt.

lolinder 3y ago
As a rule I don't connect to my local services from my company laptop—it sits in the guest network isolated from the rest of the network.
- saladdressing 3y ago
  [dead]

lolinder 3y ago

Caddy will do this for you as long as you don't give it an ACME config. It handles the root CA creation as well as all of the certificates for any domains that you define in the Caddyfile, so all you have to do is find the root CA it generates and install it on your devices.

e12e 3y ago
> all you have to do is find the root CA it generates and install it on your devices. Unfortunately that's the hard part - getting Firefox/chrome/edge/safari and is/libc/curl to all trust the ca. It's a little easier on Linux, but still convoluted. And with an actual trusted CA the trust is way too wide (every domain). Not to mention revocation lists and certificate renewals (and revocation s) ... Dedicated letsencrypt "internal" domain is probably the sweetspot for most uses these days. Maybe a serviceN.int.example.com where int.example.com allows for dynamic DNS updates/DNS challenges. I've been thinking about setting up powerdns/coredns/knotdns with rfc dynamic updates for a dedicated internal domain - but for now tailscale with magic DNS mostly fills the need (unfortunately not with ssl for all k8s internal services, "only" VPN).
- e12e 3y ago
  As mentioned in the excellent documentation from TFA - I should probably use acme-dns for this: https://github.com/joohoi/acme-dns/ https://github.com/joohoi/acme-dns/ https://docs.getlocalcert.net/tips/validation-domain/#self-hosting https://docs.getlocalcert.net/tips/validation-domain/#self-h...

attentive 3y ago

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

throwanem 3y ago
Especially if it's an iPhone.
- worik 3y ago
  > Especially if it's an iPhone. That was my exact problem, an why I learnt this. It is easy to install and easy to remove from an iOS device.
  - throwanem 3y ago
    I would love to know how! I've never had success with local CAs and self-signed certs on iPhone, despite going through the whole rigamarole of creating and installing an MDM profile with the trust root. Even after doing that, apps and Safari behave as if the certificate was untrusted. Is there some documentation you've successfully used and wouldn't mind pointing to?
    - doubled112 3y ago
      This has changed recently, because I did a lot of fighting with this at one point. Download the certificate, import/install it, and then do this: https://support.apple.com/en-us/HT204477 https://support.apple.com/en-us/HT204477
      - throwanem 3y ago
        Thank you! This is new since the last time I tried setting up a CA for my home network, and it looks like just the ticket.

jart 3y ago

If you use the Redbean web server, I put a lot of thought into making local network SSL easy. https://redbean.dev/#ssl https://redbean.dev/#ssl Basically all you have to do is create a single key signing key which is installed on all your client devices. Then whenever you want to spin up a web server on any given host, you just give Redbean access to the key signing key, and it'll create RSA/ECDSA serving certificates automatically, which list all of the local system's hostnames and network IPs in the correct manner (which is a nightmare to figure out how to get OpenSSL to do). In fact you can even embed the key-signing key inside your Redbean so that when you SCP it to another machine and run it via SSH, it'll just do the right thing there as well, and Chrome won't shut it down. Or you could email your redbean single-file executable to a coworker, who just has to double click on the thing, and it'll start up a valid HTTPS server on their workstation which you can access, for easy local web dev collaborations.

8organicbits 3y ago
Redbean may work well for a domain auto-registration idea I mentioned elsewhere [1]. I've been looking for an excuse to play with redbean. [1] https://news.ycombinator.com/item?id=36675925 https://news.ycombinator.com/item?id=36675925

8organicbits 3y ago

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]. Public CAs give you certificate transparency and you can subscribe to events to detect mis-issuance. Some hosted private CAs like AWS's offer logs [5], but DIY setups don't. Even still, there are a lot of folks happily using private CAs, they aren't the target audience for this initial release. [1] https://github.com/FiloSottile/mkcert/issues/302 https://github.com/FiloSottile/mkcert/issues/302 [2] https://github.com/cert-manager/cert-manager/issues/3655 https://github.com/cert-manager/cert-manager/issues/3655 [3] https://alexsci.com/blog/name-non-constraint/ https://alexsci.com/blog/name-non-constraint/ [4] https://github.com/Netflix/bettertls/issues/19 https://github.com/Netflix/bettertls/issues/19 [5] https://docs.aws.amazon.com/privateca/latest/userguide/security-logging-and-monitoring.html https://docs.aws.amazon.com/privateca/latest/userguide/secur...

jart 3y ago
Your private root CA can only be used maliciously if it's compromised. If you use certificate transparency to publicly leak all your local network administrative activities, then you won't need to worry about someone compromising your network because you've already compromised yourself.
- captn3m0 3y ago
  The risk in both of theses is vastly different. A root CA leak is hard to detect, has tremendous consequences, and adding limitations to the cert (TLD/domain) don’t work across every OS. OTOH, leaking the existence of your private services (which are likely inaccessible over the internet for the general attacker) is a much smaller risk, and can be contained with wildcard certs as a workaround.
- 8organicbits 3y ago
  Compromise of private CAs isn't always difficult. People store unencrypted keys on SharePoint or send them in email along with the password. There's also cases of rogue IT department staff using the private CA intended to be used for `*.corp` to MITM employee Internet traffic, so "compromise" isn't needed for harm to occur. For companies that do it right, yeah, the concern is minimal. I think the risk of leaking internal domain names is real, but overblown. If you find a vulnerable internal service via CT logs you still need to connect to the private network to exploit it. If you're connected to the private network, you could have enumerated subdomains many other ways. Early knowledge of vulnerable subdomains can speed up an attack or target selection, but this is still a two step process. Most subdomains are pretty boring anyway; it's not surprising to learn that $corp has subdomains like webmail, wiki, etc. These names don't leak version or brand information. I was playing with the idea of doing CT log poisoning, where you register and renew certificates for decoy subdomains along side your real subdomain names. If you add enough noise, CT logs are no longer useful for enumerating private subdomains.

nine_k 3y ago

This sounds very much like the famous HN comment saying that Dropbox is unnecessary because you can construct an analog using rsync and half-dozen other tools. It's like saying that having a chair is unnecessary because you have a log, an axe, a saw, etc, and can build a sit to your liking when need be. The thing is that when the need actually comes to be, you want a seat right now and of a known working kind, and strongly prefer a comfortable one. So thank the carpenter.

worik 3y ago
The thing is when you build a private network you want it to be private. The thing is when you are securing a network you are building things with powerful tools. Thing is using powerful tools can backfire badly.

KronisLV 3y ago

> 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 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!

worik 3y ago
> 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.

kelnos 3y ago

I've considered doing that for my home network, but if my local CA was ever compromised, someone would be able to generate certs for any site (such as my bank), and my devices would trust those certs if they were able to MitM me. Browsers don't support name constraints, so I couldn't restrict the CA to signing just my local domain. Yes, I know, I'm small potatoes, and that would require a very targeted attack, but the idea still bothers me.

BeefWellington 3y ago
My local CA is on a raspberry pi that is offline. :) However, my paranoia level is high.