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


<WRAP info>
**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/.

</WRAP>

----

===== Prerequisites =====

Ensure that openssl is installed. 

<code bash>
sudo apt install openssl
</code>

<WRAP info>
**NOTE:**  Look at the openssl man page to understand all of the openssl options.

<code bash>
man openssl
</code>

</WRAP>

----

===== Create a self-signed certificate =====

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

<code bash>
openssl req -x509 -newkey rsa:2048 -keyout file1.key -out file2.crt -days 9999 -nodes
</code>

or

<code bash>
openssl req -new -x509 -days 9999 -nodes -out file1.pem -keyout file2.key
</code>

<WRAP info>
**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.). 

</WRAP>


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

<code>
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
</code>




<WRAP info>
**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.  

</WRAP>

<WRAP important>
<color red>**WARNING**</color>:  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.
</WRAP>



----

===== Broken down =====

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

<code bash>
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
</code>

----

===== Another method =====

<code bash>
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'
</code>


----

===== Set Permissions for the certificate files =====

<code bash>
chmod 600 file1*
chmod 600 file2*
</code>

----

===== 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/