getssl VS uacme

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.

> So you're saying telemetry should be handled as a separate process that has nothing to do with the rest of the browser, and treated like a hostile service? [... T]his was a dumb bug and it is completely unreasonable to expect some kind of adversarial design "just in case a freak bug triggers on telemetry network requests".

I absolutely agree that this a dumb bug having little to nothing to do with telemetry. It is not even the first case-sensitivity HTTP/3 bug I’m personally encountering in the course of completely casual use[1].

At the same time, you know what? I’m glad you suggested this, because I certainly didn’t think of it. Yes, in an ideal world, telemetry absolutely should be a separate process (or thread, or at least not share an event loop—a separate “hang domain”, a vat[2] if you want). And so should everything off the critical path.

I’m not saying Firefox is bad for doing it differently. I’m saying it’s silly that Firefox is forced to play OS to such an extent because the actual one isn’t up to its demands.

[1] https://github.com/ndilieto/uacme/pull/11

[2] http://www.erights.org/elib/concurrency/vat.html

Hmm .... not sure i'd necessarily say that's where i'm coming from. i'd be happy with a mix'n'match OS if most of the individual components were created and maintained with thought and care. (As distinct from e.g. "Over the last couple of weekends I learned Rust, and here's my first full program, an encrypted chat server. Enjoy!") Like, SQLite is not maintained by the OpenBSD project, but i believe it's generally considered to be a high-quality codebase. And i recently started using uacme on my server; i don't feel competent enough in C to comment directly on the quality of the codebase, but this and this indicate to me that the author has a clue (and in fact, i feel confident that they have far more of a clue than i do).