Another free CA as an alternative to Let's Encrypt
scotthelme.co.uk
scotthelme.co.uk
In Caddy 2.3, Caddy [1] will default to both Let's Encrypt and ZeroSSL [2]. If it can't get a cert from one, it will try the other. You can configure more too, including self-signed certs, as a last fallback for example. Caddy will be the first web server and ACME client to support multi-issuer fallback. (Pre-releases coming soon, or you can build from source and try it today.)
ZeroSSL's website is being updated to clarify that certs are free and unlimited through ACME. You can even view them in your ZeroSSL dashboard.
More recently I set up a VM at work to be a domain redirector for a bunch of typo domains to our main domains, since the old outsourced redirectors didn't have TLS, and it was dead simple!
I would appreciate better and consistent documentation to do more non-trivial things with Caddy, but for your basic use-cases it takes a lot of the pain away. Unfortunately, nginx and Apache still win on the (probably unfair) basis that they've got well over 10 years of history, and all of the cultural knowledge that comes with that.
In the meantime, I always encourage anyone to contribute to our wiki: https://caddy.community/c/wiki/13 -- there's already lots of great topics there and room for plenty more, especially examples.
Hint: there's a LOT of market space for paid content to master the Caddy web server, if anyone reading this is looking to profit from their expertise...
Docs have gotten way better since. As has the install story. Before it was some scripted thing that I was never quite confident in, now it's a deb package that I feel confident in running updates and Ansible against. And honestly I have not had any problems since installing it.
my.public.hostname {
reverse_proxy localhost:3000
}https://tools.ietf.org/html/rfc6066#section-3
> "HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using ASCII encoding without a trailing dot. †
So, when your web browser sends the hostname "news.ycombinator.com." that's not an "absolute hostname" that's just an error. Maybe you can demand that web browsers stop doing that, but they'll likely tell you they don't care, and you should stop writing URLs incorrectly.
† The trailing dot rule was in every version, but earliest sources talked about using UTF8 because they pre-date the insight that all this backend (ie not human-facing) stuff can use A-labels which are ASCII and avoid any complicated Unicode problems. This version just says to use ASCII here.
So while the SNI error is clearly on browsers (and bugs have been already filed), the Host header issue is clearly on caddy (which caddy sees as wontfix)
That said, you can just make a site block with that host label and Caddy will handle it just fine. You just need to explicitly ask Caddy for it.
example.com, example.com. {
...
}That's what mholt said as well: It's the site maintainers task to fix it. Yet caddyserver.com still doesn’t support it.
> you're the only person I've ever seen complain about this
I didn’t actually find the bug myself, someone else did first, but it’s something that’s been annoying me for quite a bit.
> You bring it up on every thread on HN that ever has a mention of Caddy. It's very annoying.
It’s definitely a red flag something people should know before using caddy, as it’s a sign caddy will also interpret other specs funnily.
Right, because Matt (and the large majority of everyone on the internet) doesn't care.
> It’s definitely a red flag something people should know before using caddy, as it’s a sign caddy will also interpret other specs funnily.
Pure FUD. It's such a non-issue. As you've been told many times.
If it's such a non-issue, why did matt say he wouldn't accept a PR that'd fix this?
This is all from four years ago. And kuschku hasn't taken no for an answer after all this time. It's frustrating and annoying to hear their complaints on every HN thread since.
I agree with you the thread is shitty. I'm just hoping being direct will end the trolling.
If you want to learn why supporting FQDNs is important, you can actually read the issue and PR on the traefik repo where they chose to add support for this:
https://github.com/traefik/traefik/issues/4622 https://github.com/traefik/traefik/pull/4763
They just accepted the issue, and fixed it. Super easy, no 4 years of "no one needs this" "no you're wrong" "the specs are wrong" "you're trolling"
You make it out to be a simple change, but it's really not. And the arguments for making any changes are not compelling enough to warrant the risks involved. Compliance for the sake of compliance is completely pointless.
That’s why I’m comparing it to traefik, which can also automate TLS management, in the exact same way (even using the same libraries for most of the functionality, they’re after all both go webservers).
> And the arguments for making any changes are not compelling enough to warrant the risks involved
Why is it that you think you know better than the maintainers of e.g. traefik? It’s not like this is legacy functionality they kept around just for the sake of it, they added it in 2019 because there’s demand for it, today.
You're wrong. Caddy uses a superior library that's been more stress-tested at scale in production: https://github.com/caddyserver/certmagic and https://github.com/mholt/acmez - neither of which lego uses. Bugs and limitations in lego caused severe problems for several of our larger customers.
Actually no, not anymore.
https://github.com/caddyserver/caddy/pull/3621
> because there’s demand for it, today
We've only seen the demand from you. Nobody else. One individual isn't enough demand.
At this point it's just a game of wasting other people's time.
And I can’t remotely telepathically make all caddy users switch to nginx. So as long as a single HTTP server runs a version of caddy with this bug, I’ve got extra work to do, because the caddy people are wasting my time
"Caddy has been acquired by the company behind ZeroSSL"
- Let's Encrypt is a busy non-profit organization. We can help maximize their budget by not using it as the exclusive default for every server.
- ZeroSSL does not have rate limits and is also publicly trusted. And yes, it is free to use it with ACME.
- ZeroSSL offers a graphical dashboard where you can log in and see and download your certificates.
- Having more than just 1 free ACME CA is a very, very good thing for the PKI ecosystem.
This is the beauty of standardization; if you give a server a URL, you can give it two and three and four, and not have to worry about global reliance on a single source.
IMO the biggest, easiest feature no CA has implemented is CTLog monitoring / reconciliation. The problem I have with LE even on a small scale is that I'm grabbing certificates for ~20 (sub)domains. I also have several of them set up via Cloudflare. With CTLog monitoring notifications (via Cloudflare and Facebook), I get too many notifications. I don't know what's coming or going or which machines are requesting certificates for which (sub)domains.
A service like ZeroSSL is already acting like a central point of certificate management (for me), so it's the ideal location to do CTLog monitoring since the bulk of certificate issuances happen there. That means legitimate CTLog entries can be reconciled and ignored silently (they'll already show up in the dashboard).
I'm not sure how user accounts work in ACME, but the other thing I'd like is to be able to track which user or machine requested a certificate.
I'm sure something like that could also be built as a proxy. I thought about trying once, but it's firmly in my "things I'll never get to" idea box. Lol.
Another problem I've had with LE that could use a solution is a 3rd party service that I signed up for requesting certificates, but not installing them correctly and hitting the LE limits for that domain. If the mindshare changes from LE to ACME, maybe there'll be a day where 3rd parties will let me specify an ACME provider and link it to my main account somehow.
Hey, where on the site is that said?
I'd like to consider that for work purposes, but I can't find the "we don't rate limit" writing anywhere.
> Unlimited & Zero Cost
> In an effort to ensure the widest possible SSL certificate coverage around the world, our team has decided to keep all ZeroSSL certificates created using the ACME protocol completely free of charge.
Older tools might support technologies like SCEP but not ACME. These older protocols can't be used (on their own) to get certificates trusted in the Web PKI because the whole point of ACME is to do the proof-of-control step needed to get those certificates. But in your private PKI you likely don't need or even want that feature.
I guess it can make sense for new software that is at least sometimes for public access to just do ACME, but it does feel like maybe Smallstep should have a legacy SCEP mechanism available. I see there is a GitHub ticket for that so no need to raise it again.
They only offer 3 domains for free on their pricing page.
> In an effort to ensure the widest possible SSL certificate coverage around the world, our team has decided to keep all ZeroSSL certificates created using the ACME protocol completely free of charge.
But, you can still use Let's Encrypt with old Android devices until the later part of 2021 using the alternate chain: https://letsencrypt.org/2020/11/06/own-two-feet.html (As a point of reference, Caddy supports configuring this alternate chain.)
Sectigo is the new name for Comodo. The same bunch of pricks who tried to trademark “Let’s Encrypt”.
Other players in the acme cert “business” is great. Renaming a slime ball name and carrying on like nothing happened is not ok.
Yes. The intermediate certificate has been included since Android 6.0 [1] and the root expires in 2038 [2].
[1] https://android.googlesource.com/platform/system/ca-certific...
It seems that there is no real alternative... Let's Encrypt's move is going to obsolete a huge lot of devices :-/
That doesn't matter, the root that signed the intermediate cert was created in 2010 [1] which means it's usable for Android>=2.2.
You can limit certificate issuance to a single issuer via CAA in DNS, so you could set your domains to use ZeroSSL exclusively and ZeroSSL could validate ownership of a domain to allow you to create that hierarchy.
I can think of a lot of value added services that can be sold alongside SSL certificates. One example would be CTLog monitoring including for lookalike (FACEB00K) issuances.
The other thing with SSL is that a lot of people equate it with domain security, so I think there's a certain level of domain monitoring that could be sold alongside certificates. Things like domain expiration monitoring, registration of lookalike domains, NS changes, DMARC reporting, etc. all start to feel like a single "domain security" service.
They say "No REST API access" - but presumably ACME does work?
/me searches...
https://community.letsencrypt.org/t/acme-v2-production-envir...
[1] https://torrentfreak.com/sci-hub-pirate-bay-for-science-secu... [2] https://letsencrypt.org/documents/LE-SA-v1.2-November-15-201...
it is!! in recent news: https://news.ycombinator.com/item?id=25091994
For frequently changing IPs there are also services like
which provide you with a third-level domain like xyz.duckdns.org
For anything with even the smallest bit of value, a cheap tld like .party can be had for a decade for around $20.
E-mail is one example. Technically domain names are not necessary to successfully send own mail with own server, i.e., without using a 3rd party email provider. E-mail predates DNS; mail software has always supported IP addresses. However, today, the dominant 3rd party e-mail providers will reject mail coming from an IP address not associated with a domain name.
It offers a lot for free; I started using it when I moved off cloudflare and have quite liked it.
The free .tk domains are only free for 1 year. And even if you are only going to use it for a year, some people would rather not give out their credit card number for a free trial.
Now I’m wondering, how does Freenom make money?
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-... (section 3.2.2.5.1)
There is no such section?
So there's going to be a section 3 about "Identification and Authentication" and it's going to have a subsection 3.2 "Initial Identity Validation" and that's going to have a sub-subsection 3.2.2 about how we figure out who this actually is we're talking to, and so these sections will be further divided. 3.2.2.4.x is the "Ten Blessed Methods" (these days there are rather more than ten) for how we validate DNS names in the Web PKI).
This is where I shamelessly plug my project, Certera: https://docs.certera.io
I love LE, like really really love it. I was surprised to hear that certs were going from 2 to 1 year expiration and that made me really pause for a second to think about the lack of proper infrastructure around certificates, especially LE certs. I envision these short lived certs from LE/ZeroSSL needing some of the components that ZeroSSL mentioned above and much, much more. Eventually, if/when we have 1 week/1 day cert expirations, we'll need a certificate exchange system to better handle complex scenarios where other parties are involved (i.e. when doing client certs, SAML certs, etc.).
What I'd like to have is an ACME compatible endpoint so I can change the ACME endpoint in my Traefik config to `https://acme.certera.example.com` and not have to make any other significant changes.
Basically I'd like to have an ACME proxy with a dashboard like Certera.
Yes, and it's very simple & basic. A single CURL to get it like so: curl https://<your_certera>/api/certificate/<cert_name> \ -H "apiKey:<your_api_key>"
You can pipe that out to a file directly as it's in PEM format by default. More info here: https://docs.certera.io/#certificates-api
The thing that's unique about Certera is that it's not opinionated on your existing setup. It doesn't care whether it's Traefik, apache, nginx or IIS. The "glue" is a standard PEM file format, the way it should be. It's up to you how to tell whatever system cares about the PEM and do the "reload" of the cert.
I'm not sure how Traefik would communicate with it as I'm not familiar with Traefik in general. I'm assuming that you'd like Traefik to simply say: "gimme the cert for xyz domain" and have some endpoint/system take care of the rest, right? Don't hesitate to create an issue in GitHub and we can discuss further. Sometimes I lose track of HN comments due to a lack of notifications.
Having a non-opinionated system using a simple http call makes sense to me. I would say the main drawback is that a lot of automated certificate management has, in effect, standardized around ACME and hook points for integrating anything else seem like an afterthought. For Traefik specifically, it's not possible to cleanly reload TLS certificates:
https://github.com/traefik/traefik/issues/5495
So with an ACME provider, Traefik deals with scheduling of renewals and reloading TLS certificates as needed and I don't have to think about it. Obviously that has the downside of being a hard to debug (for me) black box, but I think a lot of people are willing to accept opaque systems if it saves them any amount of effort / thought.
That said, when I started using Traefik for TLS termination a year or two ago, it would have been much easier to set up cron or systemd timers to request certificates from Certera than to learn Traefik's manual config for terminating non-docker endpoints. In fact I might be using Certera and HAProxy for all my TLS termination had I known about it back then.
I'll definitely create an issue on GitHub if I try it and run into problems, but I'll try the existing setup first. I actually prefer HAProxy to Traefik and IIRC the only reason I'm using Traefik is that I didn't have an easy way to solve LE challenges in HAProxy. If I can have Certera playing that role I could drop Traefik and it's one less thing to keep up with.
BTW, I've used Caddy before and I like it. It's the first name that pops into my head when I need a webserver. I mocked out my own plugin to add auth to GitLab pages a couple years ago and remember thinking it (Caddy) was pretty slick.
I'm still not sure what it does that I couldn't do with a normal ssh session.
From their Terms and Conditions:
" ZeroSSL is for your personal or internal business use only and must be in compliance with all applicable ZeroSSL policies, laws, rules and regulations. As well as this, no third party rights can be violated or infringed upon through use of ZeroSSL. You may not use ZeroSSL for any commercial purpose including but not limited to selling, licensing, providing services, or distributing ZeroSSL to any third party unless you have received the express written consent of ZeroSSL beforehand."
In general it doesn't matter who issues the certificate as long as they're trusted.
So technically we don’t need a cert for onion
They do offer ACME though: https://docs.digicert.com/certificate-tools/Certificate-life...
edit: thanks for the replies!
More options are good, Let’s Encrypt is mandatory to ensure good (or non predatory or oligopoly) behavior by other cert providers. It’s a check on their power.
https://letsencrypt.org/about/ https://www.abetterinternet.org/
I'm surprised this model isn't more common as an alternative to licensing.
they could sell their keys, but impersonations would likely be spotted thanks to certificate transparency
NSA could still mount an attack by asking the CA to register NSA's certs as valid, and tamper the victim's network connection. What makes certs secure is our trust in certificate authorities.
Would that allow transparent sniffing of traffic encrypted with these certs?
If an attacker has the CA's private key, then the attacker can mint new HTTPS certificates. They wouldn't be able to do passive listening attacks on connections, but they could use an active man-in-the-middle attack to swap out the server's certificate in the connection. However, this attack could be detected through Certificate Transparency, and the CA's leaked keys would become untrusted by browsers.
“ The world’s most valuable resource is no longer oil, but data.” ~The Economist, May 6, 2017
Certificate logs from the certificate transparency project [0] are already public knowledge and shared freely.
The only thing lets encrypt gets in addition to what's in those logs and publicly discoverable is what challenge you chose (dns or tls), and what email you're using.
> So yes I personally welcome another CA
More CAs generally means more chance that one CA loses a private key or has a vulnerability. Tragically, since browsers trust all CAs for all websites, if the new CA has an issue, people can forge TLS certs for my website even though I have no intention of ever using that new CA.
In a very real way, having an excess of CAs is bad for the security of the entire internet. Letting anyone become a trusted CA would be an unequivocal disaster, so clearly more CAs isn't always good.
I do think there's a balance, where we should have several viable CAs that we trust to be secure, but not 100s of them, just 10s. We already trust a ton more roots than that, so right now I see a new CA as being detrimental to security overall.
That all being said, I'm pretty sure this CA is using an existing trusted root and processes, so since it doesn't require cross-signing in a new root, it's less big of a deal.
I acknowledge your points with the risk of intelligence leaking. However most DNS is benign / not a state secret in general.
https://letsencrypt.org/privacy/#we-do-not-sell-your-data-or...
PKI in a nutshell: the CA signs your CSR which was created with your private key; the CA gives you a cert based on your CSR; you show random people a website using your private key + CA-signed cert; random person's browser trusts your private key+CA-signed cert content because their browser trusts the CA-signed stuff implicitly.
Why we need more than 1 of them: in case one of them goes down and so we can't get new certs; in case one gets compromised and the browser revokes their trusted CA cert; diversity of "features".
What could we do instead of this process?
Idea 1: the registry becomes the CA.
Why?
To get a cert, you have to prove you are allowed to have it. Currently that almost always involves proving that you currently control the IP space that is pointed to by a DNS record. There are other verification methods which are somewhat more problematic than this, but this is the simplest method. And if you can find one single CA which will create you a cert if you can do this, that means that if anyone can do it, they can get a cert. Meaning that this verification method is the minimum security barrier for getting a valid cert.
How can an attacker to subvert this process to generate a valid cert for any domain?
Options: 1) Take over the domain, by hacking the domain's account at the registrar. 2) MITM the registrar, such that updates to the registry's NS end up controlled by the attacker. 3) Take over the domain, by hacking one of the domain's nameservers. 4) Perform a DNS hijack, such as cache poisoning, so when the CA looks up your domain to find the IP space, you return attacker IP space. 5) Perform a BGP hijack so when the CA tries to connect to the IP space, it connects to attacker-controlled IP space. 6) Plenty of others based on other validation methods such as DNS record alone, HTTP [no S] content, a pre-configured list of e-mails for a domain, etc.
How to prevent all but one of these attacks?
Option A: Make the registrar the CA. The registrar would simply request the user use an HTTPS API to request a new cert, using an API token generated by the login for the domain's account. The only way for an attacker to generate a cert at that point is to either hack the registrar account, or hack the customer's server to get the API token (basically the same impact as if they compromised the customer's web server).
The browsers would trust the registrars who would follow the exact same stringent guidelines that CAs use today. The difference to the end-user is the CA is run by the registrar.
Option B: The registrar and the CAs stay independent, but they use a standard secure protocol to authorize signing of certs using a customer API token. Same benefits, but an extra hop. Browsers continue working as before, users use an HTTPS API to the CA to generate the certs.
With either options A or B, there's no more stupid hoops to jump through just to prove you own the domain and thus deserve a certificate.
All you actually need is a stripped-down REST API (or some wireline protocol with 4 fields) and a TLS connection. No need to require DNS or DNSSEC at all.
The registrar generates a unique token for whatever the domain owner wants to manage a cert for that's based on their domain. "oj3942hur9h239rh9hr4394834r domain.com" or "92839ub9f93hh9hsjdksjd * .foo.domain.com", doesn't matter. CA makes a request with the token and the CSR, registrar looks at the CSR, finds the record matching the token, finds that the CSR matches the record, signs its reply "yes, this is valid" with its own key, and the CA obliges the user. You don't even need DNS to make the request if it's hosted on some static IPs.
If anyone's seriously waiting on DANE in order to resolve a handful of security vulnerabilities that affect the entire Internet (because at this point the entire Internet's security hinges on TLS), we might as well also wait for Jesus to come down from his bachelor pad in the sky and solve our national debt.
Once you're checking that box, DANE is almost free. Egos involved may determine that it's important to never technically do DANE, so as to save face, see also why TLS 1.3 isn't just named SSL 3.4 or SSL 4.0 even though that's what it "is" in some sense. But the effect, yes. If that scenario plays out it's what will happen.
One blocker for DNSSEC and thus DANE was deployability difficulties facing middleboxes. But middleboxes have choked so much else since that today "defeat middleboxes" is just table stakes. It was needed for TLS 1.3 and it's needed for QUIC and for HTTPS DNS records and... if you're defeating middleboxes anyway you might as well have DNSSEC.
This isn't a chicken-and-egg problem: domains can DNSSEC-sign now, without any middlebox interference, and overwhelmingly choose not to.