Demystifying Digital Certificates: Types, Security & Practical Guide

Think back to our previous article, we explored encryption and digital signatures, delving into their importance. Now, let's continue our digital journey and discover the world of digital certificates. Imagine our friend Eman, who has many keys from different people, including Ahmed. But how can she trust these keys without any labels? Enter the digital certificates, our heroes! They provide a way to connect the keys to their rightful owners, building trust.

Eman's contacts keys

In this article, we will demystify digital certificates, understand Certificate Authorities (CAs), and learn about the certificate validation process. But that's not all! We'll also venture into the exciting realm of creating our own CAs and designing digital certificates using OpenSSL. Get ready for an exciting adventure as we explore the universe of digital certificates and their vital role in securing communication.

What Is A Digital Certificate?

Our friend Eman somehow manages to collect keys from Ahmed, Ali, and a few more folks. But here's the conundrum she faces: Without some form of ID, how can she possibly know which key belongs to which person? These tools bundle both the identity of the key owner and the key itself, along with some extra information like issuance details and a unique serial number into a single packet. This way, not only can Eman tell the keys apart, but she can also verify who they belong to.

The primary details stored in a certificate are depicted in the image below.

Digital certificate components

But how can Ahmed securely share his public key with Eman? What if someone pretends to be Ahmed and provides Eman with a fraudulent certificate? This situation highlights the need for a trusted third party to facilitate secure certificate exchange.

Secure certificate exchange challenge

Third party (CA)

To address these concerns, a third-party entity known as a Certificate Authority (CA) can be involved. The CA plays a crucial role in verifying the identities of individuals or entities and issuing digital certificates that bind their public keys to their identities.

In this scenario, Ahmed would generate his key pair, consisting of a private key and a corresponding public key. To securely share his public key with Eman, Ahmed would submit a certificate signing request (CSR) to the CA. This request includes his public key and proof of his identity.

The CA would then perform a verification process to validate Ahmed's identity, employing various methods such as personal information verification or in-person identification procedures.

Once Ahmed's identity is successfully verified, the CA would issue a digital certificate. This certificate contains Ahmed's public key, his identity information, and a digital signature from the CA, serving as a trusted confirmation of Ahmed's identity and the authenticity of his public key.

The task of constructing the certificate chain can be carried out by Ahmed, the CA, or anyone involved.

To share his public key securely, Ahmed can provide Eman with the issued digital certificate. This can be done directly or by publishing the certificate in a publicly accessible certificate directory. Eman can now have peace of mind knowing that Ahmed's identity is verified and that his certificate is trustworthy, as it has been issued by a CA that Eman trusts.

Eman can then extract Ahmed's public key from the certificate and use it for encryption or verifying digital signatures.

You've probably heard of Certificate Authorities (CAs) like Let's Encrypt, DigiCert, Comodo, and GlobalSign, right? They're giants in the industry, having proven their trust and credibility through consistent commitment to stringent security protocols and industry standards. But did you know, if you're hungry to learn and broaden your understanding, you can use OpenSSL to establish your very own CAs and craft digital certificates? Sounds exciting? Let's dive right into a sequence of commands to make it happen!

CA self-signed Certificate

1. Create CA certificate configuration: Create a file called ca.cnf and open it with a text editor. Paste the necessary configuration settings for your CA into the file.

HOME            = .
RANDFILE        = $ENV::HOME/.rnd

####################################################################
[ ca ]
default_ca    = CA_default      # The default ca section

[ CA_default ]

default_days     = 365          # How long to certify for
default_crl_days = 30           # How long before next CRL
default_md       = sha256       # Use public key default MD
preserve         = no           # Keep passed DN ordering

base_dir      = .
certificate   = $base_dir/ca.pem   # The CA certifcate
private_key   = $base_dir/caKey.pem    # The CA private key
new_certs_dir = $base_dir              # Location for new certs after signing
database      = $base_dir/index.txt    # Database index file
serial        = $base_dir/serial.txt   # The current serial number

unique_subject = no  # Set to 'no' to allow creation of
                     # several certificates with same subject.

x509_extensions = ca_extensions # The extensions to add to the cert

email_in_dn     = no            # Don't concat the email in the DN
copy_extensions = copy          # Required to copy SANs from CSR to cert

####################################################################
[ req ]
default_bits       = 4096
default_keyfile    = caKey.pem
distinguished_name = ca_distinguished_name
x509_extensions    = ca_extensions
string_mask        = utf8only

####################################################################
[ ca_distinguished_name ]
countryName         = Country Name (2 letter code)
countryName_default = SA

stateOrProvinceName        = State or Province Name (full name)
stateOrProvinceName_default = Riyadh

localityName               = Locality Name (eg, city)
localityName_default       = Riyadh

organizationName           = Organization Name (eg, company)
organizationName_default   = NoraTeck

organizationalUnitName         = Organizational Unit (eg, division)
organizationalUnitName_default = NoraTeckBlog

commonName         = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Nora Teck CA

emailAddress        = Email Address
emailAddress_default = ca@norateck.blog

####################################################################
[ ca_extensions ]

subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always, issuer
basicConstraints       = critical, CA:true
keyUsage               = keyCertSign, cRLSign

####################################################################
[ signing_policy ]
countryName            = optional
stateOrProvinceName    = optional
localityName           = optional
organizationName       = optional
organizationalUnitName = optional
commonName             = supplied
emailAddress           = optional

####################################################################
[ signing_req ]
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer
basicConstraints       = CA:FALSE
keyUsage               = digitalSignature, keyEncipherment

2. Create a serial file (with no extension) and add the text "01" inside. This file will be automatically updated each time you sign a certificate.

touch index.txt
echo '01' > serial.txt

This command will generate two output files: index.txt and serial.txt.

3. Generate CA key pair and self-sign the certificate:

openssl req -x509 -config ca.cnf -days 365 -newkey rsa:4096 -sha256 -nodes -out ca.pem -outform PEM

During the execution of this command, you will encounter a series of questions. If you prefer to utilize the default values that have already been set in the ca.cnf file (indicated between brackets), you can simply press Enter without entering any input. However, if you wish to specify different values, kindly enter them before pressing Enter.

These are the questions you will encounter.

Country Name (2 letter code) [SA]:
State or Province Name (full name) [Riyadh]:
Locality Name (eg, city) [Riyadh]:
Organization Name (eg, company) [NoraTeck]:
Organizational Unit (eg, division) [NoraTeckBlog]:
Common Name (e.g. server FQDN or YOUR name) [Nora Teck CA]:
Email Address [ca@norateck.blog]:

Great! Now that we have our own CA, let's take a look at the files we've generated: ca.pem and caKey.pem. These files represent our CA certificate and private key, respectively.

Currently, the Certificate Authority (CA) serves no purpose unless it issues certificates for end-users or other CAs. Now, let's proceed with generating a certificate specifically for Ahmed.

End-user Certificate

Remember, Ahmed needs to create a key pair and a Certificate Signing Request (CSR). Afterward, Ahmed should submit the CSR to the Certificate Authority (CA), who will then issue (sign) a certificate and provide it to Ahmed.

CSR submission

Now, let's begin with the following steps.

1. Create Ahmed's certificate configuration:

Create a file called ahmed.cnf and open it with a text editor.

Paste the required configuration settings for your server certificate into the file.

HOME            = .
RANDFILE        = $ENV::HOME/.rnd

####################################################################
[ req ]
prompt                 = no
days                   = 365
distinguished_name     = req_distinguished_name
req_extensions         = v3_req


[ req_distinguished_name ]
countryName            = SA
stateOrProvinceName    = RUH
localityName           = RUH
organizationName       = AhmedOrg
organizationalUnitName = AhmedOu
commonName            = Ahmed Abdullah
emailAddress          = ahmed@xxx.com

[ v3_req ]
basicConstraints       = CA:false
extendedKeyUsage       = clientAuth
subjectAltName         = @sans

[ sans ]
DNS.0 = localhost
####################################################################

1. Generate Ahmed key pair and certificate signing request (CSR)

openssl genpkey -algorithm RSA -out ahmed_privatekey.pem -aes256
openssl rsa -pubout -in ahmed_privatekey.pem -out ahmed_publickey.pem
openssl req -new -key ahmed_privatekey.pem -out ahmed_csr.pem -outform PEM -config ahmed.cnf

During the execution of the command, you will be prompted to answer the following questions:

1. Enter PEM pass phrase: This is a passphrase used to encrypt the private key file (ahmed_privatekey.pem). It adds an extra layer of security by requiring a password to access the private key.

2. Verifying - Enter PEM pass phrase: This prompt asks you to re-enter the same passphrase as a verification step. Make sure the passphrase you enter matches the one you provided in the previous step.

3. Enter pass phrase for ahmed_privatekey.pem: This is another request to enter the passphrase for the private key file (ahmed_privatekey.pem). It is a security measure to ensure that only authorized users can access the private key.

For the remaining questions, simply press Enter.

These commands will generate multiple output files: ahmed_privatekey.pem, ahmed_publickey.pem, and ahmed_csr.pem.

2. Verify the CSR:

openssl req -text -noout -verify -in ahmed_csr.pem

A textual representation of the contents of the CSR (Certificate Signing Request) file (ahmed_csr.pem) will be displayed. It verifies the CSR's integrity and provides information about the certificate request, such as the subject, public key details, and any additional attributes included in the CSR.

3. Sign the CSR with the CA certificate

openssl ca -config ca.cnf -policy signing_policy -extensions signing_req -out ahmed_cert.pem -infiles ahmed_csr.pem 

you will be prompted with two questions. Please press "y"

 Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Database updated

A file named "ahmed_cert.pem" will be generated. If you open it using a text editor, you will be able to observe the structure of the certificate. The following table provides explanations for the most important components of the certificate.

Field	Explanation
Serial Number	Uniquely identifies the certificate.
Signature Algorithm	Identifies the algorithm used for signing the certificate
Issuer	Provides information about the entity that issued (signed) the certificate.
Validity	Specifies the period during which the certificate is valid.
Not Before	The certificate is not valid before this date and time.
Not After	The certificate is not valid after this date and time.
Subject	Identifies the entity to which the certificate is issued.
Public Key Algorithm	Specifies the algorithm used for the public key encryption.
Public-Key	The actual public key value.
Signature Algorithm	Identifies the algorithm used to sign the certificate.
Signature Value	The actual signature value of the certificate, created using the private key of the issuer.
-----BEGIN CERTIFICATE-----	Marks the beginning of the certificate data.
-----END CERTIFICATE-----	Marks the end of the certificate data.

Excellent! Ahmed now possesses the capability to perform decryption and signing operations using his keys. Furthermore, his friends have the ability to send encrypted messages using Ahmed's certificate.

To perform encryption and signing on behalf of Ahmed and Eman, you can refer to the previous article where you can find the commands for these operations.

Have you noticed that the ahmed_cert.pem file only includes Ahmed's certificate and not the entire certificate chain? That's correct! Our CA is a simplified one and may not be as comprehensive as widely trusted public CAs. However, don't worry! We can easily create a complete certificate chain by running a command that combines both the ahmed_cert.pem and ca.pem files.

cat ahmed_cert.pem ca.pem > certificate_chain.pem

That's it! In conclusion, we covered the concepts of digital certificates, including third-party CAs, self-signed certificates, and end-user certificates. We also provided a practical guide using OpenSSL commands

I hope you enjoyed this article ♡