Securing Communication with TLS Certificates: A Definitive Guide for Couchbase Server (Part 1 of 3)

Transport Layer Security (TLS) certificates are vital components in securing network communications with a Couchbase Server deployment. TLS ensures the confidentiality, integrity, and authenticity of data transmitted between clients and servers. This comprehensive guide aims to demystify the configuration and utilization of TLS certificates in Couchbase Server, empowering administrators to enhance the security of their deployments.

In this 3 part series, we’ll first look at the history of TLS and the components involved,  then in Part 2 we’ll look at some of the functional aspects of TLS in action and finally in Part 3 we’ll look at using TLS with Couchbase Server.  

Understanding TLS and How It Works

Let’s start by explaining some of the fundamentals of TLS.  TLS is a cryptographic protocol that establishes a secure connection between a client and a server over an untrusted network.  TLS replaced the legacy SSL protocol and provides end-to-end encryption, protecting data from eavesdropping, tampering, and forgery. TLS operates through a combination of asymmetric and symmetric encryption algorithms, secure key exchange mechanisms, and digital certificates.

At the heart of TLS is the use of these certificates, which are digital documents that bind an entity’s identity (such as a website or an organization) to a cryptographic key pair.  Couchbase Server uses the x.509 standard for public-key certificates.

History and versions of TLS

Over the years, TLS has undergone several version updates to address security vulnerabilities and improve its overall strength and performance. TLS v1.0 was the first version widely adopted, but it suffered from some discovered vulnerabilities, including POODLE and BEAST attacks, which prompted the need for stronger versions. TLS v1.1 introduced more robust cryptographic algorithms and eliminated the vulnerabilities present in TLS v1.0. Subsequently, TLS v1.2 further strengthened security with improved cipher suites, enhanced forward secrecy, and support for modern cryptographic algorithms. TLS v1.3, the most current version, brings even more significant changes. It offers faster handshakes, reduced latency, and improved security by removing older and weaker cryptographic algorithms, making it the most secure and efficient version to date.

In TLS v1.3, in addition to the redesign of the handshake process, reducing the number of round trips required for establishing a secure connection, it also mandates the use of Perfect Forward Secrecy (PFS) and eliminates support for outdated encryption algorithms, further enhancing security. TLS v1.3 provides better protection against eavesdropping and tampering with the data in transit, addressing security concerns raised by previous versions. Additionally, TLS v1.3 introduces a feature called “0-RTT” (Zero Round Trip Time Resumption), which allows clients to resume a connection without any additional round trips, improving performance for repeat visits to the same server.

Certificate Authorities and their Role

In the realm of TLS, a Certificate Authority (CA) plays a pivotal role. CAs are trusted entities responsible for issuing, revoking, and managing the digital certificates. They act as the gatekeepers of trust, verifying the legitimacy of entities and signing their certificates. 

Typically an entity’s (e.g., a website or a user) certificate is generated and managed by what is known as an Intermediary Certificate Authority.   The Intermediate Certificate Authority in turn has their certificate issued and managed by a Root Certificate Authority. 

An entity certificate is typically valid only for a few months, an intermediate certificate is rotated every few years and a root certificate can be valid for multiple decades.   This Root Certificate Authority is typically kept offline for security reasons and only rarely accessed when the Intermediate Certificate Authority’s cert needs to be replaced in what is known as a key ceremony.  Key ceremonies are usually conducted in secure, controlled environments with multiple layers of physical and procedural security measures in place.

Public key cryptography

Public key encryption, also known as asymmetric encryption, is a cryptographic scheme that enables secure communication and data protection by using a pair of mathematically related keys: a public key and a private key. The public key, openly shared and distributed, is used for encrypting data, while the private key, kept secret and known only to the key owner, is used for decrypting the encrypted data.  Private keys typically do not ever leave the host on which they are generated.  Messages encrypted with the public key can only be decrypted using the corresponding private key, ensuring that only the intended recipient, who possesses the private key, can access the original information.  Asymmetric encryption is computationally more intensive and slower than symmetric encryption.

TLS uses asymmetric encryption during the initial handshake to enable a client to send a shared secret key to the server known as a session key, which is then used to establish bidirectional communication encrypted with symmetric encryption.  TLS uses symmetric encryption for the actual data transmission during a secure session because it provides high-speed, efficient encryption for bulk data. 

Digital signatures

In the context of digital certificates, a key is used to sign a certificate through a process known as digital signing. When a Certificate Authority (CA) issues a certificate to an entity (e.g., a website or a user), it generates a digital signature using the CA’s private key. This signature is computed based on the contents of the certificate, including the entity’s identity information and its public key. The digital signature serves as a unique fingerprint that binds the certificate’s content to the CA’s identity and ensures the integrity of the certificate. When the certificate is presented to others, they can use the CA’s public key to verify the digital signature. If the signature is valid, it confirms that the certificate has not been tampered with and was indeed issued by the trusted CA, establishing the authenticity and trustworthiness of the certificate for secure communication and authentication purposes.

X.509 Certificates

An X.509 certificate is a digital document used in public key infrastructure (PKI) systems to bind an entity’s identity (e.g., a website or an organization) to its public key. It contains essential information such as the entity’s name, public key, the digital signature of the Certificate Authority (CA), validity dates, and other metadata. Unlike an encryption key, which is a piece of sensitive information used for encrypting and decrypting data, the X.509 certificate does not perform encryption or decryption directly. Instead, it acts as a means to verify the authenticity of the public key it contains and establishes trust between parties. 

What’s contained in a certificate can vary, but a typical certificate file’s components are shown on the right.

Subject Alternative Name (SAN)

Within TLS certificates, the Subject Alternative Name (SAN) extension provides additional flexibility and security. The SAN field allows a certificate to specify multiple identities (such as domain names or IP addresses) that the certificate is valid for. This extension is particularly useful when a single certificate needs to cover multiple domains or subdomains associated with a specific server.

Now we’ve covered the components of TLS,  we’ll next look at some of the pieces in action.