Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

An absolute joke how many loops one needs to go through to do this very basic thing. Hell, this command line is longer than the code required to start a web server in some programming languages.


To be fair, the complicated openssl invocation is largely because OpenSSL is crap. Let's break it down:

"openssl req x509"

This is a dodge because we don't actually want to write a CSR and then sign the cert, we're going to skip all that so we're using a sub-feature of a different sub-feature. Fine.

"-out localhost.crt -keyout localhost.key"

There surely must be nicer ways to set this, but it's not so objectionable...

"-newkey rsa:2048"

This is arguably boiler-plate, the configuration file can set this default, but there's a good chance "your" config file was pasted in by an OS vendor ten years ago and says e.g. 1024-bit RSA, or worse.

"-nodes -sha256"

Now we're getting into the nonsense. We don't want DES encryption. Nobody wants DES encryption, and if we did want DES encryption we could specify the passphrase for it, which we didn't, so this needn't be here. SHA-256 has been the reasonable baseline choice here for years and so likewise we shouldn't need to specify.

"-subj '/CN=localhost'"

This is pointlessly arcane and shouldn't be needed, but it's only partly OpenSSL's fault. This abuse of X.509 Common Name was obsolete on the Internet last century, and it's annoying the people were still coming to terms with that in the last few years so that certs which lack Common Name often don't interoperate, and thus it's easier to put it in anyway.

"-extensions ...."

This part, which involves a multi-line sub-shell and other shenanigans, is completely out of hand. This is the shortest, least crazy way to ask for the certificate practically everybody running OpenSSL actually wants, and yet instead of being the default or offered with some easy to understand command line parameter, even in brand new versions of OpenSSL it's done only by this arcane hack.

All Web PKI certificates this century are supposed to use SANs (Subject Alternative Names), so you'd expect an openssl feature named say, "-san" which adds one such name, and OK, this being OpenSSL maybe you'd need to manually write "DNS:localhost" rather than it being smart enough to figure it out if you write "localhost". That'd be stupid, but par for OpenSSL. But no, you have to manually specify how SAN extensions even work in the X.509 certificate, as if it has never seen one before, even though every valid cert for the Web PKI has one. It's like if Firefox made you type not just the HTTP port default of 80 into URLs, but actually made you specify that you want to use TCP/IP in case maybe you're using Novell IPX or something.


FYI, OpenSSL has a new flag that makes the "-extensions" part somewhat simpler, but most people won't have it in their copy yet: https://github.com/openssl/openssl/pull/4986


Interesting, is it normal that there are no tests for features like that, or does it happen somewhere else?


In fairness, shorter than `python3 -m http.server` is an awfully low bar.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: