4 ms·

The internal TLS stuff built into Caddy is great, as is it's support for ACME. And using Anchor with Caddy has few extra advantages. We generate system & langua

The internal TLS stuff built into Caddy is great, as is it's support for ACME. And using Anchor with Caddy has few extra advantages. We generate system & language packages for your clients so they trust the server cert. The dashboard provides a view into all the cert material in your environment. And we have built in maintenance schedules for rotating certificate material. And we constrain the CAs to minimize the risk of key leaks: https://blog.anchor.dev/blast-radius-certificate-constraints-6aa8081c66f7 https://blog.anchor.dev/blast-radius-certificate-constraints...

8organicbits 3y ago
Have you done any research about how well different web clients support name constraints? I know that Chrome only recently started respecting Name Constraint on root CAs [1]. The BetterTLS project tracks a bunch of related concerns, but oddly missed this one [2]. I'm wary of this approach since I don't know if the various software I use will enforce it. 1. https://alexsci.com/blog/name-non-constraint/ https://alexsci.com/blog/name-non-constraint/ 2. https://github.com/Netflix/bettertls/issues/19 https://github.com/Netflix/bettertls/issues/19
- benburkert 3y ago
  We did do some research a few months ago, and I don't remember flagging this Chrome issue. It could either be because we add the name constraints to the intermediate CA certs (we always setup a two-tier PKI), or because our tooling adds the certs to the system trust store (same as mkcert, which IIRC also adds name constraints), not importing them directly into the browser. Other than some issues with Rust's webpki crate (which they have since fixed), I don't recall any client compatibility issues with name constraints. Support was added to OpenSSL around the same time that SNI names were added, so we think of them as roughly the same level of support, which is pretty good in 2023. I don't have a solid answer, but my hunch for why BetterTLS doesn't place much emphasis on Name Constraints is because they have very limited use in public CAs. The latest cacert.pem bundle from curl only shows 141 certs with name constraints: `curl -s https://curl.se/ca/cacert.pem https://curl.se/ca/cacert.pem | certigo dump --json --format PEM | jq '.certificates[] | .name_constraints' | wc -l`
  - nickf 3y ago
    "...because they have very limited use in public CAs" Not really. It was/is mostly because NCs aren't 'widely' supported, even now. Name Constraints (referred to as 'Technical Constraints') allows - currently - a public CA to issue a CA certificate with NCs to a third party who then wouldn't require the full panel of WebTrust audits. It's very rarely used, and the one I dealt with eventually got wound down for myriad reasons including how tricky it really is to run a public CA, even a constrained one. Some solutions (ADCS) obeyed name constraints when signing, but that doesn't help much. Also - checking the cacert bundle isn't really a good test - that's for roots and you'll not find name constraints there. You'd better look at the thousands of issuing CAs (but the number is still tiny).
sirius87 3y ago
Do you offer wildcard certs for subdomains (i.e. *.news.ycombinator.com)? I believe I had some trouble with caddy's tls internal directive when trying to do something crazy like this. Maybe you could mention it as your differentiator too. EDIT: I currently use mkcert with caddy and it works fine for this.
- benburkert 3y ago
  Yes, we do support wildcard certs (and will support IP certs in the future). But we don't let you provision certs for domains that you don't own.
  - nickf 3y ago
    Any reason why? That could limit the usefulness of the solution, I'd think. Do you allow issuance of not-hosted-by-anchor CAs for TLS inspection, for example?
    - benburkert 3y ago
      We just see a whole lot of downside and no upside, what reason would someone have other than spoofing a third party domain? I don't think I understand your second question, are you asking about cross-signing?
      - nickf 3y ago
        (Full disclosure, 20+ year veteran and CTO of big-CA-you-probably-know, but I really like how your product looks - just need a bit more time to explore!) People do weird things with private CAs. Be it for testing or corporate shenanigans, they do want to issue for domains they don't control, data they can't verify, internal identifiers etc. - all in contrast to public/webPKI. This is fine, there's no real downside to letting them do it as it's a private CA after all. The other thing wasn't cross-signing (not gazing into that abyss!) I just meant issuing a CA from the private root with CA=true so that it can itself issue certificates. Commonly used on MITM proxies/TLS inspection devices - sadly more common than you think, but again no risk to anyone outside of that enterprise. I believe even in some business areas, it's basically required to TLS MITM your users (finance). Happy to chat more off here if you'd like - email on profile for personal or nick (at) sectigo dot com.

8organicbits 3y ago

Have you done any research about how well different web clients support name constraints? I know that Chrome only recently started respecting Name Constraint on root CAs [1]. The BetterTLS project tracks a bunch of related concerns, but oddly missed this one [2]. I'm wary of this approach since I don't know if the various software I use will enforce it. 1. https://alexsci.com/blog/name-non-constraint/ https://alexsci.com/blog/name-non-constraint/ 2. https://github.com/Netflix/bettertls/issues/19 https://github.com/Netflix/bettertls/issues/19

benburkert 3y ago
We did do some research a few months ago, and I don't remember flagging this Chrome issue. It could either be because we add the name constraints to the intermediate CA certs (we always setup a two-tier PKI), or because our tooling adds the certs to the system trust store (same as mkcert, which IIRC also adds name constraints), not importing them directly into the browser. Other than some issues with Rust's webpki crate (which they have since fixed), I don't recall any client compatibility issues with name constraints. Support was added to OpenSSL around the same time that SNI names were added, so we think of them as roughly the same level of support, which is pretty good in 2023. I don't have a solid answer, but my hunch for why BetterTLS doesn't place much emphasis on Name Constraints is because they have very limited use in public CAs. The latest cacert.pem bundle from curl only shows 141 certs with name constraints: `curl -s https://curl.se/ca/cacert.pem https://curl.se/ca/cacert.pem | certigo dump --json --format PEM | jq '.certificates[] | .name_constraints' | wc -l`
- nickf 3y ago
  "...because they have very limited use in public CAs" Not really. It was/is mostly because NCs aren't 'widely' supported, even now. Name Constraints (referred to as 'Technical Constraints') allows - currently - a public CA to issue a CA certificate with NCs to a third party who then wouldn't require the full panel of WebTrust audits. It's very rarely used, and the one I dealt with eventually got wound down for myriad reasons including how tricky it really is to run a public CA, even a constrained one. Some solutions (ADCS) obeyed name constraints when signing, but that doesn't help much. Also - checking the cacert bundle isn't really a good test - that's for roots and you'll not find name constraints there. You'd better look at the thousands of issuing CAs (but the number is still tiny).

sirius87 3y ago

Do you offer wildcard certs for subdomains (i.e. *.news.ycombinator.com)? I believe I had some trouble with caddy's tls internal directive when trying to do something crazy like this. Maybe you could mention it as your differentiator too. EDIT: I currently use mkcert with caddy and it works fine for this.

benburkert 3y ago
Yes, we do support wildcard certs (and will support IP certs in the future). But we don't let you provision certs for domains that you don't own.
- nickf 3y ago
  Any reason why? That could limit the usefulness of the solution, I'd think. Do you allow issuance of not-hosted-by-anchor CAs for TLS inspection, for example?
  - benburkert 3y ago
    We just see a whole lot of downside and no upside, what reason would someone have other than spoofing a third party domain? I don't think I understand your second question, are you asking about cross-signing?
    - nickf 3y ago
      (Full disclosure, 20+ year veteran and CTO of big-CA-you-probably-know, but I really like how your product looks - just need a bit more time to explore!) People do weird things with private CAs. Be it for testing or corporate shenanigans, they do want to issue for domains they don't control, data they can't verify, internal identifiers etc. - all in contrast to public/webPKI. This is fine, there's no real downside to letting them do it as it's a private CA after all. The other thing wasn't cross-signing (not gazing into that abyss!) I just meant issuing a CA from the private root with CA=true so that it can itself issue certificates. Commonly used on MITM proxies/TLS inspection devices - sadly more common than you think, but again no risk to anyone outside of that enterprise. I believe even in some business areas, it's basically required to TLS MITM your users (finance). Happy to chat more off here if you'd like - email on profile for personal or nick (at) sectigo dot com.