In our previous article on "How HTTPS Works?", we discussed the concepts of HTTPS, TCP, TLS, and SNI. We learned that servers have their own keypair and certificate to facilitate the TLS handshake. In this article, we will explore how to create a server certificate, which is essential for proving the identity of a server in real-world scenarios.
In the real world, every component of a network or service is assigned a Fully Qualified Domain Name (FQDN) or hostname and is equipped with a certificate to verify its claimed identity. To create a server certificate, we need to follow a specific process.
Certificate Authority (CA)
=> Skip this Section if Your Organization Already Has a CA; Otherwise, Create Your Own
Before we proceed with creating a server certificate, it's important to consider the role of a Certificate Authority (CA). In most cases, server certificates are issued by trusted CAs, either within the organization or from external sources. A CA is responsible for verifying the identity of the server and issuing a certificate that binds the server's public key to its identity.
If your organization already has a trusted CA, you can skip this section and obtain the server certificate from them.
However, if you don't have a CA or want to learn about the process, you can create your own CA. Our previous article, "Demystifying Digital Certificates for Enhanced Trust and Security," provides detailed instructions on creating a self-signed CA certificate. You can refer to the section on "CA Self-Signed Certificate" for step-by-step guidance. Once you have the CA certificate, you can use it to sign the server certificate.
Service Certificate (App1 Certificate)
So now, let's create the "app1.cnf" file, where we will include all the necessary information as defaults.
vim app1.cnfAfterward, please copy the provided code snippet and make sure to customize the values according to your specific application.
HOME = .
RANDFILE = $ENV::HOME/.rnd
####################################################################
[ req ]
default_bits = 2048
default_keyfile = app1Key.pem
distinguished_name = server_distinguished_name
req_extensions = server_req_extensions
string_mask = utf8only
####################################################################
[ server_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 = NIC
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = www.app1.com
#emailAddress = Email Address
#emailAddress_default =
####################################################################
[ server_req_extensions ]
subjectKeyIdentifier = hash
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alternate_names
nsComment = "OpenSSL Generated Certificate"
####################################################################
[ alternate_names ]
DNS.1 = www.app1.comAlright! Then let’s continue creating the keypair and csr :
openssl req -config app1.cnf -newkey rsa:2048 -sha256 -nodes -out app1.csr -outform PEM
openssl req -text -noout -verify -in app1.csr
Great!
let's make sure we have them :
ls Now, if your organization has a CA , please send the app1.csr to the PKI team and make sure that they will send you it's corresponding .crt or .cer or pfx
If you already made your own CA for learning or development purposes, then do this command to create the certificate (app1.pem) :
openssl ca -config ca.cnf -policy signing_policy -extensions signing_req -out app1.pem -infiles app1.csrGreat!
That's it ! You now have a server certificate that can be used for various purposes, such as securing your database, DNS server, LDAP server, backend services, webpages, and more. It's important to note that each server or service may have its own unique process for installing the certificate.
For example, when installing the certificate on your database server, you would follow the specific instructions provided by the database software or vendor. Similarly, for your DNS server, LDAP server, or any other service, you would refer to the relevant documentation or guidelines to correctly install and configure the certificate.
Remember, the process may vary depending on the software, operating system, and specific requirements of each server or service. It's crucial to ensure proper installation and configuration to establish secure communication and maintain the integrity of your systems.
I trust that you have found this article to be informative ♡
Comments