This is an old revision of the document!

Ubuntu - Certificates - Create a self-signed certificate

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

NOTE: Here, we named 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.

NOTE: A self-signed certificate made in this way is sufficient for testing, and may be adequate for all your requirements if you are mainly interested in encrypting transfers, and not in secure identification.

However, 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 described above must be installed on the client host as a trusted root certification authority (CA), and the certificate used by Exim 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/.

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'

References

http://ospkibook.sourceforge.net/

Wiki

Table of Contents