This is an old revision of the document!
Table of Contents
Ubuntu - Certificates - Create a self-signed certificate
You can create a self-signed certificate using the req command provided with OpenSSL, like this:
openssl req -x509 -newkey rsa:2048 -keyout file1.key -out file2.crt -days 9999 -nodes
- 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 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).
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
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'