> Why not just use Let's Encrypt?
ZeroSSL comes with significant advantages compared to Let's Encrypt, including access to a fully-featured SSL management console, an REST API for SSL management, SSL monitoring, and more.
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.).
I've looked at setting that up for my home lab a few times and when reading the docs I always get hung up on one thing. How do I retrieve certificates on my servers? Do I have to use the Certera API for that?
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.
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.
Hey. Thanks for replying. FYI, I just noticed the store link on your site is broken.
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:
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.
Genuine question, have you considered using Caddy? With the third party caddy-docker-proxy plugin you get essentially the same benefits of Traefik in that regard, without the frustrations/limitations you've experienced with Traefik.
I didn't know that existed. I skimmed it and it looks like it would be good, but Traefik is working well enough for me that I don't have a reason to change it. To be really honest, I'd have to get some kind of noticeable improvement vs my current setup to make it worth building Caddy to get that plugin.
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.
It's PKI for Let's Encrypt certificates. Helps you issue, renew, revoke certs from a central place. Also get alerts so you know when things have changed, expired, failed to renew.
While a lot of places give you certs built in, there's a whole world of places you still need certs. Like FTP, mail, behind load balancers, disparate environments and systems, etc.
In the future, I'm planning on creating a way to automate the certificate exchange process. This should help with using and exchanging certs used in client authentication and things like SAML SSO. If expiration get down to a month or less, I see a need for a system to help do all of these things and more.
To centrally manage all of your LE certificates, keys, alerting, etc. You can also more easily use LE certs in a wider array of scenarios too. Check out the docs to learn more.
I did have a look at the docs, but they more explained the how, rather than the why - I missed some kind of intro/overview explaining the value proposition.
I'm still a bit fuzzy on this - why would I want alerting, for example? Automation is a big part of LE, and my certs are configured to auto-renew. If that was to fail for some reason, then LE will send me an email - is it this part where this tool comes in, providing improved alerts where automation has failed?
That's great feedback. I'll update the docs to better explain the why.
To elaborate on the why for alerting, there are many situations that I've seen where things change and subsequently fail silently. Perhaps some dependencies, or maybe configuration changes, caused things to break. Also, alerting doesn't only have to be for your certificates. You can point to any endpoint to monitor as well. There are three aspects of alerting: changes to the cert (perhaps you care about a 3rd party certificate and its underlying key changing), failure to renew, and expirations. Each comes with its own benefits and use cases.
To expand on the why a bit further for the project as a whole, it's really as a way to help consolidate and centralize things. I've seen many disparate ways of using Let's Encrypt. From various clients to some hacks to better support more complicated scenarios. By separating obtaining the certificate from applying, it helps facilitate many things, like using LE certs behind load balancers & proxies, non-standard ports, things that don't speak HTTP, etc.
If certificate expiration continues to decrease in time, we'll need some capabilities to exchange certificates in an automated fashion as well. I'd also like to incorporate Certificate Transparency logs so you can be sure no one has issued certs for your domain(s). There are many cool and interesting scenarios but mostly the challenges come when managing things at scale. So, it's not really all that useful if you're only managing one or two certs.
This seems interesting. I also saw Caddy 2 which seems to have a lot of functions (with handling certs as one) and it's good to have something that's complementary with other software.
Also nice write-up on the 'source available' licensing rationale.
Yes we want to test asymptomatic people too. Some countries like Germany and South Korea are doing are better job of testing widely and so they have many more mild/asymptomatic samples that can be screened.
That was my first thought as well. Their main park, where the zoo is, has only the trees along the walk way defined. Maybe I didn't understand where this thing was supposed to be going.
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.).