To configure trusted certificates, you need to know what certificate authority is and its role in issuing certificates. Read below to learn more about certificate authorities, trusted SSL certificates, the dangers of untrusted certificates, and more.
Trusted Certificates Security Assessment
CVSS Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
What is a Certificate Authority?
A certificate authority (CA), also called a certification authority, is an organization that issues, signs, and stores digital certificates to create greater trust and security online. Certificate authorities are part of a more extensive system called the public key infrastructure (PKI), whose purpose is to facilitate the secure transfer of information, particularly in cases where more rigorous forms of security and authentication are required.
One of the main roles of CAs is to issue certificates that verify websites. These are so-called SSL/TLS certificates, but CAs issue code-signing and email and document-signing certificates.
By issuing a certificate for a website and its corresponding server, the CA acts as a trusted third party that guarantees that the certified party is who they claim to be. This allows clients to create secure connections to servers and circumvent any malicious parties, such as hackers, who may want to eavesdrop on the connection and interfere with it.
To be trusted, the certificate issued by the authority must comply with the X.509 cryptographic standard that binds the party’s identity (an individual, an organization, or a hostname) to the public key they will be using. This public key is part of the certificate and is known by everyone, whereas the corresponding private key is only known to the certificate holder. These two keys are necessary for the encryption and decryption of communications between clients and the server (certificate holder).
The process of validating the identity of the certificate applicant can be more or less complex, depending on the party’s needs. In its simplest form, it is a fundamental domain validation (DV) that confirms that the person or entity is the domain manager. In its more complex forms, it goes through more thorough validation of the organization (OV) that requests the certificate or even an extended validation (EV) which is very thorough.
In addition to vetting and validating the identities of the parties to whom they issue certificates, certificate authorities also keep certificate revocation lists (CRL). These include certificates that have become invalid before their expiry dates. Usually, this means that browsers can no longer trust a particular certificate.
Most trusted public CAs are commercial entities that issue certificates against a fee though there are also non-profits, such as Let’s Encrypt, that issue trusted certificates for free.
Certificates can also be self-signed, in which case the entity that has issued the certificate acts as its own CA. Browsers don’t consider self-signed certificates secure and trustworthy and will usually mark websites with such certificates as being “not secure” or may block the website altogether. A self-signed certificate makes sense for local development purposes or in an enclosed system but to be considered secure, websites need certificates signed by a CA.
Prevention Guide
Learn how to detect and prevent different kinds of SSL/TLS vulnerabilities.
What are Trusted Certificates?
Trusted certificates are digital certificates issued by a CA and backed by the CA’s root certificate under the so-called “chain of trust.” A trusted SSL/TLS certificate enables websites to move to HTTPS and encrypt their communications.
The certificate is hosted on the website’s server. It contains its public key, the CAs digital signature, the domain’s identity, information about the CA itself, issue and expiry dates, and other relevant information. The public key of the CA is also possessed by clients, as it is publicly available and part of each browser’s and operating system’s list of trusted CAs and root certificates.
How do SSL/TLS certificates work?
When a client attempts to connect to the website and communicates with its server, the client will reference the CA certificate to receive the website’s public key and verify the identity of the domain/server, i.e., authenticate the CA signature on the server certificate.
The purpose of the signature is to guarantee the authenticity of the sender, integrity of the message, and non-repudiation of the communication between client and server. This is done through the use of a hashing algorithm. Upon verifying the certificate, the client will establish a secure connection to the server and begin communication.
By verifying the certificate, the client ensures they are connected to the domain and server they want to connect to. Otherwise, a man-in-the-middle (MITM) could divert the connection attempt and impersonate the domain to steal authentication data from the client or conduct another type of attack.
What is a root SSL/TLS certificate?
The root certificate is the foundation of the chain of trust that extends to server certificates. The CA’s primary certificate is used to validate all other certificates in the chain. This includes intermediate certificates, which, in turn, are used to issue and validate leaf certificates (or server certificates). As the foundation of the trust hierarchy and PKI, root certificates must comply with strict security requirements and are also carefully guarded by the CA so as not to become compromised.
Root certificates are self-signed by the CA and are made trustworthy by means different from certificates. This is done via secure physical distribution, i.e., they come as part of an operating system’s or browser’s root program. Moreover, CAs usually use a hardware security module (HSM) to store their keys. They keep this module offline unless it is needed to sign and issue intermediate certificates.
Can a trusted certificate be dangerous?
The PKI is not bulletproof, and there are possibilities for trusted certificates, even root certificates, to be abused by malicious actors and become dangerous. The greatest threat lies in the possibility of the CA becoming compromised and its private key stolen and used.
A stolen root certificate key allows attackers to issue certificates that would immediately be trusted in the chain of trust. It would also allow them to abuse existing certificates, drop legitimate and validated certificates, and make all other certificates down the line unusable.
In addition, certificates are often limited to being valid only for specific purposes – i.e., server authentication, code signing, and more. However, sometimes, a certificate may be signed to be valid for all purposes. In particular, a valid root certificate for all purposes opens the door for abuse because it can be used to issue all kinds of other certificates if its private key falls into the wrong hands.
Trusted certificate configuration
To issue a trusted certificate for your web application, the certificate needs to contain the correct information for your web application, such as the domain name as the certificate’s common name.
In addition, the certificate needs to be signed by a certificate authority (CA) that the user’s browser trusts. The web server must then be configured to present the certificate on incoming HTTPS requests. Use one of the following guides to generate and use a trusted certificate:
OpenSSL
You can manually create a new, secure certificate and a certificate signing request (CSR). For example, to generate the certificate with a private key and the CSR run:
openssl req -nodes -new -newkey rsa:2048 -sha256 -out csr.pemAnswer all questions according to your needs. Then send the csr.pem file to your CA. They will use this request to sign your certificate and provide you with the signed certificate. If the signed certificate is returned to you as new.crt, you can combine the key and the signed certificate as follows:
cp privkey.pem /etc/ssl/privkey.key
cp privkey.pem /etc/ssl/new.pem
cat new.crt >> /etc/ssl/new.pemThe resulting new.pem file can be copied to your webserver directory to be used in the web application. Suppose your certificate is signed by an intermediate certificate (not stored in your user’s certificate storage) instead of a root certificate (stored in your user’s certificate storage). In that case, you will need to bundle the intermediate certificate with your server certificate.
Apache
On Apache you need to insert the certificate into the virtual host configuration in/etc/apache2/sites-enabled/domain.confor/etc/httpd/sites-enabled/domain.conf:
<IfModule mod_ssl.c>
SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
<VirtualHost *:443>
ServerAdmin webmaster@localhost
ServerName example.com
DocumentRoot /var/www
SSLEngine on
SSLCertificateFile /etc/ssl/new.pem
SSLCertificateKeyFile /etc/ssl/privkey.key
</VirtualHost>
</IfModule>nginx
For Nginx, update the configuration file, which is usually located at /etc/nginx/nginx.conf, /etc/nginx/sited-enabled/yoursite.com (Ubuntu / Debian) or /etc/nginx/conf.d/nginx.conf (RHEL / CentOS). Add the following directive to the server section:
server {
listen 443;
server_name example.org;
root /usr/share/nginx/www;
index index.html index.htm;
ssl on;
ssl_certificate /etc/ssl/new;
ssl_certificate_key /etc/ssl/privkey.key;
}Let’s Encrypt
With Let’s Encrypt is very easy to generate secure and trusted certificates. Install the certbot on the server which runs the webserver and run the following command:
certbot run -d [DOMAIN] --staple-ocsp --hsts
