Looks good. I am using Cert Warden for similar purposes, though admittedly only a few certificates. Most of my minimal needs are taken care of properly by Caddy which is already the front end proxy for the same services.
This may be good for the selfhoster who is running more an a couple of sites.
But a GUI to manage enterprise-level SSL fleets? Doubtful.
Not when a change/configuration management system (Puppet, Chef, Ansible etc etc..) driven by git commits enables single-source-of-truth, peer-review, and automatic creation/monitoring/renewal of certificates.
You're absolutely right, at the enterprise level, managing an SSL fleet goes far beyond just issuance, and you can't assume the certificates you're issuing are the only ones that exist.
Shameless plug: if you need to cut through the noise of thousands of certs across thousands of hosts, there's https://sslboard.com
To be honest, it's rather difficult and costly to run, with a 1.5B rows database of indexed unexpired certificates and a scanning job that took weeks from dozens of IPs.
SSL officially became TLS in 1999 when the Internet Engineering Task Force published TLS 1.0 as RFC 2246. TLS 1.0 was designed as an upgrade to SSL 3.0, addressing security vulnerabilities and making several improvements, but the changes were significant enough to prevent interoperability between SSL 3.0 and TLS 1.0
It seems a bit silly to call a new tool an SSL manager?
I came from a decade of certificate management in multiple work contexts and YES, all the people refer to them as SSL and not TLS, while TLS 1.2 is the minimum de facto standard nowadays.
The point of certmate is to have a simple url like https://certmate/domain/tls to grab a valid cert from wherever I am, any time. This because I focused on DNS challenge only.
A good feat btw is the deploymenet check, where the app verify if the cert issued is the same deployed on public FQDN.
Of course some more interesting additional features will be added soon like:
- multiple cloud accounts support
- deploy to remote nodes
- vault integration/support
Yeah, nobody should ever employ features that only work on newer versions of software because then someone somewhere might not be able to make use of them.
But less snarkily, maybe put in the work to hack up their dockerfiles if you want to do something they don't directly support.
Sounds cool, but what if you don't use one of the listed DNS providers, but rather run your own DNS? I didn't see an option that would let you do that.
RFC2136 would let you do that, though setting it up is “an exercise left up to the reader”. My suggestion would be to get RFC2136 working with certbot first.
So this just writes the certificates to disk and you still have to manage binding certificates to services? I’m using Caddy in-front of containers using Cloudflare DNS and it works amazingly. Zero configuration.
Looks good. I am using Cert Warden for similar purposes, though admittedly only a few certificates. Most of my minimal needs are taken care of properly by Caddy which is already the front end proxy for the same services.
https://www.certwarden.com/
This may be good for the selfhoster who is running more an a couple of sites.
But a GUI to manage enterprise-level SSL fleets? Doubtful.
Not when a change/configuration management system (Puppet, Chef, Ansible etc etc..) driven by git commits enables single-source-of-truth, peer-review, and automatic creation/monitoring/renewal of certificates.
You're absolutely right, at the enterprise level, managing an SSL fleet goes far beyond just issuance, and you can't assume the certificates you're issuing are the only ones that exist.
Shameless plug: if you need to cut through the noise of thousands of certs across thousands of hosts, there's https://sslboard.com
Shame this isn't open source or some open source equivalent
To be honest, it's rather difficult and costly to run, with a 1.5B rows database of indexed unexpired certificates and a scanning job that took weeks from dozens of IPs.
Most "homelabs", self hosters or small outfits would already use something like Traefik or Cloudflare tunnels with auto cert management.
Their main concerns are getting browser "unsafe" warnings disappear and keep it so. They want nothing to do with cert issuance or renewal.
SSL officially became TLS in 1999 when the Internet Engineering Task Force published TLS 1.0 as RFC 2246. TLS 1.0 was designed as an upgrade to SSL 3.0, addressing security vulnerabilities and making several improvements, but the changes were significant enough to prevent interoperability between SSL 3.0 and TLS 1.0
It seems a bit silly to call a new tool an SSL manager?
You can’t fight mindshare. Naming is branding, not a ruleset.
Maybe think of it as “SSL certs” the thing uses TLS x.0 standard.
Too many people will say “what?” if you call it TLS cert management. Or worse, they will ignore it because it doesn’t trip the synapses.
unfortunately outside tech circles, most people still refer to it as SSL or HTTPS. They dont know about the intricacies of the changes involved
certmate dev here :)
I came from a decade of certificate management in multiple work contexts and YES, all the people refer to them as SSL and not TLS, while TLS 1.2 is the minimum de facto standard nowadays.
The point of certmate is to have a simple url like https://certmate/domain/tls to grab a valid cert from wherever I am, any time. This because I focused on DNS challenge only.
A good feat btw is the deploymenet check, where the app verify if the cert issued is the same deployed on public FQDN.
Of course some more interesting additional features will be added soon like:
- multiple cloud accounts support - deploy to remote nodes - vault integration/support
Enjoy and contribute!
I like how docker and kubernetes were supposed to solve dependency problems.
But then I read:
Prerequisites Docker 20.10+ Docker Compose 2.0+.
So now if I have app that can run on v19 I need docker for dockers :) to use CertMate because if I upgrade my other apps might be messed up.
Yeah, nobody should ever employ features that only work on newer versions of software because then someone somewhere might not be able to make use of them.
But less snarkily, maybe put in the work to hack up their dockerfiles if you want to do something they don't directly support.
Sounds cool, but what if you don't use one of the listed DNS providers, but rather run your own DNS? I didn't see an option that would let you do that.
RFC2136 would let you do that, though setting it up is “an exercise left up to the reader”. My suggestion would be to get RFC2136 working with certbot first.
hello, certmate dev here :)
Custom DNS servers are already supported via certbot-dns-rfc2136 plugin as you suggested!
So this just writes the certificates to disk and you still have to manage binding certificates to services? I’m using Caddy in-front of containers using Cloudflare DNS and it works amazingly. Zero configuration.