One may have heard at least heard once about the self-signed certificate working in the computer science domain. In short, a self-signed certificate is a digital certificate that is not signed by any publicly trusted Certificate Authority (CA).
The key difference between the self-signed certificate and a traditional certificate is the public and privately trusted certificate. On the traditional SSL certificate, the publicly trusted Certificate is issued only by an external trusted third-party Certificate Authority (such as DigiCert) but the self-signed certificate is created, issued, and signed by either organization or developer that runs their own dedicated internal public key infrastructure like Microsoft CA. The components like SSL/TLS certificates, code signing certificates, and S/MIME certificates are included on the self-signed certificate. The cryptographic key pair architecture is called X.509 certificates, both self-signed and traditional certificates are based on it.
Why does one need a self-signed certificate?
SSL/TLS certificates enable the user to communicate over open networks using encryption over the transmitted data that eliminates the challenges of data tampering and interception by the malicious actor. It also provides a trusted environment for the users to communicate. Digitalization has addressed the need for a trusted environment with the purpose to communicate in a secure channel over the open network.
To better understand the purpose of a self-signed certificate, one needs to have at least a general overview of its working mechanism. SSL/TLS protocol is responsible for the security and authentication of the users. Self-signed certificates can refer to many different certificate types such as SSL/TLS certificates, S/MIME certificates, code signing certificates, and many others.
In a general overview, a user wants to access the request from a server and initiates the request from his browser. Both the server and the user should be able to trust each other in order to initiate communication between them. Since both the server and the user are trying to communicate in an open network so the need for authentication and security raises.
The Certificate Authority (CA) acts as the third party who is responsible to build the trust between the server and the users through the authentication process. A publicly trusted Certificate Authority only issues and signs the server certificate by fulfilling the criteria of the Certificate Authority. The criteria can differ with each individual Certificate Authority, but the main objective is to only provide the certificate to the legitimate certificate requestor. The credentials required to verify the server’s certificate signed and issued by the Certificate Authority are stored on the user’s browser. Once the full certificate chain is validated then the user will access the requested resources without any warnings from the Certificate Authority while visiting the requested resource.
The following figure illustrated the typical full certificate chain in action:
Even though the self-signed certificate is quite risky, it does have its own uses. One does not need to pay for the self-signed certificate and is able to easily generated by any developer with a custom requirement certificate. Mostly self-signed certificate is used in the internal testing environment or web servers to prohibit external users to access. The functionality of a self-signed certificate for both encryption and decryption is identical to the paid SSL/TLS certificates.
How can generate a self-signed certificate?
After a general overview of the self-signed certificate, you want to experiment with the self-signed certificate. There are various ways to generate the self-signed certificate, and the following are the requirements for this demonstration purpose.
Ubuntu LTS 20.04 is used as the operating system and OpenSSL needs to be installed on the system in order to generate the self-signed certificate. The process will be divided into three major parts for the sake of clarity.
At first, highly recommended to create a new directory and then generate a key followed by AES encryption that will be used on Certificate Authority (CA) while generating.
To create a directory:
mkdir <directory_name>
To generate a private key:
openssl genrsa -aes256 -out ca-key.pem 4096
You can input any desired password, in this case: password — lab@2022
To generate a CA certificate:
openssl req -new -x509 -sha256 -days 365 -key ca-key.pem -out ca.pem
To view the generated CA certificate in a human-readable format
openssl x509 -in ca.pem -text
In the second part, we need to create a private key for the server certificate. You can include a passphrase while generating the private key for the server certificate but it can be quite a tedious task while implement the server certificate on multiple servers consisting of the same domain. The passphrase is not included in this demonstration.
To generate a private key for the server certificate
openssl genrsa -out cert-key.pem
To generate the server certificate
openssl req -new -sha256 -subj “/CN=nitric” -key cert-key.pem -out cert.csr
To create a config file
echo “subjectAltName=DNS:*.nitratic.com,IP:172.20.100.173” >> extfile.cnf
cat .\extfile.cnf
The last part is to generate a CA-signed SSL certificate and a full chain certificate.
To generate a CA-signed SSL certificate
openssl x509 -req -sha256 -days 400 -in cert.csr -CA ca.pem -CAkey ca-key.pem -out cert.pem -extfile extfile.cnf -CAcreateserial
To generate a full chain certificate
cat cert.pem > fullchain.pem
cat ca.pem >> .\fullchain.pem
Some server requires cert format to be imported so,
To convert pem into ssl certificate
openssl x509 -in fullchain.pem -out server.crt
To convert pem into key
openssl rsa -outform der -in cert-key.pem -out server.key
The final step is to perform the following steps to import the certificate on the respective browser and server for a self-signed certificate.
- Import the CA.PEM on the web browser on the trusted root certificate
- Import the fullchain.pem and converted server key on the server
