4 ms·

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

35 points by tiyema 11y ago

ge0rg 11y ago
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 11y ago
  Good point. Download the script, read it, add it as a function in your bashrc if you trust it.
  - fit2rule 11y ago
    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 11y ago
      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 11y ago
        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 11y ago
        Well, latest SSH vulnerabilities came from the official repos as well. Sure, those were bugs not evil modifications, but still.
        lmm 11y ago
        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 11y ago
        Is there a distro with a stronger policy than Debian? what are you using now?
        lmm 11y ago
        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).
      - solidpy 11y ago
        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 https://github.com/docker/notary
- nitramnitram 11y ago
  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?
akerl_ 11y ago
"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.
- VeejayRampay 11y ago
  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/205413738-Obtain-and-Install-SSL-Certificates 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.
  - akerl_ 11y ago
    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"
- praseodym 11y ago
  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 11y ago
    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.
diafygi 11y ago
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 11y ago
  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 11y ago
    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)
praseodym 11y ago
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
Someone1234 11y ago
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."

35 points by tiyema 11y ago

ge0rg 11y ago

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 11y ago
Good point. Download the script, read it, add it as a function in your bashrc if you trust it.
- fit2rule 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        Well, latest SSH vulnerabilities came from the official repos as well. Sure, those were bugs not evil modifications, but still.
        lmm 11y ago
        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 11y ago
        Is there a distro with a stronger policy than Debian? what are you using now?
        lmm 11y ago
        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).
    - solidpy 11y ago
      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 https://github.com/docker/notary
nitramnitram 11y ago
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?

akerl_ 11y ago

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

VeejayRampay 11y ago
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/205413738-Obtain-and-Install-SSL-Certificates 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.
- akerl_ 11y ago
  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"
praseodym 11y ago
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 11y ago
  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.

diafygi 11y ago

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 11y ago
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 11y ago
  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)

praseodym 11y ago

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

Someone1234 11y ago

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