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.
PeterStuer · 1h ago
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.
weddpros · 2h ago
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
woleium · 7h ago
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?
browningstreet · 7h ago
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.
vivzkestrel · 5h ago
unfortunately outside tech circles, most people still refer to it as SSL or HTTPS. They dont know about the intricacies of the changes involved
fab_space · 1h ago
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!
ozim · 10h ago
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.
meepmorp · 10h ago
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.
schwingy · 10h ago
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.
CaliforniaKarl · 10h ago
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.
fab_space · 37m ago
hello, certmate dev here :)
Custom DNS servers are already supported via certbot-dns-rfc2136 plugin as you suggested!
nodesocket · 6h ago
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.
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.
Their main concerns are getting browser "unsafe" warnings disappear and keep it so. They want nothing to do with cert issuance or renewal.
Shameless plug: if you need to cut through the noise of thousands of certs across thousands of hosts, there's https://sslboard.com
It seems a bit silly to call a new tool an SSL manager?
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.
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!
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.
But less snarkily, maybe put in the work to hack up their dockerfiles if you want to do something they don't directly support.
Custom DNS servers are already supported via certbot-dns-rfc2136 plugin as you suggested!