Creating Self-Signed Certificates
This article explores the process of generating self-signed certificates, offering insights on how to create secure and reliable certificates for various digital applications and websites. Dive into the world of cybersecurity and enhance your knowledge on protecting sensitive data online.
Updated at July 27th, 2024
Table of Contents
This article provides information on the creation of basic certificate authority and security certificate with built-in Symas-provided OpenSSL CA tools.
This article is oriented towards creating security certificates with a private certificate authority for use in test environments only. In production environments or where test data may still be considered sensitive, use certificates issued by publicly trusted certificate authorities such as VeriSign, Let's Encrypt, DigiCert, etc.
Requirements
- Symas OpenSSL
- A perl interpreter
Installing Symas OpenSSL
OpenSSL is a set of utilities and runtime libraries used to handle encryption and identification tasks. Most Linux servers come with OpenSSL preinstalled. Symas provides an add-on OpenSSL package that's tailored for creating test certificate authorities and test certificates. In this guide, we'll be using Symas's OpenSSL package.
To install Symas's OpenSSL package, configure your server's package manager to use the Symas OpenLDAP software repository. Instructions for this may be found at https://repo.symas.com.
Once the Symas OpenLDAP software repository is configured, run the following:
Redhat and Redhat-like operating systems:
sudo dnf install symas-opensslDebian, Ubuntu and similar:
apt-get install symas-opensslThe package creates the directory /opt/symas/ssl which contains everything needed to create a private certificate authority and issue self-signed certificates. From this point on we'll be working from this directory exclusively.
Working With OpenSSL
All certificate related tasks (CA/certificate creation, certificate revocation, etc.) are performed with the openssl command. The command has many, many options and can have a steep learning curve, so we'll be using OpenSSL's CA.pl script (/opt/symas/ssl/misc/CA.pl). This script greatly simplifies CA and certificate related tasks.
Note: When running the CA.pl script, your current working directory must be /opt/symas/ssl:
cd /opt/symas/ssl OpenSSL Configuration (openssl.cnf)
The openssl.cnf file provides configuration information to the openssl utility. On a new Symas OpenLDAP installation, the file is named /opt/symas/ssl/openssl.cnf. The file /opt/symas/ssl/openssl.cnf.dist is a backup copy.
The configuration contains default paths and filenames, the length of time a certificate is valid, what hashing algorithm to use for the certificate and the default values for certificate information like organization, organizational unit, country name, etc. and many other settings.
When creating a CA or issuing certificates, most information in openssl.cnf should remain as-is. There are some items where default values may be added or changed and makes it easier to keep certificate information more consistent.
| Item | Description |
|---|---|
| default_days | The default_days variable sets the number of days that a certificate is valid. The default is 365 and can be adjusted upward or downward to suit your needs. |
| countryName* | The name of the country where the certificate is used or issued. |
| stateOrProvinceName* | The name of the state or province where the certificate is used or issued. |
| localityName* | The name of the city where the certificate is used or issued. |
| 0.organizationName* | The name of the company or organization that the certificate is for. |
| organizationalUnitName* | The name of the organizational unit that the certificate is for. |
| commonName** | While the description for the commonName says "(eg. YOUR name)" it is best to use the fully qualified host names. When creating the CA, use the fully qualified host name of the machine that the CA is being created on. When creating server and client certificates, use the fully qualified host name for the host that the certificate is going to be installed on. |
| emailAddress* | An email address, usually for the user or group that will be the administrator for the CA. |
Items may have a default value set by adding a new line that starts with the item name appended with "_default" and then the desired value. Here's an example for the countryName field:
countryName = Country Name (2 letter code)
countryName_default = USCreating a Certificate Authority
Security certificates are created by trusted issuer, known as a Certificate Authority. We'll be creating our own private Certificate Authority for creating certificates.
Create The CA
Use the following command to create the CA:
/opt/symas/ssl> ./misc/CA.pl -newcaRespond to all the prompts. If you have set defaults for fields in openssl.cnf and see the value in brackets at the prompt, press enter to accept it or enter a new value to override it.
Please note that the challengePassword and unstructuredName fields are optional. Make sure to back up the passphrase you create. The passphrase is required every time the CA is used to create or revoke certificates. If the passphrase is lost there is no way to recover it.
Your CA is now set up and ready to issue certificates. The certificate/public key for the CA is saved to /opt/symas/demoCA/cacert.pem. The private key for the CA is stored in the file /opt/symas/ssl/demoCA/private/cakey.pem. Access to the CA private key must be protected. It should only be accessible to those who are allowed to perform CA duties (create & revoke certificates, create CRLs, etc.) and not to the general public.
Creating Certificates
Creating a security certificate is a two-step process. A certificate request must be made first and then the certificate request must be signed by the certificate authority.
To generate the certificate request. Use ‘-newreq-nodes’ to create the request without DES encryption:
/opt/symas/ssl> ./misc/CA.pl -newreq-nodesWhen the script prompts for a challenge password, leave it blank (just hit enter twice.) If a challenge password is entered the certificate will not work with OpenLDAP as the certificate will require the password on every request.
After the request is complete, sign the certificate with the CA.pl script:
/opt/symas/ssl> ./misc/CA.pl -signOnce signed, there will be two files in /opt/symas/ssl: newcert.pem and newkey.pem. The newcert.pem file is the certificate and newkey.pem is the private key for the certificate. These files should be moved and renamed immediately. For example:
mv /opt/symas/ssl/newcert.pem /opt/symas/ssl/demoCA/certs/server-cert.pem
mv /opt/symas/ssl/newkey.pem /opt/symas/ssl/demoCA/certs/server-key.pemServer Configuration
Now that you have a CA certificate and a certificate issued by the CA, you're ready to set up your server to use these files. Server configuration is covered in the Basic Security Certificate Setup article.
Important!
The CA and certificates created in this procedure are considered “self-signed”. By default, OpenLDAP will not recognize self-signed CA or server/client certificates as valid and will reject SSL/TLS connections. To allow self-signed certificates, TLS client verification must be set to “never”, “try” or “allow” in the slapd configuration. For example:
# slapd.conf:
TLSVerifyClient try
# cn=config:
olcTLSVerifyClient tryThis is also covered in the Basic Security Certificate Setup article.