Changes

Jump to navigation Jump to search
2,792 bytes added ,  19:59, 11 February 2018
Line 24: Line 24:     
Fuente: www.akadia.com/services/ssh_test_certificate.html
 
Fuente: www.akadia.com/services/ssh_test_certificate.html
 +
== SubjectAltName ==
 +
Find your openssl.cnf file. It is likely located in /usr/lib/ssl/openssl.cnf
 +
 +
First, modify the req parameters. Add an alternate_names section to openssl.cnf with the names you want to use. There are no existing alternate_names sections, so it does not matter where you add it.
 +
 +
[ alternate_names ]
 +
DNS.1        = example.com
 +
DNS.2        = www.example.com
 +
DNS.3        = mail.example.com
 +
DNS.4        = ftp.example.com
 +
 +
Next, add the following to the existing [ v3_ca ] section. Search for the exact string [ v3_ca ]:
 +
subjectAltName      = @alternate_names
 +
You might change keyUsage to the following under [ v3_ca ]:
 +
keyUsage = digitalSignature, keyEncipherment
 +
 +
 +
 +
 +
    Can someone help me with the exact syntax?
 +
 +
Its a three step process, and it involves modifying openssl.cnf file. You might be able to do it with only command line options, but I don't do it that way.
 +
 +
Find your openssl.cnf file. It is likely located in /usr/lib/ssl/openssl.cnf:
 +
 +
$ find /usr/lib -name openssl.cnf
 +
/usr/lib/openssl.cnf
 +
/usr/lib/openssh/openssl.cnf
 +
/usr/lib/ssl/openssl.cnf
 +
 +
On my Debian system, /usr/lib/ssl/openssl.cnf is used by the built-in openssl program. On recent Debian systems it is located at /etc/ssl/openssl.cnf
 +
 +
You can determine which openssl.cnf is being used by adding a spurious XXX to the file and see if openssl chokes.
 +
 +
First, modify the req parameters. Add an alternate_names section to openssl.cnf with the names you want to use. There are no existing alternate_names sections, so it does not matter where you add it.
 +
 +
[ alternate_names ]
 +
 +
DNS.1        = example.com
 +
DNS.2        = www.example.com
 +
DNS.3        = mail.example.com
 +
DNS.4        = ftp.example.com
 +
 +
Next, add the following to the existing [ v3_ca ] section. Search for the exact string [ v3_ca ]:
 +
 +
subjectAltName      = @alternate_names
 +
 +
You might change keyUsage to the following under [ v3_ca ]:
 +
 +
keyUsage = digitalSignature, keyEncipherment
 +
 +
digitalSignature and keyEncipherment are standard faire for a server certificate. Don't worry about nonRepudiation. Its a useless bit thought up by comp sci guys who wanted to be lawyers. It means nothing in the legal world.
 +
 +
In the end, the IETF (RFC 5280), Browsers and CAs run fast and loose, so it probably does not matter what key usage you provide.
 +
Second, modify the signing parameters. Find this line under the CA_default section:
 +
# Extension copying option: use with caution.
 +
# copy_extensions = copy
 +
 +
And change it to:
 +
# Extension copying option: use with caution.
 +
copy_extensions = copy
 +
 +
Third, generate your self-signed:
 +
$ openssl genrsa -out private.key 3072
 +
$ openssl req -new -x509 -key private.key -sha256 -out certificate.pem -days 730
 +
 +
Finally, examine the certificate:
 +
$ openssl x509 -in certificate.pem -text -noout
 +
 
== Generate self signed certificate ==
 
== Generate self signed certificate ==
 
# Generate a Private Key
 
# Generate a Private Key
Line 34: Line 103:  
# Generate Self-Signed Certificate
 
# Generate Self-Signed Certificate
 
#:<source lang="bash">openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt</source>will generate a temporary certificate which is good for 365 days
 
#:<source lang="bash">openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt</source>will generate a temporary certificate which is good for 365 days
 +
 
== Create your own CA ==
 
== Create your own CA ==
 
* Create the root key
 
* Create the root key

Navigation menu