Differences

This shows you the differences between two versions of the page.

--- ubuntu:certificates:create_a_self-signed_certificate [2023/06/09 16:07] – peter
+++ ubuntu:certificates:create_a_self-signed_certificate [2023/06/09 16:26] (current) – peter
@@ Line 1: / Line 1: @@
 ====== 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 =====
@@ Line 8: / Line 42: @@
 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>
@@ Line 26: / Line 101: @@
 <WRAP important>
-<color red>**WARNING**</color>:  we are now past the point where 9999 days takes us past the 32-bit Unix epoch.  If your 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’re deploying, and either reduce the duration of the certificate or reconsider your platform deployment.  (At time of writing, 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).
+<color red>**WARNING**</color>:  we are now past the point where 9999 days takes us past the 32-bit Unix epoch.
-</WRAP>
-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.
+  * 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>
-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:
 <code bash>
@@ Line 56: / Line 133: @@
 </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/