

Generate self-signed x509 certificates valid for multiple URLs/IPs - tiyema
https://github.com/frntn/x509-san

======
diafygi
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

~~~
tiyema
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

~~~
tiyema
Also, looking at the gencert.sh file
([https://github.com/frntn/x509-san/blob/686f0468/gencert.sh](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)

------
ge0rg
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.

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

~~~
fit2rule
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.

~~~
digitalsushi
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?

~~~
lmm
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.

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

~~~
lmm
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.

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

~~~
lmm
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).

------
Someone1234
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."

------
praseodym
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](https://gist.github.com/praseodym/8186510)

------
akerl_
"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.

~~~
praseodym
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.

~~~
Someone1234
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.

~~~
edwintorok
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).

