Ubuntu - Certificates - Create a self-signed certificate

A self-signed certificate made in this way is sufficient for testing, but should not be used in a production environment.

NOTE:

Many clients require that the certificate presented by the server be a user (also called “leaf” or “site”) certificate, and not a self-signed certificate.
- In this situation, the self-signed certificate must be installed on the client host as a trusted root certification authority (CA), and the certificate used must be a user certificate signed with that self-signed certificate.

For information on creating self-signed CA certificates and using them to sign user certificates, see the General implementation overview chapter of the Open-source PKI book, available online at http://ospkibook.sourceforge.net/.

Prerequisites

Ensure that openssl is installed.

sudo apt install openssl

NOTE: Look at the openssl man page to understand all of the openssl options.

man openssl

Create a self-signed certificate

Create a self-signed certificate using the req command provided with OpenSSL:

openssl req -x509 -newkey rsa:2048 -keyout file1.key -out file2.crt -days 9999 -nodes

or

openssl req -new -x509 -days 9999 -nodes -out file1.pem -keyout file2.key

NOTE: Here, we name our certificate and key “file1” and “file2”, but when you have multiple certificates, they will require different names, or, should reside in different sub-directories of /etc/ssl.

You could, in /etc/ssl/localcerts, have several certificates and name them according to domain (i.e. somesite.com.pem and somesite.com.key, othersite.net.pem and othersite.net.key, etc.).

This will prompt with a number of questions. Answer as appropriate.

Generating a 2048 bit RSA private key
...........................+++
...........................................................................+++
writing new private key to 'my_cert.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:JE
State or Province Name (full name) [Some-State]:Jersey  
Locality Name (eg, city) []:St. Helier
Organization Name (eg, company) [Internet Widgits Pty Ltd]:ShareWiz International
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:sharewiz.net
Email Address []:admin@sharewiz.net

NOTE:

openssl: This is the basic command line tool for creating and managing OpenSSL certificates, keys, and other files.
req: This subcommand specifies that we want to use X.509 certificate signing request (CSR) management. The “X.509” is a public key infrastructure standard that SSL and TLS adheres to for its key and certificate management. We want to create a new X.509 cert, so we are using this subcommand.
-x509: This further modifies the previous subcommand by telling the utility that we want to make a self-signed certificate instead of generating a certificate signing request, as would normally happen.
-newkey rsa:2048: This specifies that we want to generate a new certificate and a new key at the same time. We did not create the key that is required to sign the certificate in a previous step, so we need to create it along with the certificate. The rsa:2048 portion tells it to make an RSA key that is 2048 bits long.
-keyout: This line tells OpenSSL where to place the generated private key file that we are creating.
-out: This tells OpenSSL where to place the certificate that we are creating.
-days 9999: This option sets the length of time that the certificate will be considered valid.
-nodes: This tells OpenSSL to skip the option to secure our certificate with a passphrase. Many applications, such as NginX need to be able to read the certificate file without user intervention, when the server starts up. A passphrase would prevent this from happening because a password would have to be entered after every restart.

file1 and file2 can be the same file; the key and the certificate are delimited and so can be identified independently.

WARNING: we are now past the point where 9999 days takes us past the 32-bit Unix epoch.

If the system uses unsigned time_t (most do) and is 32-bit, then the above command might produce a date in the past.
Think carefully about the lifetime of the systems you are deploying, and either reduce the duration of the certificate or reconsider your platform deployment.
- Reducing the duration is the most likely choice, but the inexorable progression of time takes us steadily towards an era where this will not be a sensible resolution.

Broken down

The same code as above, but split into separate commands:

openssl req -new -out file1.pem -keyout file2.pem
openssl rsa -in file2.pem -out www.key
openssl req -x509 -in file1.pem -out www.crt -key www.key -days 3650

Another method

openssl req -new -x509 -days 3650 \
  -newkey rsa:2048 -nodes -keyout test.key \
  -out test.crt \
  -subj '/C=PL/ST=example/O=ShareWiz/OU=test/CN=test'

Set Permissions for the certificate files

chmod 600 file1*
chmod 600 file2*

References

https://wiki.debian.org/Self-Signed_Certificate

http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#aboutcerts

http://nginx.org/en/docs/http/configuring_https_servers.html

http://ospkibook.sourceforge.net/

Wiki

Table of Contents