Live data from Hacker News

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

github.com

1–10 of 25 posts

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

#2
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.

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

#3
post #2

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.

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

#4
post #2

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.

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

#6
post #5

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

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

#7
post #5

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

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

#8
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 
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 

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

#9
post #4

Earlier quoted context omitted.

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?

Post reply on HN