{"id":14907,"date":"2023-09-25T12:49:01","date_gmt":"2023-09-25T19:49:01","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=14907"},"modified":"2023-10-18T03:04:29","modified_gmt":"2023-10-18T10:04:29","slug":"securing-couchbase-with-tls-certificates-part-2","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/securing-couchbase-with-tls-certificates-part-2\/","title":{"rendered":"Securing Communication with TLS Certificates: A Definitive Guide for Couchbase Server (Part 2 of 3)"},"content":{"rendered":"

In part 1 of this 3 part series we learned about the components of TLS<\/a>, in part 2 we will see how the TLS components interact with each other.\u00a0 In Part 3<\/a> of this guide, we’ll see how the components are used in Couchbase Server.<\/span><\/p>\n

Certificate Signing Process<\/h2>\n

Whether you are managing your own in-house Certificate Authority, or using an established commercial vendor such as DigiCert, GlobalSign or GoDaddy the first stage is to generate a Certificate Signing Request. Any time a new certificate or a replacement certificate needs to be issued, the entity requesting the certificate generates a key pair consisting of a private key and a public key themselves, typically using the OpenSSL package. In a Couchbase Server Cluster the entity would be an individual Couchbase Server Node. The private key is kept securely by the entity, while the public key is included in a certificate signing request (CSR) which is sent to the CA. Typically this is performed with an intermediate CA not a root CA.\u00a0<\/span><\/p>\n

\"\"<\/p>\n

Upon receiving the CSR, the CA verifies the identity of the entity by employing various validation methods, such as domain validation or organization validation. Once the identity is confirmed, the CA generates a digital signature using its private key, which binds the entity’s public key with its identity information. This signed certificate is then returned to the entity.<\/span><\/p>\n

Certificate Validation<\/span><\/h2>\n

To validate a certificate, the relying party (e.g., a web browser) needs to ensure that the certificate is genuine and issued by a trusted CA. This process involves a series of steps, including the following four stages.<\/span><\/p>\n

Trust Anchor<\/span><\/h3>\n

\"\"<\/h3>\n

The relying party, for example a web browser, possesses a pre-installed set of trusted root certificates, also known as trust anchors. These certificates belong to well-known CAs and contain their public keys, this serves as the foundation of trust.<\/span><\/p>\n

When a client or server receives a certificate during the SSL\/TLS handshake, it checks if the certificate’s digital signature can be validated by any of the trust anchors installed in the system. If the certificate chain can be traced back to a trust anchor, the certificate is deemed genuine, and the TLS connection proceeds with confidence.\u00a0<\/span><\/p>\n

Certification Path<\/span><\/h3>\n

\"\"<\/p>\n

When establishing a TLS encrypted connection the relying party (web browser) examines the certificate’s certification path, which includes a chain of certificates starting from the issued certificate and leading up to a trust anchor. Each certificate in the chain is signed by the subsequent certificate, ultimately reaching a trust anchor.<\/span><\/p>\n

Signature Verification<\/span><\/h3>\n

The relying party (Web Browser) uses the public key of each certificate in the certification path to verify the digital signature of the next certificate. This process continues until the trust anchor is reached.<\/span><\/p>\n

The digital signature is a cryptographic value created by the CA using its private key, binding the certificate’s content to the CA’s identity. The client uses the CA’s public key to decrypt the digital signature, and if the decryption matches the certificate’s content, the signature is considered valid. This validation confirms that the certificate has not been tampered with and was indeed issued by the trusted CA.\u00a0<\/span><\/p>\n

Trust and Expiry Checks<\/span><\/h3>\n

The relying party checks if the trust anchor is included in its pre-installed trusted root certificates. It also verifies the expiration date of each certificate to ensure it is still valid.<\/span><\/p>\n

\"\"<\/p>\n


\n<\/span>If the entire certification path is successfully validated, and the trust anchor is trusted, the relying party considers the certificate genuine and proceeds with the secure connection. With Couchbase Server 7.2.x this chain can be 10 certificates deep.<\/span><\/p>\n

In this example, the built-in trusted root certificate authorities in the web browser are just made up names, but you can look at an actual list. Firefox pre-authorized trusted CAs are linked to from their wiki<\/a><\/span>. If your certificate is generated by a CA that isn\u2019t issued from one of the built-in trusted CAs, you will first need to add the CA\u2019s public certificate as a trusted entity to your Operating System and Browser before you will be able to use certificates issued by that CA.<\/span><\/p>\n

Now we\u2019ve seen the components involved in TLS and how they work, in part 3 we’ll look at how TLS works in Couchbase Server<\/a>.<\/span><\/p>\n