10 ms·

I went with DNS based Let's Encrypt for internal certificates, since I'm okay leaking my internal DNS names. > An obvious downside of this is having to guard a

I went with DNS based Let's Encrypt for internal certificates, since I'm okay leaking my internal DNS names. > An obvious downside of this is having to guard a bunch of secrets and the need to rotate the host certificates yearly – because Apple says so. The guarding secrets thing makes me too uncomfortable with managing my own CA. I'm sure it'd be fine, but since there are other equivalent and safer ways to do it.. Name constraints are a thing in the spec for restricting your CA to specific domains (which is amazing,) but browser/etc support was crappy when I looked at it and maybe getting better? I don't understand why name constraints aren't implemented everywhere. Unless an enterprise environment is doing TLS inspection, name constraints are a way saner implementation.

hnarn 3y ago
> I went with DNS based Let's Encrypt for internal certificates, since I'm okay leaking my internal DNS names. Lets Encrypt offers wildcard certificates, there is no reason to have internal DNS records exposed.
wejn 3y ago
Thanks, I've incorporated the name constraints into the article now. (it is indeed supported by Apple and FF just fine)
- NegativeK 3y ago
  Very nice!
aberoham 3y ago
Did you use elliptic curve instead of RSA?
fiddlerwoaroof 3y ago
The one thing you can’t do with Let’s Encrypt is generate a certificate with a CN of localhost which, since browsers are getting really picky about mixed HTTP/HTTPS content, is a real issue with local development using certain web features.
- xg15 3y ago
  > is a real issue with local development using certain web features. Is it? I thought browsers treat localhost/127.0.0.* specifically as if it were served over https, even if it isn't - otherwise, you could basically forget developing anything locally. Is there any feature which doesn't treat localhost as a secure origin? I figure you can always buy a hostname, get a cert using the DNS-01 challenge, then resolve the domain to 127.0.0.1 though - or getting back to the OP and running a custom CA.
  - fiddlerwoaroof 3y ago
    I have a dashboard I run via nginx on localhost that makes a bunch of requests to various https endpoints. It definitely doesn’t just work unless you have a trusted SSL certificate and run localhost as HTTPS
    - xg15 3y ago
      Huh, that's odd. Gonna test this as well then.
      - cpach 3y ago
        I think it’s the mixing of HTTP and HTTPS that most browsers doesn’t like. If you develop locally and it’s only HTTP with no HTTPS, then I think it works.
        xg15 3y ago
        I always thought that "mixed content" was defined as mixing "secure" and "insecure" origins (where a "secure origin" could be either https://something https://something or http://localhost http://localhost) and not literally mixing http and https urls. But this would explain the problem. To my knowledge, https on loopback doesn't give you any kind of added security: Everything with enough privileges to capture the encrypted packets on loopback also has enough privileges to just capture the unencrypted memory directly. And "localhost" is also a single "domain", so a cert wouldn't even give you the ability to distinguish between different origins (as other ports or hostnames that resolve to 127.0.0.1 would do) So it's just some buerocratic hoops to jump through to satisfy browsers. Edit: I remember reading about some objection that the "localhost" domain could be resolved to something other than 127.0.0.1, either through the hosts file or through a faulty DNS resolver. I think those objections were addressed in the "let localhost be localhost" proposal which mandated that the hostname "localhost" must be hardwired to 127.0.0.1 in the OS/browsers/resolvers etc and must never be permitted to point to anything else. But maybe this proposal didn't gain traction and so browsers are defending against such rebound localhost domains. In that case, I'd try and check if "http://127.0.0.1 http://127.0.0.1" works, as the IP address can't be rebound in the same way as the hostname. Edit2: And of course there is the issue with everything that is defined on top of TLS itself, e.g. ALPN and HTTP2. If you want to test anything involving that, you'll of course need to run TLS on localhost and are gonna need a cert too.
woodruffw 3y ago
> I don't understand why name constraints aren't implemented everywhere. They have weird semantics, especially in scenarios with multiple prospective validation paths: path `EE -> ICA' -> ICA'' -> TA` might result in different name constraints than `EE -> ICA' -> ICA''' -> TA`, resulting in hard-to-debug validation errors (or successes) depending on the user's trust store state. (I don't believe that's why Chrome doesn't support them, however. Chrome's stated reason[1] is that they don't support them on user roots because RFC 5280 doesn't require them to, which is IMO a correct reading of the spec.) [1]: https://bugs.chromium.org/p/chromium/issues/detail?id=1072083 https://bugs.chromium.org/p/chromium/issues/detail?id=107208...
mirchiseth 3y ago
I used to have my own local root CA as well but now trying the Let's Encrypt with DNS-01. What is the easiest combination of software to try it? I have failed miserably trying Opnsense + ACME client plugin + Cloudflare DNS + HAProxy / NGinx. I would get 100% ssllabs certs but somehow the reverse proxy won't forward to internal services. Next I am gonna go caddyserver for reverse proxy as it has SSL with LE inbuilt. Let's see.
- petronio 3y ago
  I've had a lot of success with https://github.com/dehydrated-io/dehydrated https://github.com/dehydrated-io/dehydrated . It exposes the different parts of the process (deploy challenge to DNS, deploy cert to filesystem, etc) as hooks, so it's pretty easy to integrate with anything and however you want, if you don't mind writing a bit of bash. There's a few scripts out there that use Cloudflare that you can use as well.
- psd1 3y ago
  I found LE + CF DNS trouble-free. Dockerfile: ``` FROM certbot/certbot RUN pip3 install certbot-dns-cloudflare cloudflare ``` docker-compose.yml: ``` volumes: - ${CREDENTIALS_DIRECTORY:-.}/cloudflare.ini:/cloudflare.ini - ${STATE_DIRECTORY:-./certbot}/:/etc/letsencrypt/ - ${LOGS_DIRECTORY:-/var/log/certbot}/:/var/log/letsencrypt/ command: " \ certonly \ --non-interactive \ --agree-tos \ --email postmaster@foo.bar \ --preferred-challenges dns-01 \ --dns-cloudflare \ --dns-cloudflare-credentials /cloudflare.ini \ --dns-cloudflare-propagation-seconds 30 \ -d foo.bar,*.foo.bar" ```
- cpach 3y ago
  This ACME client looks promising, but I haven’t tried it yet: https://github.com/go-acme/lego https://github.com/go-acme/lego
- wejn 3y ago
  A friend of mine runs dns01 thusly: https://ipng.ch/s/articles/2023/03/24/lego-dns01.html https://ipng.ch/s/articles/2023/03/24/lego-dns01.html
- 3y ago
soraminazuki 3y ago
> Name constraints are a thing in the spec for restricting your CA to specific domains (which is amazing,) but browser/etc support was crappy It's well supported now. I use it and it works for OpenSSL, Firefox, and Safari. Personally, I don't think there's much to gain from using public PKI for internal infrastructure. I already manage secrets on my personal devices and this is no different. Also, being able to issue certs for .home.arpa domains is nice too.

hnarn 3y ago

> I went with DNS based Let's Encrypt for internal certificates, since I'm okay leaking my internal DNS names. Lets Encrypt offers wildcard certificates, there is no reason to have internal DNS records exposed.

wejn 3y ago

Thanks, I've incorporated the name constraints into the article now. (it is indeed supported by Apple and FF just fine)

NegativeK 3y ago
Very nice!

aberoham 3y ago

Did you use elliptic curve instead of RSA?

fiddlerwoaroof 3y ago

The one thing you can’t do with Let’s Encrypt is generate a certificate with a CN of localhost which, since browsers are getting really picky about mixed HTTP/HTTPS content, is a real issue with local development using certain web features.

xg15 3y ago
> is a real issue with local development using certain web features. Is it? I thought browsers treat localhost/127.0.0.* specifically as if it were served over https, even if it isn't - otherwise, you could basically forget developing anything locally. Is there any feature which doesn't treat localhost as a secure origin? I figure you can always buy a hostname, get a cert using the DNS-01 challenge, then resolve the domain to 127.0.0.1 though - or getting back to the OP and running a custom CA.
- fiddlerwoaroof 3y ago
  I have a dashboard I run via nginx on localhost that makes a bunch of requests to various https endpoints. It definitely doesn’t just work unless you have a trusted SSL certificate and run localhost as HTTPS
  - xg15 3y ago
    Huh, that's odd. Gonna test this as well then.
    - cpach 3y ago
      I think it’s the mixing of HTTP and HTTPS that most browsers doesn’t like. If you develop locally and it’s only HTTP with no HTTPS, then I think it works.
      - xg15 3y ago
        I always thought that "mixed content" was defined as mixing "secure" and "insecure" origins (where a "secure origin" could be either https://something https://something or http://localhost http://localhost) and not literally mixing http and https urls. But this would explain the problem. To my knowledge, https on loopback doesn't give you any kind of added security: Everything with enough privileges to capture the encrypted packets on loopback also has enough privileges to just capture the unencrypted memory directly. And "localhost" is also a single "domain", so a cert wouldn't even give you the ability to distinguish between different origins (as other ports or hostnames that resolve to 127.0.0.1 would do) So it's just some buerocratic hoops to jump through to satisfy browsers. Edit: I remember reading about some objection that the "localhost" domain could be resolved to something other than 127.0.0.1, either through the hosts file or through a faulty DNS resolver. I think those objections were addressed in the "let localhost be localhost" proposal which mandated that the hostname "localhost" must be hardwired to 127.0.0.1 in the OS/browsers/resolvers etc and must never be permitted to point to anything else. But maybe this proposal didn't gain traction and so browsers are defending against such rebound localhost domains. In that case, I'd try and check if "http://127.0.0.1 http://127.0.0.1" works, as the IP address can't be rebound in the same way as the hostname. Edit2: And of course there is the issue with everything that is defined on top of TLS itself, e.g. ALPN and HTTP2. If you want to test anything involving that, you'll of course need to run TLS on localhost and are gonna need a cert too.

woodruffw 3y ago

> I don't understand why name constraints aren't implemented everywhere. They have weird semantics, especially in scenarios with multiple prospective validation paths: path `EE -> ICA' -> ICA'' -> TA` might result in different name constraints than `EE -> ICA' -> ICA''' -> TA`, resulting in hard-to-debug validation errors (or successes) depending on the user's trust store state. (I don't believe that's why Chrome doesn't support them, however. Chrome's stated reason[1] is that they don't support them on user roots because RFC 5280 doesn't require them to, which is IMO a correct reading of the spec.) [1]: https://bugs.chromium.org/p/chromium/issues/detail?id=1072083 https://bugs.chromium.org/p/chromium/issues/detail?id=107208...

mirchiseth 3y ago

I used to have my own local root CA as well but now trying the Let's Encrypt with DNS-01. What is the easiest combination of software to try it? I have failed miserably trying Opnsense + ACME client plugin + Cloudflare DNS + HAProxy / NGinx. I would get 100% ssllabs certs but somehow the reverse proxy won't forward to internal services. Next I am gonna go caddyserver for reverse proxy as it has SSL with LE inbuilt. Let's see.

petronio 3y ago
I've had a lot of success with https://github.com/dehydrated-io/dehydrated https://github.com/dehydrated-io/dehydrated . It exposes the different parts of the process (deploy challenge to DNS, deploy cert to filesystem, etc) as hooks, so it's pretty easy to integrate with anything and however you want, if you don't mind writing a bit of bash. There's a few scripts out there that use Cloudflare that you can use as well.
psd1 3y ago
I found LE + CF DNS trouble-free. Dockerfile: ``` FROM certbot/certbot RUN pip3 install certbot-dns-cloudflare cloudflare ``` docker-compose.yml: ``` volumes: - ${CREDENTIALS_DIRECTORY:-.}/cloudflare.ini:/cloudflare.ini - ${STATE_DIRECTORY:-./certbot}/:/etc/letsencrypt/ - ${LOGS_DIRECTORY:-/var/log/certbot}/:/var/log/letsencrypt/ command: " \ certonly \ --non-interactive \ --agree-tos \ --email postmaster@foo.bar \ --preferred-challenges dns-01 \ --dns-cloudflare \ --dns-cloudflare-credentials /cloudflare.ini \ --dns-cloudflare-propagation-seconds 30 \ -d foo.bar,*.foo.bar" ```
cpach 3y ago
This ACME client looks promising, but I haven’t tried it yet: https://github.com/go-acme/lego https://github.com/go-acme/lego
wejn 3y ago
A friend of mine runs dns01 thusly: https://ipng.ch/s/articles/2023/03/24/lego-dns01.html https://ipng.ch/s/articles/2023/03/24/lego-dns01.html
3y ago

soraminazuki 3y ago

> Name constraints are a thing in the spec for restricting your CA to specific domains (which is amazing,) but browser/etc support was crappy It's well supported now. I use it and it works for OpenSSL, Firefox, and Safari. Personally, I don't think there's much to gain from using public PKI for internal infrastructure. I already manage secrets on my personal devices and this is no different. Also, being able to issue certs for .home.arpa domains is nice too.