5 ms·

I've used https://smallstep.com/docs/step-ca/ https://smallstep.com/docs/step-ca/ as a CA internally, works well.

mojzu 5y ago
I've been using it too and it works well, particularly with Caddy to do automatic certificates with ACME where possible Plus all my services go through Tailscale, so although I am leaking internal hostnames via DNS, all those records point to is 100.* addresses
- chrisweekly 5y ago
  I'm a fan of both Caddy and Tailscale; any chance you have any devnotes to share on your setup?
  - mojzu 5y ago
    My notes were pretty rough but I've tried putting them into a gist here: https://gist.github.com/mojzu/b093d79e73e7aa302dde8e335945b2cd https://gist.github.com/mojzu/b093d79e73e7aa302dde8e335945b2... Which covers using step-ca with Caddy to get TLS certs via ACME for subdomains, and protecting internal services using client certificates/mtls I then install Tailscale on the host which is running the docker containers, and configure the firewall so that only other 100.* IP addresses can connect to ports 80/443/444. The combination of VPN+MTLS mitigates most of my worries about exposing internal subdomains on public DNS
    - chrisweekly 5y ago
      Awesome, thanks!
- Proven 5y ago
- dolmen 5y ago
  Tailscale+TLS: isn't it two strong layers of encryption?
  - mojzu 5y ago
    Yeah, it's probably overkill but I think the multiple layers would help in cases I misconfigured something or if an account someone uses to log into Tailscale was compromised. For example when I ran the containers on a linux host I discovered later docker was bypassing the firewall rules and allowing all connections, but it probably wasn't a big deal because of the MTLS (and the server was behind a NAT router anyway so it was only addressable within the local network)
mrweasel 5y ago
What I'd want is an internal CA, like step-ca, but have the certificates signed by a "real" CA, so I don't have to distribute my own root CA certificate.
- filleokus 5y ago
  The dream would truly be an internal CA backed by a publicly trusted subordinate cert (limited to the domain you control). But afaik that can’t happen until the Name Constraint Extension is enforced by “all” clients.
  - deleted 5y ago
    [deleted]
  - throw0101a 5y ago
    > But afaik that can’t happen until the Name Constraint Extension is enforced by “all” clients. For those curious about this extension, see RFC 5280 § 4.2.1.10: * https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10
- corobo 5y ago
  Wouldn't that allow you to issue certificates for Google.com? Correct me if I've misunderstood but for the sake of discussion pretend cert pinning doesn't exist, use another example domain if it's easier
  - mrweasel 5y ago
    I'm not a 100% sure how certificates work. What I imagined would be possible is having a certificate for mydomain.com, which can be used to sign certificates for subdomains.
    - mmalone 5y ago
      You can put "name constraints" on an intermediate that, in theory, can restrict the intermediate to only signing certs for a particular subdomain. In theory, name-constrained intermediate certificate for `.example.com` would have no more authority than a wildcard certificate for `.example.com`. But, name constraints are enforced by "relying parties" -- HTTPS/TLS clients & servers that are validating certificates and authenticating remote peers. In practice, there's a risk that a broken/misconfigured relying party would trust a cert for google.com signed by an intermediate that's name constrained / only trusted to issue for `*.example.com`.
gclawes 5y ago
I've been setting this up for my homelab under .home.arpa, seems to work pretty well so far.
metafunctor 5y ago
This is the correct answer ;) If you're going to run a serious internal network, you'll need the basic things like NTP, DNS, a CA server, and, yes, some kind of MDM to distribute internal CA certificates to your people. The real PITA is when you don't have these in place.

I've been using it too and it works well, particularly with Caddy to do automatic certificates with ACME where possible Plus all my services go through Tailscale, so although I am leaking internal hostnames via DNS, all those records point to is 100.* addresses

chrisweekly 5y ago
I'm a fan of both Caddy and Tailscale; any chance you have any devnotes to share on your setup?
- mojzu 5y ago
  My notes were pretty rough but I've tried putting them into a gist here: https://gist.github.com/mojzu/b093d79e73e7aa302dde8e335945b2cd https://gist.github.com/mojzu/b093d79e73e7aa302dde8e335945b2... Which covers using step-ca with Caddy to get TLS certs via ACME for subdomains, and protecting internal services using client certificates/mtls I then install Tailscale on the host which is running the docker containers, and configure the firewall so that only other 100.* IP addresses can connect to ports 80/443/444. The combination of VPN+MTLS mitigates most of my worries about exposing internal subdomains on public DNS
  - chrisweekly 5y ago
    Awesome, thanks!
Proven 5y ago
dolmen 5y ago
Tailscale+TLS: isn't it two strong layers of encryption?
- mojzu 5y ago
  Yeah, it's probably overkill but I think the multiple layers would help in cases I misconfigured something or if an account someone uses to log into Tailscale was compromised. For example when I ran the containers on a linux host I discovered later docker was bypassing the firewall rules and allowing all connections, but it probably wasn't a big deal because of the MTLS (and the server was behind a NAT router anyway so it was only addressable within the local network)

mrweasel 5y ago

What I'd want is an internal CA, like step-ca, but have the certificates signed by a "real" CA, so I don't have to distribute my own root CA certificate.

filleokus 5y ago
The dream would truly be an internal CA backed by a publicly trusted subordinate cert (limited to the domain you control). But afaik that can’t happen until the Name Constraint Extension is enforced by “all” clients.
- deleted 5y ago
  [deleted]
- throw0101a 5y ago
  > But afaik that can’t happen until the Name Constraint Extension is enforced by “all” clients. For those curious about this extension, see RFC 5280 § 4.2.1.10: * https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10
corobo 5y ago
Wouldn't that allow you to issue certificates for Google.com? Correct me if I've misunderstood but for the sake of discussion pretend cert pinning doesn't exist, use another example domain if it's easier
- mrweasel 5y ago
  I'm not a 100% sure how certificates work. What I imagined would be possible is having a certificate for mydomain.com, which can be used to sign certificates for subdomains.
  - mmalone 5y ago
    You can put "name constraints" on an intermediate that, in theory, can restrict the intermediate to only signing certs for a particular subdomain. In theory, name-constrained intermediate certificate for `.example.com` would have no more authority than a wildcard certificate for `.example.com`. But, name constraints are enforced by "relying parties" -- HTTPS/TLS clients & servers that are validating certificates and authenticating remote peers. In practice, there's a risk that a broken/misconfigured relying party would trust a cert for google.com signed by an intermediate that's name constrained / only trusted to issue for `*.example.com`.

gclawes 5y ago

I've been setting this up for my homelab under .home.arpa, seems to work pretty well so far.

metafunctor 5y ago

This is the correct answer ;) If you're going to run a serious internal network, you'll need the basic things like NTP, DNS, a CA server, and, yes, some kind of MDM to distribute internal CA certificates to your people. The real PITA is when you don't have these in place.