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.
The CT Log scanning infrastructure is cloud based (rather bare metal actually), the application db, service, and Host scanning can be on-prem. An exceptional enterprise customer could convince me to offer a 100% on-prem solution
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.
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.
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.
Downside for me is that people FUCKING scream at me when I want to remove a piece and make it unsupported but FB, Google, Docker, Atlassian they can just get away with it.
So I reserve being pissed off for myself — that I can do and no one can stop me :D.
Or just making fun of whatever instance I find on the internet.
Question is "can you just do that" on whatever system you are working on, or maybe you have wait 10 years or you just switch company every 2 years to avoid dealing with it?
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.
Oh so this is only cloud hosted service, no on-prem option?
The CT Log scanning infrastructure is cloud based (rather bare metal actually), the application db, service, and Host scanning can be on-prem. An exceptional enterprise customer could convince me to offer a 100% on-prem solution
Helo and thank you to point out this tool I ignored before.
There is an opportunity to improve the tool then I added this feature as wanted feature in the plan as certmate dev :)
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.
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.
A feature I'd like would be creating & managing your own private CA in addition to using letsencrypt for public CAs.
suggestion noted and added to the upcoming major release :)
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!
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.
Well they could.
Downside for me is that people FUCKING scream at me when I want to remove a piece and make it unsupported but FB, Google, Docker, Atlassian they can just get away with it.
So I reserve being pissed off for myself — that I can do and no one can stop me :D.
Or just making fun of whatever instance I find on the internet.
Question is "can you just do that" on whatever system you are working on, or maybe you have wait 10 years or you just switch company every 2 years to avoid dealing with it?
My guy made this with AI -- not a bad thing, just an observation.