9 ms·

Show HN: Anchor – developer-friendly private CAs for internal TLS

76 points by benburkert 3y ago

Hi HN! I'm Ben, co-founder of Anchor (https://anchor.dev/ https://anchor.dev/). Anchor is a hosted service for ACME powered internal X.509 CAs. We recently launched our features & tooling for local development. The goal is to make it easy and toil-free to develop locally with HTTPS, and also provide dev/prod parity for TLS/HTTPS encryption. You can add Anchor to your development workflow in minutes. Here's how: - https://blog.anchor.dev/getting-started-with-anchor-for-local-development-6dd2cd605c08 https://blog.anchor.dev/getting-started-with-anchor-for-loca... - https://blog.anchor.dev/service-to-service-tls-in-development-d0df479d67ce https://blog.anchor.dev/service-to-service-tls-in-developmen... We started Anchor because private CAs were a constant source of frustration throughout our careers. Avoiding them makes it all the more painful when you're finally forced to use one. The release of ACME and Let's Encrypt was a big step forward in certificate provisioning, but the improvements have been almost entirely in the WebPKI and public CA space. Internal TLS is still as unpleasant & painful to use as it has been for the past 20 years. So we've built Anchor to be a developer-friendly way to setup internal TLS that fully leverages the benefits of ACME: - no encryption experience or X.509 knowledge required - automatically generated system and language packages to manage client trust stores - ACME (RFC 8555) compliant API, broad language/tooling support for cert provisioning - fully hosted, no services or infra requirements - works the same in all deployment environments, including development If you're interested in more specific details and strategy, our blog posts cover all this and more: https://blog.anchor.dev/ https://blog.anchor.dev/ We are asking for feedback on our features for local development, and would like to hear your thoughts & questions. Many thanks!

Wool2662 3y ago
Your footer 'Get Started' link is broken.
- benburkert 3y ago
  oops! Sorry about that, should have a fix for that soon. In the mean time, here's the correct url: https://docs.anchor.dev/getting-started/quick-start https://docs.anchor.dev/getting-started/quick-start
candiddevmike 3y ago
I'm not sure I understand the value prop. For localhost, you typically just generate a self-signed certificate that doesn't need to be trusted by everyone, as the dev can just add it to their local store. There are also other services that provide ACME certificates for localhost domains, basically what you do for free (I can't find a link to one but it was posted on HN recently). If you need a trusted certificate for local dev, something like Cloudflare Tunnels is more valuable as you can have other folks access the service.
- fearface 3y ago
  The core usecase might be to have anchor and a cert-manager in k8s connected to it and then be able to generate valid certificates for non-public services. Also they would use solely private DNS.
  - nonameiguess 3y ago
    You can create a self-signed CA in cert-manager directly already, which has the advantage that the private key never leaves your infrastructure, you don't need to create a login account on some external service to do it, it will work fine behind an airgap, and you can use your existing DNS domain instead of having to use Anchor's "lcl.host" which seemingly requires all of your queries to resolve "private" URLs now have to go to public DNS servers.
    - robinhoodexe 3y ago
      Can you elaborate on this? We have some 300 internal APIs on a valid domain. We used to use let’s encrypt, but got rate limited for obvious and fair reasons when we were migrating between clusters. It’s a bit better with zerossl, but we still get 429s when cert-manager is issuing a ton of certs at the same time.
      - benburkert 3y ago
        Just wanted to clarify that `lcl.host` is a service that only helps with local development, it's not useful (and shouldn't be used) in staging & production environments. For staging & production, we let customers use a public domain they own, or a special use domain (`.local`, `.test`, `.lan` etc). Here's how the architecture you described works with Anchor: assuming your domain is `mycorp.it`, you can add it to your organization. Then create staging & production environments. This provisions a stand-alone CA per environment, and the CA is name constrained for the environment (e.g. only `*.stg.mycorp.it` in staging). Each of the 300 APIs can be registered as a service: this provisions an intermediate CA per environment that is further name constrained (e.g. `foo-api.stg.mycorp.it` in staging). For each service in each environment you generate a set of API tokens (EAB tokens in ACME parlance) that allows your automation to provision server certs with the ACME client of your choice. edit: in your case, cert-manager would be the acme client delegating to Anchor.
tomjen3 3y ago
How is this better than using the internal tls setting for caddy?
- benburkert 3y ago
  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`
2023throwawayy 3y ago
Pricing is missing.
- deleted 3y ago
  [deleted]
- benburkert 3y ago
  We don't have a paid offering yet. Right now we're focused on local development environments, which is free to use as individuals and organizations. In the future, we'll have a paid offering for organizations to use in their staging/production environments. Anyone interested in being a part of that pilot, please email me: my-username at anchor.dev
samcat116 3y ago
Does this help at all with the issue of deploying the root CA cert on every device that will interact with services with these certs deployed? That seems to me to be the hardest part about running an internal CA. You've got to put it on everyones laptops as well as all your servers.
- benburkert 3y ago
  Indeed, we automatically build language (JS, Go, Ruby, Python soon) and OS (debian) packages that you can use in your application or base image. Those packages bundle the set of root CA certs so that your clients trust the certificates presented by servers. Soon we'll have automatic package publishing, so that rotating cert material is just another dependabot PR. edit: for the laptop problem, we have a CLI toolchain that gets your development environment setup by adding all the necessary CA certs to your local trust store. More about that here: https://blog.anchor.dev/getting-started-with-anchor-for-local-development-6dd2cd605c08 https://blog.anchor.dev/getting-started-with-anchor-for-loca...
  - filleokus 3y ago
    Considering the amount of time I’ve spent dealing with trusting CA’s in different environments (and worse, seen people just disable cert verification) I think the real value proposition is probably in the client tooling. Any org that care enough to have an internal PKI (compared to just using e.g public certs for internal dns names or wildcard certs) probably don’t hosting something internally. But if the pricing is reasonable and help the client situation enough, then I see it could maybe be worth it?
  - samcat116 3y ago
    One thing I'd say on the client side would be an integration with MDM vendors somehow. All the platforms have native hooks to install certs into their trusts that the MDMs use, and corporate IT is already using MDMs. I think that would actually be a lot easier than telling everyone "go download this CLI", especially if a non engineer needs to access these internal services.
moqmar 3y ago
I don't really understand how "hosted" and "internal" go together here - does this mean that a) the devices I need certificates for must connect to your servers, and that b) your servers could theoretically sign certificates for devices which do not exist? If so, especially for the latter point, this IMO isn't really useful for any real-world application, as the most important things of a CA is control.
- benburkert 3y ago
  Yes, this is both "hosted" and "internal": we build & manage a CAs per org. It's a bit like having an instance of Let's Encrypt, but just for your org (or per environment). Your clients will only trust the certs for your CA, and those CAs have constraints in place so that we could never issue a certificate outside of your set of configured DNS names. For example, even if a certificate was issued for gmail.com, it wouldn't be trusted by your clients. We always build two-tier PKIs, which means your server certificates are issued by intermediate certificates, and those intermediates are issued by a root certificate. In the future, we will let users bring their own root certificate so that we never see your root key material, which you can keep safely in an HSM or KMS.
  - tempay 3y ago
    > Your clients will only trust the certs for your CA, and those CAs have constraints in place so that we could never issue a certificate outside of your set of configured DNS names. Does this work in practice? I was under the impression that the extensions for restricting which domains a CA can use weren’t widely supported.
    - benburkert 3y ago
      It does work, and we've found it to be about as well supported as SAN names, which is pretty extensive these days. It's just not commonly used by public CAs because the real value of these public CAs is that they can issue for any valid domain name, not a predefined set.
westurner 3y ago
What advantages over say, smallstep/certificates, letsencrypt/boulder, django-ca, square/certstrap, or hashicorp/vault (and e.g. OpenWRT's luci-app-acme ACMEv2 GUI) does Anchor offer? https://github.com/topics/acme https://github.com/topics/acme applications/luci-app-acme/htdocs/luci-static/resources/view/acme.js: https://github.com/openwrt/luci/blob/master/applications/luci-app-acme/htdocs/luci-static/resources/view/acme.js https://github.com/openwrt/luci/blob/master/applications/luc... https://openwrt.org/docs/guide-user/services/tls/acmesh https://openwrt.org/docs/guide-user/services/tls/acmesh https://developer.hashicorp.com/vault/tutorials/secrets-management/pki-engine https://developer.hashicorp.com/vault/tutorials/secrets-mana... https://github.com/hashicorp/vault https://github.com/hashicorp/vault : > Refer to Build Certificate Authority (CA) in Vault with an offline Root for an example of using a root CA external to Vault.
- benburkert 3y ago
  This is a managed SaaS solution, not self-hosted software like the ones listed. We're more akin to one of the certificate management products in cloud providers, but our target users are not security experts with prior PKI/X.509 deployment experience. We're building anchor for developers who want or need TLS/HTTPS, but don't want the headache & toil of manually setting up & running an internal CA and the extra infra that goes with it.
sneak 3y ago
Feedback: I don’t use services that require external services to auth with. I’ve stopped using GitHub whenever/wherever possible because of the ICE concentration camps thing and your service doesn’t allow me to log in or create an account without using GitHub. Your website doesn’t say how much it costs.

76 points by benburkert 3y ago

Wool2662 3y ago

Your footer 'Get Started' link is broken.

benburkert 3y ago
oops! Sorry about that, should have a fix for that soon. In the mean time, here's the correct url: https://docs.anchor.dev/getting-started/quick-start https://docs.anchor.dev/getting-started/quick-start

candiddevmike 3y ago

I'm not sure I understand the value prop. For localhost, you typically just generate a self-signed certificate that doesn't need to be trusted by everyone, as the dev can just add it to their local store. There are also other services that provide ACME certificates for localhost domains, basically what you do for free (I can't find a link to one but it was posted on HN recently). If you need a trusted certificate for local dev, something like Cloudflare Tunnels is more valuable as you can have other folks access the service.

fearface 3y ago
The core usecase might be to have anchor and a cert-manager in k8s connected to it and then be able to generate valid certificates for non-public services. Also they would use solely private DNS.
- nonameiguess 3y ago
  You can create a self-signed CA in cert-manager directly already, which has the advantage that the private key never leaves your infrastructure, you don't need to create a login account on some external service to do it, it will work fine behind an airgap, and you can use your existing DNS domain instead of having to use Anchor's "lcl.host" which seemingly requires all of your queries to resolve "private" URLs now have to go to public DNS servers.
  - robinhoodexe 3y ago
    Can you elaborate on this? We have some 300 internal APIs on a valid domain. We used to use let’s encrypt, but got rate limited for obvious and fair reasons when we were migrating between clusters. It’s a bit better with zerossl, but we still get 429s when cert-manager is issuing a ton of certs at the same time.
    - benburkert 3y ago
      Just wanted to clarify that `lcl.host` is a service that only helps with local development, it's not useful (and shouldn't be used) in staging & production environments. For staging & production, we let customers use a public domain they own, or a special use domain (`.local`, `.test`, `.lan` etc). Here's how the architecture you described works with Anchor: assuming your domain is `mycorp.it`, you can add it to your organization. Then create staging & production environments. This provisions a stand-alone CA per environment, and the CA is name constrained for the environment (e.g. only `*.stg.mycorp.it` in staging). Each of the 300 APIs can be registered as a service: this provisions an intermediate CA per environment that is further name constrained (e.g. `foo-api.stg.mycorp.it` in staging). For each service in each environment you generate a set of API tokens (EAB tokens in ACME parlance) that allows your automation to provision server certs with the ACME client of your choice. edit: in your case, cert-manager would be the acme client delegating to Anchor.

tomjen3 3y ago

How is this better than using the internal tls setting for caddy?

benburkert 3y ago
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`

2023throwawayy 3y ago

Pricing is missing.

deleted 3y ago
[deleted]
benburkert 3y ago
We don't have a paid offering yet. Right now we're focused on local development environments, which is free to use as individuals and organizations. In the future, we'll have a paid offering for organizations to use in their staging/production environments. Anyone interested in being a part of that pilot, please email me: my-username at anchor.dev

samcat116 3y ago

Does this help at all with the issue of deploying the root CA cert on every device that will interact with services with these certs deployed? That seems to me to be the hardest part about running an internal CA. You've got to put it on everyones laptops as well as all your servers.

benburkert 3y ago
Indeed, we automatically build language (JS, Go, Ruby, Python soon) and OS (debian) packages that you can use in your application or base image. Those packages bundle the set of root CA certs so that your clients trust the certificates presented by servers. Soon we'll have automatic package publishing, so that rotating cert material is just another dependabot PR. edit: for the laptop problem, we have a CLI toolchain that gets your development environment setup by adding all the necessary CA certs to your local trust store. More about that here: https://blog.anchor.dev/getting-started-with-anchor-for-local-development-6dd2cd605c08 https://blog.anchor.dev/getting-started-with-anchor-for-loca...
- filleokus 3y ago
  Considering the amount of time I’ve spent dealing with trusting CA’s in different environments (and worse, seen people just disable cert verification) I think the real value proposition is probably in the client tooling. Any org that care enough to have an internal PKI (compared to just using e.g public certs for internal dns names or wildcard certs) probably don’t hosting something internally. But if the pricing is reasonable and help the client situation enough, then I see it could maybe be worth it?
- samcat116 3y ago
  One thing I'd say on the client side would be an integration with MDM vendors somehow. All the platforms have native hooks to install certs into their trusts that the MDMs use, and corporate IT is already using MDMs. I think that would actually be a lot easier than telling everyone "go download this CLI", especially if a non engineer needs to access these internal services.

moqmar 3y ago

I don't really understand how "hosted" and "internal" go together here - does this mean that a) the devices I need certificates for must connect to your servers, and that b) your servers could theoretically sign certificates for devices which do not exist? If so, especially for the latter point, this IMO isn't really useful for any real-world application, as the most important things of a CA is control.

benburkert 3y ago
Yes, this is both "hosted" and "internal": we build & manage a CAs per org. It's a bit like having an instance of Let's Encrypt, but just for your org (or per environment). Your clients will only trust the certs for your CA, and those CAs have constraints in place so that we could never issue a certificate outside of your set of configured DNS names. For example, even if a certificate was issued for gmail.com, it wouldn't be trusted by your clients. We always build two-tier PKIs, which means your server certificates are issued by intermediate certificates, and those intermediates are issued by a root certificate. In the future, we will let users bring their own root certificate so that we never see your root key material, which you can keep safely in an HSM or KMS.
- tempay 3y ago
  > Your clients will only trust the certs for your CA, and those CAs have constraints in place so that we could never issue a certificate outside of your set of configured DNS names. Does this work in practice? I was under the impression that the extensions for restricting which domains a CA can use weren’t widely supported.
  - benburkert 3y ago
    It does work, and we've found it to be about as well supported as SAN names, which is pretty extensive these days. It's just not commonly used by public CAs because the real value of these public CAs is that they can issue for any valid domain name, not a predefined set.

westurner 3y ago

What advantages over say, smallstep/certificates, letsencrypt/boulder, django-ca, square/certstrap, or hashicorp/vault (and e.g. OpenWRT's luci-app-acme ACMEv2 GUI) does Anchor offer? https://github.com/topics/acme https://github.com/topics/acme applications/luci-app-acme/htdocs/luci-static/resources/view/acme.js: https://github.com/openwrt/luci/blob/master/applications/luci-app-acme/htdocs/luci-static/resources/view/acme.js https://github.com/openwrt/luci/blob/master/applications/luc... https://openwrt.org/docs/guide-user/services/tls/acmesh https://openwrt.org/docs/guide-user/services/tls/acmesh https://developer.hashicorp.com/vault/tutorials/secrets-management/pki-engine https://developer.hashicorp.com/vault/tutorials/secrets-mana... https://github.com/hashicorp/vault https://github.com/hashicorp/vault : > Refer to Build Certificate Authority (CA) in Vault with an offline Root for an example of using a root CA external to Vault.

benburkert 3y ago
This is a managed SaaS solution, not self-hosted software like the ones listed. We're more akin to one of the certificate management products in cloud providers, but our target users are not security experts with prior PKI/X.509 deployment experience. We're building anchor for developers who want or need TLS/HTTPS, but don't want the headache & toil of manually setting up & running an internal CA and the extra infra that goes with it.

sneak 3y ago

Feedback: I don’t use services that require external services to auth with. I’ve stopped using GitHub whenever/wherever possible because of the ICE concentration camps thing and your service doesn’t allow me to log in or create an account without using GitHub. Your website doesn’t say how much it costs.