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.
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?
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.
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.
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
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.
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.