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.
> 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.).
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.
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.
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.
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.
Completely agree. The emails you get from LE are nice, but often not enough and hard to manage at scale. I created Certera to help manage LE at scale (helps with rate limits, has monitoring and alerting of expiring certificates as well as failure to renew), also helps with key storage and rotation. I'm hoping to keep iterating and adding more features and functionality. Think of it as PKI for LE certs.
GPL is great for certain types of products, however, infrastructure types of projects aren't one of them.
I haven't been marketing at all, and I just recently finished the first stable release, so the jury is still out on whether this is all a good idea or not!
The docs are based on ReadTheDocs, but settled on a single file layout instead of having multiple pages.
I'm going to shamelessly plug my project, Certera, here. It handles monitoring/tracking, cert issuance and renewals and helps larger organizations manage their certificate needs more consistently.
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.