TLS terms
Explanations of Transport Layer Security (TLS) terminology and concepts
Transport Layer Security (TLS) is a secure way for computers to communicate. It uses encryption, a certificate file , and a private key file to create secure communications between computers. TLS was formerly called Secure Sockets Layer (SSL). FairCom products support TLS 1.3, which is the latest version.
Transport Layer Security (TLS) is a secure way for computers to communicate. It uses encryption, a certificate file , and a private key file to create secure communications between computers. TLS was formerly called Secure Sockets Layer (SSL). FairCom products support TLS 1.3, which is the latest version.
TLS works by defining a series of requests and responses between a client computer and a server computer. This is called the TLS handshake.
Section | Description |
|---|---|
A certificate authority (CA) issues digital identity certificates to identify computers to each other using the TLS protocol. Popular CAs include letsencrypt.org and verisign.com. | |
A certificate authority administrator creates, manages, and renews a company's private certificates. | |
A CA application is software that enables a company to be a private certificate authority by providing means to create, manage, and renew certificates. | |
A CA certificate is a digital identity certificate issued by a public or private certificate authority (CA). | |
A CA certificate file is a certificate file created by a CA administrator that contains a CA certificate. | |
A CA private key is a key that, when paired with its corresponding CA certificate, functions to create client and server certificates. | |
A CA private key file is a file that contains a CA private key. | |
A digital identity certificate is an electronic document used by TLS to allow an application, such as a web browser, MQTT client, or server, to know when it is communicating with an intended computer rather than a fraudulent computer impersonating the intended computer. | |
A certificate authority (CA) is a trusted entity that issues digital certificates to verify the identity of computers on a network. | |
A certificate authority administrator creates certificates that use public and private keys to certify their authenticity. | |
A certificate chain is the genealogy of certification signatures that verify the authenticity of a certificate. | |
A certificate file contains the certficate required by TLS to prove the identity of a computer. | |
A certificate signing request is a request made for a certificate authority to create a certificate. | |
A client certificate is a digital identity certificate that a client computer uses to identify itself to a server computer. | |
A client certificate file contains a client certificate with its associated public key and client private key. | |
A client private key can be embedded in a client certificate in order to authenticate user accounts on a FairCom server. | |
A client private key file is a file that contains a client's private key. | |
A certificate signing request (CSR) is a file that contains the identity information needed to create a certificate. A CA creates a certificate by signing a CSR file using its own closely held private key. | |
A digital certificate is a certificate used in tandem with private keys by TLS to create secure communications between computers. See certificate for more information. | |
A PEM file is a file format that may contain one or more embedded parts, such as a certificate, certificate request, private key, and certificate revocation list. | |
A private certificate authority is a type of CA that generates and issues digital certificates for internal use within a company rather that public use on the internet. | |
A private key is the secret required by TLS to prove the identity of a computer. It is the private key of the public-private key pair that is used to create a computer's digital identity certificate. It is stored in a private key file. | |
A private key file is a file that contains the private key required by TLS to prove the identity of a computer. The private key file contains the private key of the public-private key pair that is used to create a computer's digital identity certificate . The private key file typically has the extension, | |
A private key password is a password that encrypts a private key for safely embedding in a client certificate. | |
A public certificate authority is a CA that issues digital certificates for use on the public internet, but does not provide certificates for internal use within a company. | |
A public key is used in tandem with a private key in order to create secure communications with servers. Public keys are used to decrypt the content encrypted by the private key. | |
A public-private key pair is a pair of asymmetrical keys. The private key can encrypt a secret and only the public key can decrypt that secret. This also works in reverse where the public key can encrypt a secret and only the private key can decrypt that secret. | |
A self-signed server certificate is a simple alternative to creating, managing, and distributing a CA certificate to client computers. A self-signed server certificate file can verify the identity of a server for a client computer. | |
A self-signed server certificate file contains a self-signed server certificate. FairCom supports certificates stored in PEM files. | |
A server certificate is a certificate that a server computer uses to identify itself to client computers. | |
A server certificate file contains a client certificate with its associated public key and server private key. | |
A server private key can be embedded in a server certificate in order to authenticate itself to user accounts. | |
A server private key file is a file that contains a server's private key. | |
TLS handshake is a series of requests by a client computer and the corresponding responses by a server computer. | |
Transport layer security (TLS) is the industry standard method of securing network communications over TCP/IP. | |
X.509 is a standard that defines a hierarchical format for public key certificates. | |
The X.509 Not After field defines the latest date and time that a certificate is valid. | |
The X.509 Not Before field defines the earliest date and time that a certificate is valid. | |
The X.509 Subject field identifies the primary subject of a certificate. The subject typically contains the username for clients and the LDAP-distinguished name for servers. |
A certificate authority administrator creates, manages, and renews a company's private certificates.
The CA administrator is like a notary. She is responsible for correctly using certificates and protecting their private keys. For example, she must ensure malicious actors cannot access a private key file. She must protect a file from unauthorized access using file permissions or key management software. She must securely distribute private key files to their appropriate locations. She must protect a private key password from unauthorized access and securely distribute it for appropriate use.
The CA administrator chooses whether to manage self-signed server certificates, which is the simpler approach, or she chooses to manage server and client certificates using a CA certificate, which is the more capable approach. For pros and cons, see self-signed server certificate file.
Simpler approach
The CA administrator creates a self-signed server certificate for each internal server that communicates using TLS. She distributes this file to server administrators, who register it with FairCom software.
More capable approach
The CA administrator starts by creating a CA certificate and its private key and storing them in the CA certificate file and CA private key file. She never distributes the CA private key file and must secure it carefully from unauthorized access. Likewise, she must never combine the CA private key and CA certificate into the same file because it is too easy to distribute the CA private key accidentally.
The CA administrator uses the CA certificate and its private key to create a server certificate and server private key for each internal server that communicates using TLS. She stores the certificate in the server certificate file and the private key in the server private key file. She distributes these files to server administrators, who register them with FairCom software.
The CA administrator uses the CA certificate and its private key to create a client certificate and client private key for each account the company wants to authenticate using TLS. She creates a private key password and stores it safely in a password management system. She uses the private key password to encrypt the client private key and stores it with the client certificate in the client certificate file. She secures the private key password and securely shares it with appropriate users.
A CA application is software that allows a company to be a private certificate authority. It provides all the functionality needed by a CA administrator, such as creating, managing, and renewing CA certificate files, server certificate files, and client certificate files.
A CA certificate is a digital certificate. It is analogous to a notary stamp: it signs other certificate files to verify their authenticity. A CA certificate is always paired with a CA private key. You can use them together to create client and server certificates. A CA certificate exists in memory and is stored in a CA certificate file.
A CA certificate file is a certificate file that contains a CA certificate.
A CA administrator creates a CA certificate and saves it to a CA certificate file. A CA application often combines these two steps into one.
FairCom's CA application names the CA certificate file ca.crt.
FairCom software expects a certificate to be stored in a PEM file.
A company distributes the CA certificate file to client computers and configures client software to validate server identities. For example, a web browser stores and uses CA certificates to validate the identity of web servers.
A company distributes the CA certificate file to its servers and configures server software to use it to authorize clients. For example, a client may use a client certificate to authenticate with a server.
A CA private key is always paired with a CA certificate. Together, they can create client and server certificates. A CA private key exists in memory and is stored in a CA private key file.
A CA private key file contains a CA private key. FairCom's CA application names the CA private key file, ca.key.
FairCom software expects a private key to be stored in a PEM file.
The CA administrator must never distribute the CA private key file and must carefully secure it from unauthorized access. Likewise, she must never combine the CA private key and CA certificate into the same PEM file because it is too easy to distribute the CA private key accidentally.
TLS uses digital certificates and private keys to create secure communications between computers.
A certificate consists of a public key, information about the key in X.509 format, a certificate signing request (CSR), and a digital signature. A CA creates the digital signature by encrypting the certificate's information with its private key. In this way, a CA acts like a notary that signs and verifies that a server is legitimate.
Software using a certificate must trust the certificate authority (CA) and use the CA’s public key to decrypt the contents of the digital signature. When the certificate's contents match the decrypted contents of the digital signature, the certificate is verified. Software is like a lawyer verifying the legitimacy of a signed contract. The software trusts the CA, verifies a CA signed the certificate, and verifies the certificate has not been tampered with.
A certificate is associated with a public key and a private key. The certificate and its public key are stored in one file called a certificate file. The private key is stored in a private key file and must be carefully secured. A client certificate file may optionally include its private key when encrypted by a private key password.
Digital Certificate for FairCom's Public Website
Types of certificates
FairCom servers and client software support three types of certificates:
A certificate authority (CA) is a trusted entity that issues digital certificates to verify the identity of computers on a network.
A CA is like a government office that issues a notary stamp. A CA certificate is similar to a notary stamp: it signs other certificate files to verify their authenticity. Like a notary, a certificate authority administrator creates certificates that use public and private keys to certify their authenticity. Software verifies the legitimacy of certificates, like a lawyer verifying the legitimacy of a signed contract.
A public certificate authority generates and issues digital certificates for use on the public Internet. It does not provide certificates for internal use within a company. Thus, communications with FairCom server software, which is not typically public-facing, are not secured using certificates from public CAs.
A company often needs to secure communications between its internal servers to prevent eavesdropping by malicious attackers who penetrate its internal network.
Companies can protect internal network communications by providing certificates for internal use. A company is often the private certificate authority for its internal servers. A company uses an internal CA application to generate, issue, and manage internal-use certificates.
FairCom provides a simple CA application for customers to create and manage certificates. FairCom does not act as a CA for customers’ internal servers; instead, it supplies the customers with the software to create and manage their certificates. Using the notary analogy, FairCom provides the tools for customers to create their notary stamps.
A certificate chain establishes trust. The public key of the next certificate in the chain signs the previous certificate, and the last certificate in the chain is a trusted certificate authority.
A certificate chain is stored in a certificate file. The TLS handshake process validates a certificate chain when it validates a CA, server certificate, or client certificate.
A private certificate authority typically creates certificates that contain only the CA certificate, but a large company may have a hierarchy of certificate authorities requiring a certificate to contain a certificate chain.
A certificate file contains a certificate, such as a CA, server, or client certificate.
FairCom software requires a certificate file to implement the following:
A certificate signing request is a request for a certificate authority to create a certificate. It contains the X.509 information required by the certificate.
A private certificate authority typically requires someone to fill out a form that requests the information needed to create a server or client certificate. A CA administrator uses this information to create a certificate file and its private key file.
A client certificate authenticates a user or software account. It can replace a username and password. Client software connects to a server through TLS and uses a client certificate to prove its identity to the server.
A company uses its CA certificate and the CA private key to create a client certificate and client private key. It assigns the account’s username to the X.509 subject field. It typically encrypts the client private key with a private key password and combines the client certificate with the encrypted client private key into a client certificate file. It distributes the client certificate file to users or client computers.
A company must also configure the server software to use the CA certificate so the server can authenticate the account represented by a client certificate.
When client software uses TLS and a client certificate to connect to a FairCom server, the TLS handshake challenges the server to validate the client certificate. If the certificate is valid, a FairCom server uses the X.509 subject field as the account's username and authenticates it. The server uses the account’s internally assigned permissions to authorize what the account can do.
NOTE: Client certificate authentication does not work with LDAP authentication.
The client certificate file contains a client certificate with its associated public key and client private key. A CA administrator uses the private key password to encrypt the client private key.
A user configures client software to use the client certificate file instead of a username and password.
If the client private key in the PEM file is encrypted, the software must decrypt it before it can authenticate to the server. The user must embed the private key password in the software or supply it when logging in.
FairCom software determines a client certificate file is valid under the following conditions:
It must be a PEM file.
It must follow the X.509 standard.
It must have a complete certificate chain using the same root CA as the server certificate.
The current date must be between the X.509 Not Before and X.509 Not After fields.
The X.509 subject field must contain a valid username.
Advantages of client certificate files
Client certificate files have the following advantages over usernames and passwords:
A client certificate file is more secure than a username because a certificate authority signs the username, making it irreputable.
A client certificate is more secure than a password because its private key is the password. A private key cannot be brute forced because it is too long and crypto-random. In addition, client software never transmits the private key to the server; instead, the TLS handshake validates it.
You can store a client certificate in secure key stores provided by the operating system or certificate management software. File system permissions can also protect a certificate.
The organization must sign a client certificate. Malicious attackers cannot falsify a client certificate because they do not have the private CA key that signed it.
A client certificate with an encrypted private key provides multi-factor authentication because a client using the certificate must also provide the private key password to decrypt the private key.
An organization may optionally assign a client certificate's validity start and end dates to prevent the use of old credentials and the premature use of new credentials.
An organization may optionally embed specific IP Addresses or hostnames into a certificate to ensure the certificate is valid only when a client connects from one of those locations.
An organization can revoke a certificate to prevent it from being used.
The client certificate file contains a client certificate with its associated public key and client private key. A CA administrator uses the private key password to encrypt the client private key.
A user configures client software to use the client certificate file instead of a username and password.
If the client private key in the PEM file is encrypted, the software must decrypt it before it can authenticate to the server. The user must embed the private key password in the software or supply it when logging in.
FairCom software determines a client certificate file is valid under the following conditions:
It must be a PEM file.
It must follow the X.509 standard.
It must have a complete certificate chain using the same root CA as the server certificate.
The current date must be between the X.509 Not Before and X.509 Not After fields.
The X.509 subject field must contain a valid username.
Advantages of client certificate files
Client certificate files have the following advantages over usernames and passwords:
A client certificate file is more secure than a username because a certificate authority signs the username, making it irreputable.
A client certificate is more secure than a password because its private key is the password. A private key cannot be brute forced because it is too long and crypto-random. In addition, client software never transmits the private key to the server; instead, the TLS handshake validates it.
You can store a client certificate in secure key stores provided by the operating system or certificate management software. File system permissions can also protect a certificate.
The organization must sign a client certificate. Malicious attackers cannot falsify a client certificate because they do not have the private CA key that signed it.
A client certificate with an encrypted private key provides multi-factor authentication because a client using the certificate must also provide the private key password to decrypt the private key.
An organization may optionally assign a client certificate's validity start and end dates to prevent the use of old credentials and the premature use of new credentials.
An organization may optionally embed specific IP Addresses or hostnames into a certificate to ensure the certificate is valid only when a client connects from one of those locations.
An organization can revoke a certificate to prevent it from being used.
A client private key embedded in a client certificate can authenticate user accounts on a FairCom server.
A client private key is always paired with a client certificate and its embedded public key. It is encrypted by a private key password and embedded in the client certificate. You rarely store it separately in a client private key file.
A client private key file contains a client private key. Normally, a CA administrator does not create this file; instead, she encrypts the client private key using a private key password and embeds it in the client certificate.
If a client private key is not encrypted and embedded in the client certificate file, you must configure client software to use both the client private key file and the client certificate file.
Certificates and private keys are typically stored in Privacy-Enhanced Mail (PEM) files. A PEM file is a file format that may contain one or more embedded parts, such as a certificate, certificate request, private key, and certificate revocation list.
FairCom software works with certificates and private keys stored in PEM files.
You must know when a private key is stored in a PEM file so you do not inappropriately distribute it. You can look inside a PEM file for the following markers that indicate it contains a private key:
-----BEGIN PRIVATE KEY----- -----END PRIVATE KEY-----
A private certificate authority generates and issues digital certificates for internal use within a company. It does not provide certificates for use on the public Internet.
A private certificate authority can create a CA certificate that can secure communications with FairCom server software.
A private key is part of public-key cryptography. It is always paired with a public key. Only the private key can decrypt the content encrypted by the public key, and only the public key can decrypt the content encrypted by the private key.
You must not distribute a private key and must carefully protect it from unauthorized access.
A private key is part of public-key cryptography. It is always paired with a public key. Only the private key can decrypt the content encrypted by the public key, and only the public key can decrypt the content encrypted by the private key.
You must not distribute a private key and must carefully protect it from unauthorized access.
A company must protect each certificate's private key file. If a malicious actor can copy a certificate and its private key, the actor can use it to impersonate a server or client. If a malicious actor can copy a CA certificate and its private key, the actor can create client and server certificates to impersonate any server or client.
A private key password encrypts the client private key in the client certificate file. After decrypting the client private key, software can use the client certificate file to authenticate an account.
A user typically provides the private key password to a software application at run time or when configuring it. A software vendor may embed a private key password in an application to validate a client certificate before allowing the certificate to authorize users on a server. A software vendor may use this approach to validate software license keys.
A public certificate authority generates and issues digital certificates for use on the public Internet. It does not provide certificates for internal use within a company. Thus, communications with FairCom server software, which are not typically public-facing, are not secured using certificates from public CAs.
A public key is part of public-key cryptography. It is always paired with a private key. Only the private key can decrypt the content encrypted by the public key, and only the public key can decrypt the content encrypted by the private key.
Unlike a private key, you can freely distribute a public key.
Software creates digital certificates using public and private key pairs. A CA application creates a certificate by creating a matching pair of public and private keys. It uses the private key to encrypt the certificate's information as a tamperproof digital signature. The application then embeds the signature and the matching public key in the certificate so software can use the public key to decrypt the signature and verify that it matches the certificate's contents.
A simple alternative to creating, managing, and distributing a CA certificate to client computers is to use self-signed certificates. You distribute a unique self-signed server certificate file to each server and each client computer. The client computer uses the self-signed server certificate file to verify the identity of a server.
A self-signed server certificate file contains a self-signed server certificate. FairCom supports certificates stored in a PEM file.
The self-signed server certificate file must not contain the server private key.
A self-signed server certificate file is simple to manage but has the following disadvantages because a CA does not sign it:
Web browsers reject all communications with a server that has a self-signed certificate. The browser tells the user that communications are unsafe, which leads the user to doubt the server's security. There is no workaround because there is no trusted internal CA certificate to register with the web browser.
A client requires a separate self-signed server certificate file for each server to which it connects. You must distribute the server’s self-signed server certificate file to each client computer that connects to it. In contrast, if you use a CA certificate, you only need to distribute one CA certificate to each client computer.
Client certificates must be signed by a CA certificate. Once you choose to use client certificates, managing all certificates through a CA certificate is simpler.
A server certificate protects communications between servers and software. It verifies a server's identity and prevents a man-in-the-middle attack.
A company uses its CA certificate and the CA private key to create a server certificate file and a server private key file for each internally facing server that requires secure communications. A server administrator copies these files to the appropriate server. A server needs the server certificate and private key to verify its identity to client software.
You must configure server software to use a server certificate file and a server private key file to prove the server's identity to software connecting to the server through TLS. You must also configure client software to use the CA certificate file so the client software can verify the server's identity.
When client software uses TLS to connect to a FairCom server, the TLS handshake challenges the client to validate the server certificate. The client uses a local copy of the CA certificate to complete the challenge. If the client verifies the certificate is authentic, TLS establishes a secure connection between the computers.
The client certificate file contains a server certificate with its associated public key and server private key. A CA administrator uses the private key password to encrypt the server private key.
A server administrator configures server software to use the server certificate file.
A server private key embedded in a server certificate can prove the server's identity to software connecting to the server through TLS.
A server private key is always paired with a server certificate and its embedded public key. It is encrypted by a private key password and embedded in the server certificate. You rarely store it separately in a server private key file.
A server private key file contains a server private key. Normally, a CA administrator creates this file and embeds it in the server certificate.
If a server private key is not encrypted and embedded in the server certificate file, you must configure server software to use both the server private key file and the server certificate file.
Transport Layer Security (TLS, previously Secure Sockets Layer or SSL) is the best practice for securing network communications over TCP/IP. It uses proven public and private key cryptography. It is the technology that secures all communications on the World Wide Web.
The TLS protocol uses digital certificates, private keys, and a TLS handshake to establish a secure encrypted session between two computers. It can verify the computers' identities without transmitting the private keys used to create the certificates.
FairCom servers use the OpenSSL toolkit, which implements TLS protocol V1.3. As of this writing, TLS 1.3 is the latest version of TLS and fixes vulnerabilities in earlier versions.
The X.509 standard defines a hierarchical format for public key certificates. The following hierarchy contains standard fields.
Certificate
Version
Serial Number
Signature Algorithm
Issuer
Validity
Not Before
Not After
Subject
Subject Public Key Info
Public Key Algorithm
Subject Public Key
Subject public Key IX509v3 extensions:
X509v3 Subject Alternative Name
DNS Name
The X.509 not after field defines the latest date and time that a certificate is valid, such as:
Not After: Nov 22 07:59:59 2025 GMT
The X.509 not before field defines the earliest date and time that a certificate is valid, such as:
Not Before: Nov 21 08:00:00 2024 GMT
The X.509 subject field identifies the primary subject of a certificate.
For client certificates, the subject typically contains the username of the account represented by the client certificate.
For server certificates, the subject typically contains the LDAP-distinguished name of the server, such as:
"CN = docs.faircom.com O = FAIRCOM USA CORPORATION L = CARSON CITY ST = Nevada C = US"