TLS terms

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.

TLS uses a public-private key pair to establish the identity of a computer. It does this by putting the private key in a private key file that is stored only on the computer being identified. It then requires the public key to be embedded in a certificate that is shared with other computers. When a client computer wants to verify the identity of a server computer, the TLS protocol requires the client computer to encrypt a calculated secret using the public key in the certificate and requires the server computer to successfully decrypt the calculated secret using its private key. Since the only way to decrypt the calculated secret is to have the private key file, it proves the identity of the server. Verifying client identity to a server is a similar process.

The private key file contains the secret key that identifies a computer and the certificate contains the public key that validates identity.

See Certificate Authority.

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.

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 identity certificate issued by a public or private certificate authority (CA). 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 shares its CA certificate file to allow computers to verify the identity of certificates signed by the CA. Operating systems contain public CA certificates from the major CAs so they can verify the identity of websites. Organizations create and distribute private CA certificate files to the computers inside their network so they can verify each other's identity.

In contrast, a server certificate or client certificate is a certificate signed by a CA to identify one specific computer.

"tls": {
  "certificateAuthoritiesFilename": "C:/Certificates/ca.crt",
  "certificateFilename":            "C:/Certificates/server.crt",
  "privateKeyFilename":             "C:/Certificates/server.key"
}

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

A certificate authority (CA) is a trusted entity that issues digital certificates to verify the identity of computers on a network using the TLS protocol.

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 to securely identify servers 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 private 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 so that a client, for example, can use a client certificate to identify itself to a server.

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.

See CA administrator.

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, required by TLS to prove the identity of a computer.

The certificate file often has the extension, .crt, such as server.crt or client.crt. It may also have one of the file extensions: .cer, .pem, .ca-bundle, .p12, .pfx, etc.

A PEM (privacy-enhanced mail) file often combines multiple certificates and the private key in one file.

FairCom software requires a certificate file to implement the following:

"tls": {
  "certificateAuthoritiesFilename": "C:/Certificates/ca.crt",
  "certificateFilename":            "C:/Certificates/server.crt",
  "privateKeyFilename":             "C:/Certificates/server.key"
}

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.

The identity information in the CSR file includes the computer's domain name, hostname, and potentially other information defined by the X.509 standard. In addition, a CSR file always includes the public key of a public-private key pair that is crypto-randomly generated to identify the computer. The private key of the public-private key pair is stored separately from the certificate in a private key file.

A certificate file and its corresponding private key file are required by the TLS protocol to identify a computer to other computers.

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 is a digital identity certificate that a client computer uses to authenticate a user or software account to a server computer. 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.

client.tls_set( ca_certs = "/Certificates/ca.crt", certfile = "/Certificates/client.crt", keyfile = "/Certificates/client.key" )

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:

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.

See certificate signing request.

See certificate.

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 the secret key used in public-key cryptography and is stored in a private key file. 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 the secret key used in public-key cryptography and is stored in a private key file. 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 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 .key, such as server.key or client.pem.

When you create a certificate, you first create a public-private key pair for a specific computer. You save the private key to its own file with a .key file extension. This is the private key file. The certificate file contains the public key from the public-private key pair.

In TLS, the private key file and the certificate file are both required to verify a computer's identity.

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.

See Transport Layer Security.

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:

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.

In FairCom servers, you configure TLS to use a certificate by setting the "tls" property in listeners in the services.json file. The "certificateAuthoritiesFilename" property specifies the CA certificate file. The "certificateFilename" property specifies the server certificate file. The "privateKeyFilename" property specifies the private key file. When the certificate and private key are combined into one file, assign the file to the "certificateFilename" property.

"tls": {
  "certificateAuthoritiesFilename": "C:/Certificates/ca.crt",
  "certificateFilename":            "C:/Certificates/server.crt",
  "privateKeyFilename":             "C:/Certificates/server.key"
}

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.

See Transport Layer Security.

See Transport Layer Security.

TLS handshake is a series of requests by a client computer and the corresponding responses by a server computer.

TLS handshake

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.

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"