daemon
bettertls
daemon | bettertls | |
---|---|---|
2 | 3 | |
11 | 157 | |
- | 1.3% | |
8.3 | 4.8 | |
4 months ago | 2 months ago | |
Go | Go | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
daemon
-
Running one’s own root Certificate Authority in 2023
I made a web server / microservices thing that issues certs for clients from a CA root it automatically generates. Then internal reverse proxy connections use that cert so the whole path is TLD encrypted with full cert validation.
https://github.com/fsmv/daemon
- Show HN: A web server for using TLS with many back end servers
bettertls
-
Show HN: Anchor – developer-friendly private CAs for internal TLS
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/
2. https://github.com/Netflix/bettertls/issues/19
-
Running one’s own root Certificate Authority in 2023
Wouldn't it be nice if LetsEncrypt could issue you a (1) name constrained, (2) 90-day limited intermediate CA with just the (3) DNS-01 challenge? I argue that such an intermediate CA would have no more authority than a wildcard cert which you can get today, so they should be able to issue it. [1] Everything supports name constraints now, which used to be an issue but isn't anymore.
Then stick it in step-ca and issue all your certificates with internal ACME.
This would solve a lot of problems, such as leaking private hostnames in the certificate transparency log, or hitting issuance rate limits on LE servers.
[1]: https://news.ycombinator.com/item?id=29811552
[2]: https://bettertls.com/
-
Easy HTTPS for your private networks
I've been pretty frustrated with how private CAs are supported. Your private root CA can be maliciously used to MITM every domain on the Internet, even though you intend to use it for only a couple domain names. Most people forget to set Name Constraints when they create these and many helper tools lack support [1][2]. Worse, browser support for Name Constraints has been slow [3] and support isn't well tracked [4]. Public CAs give you certificate transparency and you can subscribe to events to detect mis-issuance. Some hosted private CAs like AWS's offer logs [5], but DIY setups don't.
Even still, there are a lot of folks happily using private CAs, they aren't the target audience for this initial release.
[1] https://github.com/FiloSottile/mkcert/issues/302
[2] https://github.com/cert-manager/cert-manager/issues/3655
[3] https://alexsci.com/blog/name-non-constraint/
[4] https://github.com/Netflix/bettertls/issues/19
[5] https://docs.aws.amazon.com/privateca/latest/userguide/secur...
What are some alternatives?
certificates - 🛡️ A private certificate authority (X.509 & SSH) & ACME server for secure automated certificate management, so you can use TLS everywhere & SSO for SSH.
minica - minica is a small, simple CA intended for use in situations where the CA operator also operates each host where a certificate will be used.
lego - Let's Encrypt/ACME client and library written in Go
cfssl - CFSSL: Cloudflare's PKI and TLS toolkit
easy-rsa - easy-rsa - Simple shell based CA utility
rgca - Experiment in SSL CA management.
luci - LuCI - OpenWrt Configuration Interface
lexicon - Manipulate DNS records on various DNS providers in a standardized way.
dehydrated - letsencrypt/acme client implemented as a shell-script – just add water
caniuse - Raw browser/feature support data from caniuse.com