Differences

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

--- certificates:create_a_self-signed_certificate [2016/11/10 10:31] – peter
+++ certificates:create_a_self-signed_certificate [2019/11/26 21:48] (current) – removed peter
@@ Line 1: / Line 1: @@
-====== Certificates - Create a self-signed certificate ======
-You can create a self-signed certificate using the req command provided with OpenSSL, like this:
-<code bash>
-openssl req -x509 -newkey rsa:1024 -keyout file1 -out file2 -days 9999 -nodes
-</code>
-file1 and file2 can be the same file; the key and the certificate are delimited and so can be identified independently.  The **-days** option specifies a period for which the certificate is valid. The **-nodes** option is important: if you do not set it, the key is encrypted with a passphrase that you are prompted for, and any use that is made of the key causes more prompting for the passphrase.  This is not helpful if you are going to use this certificate and key in an MTA, where prompting is not possible.
-<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).
-</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.
-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/.