Generate self-signed x509 certificates valid for multiple URLs/IPs | Hacker News Reader

Generate self-signed x509 certificates valid for multiple URLs/IPs

github.com

35 pointstiyema24 comments

This can be a one-liner in openssl:

    openssl req -new -sha256 -x509 -days 365 -newkey RSA:4096 -nodes -keyout domain.key -subj "/CN=example.com" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:www.example.com,DNS:mail.example.com")) -out domain.crt

For a CSR, the same technique can be used:

    openssl req -new -sha256 -newkey RSA:4096 -nodes -keyout domain.key -subj "/CN=example.com" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:www.example.com,DNS:mail.example.com")) -out domain.csr

It works too thanks.

We should also notify the differences : I have compared both and have noticed your oneliner generates a CA certificate (which may not be what we want). Also the oneliner rely on the /etc/ssl/openssl.conf file which can change over the time, so the generated certificate may be affected too

Also, looking at the gencert.sh file (https://github.com/frntn/x509-san/blob/686f0468/gencert.sh) we can see it also uses a oneliner with process substitution. (may be unrelevant but that kind of nice too)

While helper scripts for OpenSSLs arcane syntax are highly appreciated, running some .sh file downloaded from the Internet is not the wisest of security ideas. The author (or somebody from GitHub) could just replace this script with one that actually uploads your freshly-generated private key to somewhere.

Good point. Download the script, read it, add it as a function in your bashrc if you trust it.

For example, in this case any cert you blindly create with the example will have you located in Paris, France, which may not be accurate.

So, never blindly pipe the web into your bash, kids.

You know, I've struggled with this concept. I agree that we shouldn't pipe a URL into a bash script without knowing what it is.

But an unsigned software repository that calls post install scripts seems just as absolutely easy to modify, and we see those regularly.

My software is most easily installed with a piped bash script. In the script contents, I try to explain what's going on. I also at the top indicate that you shouldn't just trust what I am telling you. And then in the documentation, where you are told how to run the script, I tell you to be cautious there as well. (The script just installs the repository, and from there it's all signed and delivered over https).

I could never get over how easy it would be to whitewash a bash script with an rpm just to get some psychological credibility.

If it's not signed and/or delivered over https, it's completely hackable.

That first step of trust, how?

People who are serious about their security run something like Debian and only install from the official repositories, where all packages are signed with GPG and all package maintainers must be part of the web of trust (i.e. have had their identity vouched for by at least one other Debian maintainer).

Of course you have to make sure the original install is trustworthy; all you can really do for that is compare the .iso checksum on several different machines. If all those machines are compromised (or there's a hardware-level compromise of your machine) then you're doomed, but that at least makes attacking a lot more costly than it would otherwise be.

Well, latest SSH vulnerabilities came from the official repos as well. Sure, those were bugs not evil modifications, but still.

Yeah, I know. That was awful and should have resulted in policy changes; it hasn't, and I don't use Debian any more. But it makes a good example of the right approach to package infrastructure.

Is there a distro with a stronger policy than Debian? what are you using now?

I wouldn't think stronger than Debian, but there are plenty of distros with equivalent policies. At the moment I'm running FreeBSD (not especially for security reasons).

Checkout docker-notary [0] a tool for checking signatures that you can pipe in between the download and execution of the script.

[0] https://github.com/docker/notary

How does this differ from any other software? Either you trust the author, or you don't. I assume you haven't reviewed your entire stack to prevent it from including evil code?

Fair warning: Firefox specifically won't accept a certificate for an IP address at all ever. It will treat the "domain" like it is mismatching the CN even when they're identical.

It will work fine for self-signed otherwise, you just have to install the root CA into the Firefox trusted store (it doesn't share the operating system's store like other browsers do).

There are a few bugs open about the issue, but they often date back over five years so don't expect this to get fixed. They claim it is a security "feature."

I've used a similar script to create CSRs; you'll have to use the same messy OpenSSL syntax. See https://gist.github.com/praseodym/8186510

"Secure \n\n The generated private key is passwordless by default."

That's a bit concerning to me. One would hope that the default behavior would be to put a passphrase on the key.

It's apparently a requirement for various cloud platforms that the private key doesn't use a passphrase (probably due to automated scripts where the passphrase cannot be provided).

See Engine Yard for example (not an exception as far I know): https://support.cloud.engineyard.com/hc/en-us/articles/20541...

Now I am not saying the situation is ideal or that I condone it, just passing the information along.

Yea, for things where you're giving the private key to somebody, there's a whole corpus of debate on how useful a passphrase would be even if you could give it to them.

For that reason, I'm OK with the default being to passphrase and there being a section of the docs that says "hey, if you need to not have a passphrase for your use case, here's how to strip it off"

If an attacker can get access to your (encrypted) private key file, you have other things to worry about. And the passphrase doesn't help against memory-based attacks (e.g. Heartbleed) anyway.

A passphrase is mostly a hassle; someone will have to enter it after maintenance or (worse) a power outage.

I agree, I find passwords on certificates useful in some circumstances and bothersome in others.

I think putting a password on a root CA certificate is just a bother without any REAL security advantages. First off you'll need to enter it on every restart, secondary the raw private key will need to be in memory after that (which is trivial to extract), and lastly if the machine is completely owned anyway, this seems like "rearrange the deck chairs on the Titanic."

Now putting a password on your SSH keys? Heck yeah. Otherwise if you forget to lock your machine just once, someone can sit down, open your SSH client of choice and have access to a remote session as "you" without the need for a single password. It might not be unbreakable but it is a nice extra layer of security that buys you time if your laptop gets stolen or similar.

if you use that CA to issue a leaf certificate for your server then you don't need the root CA's password or decrypted private key to be in memory all the time, but then of course you make generating self-signed certs more complicate (generate self-signed root CA protected with password, and use that to issue a passworddless leaf certificate).

The fact that you make several valid points doesn't mean keys shouldn't default to having passphrases.

Yes, there are attack vectors which having a passphrase doesn't protect against.

Yes, passphrases require additional considerations when starting services.

No, this doesn't mean they're "mostly a hassle".

No, you probably shouldn't default to passphraseless keys.

In at least 99.9% of cases, the an RSA private key used by a service will be stored unencrypted.

Would having a default that's the opposite of what nearly all users want be sensible?

Reply on news.ycombinator.com