Self signed certificates can be useful for test and truely private work; perhaps where the sites are not externally visible so it is hard to configure with Let's Encrypt.
openssl configuration filesEXAMPLE.cnf to a name of your choosing (eg my-site.cnf), edit parameters, especially commonNameGenerateSelfSignedCertificate, eg:
./GenerateSelfSignedCertificate my-site
cp my-site.crt /etc/apache/certificates/public/my-site.crt cp my-site.key /etc/apache/certificates/private/my-site.key
ksh and openssl installedopenssl configuration fileAll answers that are needed by openssl is contained in this file.
This generates consistent certificates — no errors on what you typed last time.
The commonName is most important and must match the domain name that
the web server uses for the web site.
You can use the certificate on multiple sites, an example is at the bottom of EXAMPLE.cnf,
put the extra names as DNS.1, DNS.2, DNS.3, etc.
The base name of this file will be used for the .key, .crt & .csr
files that are generated.
Choose a name that is related to the commonName — this helps
when you have many of them.
GenerateSelfSignedCertificate has an option -s
that will decode and show you the certificate, eg:
./GenerateSelfSignedCertificate -s my-site
This can only be used on a certificate that already exists.
The certificate generated will have a life of 3650 days (10 years). A different
life cannot be put in the .cnf file. You can change this
with the -d option to GenerateSelfSignedCertificate.
Eg to set to one year:
./GenerateSelfSignedCertificate -d 365 my-site
The .key file should be kept secret, it should only be readable
by the web server. The easiest way of doing this is to put .key files
into a directory that can only be accessed by the web server.
Return to tutorial home.
If you want any help using the above, or have any comments or suggestions, please contact us.