Mkcert and certbot are new utilities. OpenSSL predates them by decades.

Before acme, someone had to create a CSR manually, often using OpenSSL.

Also, should therw be a separate tool to debug and inspect ssl certs and connection? How many individual tools should there be?

Perhaps it's worth mentioning XCA [1] at this point. It's a GUI based on openssl that provides an intuitive UI for managing keys, certs (root CA, intermediate CA, server and client) and CSR. It existed before acme and mkcert. What I liked in XCA was that it made it easy to review all parameters related to the operations it managed.

[1] https://hohnstaedt.de/xca/index.php

I continue to use it even today for small root stores I manage for internal networks. Very clean and intuitive UI that gets the job done well.

Also using Kleopatra for GPG keys.

+1 XCA. It is a fantastic way to manage your own root CA.

There should be lots of individual tools.

I have bad news for you: LetsEncrypt and ACME are almost 10 years old. Like the rest of us, you're getting old.

LetsEncrypt was founded 7 and started issuing certs about 6 years ago.

> There should be lots of individual tools.

Maybe there should be, but for many things that openssl can do (for example, testing and debugging a TLS connection, examining the contents of a certificate, creating a CSR to send to a non-ACME CA, converting between different formats of certificates, etc.) I'm not aware of good single-purpose tools.

> There should be lots of individual tools.

Arguably, OpenSSL is a collection of lots of individual tools. Each of the tabs in the "GUI" is an individual command with its own man-page, etc.

Each command still brings a lot of of options and therefore complexity with it, but that's because the domain is complex.

openssl is more than twice as old as that.

> Mkcert and certbot are new utilities. OpenSSL predates them by decades.

Certbot has been around for 7 years at this point, and is the same age as VS code. Frankly at this stage there's very little excise to not use it.

I use certbot to maintain valid certificates for my website, but there are more use cases for certificates than just https binding--and not all of them lend themselves to LetsEncrypt provisioning. The openssl CLI is definitely not simple, but in my experience it has often been the best available tool for various use cases.

You must use openssl to convert your useless certbot certificates and private keys into something that a Java program can actually use.

> You want tools designed to do one thing well, not one tool that offers a thin layer of getopt() over a low-level cryptography API.

Actually, to understand how certs, TLS and the web PKI system works in detail, I do want exactly that.

To learn, sure. Just write it yourself then.

To use day by day? No way. It's like running your car with a cross-section cut out. Fun to look at! Might work! Might break when you stick your finger in a moving part.

But these are expert level tools. The "running your car" equivalent for TLS is making sure the little padlock is closed in your browser.

A car mechanic has a ton of shit in his shop from hydraulic plattforms to torque wrenches and electronic diagnostic equipment, but you only need to put gas in and go to the shop when a warning light comes on

> You want tools designed to do one thing well, not one tool that offers a thin layer of getopt() over a low-level cryptography API.

I want both. Different higher-level crypto tools have different limitations, whereas OpenSSL can do absolutely anything I could ever want. When I'm trying to get BouncyCastle, PyCrypto and whatever library that random IoT device that I need to reverse engineer uses to play nicely together, I need a tool that can work with all of them. There are so many weird extensions and optional parts of the standards that I need to configure just right and no high-level tools expose all of them.

Sometimes you just need to generate a key or check a cert and for that, high-level tools are far better. But sometimes you need to do something in just the right way because of reasons outside of your control and in that case, you need to have every single one of those options and switches at your disposal.

> most people should be using nothing but certbot and mkcert

Most people likely don't know (and don't have to) about any of those, possibly most tech workers could indeed get away with just those two (though openssl has useful functionality other than key/certificate generation, but I guess one can avoid using that too), yet even mildly advanced usage would require more advanced tools. Actually certbot is primarily an ACME client, so not easily interchangeable with/comparable to openssl, while mkcert only covers one very specific use case: probably common in that middle group, but I don't quite see why it needs a separate program: a basic shell script (or an alias) would achieve that.

> You want tools designed to do one thing well, not one tool that offers a thin layer of getopt() over a low-level cryptography API.

Well, it offers that thin layer rather well! Seriously though, there's likely some middle ground between mkcert's lack of options and openssl's functionality covering a lot of other bits in addition to X.509 certificates. Though then again, you can consider `openssl x509` as basically a separate program, with its own man page and options -- and then it focuses on one thing, providing a rather complete functionality.

Middle ground certainly exists and has done for decades already. MacOS X has shipped with a very capable PKI GUI for a long time. It's obscure and not well known, but:

1. Start the Keychain App and you can manage your certs and keys.

2. Click the app menu, Certificate Assistant and then one of the options there to open wizards for various PKI related tasks.

The certificate assistant is quite amazing. It can do an enormous amount of stuff, including things like actually running a whole CA for you complete with creating root certs, intermediate certs, gathering CSRs, converting them into issued certs, evaluating cert validity, rendering cert contents and so on.

People don't know about it because only developers interact with certs really, and documentation likes to have copy/pasteable commands that work on Linux as well as OS X.

I would really want a tool that is a kinda swiss army knife of TLS functionality, but usable. Yet such a tool to my knowledge does not exist.

E.g. something like "check the OCSP for this certificate". This should be a simple command.

> What bugs me a little is the idea that you might want a well-designed version of what the OpenSSL CLI offers. Bad idea! You want tools designed to do one thing well, not one tool that offers a thin layer of getopt() over a low-level cryptography API.

To exaggerate a bit: should you always want a tool that's one button that's all some other dude's opinions? Isn't there a place for a tool like "well-designed version of what the OpenSSL CLI," but as something that would be less frequently used?

I think the point is that there should be multiple tools, each with its own UX that's specifically tailored towards one particular scenario that OpenSSL covers, and with customizable options that are relevant to that scenario.

I'd rather use the OpenSSL CLI than a tool that pukes an irrelevant emoji after every line of output.

There are lots of systems that don't support ACME. Enterprise firewalls for example are just starting to support it. Lots of embedded devices still do not support it. Older enterprise servers have either very poor or not compatible enough to make it work reliably.

GUI's can be counter productive for theses kind of tool. There are some contexts like "SSL" were the user needs to understand the underlaying concepts a UI cannot teach in itself

Does a config file or a pile of cli flags do a better job of teaching new users the domain?

I believe they do. Configuration files usually have comments, GUIs typically lack that or documentation. If they do not, you have to look it up somewhere. GUIs could have documentation, but it is very rare I would say. It is something similar with the CLI flags as well. That is just my opinion. Maybe I am the only one who reads manual pages that explain what a CLI flag is supposed to do, or for example what key X means in a configuration file.

I have been taught more by those two, than by GUI. The only thing I could imagine that may teach me through GUI is Smalltalk, but that is very limited. On top of that, GUIs might be less common for whatever reasons as well in the UNIX world.

Configuration files occasionally have comments. CLIs sometimes have man pages. GUIs sometimes have tooltips and often have additional help documentation. I'd say that's pretty much a wash. But GUIs can also much more easily convey complex relations between options, such as some option only taking effect when another two each have a specific value, or even simpler things there being a specific set of permitted values for an option. Sure, you can document the cli but that information is probably going to be inherently presented as part of the GUI.