4 ms·

Replace self-signed certs with a self-signed CA? Now you're just moved the problem, and you'll still have challenges with modern mobile OSes. If you're going

by luma 3y ago

Replace self-signed certs with a self-signed CA? Now you're just moved the problem, and you'll still have challenges with modern mobile OSes. If you're going through all the effort to instrument everything with certbot, why not just use LE and get a real cert?

Arch-TK 3y ago
People don't want their internal infrastructure to end up in CT logs.
- _factor 3y ago
  Can confirm. Stood up a test site with SSL on a subdomain recently. Within 2hrs of let's encrypt registration, I was getting hits on file from around the globe with no index defined yet.
- niij 3y ago
  Let's Encrypt supports wildcard certificates now.
  - Arch-TK 3y ago
    Wildcard certificates are sub-optimal. I have a personal policy of not using them. They become very much like a "shared secret" which you have to properly manage. I know LANs don't need world class security, but as someone who works in security I like to play around with doing things right.
- mavhc 3y ago
  Make a LE wildcard cert
- noirscape 3y ago
  DNS-01 + a wildcard SSL cert takes care of that unless you need third level domain names. I think the last time I issued non-wildcard SSL certs for my domains was when I was still making the mistake of self-hosting email and the entire setup was a rickety mess.
  - ahlCVA 3y ago
    This is a frequently-touted solution, but now somebody compromising printer.lan.example.com can impersonate auth.lan.example.com, which isn't great either.
    - 8organicbits 3y ago
      One approach is to put the wildcard certificate on a proxy. Clients connect to the proxy, and see a valid TLS certificate. The connection from the proxy can use whatever you'd like, including a self-signed certificate that you pin. You have the impersonation problem if the proxy is compromised, but that's a smaller attack surface than "printer", etc.
    - noirscape 3y ago
      To be frank that's one of those things where it depends on how much you care about what gets compromised. For a purely internal homelab, the main use is to get software working; the HTTPS is only needed because modern browsers get upset about a compromised secure context if you don't, which leads to them disabling all sorts of random APIs. The actual security component is pretty much secondary for the usecase where you're dealing with devices that exist solely on an intranet - you're already gating off access by different means. Personally, the way I'd solve the problem in the situation where it'd be a problem is to not put auth on the same domain; auth would go to auth.secondexample.com. That's generally speaking the better choice to begin with due to browser weirdness regarding domain isolation (which is also why you often see software with CDNs use completely different domain names; reddit images being hosted on redd.it for example but also YouTube thumbnails being on ytimg. If they didn't, a maliciously formed file could read out browser storage for different subdomains).
    - throw0101b 3y ago
      > somebody compromising printer.lan.example.com can impersonate auth.lan.example.com Nope: one can setup ACLs so that the script that can update the records for printer.lan… cannot also do foo.lan… or any *.lan….
      - 3y ago
- vbezhenar 3y ago
  Why CT logs include plaintext domain? Isn't hashing it would be enough?
jasode 3y ago
>Replace self-signed certs with a self-signed CA? [...], why not just use LE and get a real cert? I went back and forth between self-signed CA vs LetsEncrypt. I liked the self-signed CA root because you can create end-entity certificates for internal ip addresses such as 192.168.1.13 instead of domain names. (No domain name purchase and no public DNS records pointing to 192.168.1.13 required.) The public SSL services like Let'sEncrypt and ZeroSSL can't issue certs for RFC1918 ip addresses -- for obvious reasons. On the other hand, I didn't want to import my custom CA root certificate into all 8+ devices around the house. (desktops+laptops+phones+tablets+etc.) So, Let'sEncrypt won in my case on that basis.
- luma 3y ago
  If you're going to the effort to run a CA, why not also run DNS? I say this as a guy who runs an internal CA and eventually just implemented LE due to all the problems with trusting internal CAs and getting that to work across all devices.

by luma 3y ago

Arch-TK 3y ago

People don't want their internal infrastructure to end up in CT logs.

_factor 3y ago
Can confirm. Stood up a test site with SSL on a subdomain recently. Within 2hrs of let's encrypt registration, I was getting hits on file from around the globe with no index defined yet.
niij 3y ago
Let's Encrypt supports wildcard certificates now.
- Arch-TK 3y ago
  Wildcard certificates are sub-optimal. I have a personal policy of not using them. They become very much like a "shared secret" which you have to properly manage. I know LANs don't need world class security, but as someone who works in security I like to play around with doing things right.
mavhc 3y ago
Make a LE wildcard cert
noirscape 3y ago
DNS-01 + a wildcard SSL cert takes care of that unless you need third level domain names. I think the last time I issued non-wildcard SSL certs for my domains was when I was still making the mistake of self-hosting email and the entire setup was a rickety mess.
- ahlCVA 3y ago
  This is a frequently-touted solution, but now somebody compromising printer.lan.example.com can impersonate auth.lan.example.com, which isn't great either.
  - 8organicbits 3y ago
    One approach is to put the wildcard certificate on a proxy. Clients connect to the proxy, and see a valid TLS certificate. The connection from the proxy can use whatever you'd like, including a self-signed certificate that you pin. You have the impersonation problem if the proxy is compromised, but that's a smaller attack surface than "printer", etc.
  - noirscape 3y ago
    To be frank that's one of those things where it depends on how much you care about what gets compromised. For a purely internal homelab, the main use is to get software working; the HTTPS is only needed because modern browsers get upset about a compromised secure context if you don't, which leads to them disabling all sorts of random APIs. The actual security component is pretty much secondary for the usecase where you're dealing with devices that exist solely on an intranet - you're already gating off access by different means. Personally, the way I'd solve the problem in the situation where it'd be a problem is to not put auth on the same domain; auth would go to auth.secondexample.com. That's generally speaking the better choice to begin with due to browser weirdness regarding domain isolation (which is also why you often see software with CDNs use completely different domain names; reddit images being hosted on redd.it for example but also YouTube thumbnails being on ytimg. If they didn't, a maliciously formed file could read out browser storage for different subdomains).
  - throw0101b 3y ago
    > somebody compromising printer.lan.example.com can impersonate auth.lan.example.com Nope: one can setup ACLs so that the script that can update the records for printer.lan… cannot also do foo.lan… or any *.lan….
    - 3y ago
vbezhenar 3y ago
Why CT logs include plaintext domain? Isn't hashing it would be enough?

jasode 3y ago

>Replace self-signed certs with a self-signed CA? [...], why not just use LE and get a real cert? I went back and forth between self-signed CA vs LetsEncrypt. I liked the self-signed CA root because you can create end-entity certificates for internal ip addresses such as 192.168.1.13 instead of domain names. (No domain name purchase and no public DNS records pointing to 192.168.1.13 required.) The public SSL services like Let'sEncrypt and ZeroSSL can't issue certs for RFC1918 ip addresses -- for obvious reasons. On the other hand, I didn't want to import my custom CA root certificate into all 8+ devices around the house. (desktops+laptops+phones+tablets+etc.) So, Let'sEncrypt won in my case on that basis.

luma 3y ago
If you're going to the effort to run a CA, why not also run DNS? I say this as a guy who runs an internal CA and eventually just implemented LE due to all the problems with trusting internal CAs and getting that to work across all devices.