Initially developed by Netscape in 1994 to support the internet's e-commerce capabilities, Secure Socket Layer (SSL) has come a long way. Amidst all the cyber attacks, SSL certificates have become a regular necessity for any live website.
Even though Secure Socket Layer (SSL) and Transport Socket Layer (TLS) have become quite ubiquitous, we will take a brief moment to explain what they do and how they do it.
Do not skip the OpenSSL Tutorial section.
What is an SSL Certificate? How Does SSL Work?
A Secure Socket Layer (SSL) certificate is a security protocol which secures data between two computers by using encryption.
Note: Simply put, an SSL certificate is a data file that digitally ties a Cryptographic Key to a server or domain and an organization's name and location.
Typically, SSL certificates are used on web pages that transmit and receive end-user sensitive data, such as Social Security Number, credit card details, home address or password. Online payment forms are a good example and usually encrypt the aforementioned delicate information using 128 or 256-bit SSL technology.
SSL certificates ensure the identity of a remote computer, most commonly a server, but also confirms your computer's identity to the remote computer to establish a safe connection. Keeping the internet safe has always been a two-way street and thanks to SSL encryption, the server "shakes hands" with your personal computer and both sides know with whom they are communicating.
What's the Difference Between TLS and SSL?
There is none. Transport Layer Security (TLS) is an updated version of Secure Socket Layer (SSL). Even though most secure connections are via TLS protocols, people keep calling it SSL. In this case, it's safe to say that old habits do die hard.
How Can I Know Whether a Web Page is Secured With SSL?
As an internet user, you have probably noticed a padlock and the site info bar turning green in your web browser, as well as the https connection protocol.
That's your browser letting you know that a website is secured using SSL encryption. Clicking the site info bar will provide additional details about the connection as well as insight into the SSL certificate itself.
Why Do I Need an SSL Certificate?
Let's take a real-life example.
You're an e-commerce site owner who just leased a server with phoenixNAP and launched a couple of new e-commerce stores. You want your visitors to feel safe when visiting your e-store and, above all, not feel hesitant to log in and make a purchase.
An SSL certificate and HTTPS connection instills consumer confidence. The e-commerce industry is tied closely to consumer trust, and we might even say that your business depends on your customers feeling safe during the entire buying experience.
Besides the obvious security reasons, an SSL certificate increases your site's SEO and Google Ranking and builds customer trust, consequently improving overall conversion rates.
If that is not enough to make you consider getting an SSL certificate for your domain, Google is sure to persuade you. Namely, starting from July 2018 Google flags each website without SSL as unsafe.
Where Can I Get an SSL Certificate?
SSL certificates are verified and issued by a Certificate Authority (CA). You apply by generating a CSR with a key pair on your server that would, ideally, hold the SSL certificate. The CSR contains crucial organization details which the CA verifies.
- Generate a CSR and key pair locally on your server. The key pair consists of a public and private key.
- Send the CSR and public key to a CA who will verify your legal identity and whether you own and control the domain submitted in the application. The Certificate Authority runs a check on your organization and validates if the organization is registered at the location provided in the CSR and whether the domain exists.
- When verified, the organization receives a copy of their SSL certificate including business details as well as the public key. The organization can now install the certificate on their server.
- When a CA issues the certificate, it binds to a certificate authority's "trusted root" certificate. Root certificates are embedded into each browser and connected to individually issued certificates to establish an HTTPS connection.
Note: It is not uncommon for popular browsers to distrust all certificates issued by a single Certificate Authority. For example, Google Chrome has distrusted Symantec root certificates, due to Symantec breaching industry policies on several occasions. This means that all certificates rooted at Symantec have become invalid, no matter what their "valid through" date is.
SSL Certificate Types
Make sure that you choose a CA that supports the certificate type you need. For your convenience, below is a description of each certificate type:
Single Domain SSL Certificate
This type is meant to be used for a single domain and offers no support for subdomains. For example, if the certificate is to be used for www.phoenixnap.com, it will not support any other domain name.
Multiple Domain (SAN/UC Certificates)
Multiple domain certificates are used for numerous domains and subdomains. Besides the FQDN, you can add support for other (sub)domains by adding them to the Subject Alternative Name Field. For example, a SAN certificate can include the domain www.phoenixnap.com, its subdomain help.phoenixnap.com as well as another domain (e.g., www.examplesite.com).
Wildcard certificates can be used for a domain, including all of its subdomains. The main difference is that instead of it being issued for a specific FQDN, wildcard certificates are used for a wide range of subdomains. For example, a wildcard certificate issued to *.phoenixnap.com could be used for a wide range of subdomains under the main www.phoenixnap.com domain, as seen in the image below.
SSL Certificate Validation Levels
CAs have diversified certificate validation levels in response to a growing demand for certificates. Some organizations use SSL just for encryption, while others want to show their customers that they are a trusted company. Different needs have resulted in different certificate validation levels.
Domain Validation (DV SSL)
This type of SSL certificate is ideal for securing blogs, social media apps, and personal websites. The certificate authority does not guarantee for an organization's identity, and only domain ownership is verified.
Extended Validation (EV SSL)
The certificate authority verifies domain ownership and conducts a thorough investigation of the organization associated with the EV certificate. Strict rules are followed when reviewing an extended validation request, and the CA has to verify the following:
- The identity of the organization matches official records.
- The physical, legal and operation existence of the entity.
- The organization has exclusive rights to use the domain specified in the SSL certificate.
- The organization has appropriately authorized the issuance of the EV SSL certificate.
Create SSL Certificate
How to generate a certificate signing request solely depends on the platform you're using and the particular tool of choice.
We will be generating a CSR using OpenSSL.
OpenSSL is a widely-used tool for working with CSR files and SSL certificates and is available for download on the official OpenSSL website. It is an open-source implementation tool for SSL/TLS and is used on about 65% of all active internet servers, making it the unofficial industry standard.
Debian and Ubuntu
dpkg -l |grep openssl
If the OpenSSL packet is installed, it will return the following result:
ii libgnutls-openssl27:amd64 2.12.23-12ubuntu2.4 amd64 GNU TLS library - OpenSSL wrapper ii openssl 1.0.1f-1ubuntu2.16 amd64 Secure Sockets Layer toolkit - cryptographic utility
If you do not see such a result, run the following command to install OpenSSL:
apt-get install openssl
Red Hat or CentOS
Red Hat (release 7.0 and later) should come with a preinstalled limited version of OpenSSL. It offers only limited support for IDEA, RC5, and MDC2, so you may want to install the missing features. To read more about this, see OpenSSL's documentation.
To check whether OpenSSL is installed on a yum server (e.g., Red Hat or CentOS), run the following command:
rpm -qa | grep -i openssl
This command should return the following result:
openssl-1.0.1e-48.el6_8.1.x86_64 openssl-devel-1.0.1e-48.el6_8.1.x86_64 openssl-1.0.1e-48.el6_8.1.i686
If your output format differs, it means that OpenSSL is not installed on your server. Run the following command to install OpenSSL:
yum install openssl openssl-devel
What's a Certificate Signing Request (CSR)?
A certificate signing request (CSR) contains the most vital information about your organization and domain.
Usually, you would generate a CSR and key pair locally on the server where the SSL certificate will be installed. However, that is not a strict rule. You can generate a CSR and key pair on one server and install the certificate on another. However, that makes things more complicated. We shall cover that scenario as well.
Note: A certificate signing request (CSR) is an encrypted block of text that includes your organization's information, such as country, email address, fully qualified domain name, etc. It is sent to the Certificate Authority when applying for an SSL certificate.
Secure Socket Layer (SSL) uses two long strings of randomly generated numbers, which are known as private and public keys. A public key is available to the public domain as it is a part of your SSL certificate and is made known to your server.
The private key must correspond to the CSR it was generated with and, ultimately, it needs to match the certificate created from the CSR. If the private key is missing, it could mean that the SSL certificate is not installed on the same server which generated the Certificate Signing Request.
A CSR usually contains the following information:
|Common Name or FQDN||FQDN is the fully qualified domain name of your website. It must be the same as what users type in the web browser.||www.phoenixnap.com|
|Organization Name (e.g., company)||The full legal name of your organization, including suffixes such as LLC, Corp, etc.||PhoenixNAP, LLC|
|Organizational Unit Name||The division in your organization that deals with this certificate.||NOC|
|Locality Name (e.g., city)||The city in which your organization is located.||Phoenix|
|State/Region/Province (full name)||The state or region in which your organization is located.||Arizona|
|Country Code (2 letter code)||The country in which your organization is located. Always entered as a two-letter ISO code.||U.S.|
|Email Address||Email address used to contact the site's email@example.com|
|Public Key||An automatically-created key that's generated with the CSR and goes into the certificate.||An encoded text block similar to the private key. See an example of a private key below.|
Please note there are certain naming conventions to be considered. Organization Name and Organizational Unit Name must not contain the following characters:
< > ~ ! @ # $ % ^ * / \ ( ) ?.,&
How to Generate a CSR
Certificate signing requests (CSR) are generated with a pair of keys – a public and private key. Only the public key is sent to a Certificate Authority and included in the SSL certificate, and it works together with your private key to encrypt the connection. Anyone can have access to your public key, and it verifies that the SSL certificate is authentic.
A private key is a block of encoded text which, together with the certificate, verifies the secure connection between two machines. It must not be publicly accessed, and it shouldn't be sent to the CA.
The integrity of a certificate relies on the fact that only you know the private key. If ever compromised or lost, re-key your certificate with a new private key as soon as possible. Most CAs do not charge you for this service.
Note: Most key pairs are 2048-bits. Even though 4096-bits key pairs are more secure, they slow down SSL handshakes and put a strain on server processors. Due to this, most websites still use 2048-bit key pairs.
Option 1: Generate a CSR
The first thing to do would be to generate a 2048-bit RSA key pair locally. This pair will contain both your private and public key. You can use Java key tool or some other tool, but we will be working with OpenSSL.
To generate a public and private key with a certificate signing request (CSR), run the following OpenSSL command:
openssl req -out certificatesigningrequest.csr -new -newkey rsa:2048 -nodes -keyout privatekey.key
Once you have generated a CSR with a key pair, it is challenging to see what information it contains as it will not be in a human-readable format. You can easily decode the CSR on your server using the following OpenSSL command:
openssl req -in server.csr -noout -text
It is advised to decode the CSR and verify that it contains the right information about your organization before it's sent off to a certificate authority. There are a lot of CSR decoders on the web that can help you do the same just by copy-pasting the content of your CSR file.
For your convenience, we have listed two (2) online CSR decoder tools:
Note: A certificate signing request generated with OpenSSL will always have the .csr file format.
Option 2: Generate a CSR for an Existing Private Key
It is recommended to issue a new private key whenever you are generating a CSR. If, for any reason, you need to generate a certificate signing request for an existing private key, use the following OpenSSL command:
openssl req -out CSR.csr -key privateKey.key -new
Option 3: Generate a CSR for an Existing Certificate and Private Key
openssl x509 -x509toreq -in certificate.crt -out CSR.csr -signkey privateKey.key
One unlikely scenario in which this may come in handy is if you need to renew your existing certificate, but neither you nor your certificate authority have the original CSR. This will extract information about your domain and organization from the SSL certificate and use it to create a new CSR, thus saving you time.
Option 4: Generate a Self-Signed Certificate
A self-signed certificate is usually used for test and development environments and on an intranet. Let's generate a self-signed certificate using the following OpenSSL command:
openssl req -newkey rsa:2048 -nodes -keyout domain.key-x509 -days 365 -out domain.crt
-days parameter is set to 365, meaning that the certificate is valid for the next 365 days. The
x509 parameter indicates that this will be a self-signed certificate. A temporary CSR is generated, and it is used only to gather the necessary information.
Certificate Authorities do not verify self-signed certificates. Thus, they are not as secure as verified certificates. If a CA has not signed the certificate, every major browser will display an "untrusted certificate" error message, like the one seen in the image below.
If you do not want to protect your private key with a password, you can add the
Option 5: Generate a Self-Signed Certificate from an Existing Private Key and CSR
If you already have a CSR and private and need to generate a self-signed certificate, use the following command:
openssl x509 \ -signkey domain.key \ -in domain.csr \ -req -days 365 -out domain.crt
-days parameter is set to 365, meaning that the certificate is valid for the next 365 days.
How to Copy the Contents of a CSR File
Open the directory in which your CSR file is located. Type the following command:
sudo cat domain.csr
Replace domain with the FQDN parameter of your CSR. This command will display the content of the CSR file. Copy all the content, starting from "BEGIN CERTIFICATE REQUEST" and ending with "END CERTIFICATE REQUEST".
Certificate Renewal – Don't Reuse Old CSRs
Just because some web servers allow using old CSRs for certificate renewal doesn't mean you should use them. As a security precaution, always generate a new CSR and private key when you are renewing a certificate. Clinging to the same private key is a road paved with security vulnerabilities.
Also, it is recommended to renew an SSL certificate before the expiration date. Otherwise, a new certificate purchase will be required.
How to Verify Your CSR, SSL Certificate, and Key
As we have already mentioned, it would be wise to check the information provided in the CSR before applying for a certificate. Use the following commands to verify your certificate signing request, SSL certificate, and key:
openssl req -text -noout -verify -in server.csr
This command will verify the CSR and display the data provided in the request.
The following command will verify the key and its validity:
openssl rsa -in server.key -check
When you need to check a certificate, its expiration date and who signed it, use the following OpenSSL command:
openssl x509 -in server.crt -text -noout
A private key is encoded and created in a Base-64 based PEM format which is not human-readable. You can open it with any text editor, but all you will see is a few dozen lines of what seem to be random symbols enclosed with opening and closing headings. See below an example of a private key:
-----BEGIN RSA PRIVATE KEY----- MIICXAIBAAKBgQCVqGpH2S7F0CbEmQBgmbiDiOOGxhVwlG+yY/6OBQoPKcx4Jv2h vLz7r54ngjaIqnqRNP7ljKjFLp5zhnAu9GsdwXbgLPtrmMSB+MVFHTJvKjQ+eY9p dWA3NbQusM9uf8dArm+3VrZxNHQbVGXOIAPNHTO08cZHMSqIDQ6OvLma7wIDAQAB AoGAbxKPzsNh826JV2A253svdnAibeSWBPgl7kBIrR8QWDCtkH9fvqpVmHa+6pO5 5bShQyQSCkxa9f2jnBorKK4+0K412TBM/SG6Zjw+DsZd6VuoZ7P027msTWQrMBxg Hjgs7FSFtj76HQ0OZxFeZ8BkIYq0w+7VQYAPBWEPSqCRQAECQQDv09M4PyRVWSQM S8Rmf/jBWmRnY1gPPEOZDOiSWJqIBZUBznvOPOOQSH6B+vee/q5edQA2OIaDgNmn AurEtUaRAkEAn7/65w+Tewr89mOM0RKMVpFpwNfGYAj3kT1mFEYDq+iNWdcSE6xE 2H0w3YEbDsSayxc36efFnmr//4ljt4iJfwJAa1pOeicJhIracAaaa6dtGl/0AbOe f3NibugwUxIGWkzlXmGnWbI3yyYoOta0cR9fvjhxV9QFomfTBcdwf40FgQJAH3MG DBMO77w8DK2QfWBvbGN4NFTGYwWg52D1Bay68E759OPYVTMm4o/S3Oib0Q53gt/x TAUq7IMYHtCHZwxkNQJBAORwE+6qVIv/ZSP2tHLYf8DGOhEBJtQcVjE7PfUjAbH5 lr++9qUfv0S13gXj5weio5dzgEXwWdX2YSL/asz5DhU= -----END RSA PRIVATE KEY-----
In most cases, you won't need to import the private key code into the server's filesystem, as it will be created in the background while you generate the CSR and then saved onto the server automatically. During SSL certificate installation, the system fetches the key.
Verify Whether a Certificate and Private Key Match
To verify, you need to print out md5 checksums and compare them. Execute the following command:
openssl x509 -noout -modulus -in server.crt| openssl md5
openssl rsa -noout -modulus -in server.key| openssl md5
Troubleshooting SSL Issues
The System Doesn't Fetch the Private Key Automatically
Some systems do not automate the procedure of fetching a private key. Furthermore, if you need to install an existing certificate on another server, you obviously cannot expect that it will fetch the private key. The main difficulty here is how to find the exact location of the key. How you can retrieve the key depends on the server OS in use and whether a command line interface or a web-hosting control panel of a particular type was used for CSR generation.
I Need to Locate My Previously Installed Private Key
If the case is that your certificate has already been installed, follow the steps below which will help you locate your private key on popular operating systems.
You should be able to find the location of your server's private key in your domain's virtual host file.
Navigate to the site's root server location (usually, it's /var/www/directory) and open the site's main configuration file. Look for the
ssl_certificate_key directive that will supply the file path of the private key.
If you cannot find the
ssl_certificate_key directive, it might be that there's a separate configuration file for SSL details. Look for something descriptive, such as ssl.conf.
When using the OpenSSL library on Apache, the private key is saved to /usr/local/ssl by default. Run
openssl version -a, a OpenSSL command which identifies which version of OpenSSL you're running.
The output will display the directory which holds the private key. See the example output below:
OpenSSL 1.0.2g 1 Dec 2016 built on: reproducible build, date unspecified platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS - D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector- strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,- Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int - DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 - DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM - DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/usr/lib/ssl"
The last line
OPENSSLDIR defines the file path. In the example provided, it is the default location
If you didn't generate the CSR with OpenSSL, you need to find and access your main Apache configuration file, which is
httpd.conf. The SSLCertficateKeyFile directive will specify the file path of the private key.
On servers running Windows Internet Information Services, the operating system saves the private key in a hidden folder, much like any regular Windows OS stores critical system data.
However, by exporting a .pfx file, you can fetch the private key and certificate(s). To do so follow the steps below:
- Open the Microsoft Management Console (MMC).
- Located under Console Root, expand the Certificates (Local Computer) tree.
- Your certificate is either located in the Personal or Web Hosting folder. Find the certificate you are looking for. You can identify each certificate by its Common Name (Domain).
- Right-click the certificate you wish to export, and then select All Tasks > Export.
- Follow the guided wizard to export the .pfx file.
You have what you need if you want to save a backup or install the certificate on another Windows server.
If you need to install the certificate on another server that's not running Windows (e.g., Apache) you need to convert the .pfx file and separate the .key and .crt/.cer files. You can do so with OpenSSL.
How to Move an SSL Certificate from a Windows Server to Non-Windows server?
In order to move a certificate from a Windows server to a non-Windows server, you need to extract the private key from a .pfx file using OpenSSL.
- After you have downloaded the .pfx file as described in the section above, run the following OpenSSL command to extract the private key from the file:
openssl pkcs12 -in mypfxfile.pfx -out privatekey.txt -nodes
Where mypfxfile.pfx is your Windows server certificates backup.
- This command will create a privatekey.txt output file. Use a text editor to open the file, and you will see the private key at the top of the list in the standard format:
-----BEGIN RSA PRIVATE KEY----- (Encrypted Text Block) -----END RSA PRIVATE KEY-----
- Copy the private key, including the "BEGIN" and "END" tags, and paste it into a new text file. Save the text file as Your_Domain_Name.key.
I Can't Find My Private Key
If you can't find the private key, look for clues. One thing to note is whether the server is providing a working HTTPS connection. If that is the case, then the private key is accessible to the server and is most likely somewhere on the server.
The logical step would be to search for a .key file. In some cases, OpenSSL stores the .key file to the same directory from where the OpenSSL
-req command was run.
If you tried everything and still can't find the .key file, there is a slight possibility that the key is lost. Don't panic, the smart thing to do would be to generate a new CSR and reissue the certificate. Make sure to remember the location of the private key this time.
OpenSSL Commands for Converting CSRs
If you are working with Apache servers, certificate signing requests (CSRs) and keys are stored in PEM format. But what if you want to transfer CSRs to a Tomcat or Windows IIS server? Well, you would have to convert a standard PEM file to a PFX file. The following commands will help you do exactly that.
Note: Use the
-nodes parameter when you don't want to encrypt the .key file. If you do not use this parameter, you will need to provide a password.
Convert a PEM CSR and private key to PKCS12 (.pfx .p12)
FKCS12 files are used to export/import certificates in Windows IIS.
openssl pkcs12 \ -inkey domain.key \ -in domain.crt \ -export -out domain.pfx
This will take the private key and the CSR and convert it into a single .pfx file. You can set up an export passphrase, but you can leave that blank. Please note that by joining certificate character strings end-to-end in a single PEM file, you can export a chain of certificates to a .pfx file format.
Convert a PKCS12 to PEM CSR
openssl pkcs12 \ -in domain.pfx \ -nodes -out domain.combined.crt
If the .pfx file contains a chain of certificates, the .crt PEM file will have multiple items as well.
Convert PEM to DER
DER is a binary format usually used with Java. To convert an ASCII PEM file to DER, use the following OpenSSL command:
openssl x509 \ -in domain.crt \ -outform der -out domain.der
Convert DER to PEM
If you need to convert a .der file to PEM, use the following OpenSSL command:
openssl x509 \ -inform der -in domain.der \ -out domain.crt
Encrypt an Unencrypted Private Key
The following OpenSSL command will take an unencrypted private key and encrypt it with the passphrase you define.
openssl rsa -des3 \ -in unencrypted.key \ -out encrypted.key
Define the passphrase to encrypt the private key.
Decrypt an Encrypted Private Key
The following OpenSSL command will take an encrypted private key and decrypt it.
openssl rsa \ -in encrypted.key \ -out decrypted.key
When prompted, enter the passphrase to decrypt the private key.
After this tutorial guide should know how to generate a certificate signing request using OpenSSL, as well as troubleshoot most common errors.
Make sure to verify each certificate authority and the types of certificates available to make an educated purchase.