Generate self-signed x509 certificates valid for multiple URLs/IPs
1–10 of 25 posts
Re: Generate self-signed x509 certificates valid for multiple URLs/IPs
#2Re: Generate self-signed x509 certificates valid for multiple URLs/IPs
#3While 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
#4While 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.
So, never blindly pipe the web into your bash, kids.
Re: Generate self-signed x509 certificates valid for multiple URLs/IPs
#5That's a bit concerning to me. One would hope that the default behavior would be to put a passphrase on the key.
Re: Generate self-signed x509 certificates valid for multiple URLs/IPs
#6"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.
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"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.
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 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
#9Earlier 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.
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?