To provide encrypted traffic using SSL/TLS between a client and a host server, companies must create a certificate signing request (CSR) and submit it to a certificate authority (CA). The CSR contains your public key and information about your company, which the CA then verifies before providing you with an SSL/TLS certificate. The certificate lets users connecting to your server know that your company’s domain is legitimately owned by the company displayed on the website and in the CA certificate.
What Is a Certificate Signing Request (CSR)?
When you decide to implement HTTPS on your website, you need an SSL/TLS certificate from a certificate authority. The first step in requesting a certificate is to create a certificate signing request (CSR). You generate a CSR on the server hosting the website and later install the CA certificate on the same server.
The CSR contains information about your company (e.g., business name and country), and the CA will verify information using various research tools. The file generated with a CSR contains the server’s public key and cryptographic algorithm used to generate the key, usually RSA (Rivest-Shamir-Adleman) 2048 bits or 4096 bits. The private key is also generated and should never be shared, but the private key will be used to decrypt data encrypted with the public key during the SSL/TLS handshake.
After the information shared in the public key is verified, a CA authorizes your server’s certificate and sends it to you, usually within a few days. The certificate must then be installed on the server, but the data displayed in a certificate is from the original CSR sent to the CA.
What Are Digital Security Certificates?
Certificate authority (CA) organizations provide companies with SSL/TLS certificates and are responsible for validating information generated in a CSR. They hold tremendous power over the authenticity and trustworthiness of the entire public key infrastructure on the web. When users look at a digital security certificate installed on a domain, they must trust that the domain and certificate represent the organization presented on a website. They must also trust that data is encrypted and safe from eavesdropping.
Public key infrastructure (PKI) is the entire process starting with the CSR generated on a web server to the certificate a CA provides after data verification. A CSR is a component in PKI, but it does not represent the entire process. PKI processes were put into place to make the internet more secure and trustworthy, and it helps users identify potential phishing or malicious websites.
How to Generate a CSR
You should generate a CSR on the server hosting the site and where the certificate will be installed. Generating a CSR creates a public and private key. The private key is stored on the server where it can be retrieved during communication with users. The public key is retrieved during communication with a client web browser and used to encrypt the symmetric key during the SSL/TLS handshake.
The most common library used to generate a CSR is OpenSSL. OpenSSL generates a CSR and a private key simultaneously. Generating a CSR with OpenSSL only requires one command:
openssl req -newkey rsa:2048 -keyout my_private_key.key -out my_csr_request.csr
After you type the above statement, you’re prompted to enter information about your organization. The above statement creates a CSR in a file named my_csr_request.csr, which contains the public key. The private key file is named my_private_key.key, and it should be stored safely on the server. The CSR and private key are generated using RSA 2048, which is standard for most certificates, but using increased bits for your keys improves entropy of the keys.
After you create the CSR file, you can now submit it to the CA of your choice. It might take a few days to receive your certificate, but eventually you’ll receive the certificate for installation on your server. Installing the SSL/TLS certificate on your server is the last step in the process, and then you can serve encrypted HTTPS content to users.
How to Create a CSR in Linux
To generate a CSR in Linux, you must first install OpenSSL (or the SSL/TLS library of choice), and then use it in the Linux terminal. First, install OpenSSL using the following command:
sudo apt install openssl
After OpenSSL installs, type the following command to create a private key with a 2048-bit key length:
openssl genrsa -out my_private_key.key 2048
With the private key created, you can now generate a CSR using the private key. Use the following command to create a CSR in OpenSSL:
openssl req -new -key my_private_key.key -out my_csr_request.csr
After you type the above command, you’re prompted to enter private information about your organization, including country, state, or province, the organization’s name, the fully qualified domain name shown in the user’s browser, and email address. Note that the fully qualified domain name must match what shows in the user’s browser or the certificate will display a warning message. For example, if you use the “www” in the domain name, it must be included. Do not add “www” if you choose to use the naked domain (e.g., mydomain.com vs. www.mydomain.com).
After the CSR is generated, you can submit it to your CA of choice. Keep all files generated with OpenSSL in a secure location, especially the private key. Anyone with the private key can decrypt data transferred between your server and internet users, which means theft of the private key is a critical data breach for any organization.
Alternatives to OpenSSL for Generating a CSR
OpenSSL is probably the most common library for generating keys and CSRs, but alternatives exist if an organization prefers not to use OpenSSL. An OpenSSL bug was responsible for one of the biggest vulnerabilities on the open internet, Heartbleed. Heartbleed is still an issue on servers hosting older versions of OpenSSL, so it has lost the trust of some administrators.
A few alternative libraries include:
Alternatives to Digital Security Certificates
Most organizations use public digital security certificates, but private public key infrastructure keeps the entire process internal using private resources. For example, cloud users might use AWS Certificate Manager or Azure Key Vault. Other options include ZeroSSL or Keystash.
Administrators within an organization don’t need to connect to web-based administrator panels. Administration panels using HTTPS leave the server open to various vulnerabilities, so administrators can instead choose to use SSH to remotely access the server. SSH can also use public key authentication to improve security of remote administration and lower the risk of credential theft from phishing.
DNSSEC is also an alternative, but it’s still in its infancy and isn’t supported everywhere just yet. With DNSSEC, resolvers responsible for caching nameserver results use a DNS zone’s public key to encrypt requests. The public key can be used to validate authenticity of a request. Authoritative DNS servers encrypt data with the zone’s private key, and the public key on a resolver can be used to validate that the response is legitimate. The public key infrastructure in DNSSEC is used to reduce DNS poisoning attacks, which allow for attackers to replace legitimate website IP addresses with a phishing server’s IP address.
Conclusion
For any organization hosting a secure website, generating a CSR is the first step. You need to find a CA to issue a certificate, but you can generate a CSR for free without much effort. Make sure all the information in your CSR is correct to ensure that your request will be accepted, and your certificate will not cause errors in user browsers.
