Skip to content(if available)orjump to list(if available)

If OpenSSL were a GUI (2022)

If OpenSSL were a GUI (2022)

58 comments

·January 27, 2025
Visit

KronisLV

Actually, the example has way better discoverability than most CLI software, especially if every option had tooltips illustrating what it's for in more detail.

For an actually good example of adjacent software, have a look at Keystore Explorer: https://keystore-explorer.org/

I do manage my own CA for some development servers with it, way less of a headache than trying to remember a bunch of arbitrary commands (though obviously not well suited for any sort of automation, which I don't need in that specific use case).

For an example of a pleasant CLI with some good discoverability, I've always liked Docker's approach, where the commands are organized in a tree and entering a command without any arguments will print its usage in a useful format: https://docs.docker.com/reference/cli/docker/

  $>docker
  
  Usage:  docker [OPTIONS] COMMAND
  
  A self-sufficient runtime for containers
  
  Common Commands:
    run         Create and run a new container from an image
    exec        Execute a command in a running container
    ps          List containers
    build       Build an image from a Dockerfile
    pull        Download an image from a registry
    push        Upload an image to a registry
    images      List images
    login       Log in to a registry
    logout      Log out from a registry
    search      Search Docker Hub for images
    version     Show the Docker version information
    info        Display system-wide information
  
  ...

nyreed

This may be a nice example of the benefits and drawbacks of GUI vs CLI software.

Sure OpenSSL has myriad inscrutable options, but the majority of these probably aren't going to be used by 90% of people. Yet including them in a CLI gives less clutter/overhead versus what they would in a GUI. They can just stay out of the way for the people who need them.

I guess the same could be said of an "Advanced Features" second page of a GUI though.

mtillman

My favorite part is the punchline:

“This is incomplete. It covers about 80% of one corner of OpenSSL's functionality. The certificate policy options have a lot more knobs that I didn't include.”

tptacek

The OpenSSL command line is more or less a test driver / reference for the library. It's a little weird to criticize its UX. Also: it's pretty easy to make something look bananas if you surface every obscure option in its main screen!

epistasis

I don't think it's a critique of the library; calling the x509 specification complex enough to be magic seems accurate.

Honestly I love the UI presented: concise, shows all the options, a fantastic summary of the CLI without having to scroll a massive man page or website.

I'd love this for all the super complex CLI tools I need to use, as a visual cheatsheet on where to search in the man page.

AlotOfReading

I wrote a personal tool to do this automatically by parsing '--help' after I couldn't remember the tar options for the millionth time. Turns out the programs that have complicated, undiscoverable interfaces also tend to omit useful options from automatically discoverable documentation, so it wasn't especially reliable.

BoingBoomTschak

Reminds me of a similar wish for argv introspection I had at some point (e.g. https://github.com/ImageMagick/ImageMagick/issues/7688) that went nowhere. I hardcoded curl this way.

yakkers

A long time ago, Apple actually did more or less this for the coreutils in A/UX, which was their own UNIX for the 68k Macintoshes.

This page has a screenshot of the GUI provided for ls: http://toastytech.com/guis/aux3.html

FergusArgyll

What an incredible website

gyomu

I’ve always found it a shame that the UNIX philosophy seemed to stop at system/command line tools and no one ever took the further step to apply it to user interfaces.

UIs generated in systematic, composable ways emerging naturally from all the plumbing (pipes, option flags, etc) we already have in place.

tpmoney

Every few years I get the urge to dive into smalltalk/squeak/cuis/<insert smalltalk variant here> and while it suffers from being pretty heavily stuck in an era and a small community it always feels like a window into what could have been if operating systems in general and unix in particular didn’t stop at CLIs with a window manager tacked on top. In fact having recently revisited some old classic Mac things, it’s sort of interesting to note how despite how nice it is that osx has Unix underneath and windows has the WSL it also means we’re converging on a design with a lot of old baggage.

perching_aix

There was a time when I'd have agreed with you. But over time I've come to honestly disagree, perhaps unsurprisingly, since I detest the typical command line experience too.

Just like when books are adapted into movies, the good adaptations are the ones that are better than the sum of their parts (aren't a direct adaptation). Blind, generic composability is in direct contradiction with this. One could argue that it's the scale that determines whether a better integrated or a consistent but generic solution is better, but in this case I think the article very explicitly demonstrates that the latter approach is what loses out.

I have a very strong and persistent disdain towards the many shell incantations I had to come up with, have to keep around as notes, and have to have AI generated. Having to navigate the maze the article calls a GUI would result in much the same.

I feel like I'm taking crazy pills seeing people in this thread regarding this visual any good, especially given how even the article author clearly disagrees, hence "why" the article was created in the first place.

rsanek

https://github.com/chriskiehl/Gooey

behringer

I'd love this for all the cli tools. Instead we'll get more boot managers and desktop managers.

bckr

Consider helping make such a thing!

teruakohatu

> The OpenSSL command line is more or less a test driver / reference for the library

hmmm, not sure about that. Its the main (only?) interface if an individual wants to mess with certificates or generate them. It is often reported ACME/LE took off because it is easier to configure an ACME client than the annual wrestling with openssl. But if openssl had been easy for common user tasks maybe LE would have taken longer to be adopted.

ffmpeg also has a notoriously difficult CLI interface. Today you can just ask a LLM to generate you a command, the consequences are low if it gets it slightly wrong. The consequences of getting openssl wrong could not be obvious immediately and result in a lot of debugging down the line.

throwup238

LE took off because everyone was charging ridiculous amounts for certificates and few people needed the verification that comes with that. ISRG created ACME for LE.

tpmoney

One of my personal frustrations with SSL as implemented in most systems is the conflation between encrypted communication and verified communication. SSH sort of got this right with ToFU as a default behavior but I think a lot of the resistance and difficulty in adopting SSL for encrypted intranet communication comes from the need to do the CA and cert signing song and dance. If you could turn on encryption without needing to do ID validation by default it would make things easier for people

I know that encrypted communication without knowing that your talking to the right person is somewhat useless, but it works for SSH most of the time, there’s no reason it couldn’t work well for https and encrypted db connections etc.

larusso

I think you are right. On the other hand it’s the fact that a lot of tutorials / getting started guides etc include some ssl invocations to execute a specific command for key/cert creation. And a user wishing to adjust and maybe understand things gets thrown at a man page that is so overloaded. Similar to git. But git’s cli at least has a clear setup with optional vs mandatory values. I always disliked commandline interfaces with mandatory option fields.

tuwtuwtuwtuw

Where do I find the UI for it then?

fzeindl

At every enterprise job I have been in, there was always a quagmire around renewing or exchanging certificates.

The corresponding tasks always required disproportionately many high-level meetings and discussions for their actual simplicity.

I always attributed this directly to the complexity of the OpenSSL command and the fact that these tasks include hard deadlines because of certificate runtime.

The complex discussions which ultimately result in some simple commands mirror the OpenSSL CLI: you have to understand and articulate precisely what you need.

That being said I wonder some of the options (like "this file is a CER", PEM vs DER private key, etc.) couldn't be replaced by auto detection.

dang

Related:

If OpenSSL were a GUI - https://news.ycombinator.com/item?id=31697636 - June 2022 (234 comments)

tivert

I'm looking forward to "If Python Were a GUI."

LeoPanthera

Well... https://docs.python.org/3/library/idle.html

blooalien

Also, Jupyter(Lab,Notebook,QtConsole,etc), Marimo, Spyder, and a bunch of other good GUI-like options. :)

alyandon

Tangentially related, if you generate certificates infrequently enough that you always have to look up openssl command line options check out https://github.com/chris2511/xca/.

It's basically keepass but for certs instead of passwords.

mrtksn

Is this fair though? Most common tasks have tutorials all over the net, so creating a GUI should consider these use cases instead of piling every option on the main UI. Many of these things are also just options that are right for one system and the user will use always the same parameters, therefore you should be able to hide this in the settings instead of showing everything at the same time all the time.

GoblinSlayer

It's not really hypothetical, putty settings dialog has similar complexity, but is implemented as a settings tree and designed to fit ergonomically on 640*480 screen.

userbinator

X.509 certificates are not simple, the majority of the complexity being in the extensions, and OpenSSL's x509 command can be used for many different purposes. I am reminded of an old saying in the GUI vs CLI war: "what you see is all you get", and in this case, you get a lot.

aargh_aargh

I've found this tool handy for faster-than-man explanations of various CLI invocations:

https://explainshell.com/

Sadly, it hasn't been updated in years.