getssl VS boulder

A 'competitor' to this would be GetSSL which is a pure-shell ACME client (plus OpenSSL and cURL) and can be executed on one host, but send verification tokens to remote systems (where you may not have cron access):

> Get certificates for remote servers - The tokens used to provide validation of domain ownership, and the certificates themselves can be automatically copied to remote servers (via ssh, sftp or ftp for tokens). The script doesn't need to run on the server itself. This can be useful if you don't have access to run such scripts on the server itself, as it's a shared server for example.

* https://github.com/srvrco/getssl

I first got by with self signed certificates, but with all the major browsers warning they'll stop supporting those eventually I finally bit the bullet last month and installed getssl to automatically update all my certificates once a month.

because I didn't want to install another package manager (snapd) on my Ubuntu 18.04 server I checked the ACME Client Implementations page and decided to try getssl, a nice little shell script that does everything I need and then some.

I just have a dedicated container that runs getssl everyday. Anything that has a web interface (Or anything that requires TLS) gets it's own conf file that gets added to the daily check. Each conf file tells getssl how to load the certificate for its particular service.

I have been using https://github.com/srvrco/getssl for years on my raspberry pi. It's a much simpler Bash script that doesn't break after every update.

i have a problem where after installing getssl (https://github.com/srvrco/getssl) to /root/.getssl i populated it's contents with bunch of SSL files using Dockerfile's COPY command. And now no matter what i do they keep reappearing.

> acme.sh

Another shell-based ACME client I like is dehyradted. But for sending certs to remote systems from one central area, perhaps the shell-based GetSSL:

> Obtain SSL certificates from the letsencrypt.org ACME server. Suitable for automating the process on remote servers.

* https://github.com/srvrco/getssl

In general, what you may want to do is configure Ansible/Puppet/etc, and have your ACME client drop the new cert in a particular area and have your configuration management system push things out from there.

There's no reason you couldn't run your own ACME server (the Let's Encrypt folk publish an open source one, boulder, but there's plenty of others). Then you can just use certbot in your VMs to manage certificates, configured to point to your CA server instead of the Let's Encrypt one.

Let's Encrypt's ACME server is open source: https://github.com/letsencrypt/boulder

GP's post prompted me to look into LE's ACME server implementation, Boulder [1], but it's pretty apparent that Boulder is not suitable for small scale deployments. But the smallstep "certificates" project seems to be a lot more reasonable for this use-case. Thanks for sharing, I'll definitely check it out!

[1]: https://github.com/letsencrypt/boulder

There's also Boulder too which supposedly is what Let's Encrypt actually runs. But, I believe you have be running Python or Docker on your Linux server, where SmallStep didn't have that requirement.

Actually it is Open Source (I'd say "Free Software" but they're the same thing). The software that makes the CA work, Boulder, is here: https://github.com/letsencrypt/boulder and the end user software to get certificates which now called CertBot but was once just named "letsencrypt" is here: https://github.com/certbot/certbot

Why are you assuming that their workload includes just one query per emitted certificate?

The reality is that they are storing information during challenges, implementing rate limiting per-account, supporting OCSP validation and a few other things.

You can investigate further if you really want to see the queries that they make against the database since their software (Boulder) is open source [1]. Most queries are in the files in the "sa" (storage authority) folder.

[1] https://github.com/letsencrypt/boulder/

They won't pay any licensing fees at all when their whole stack is open source. They even wrote their own CA from scratch.