{"id":9325,"date":"2020-09-10T08:38:59","date_gmt":"2020-09-10T15:38:59","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=9325"},"modified":"2021-01-31T13:04:38","modified_gmt":"2021-01-31T21:04:38","slug":"authentication-using-server-side-x-509-certificates-with-n1ql","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/authentication-using-server-side-x-509-certificates-with-n1ql\/","title":{"rendered":"Authentication Using Server-Side X.509 Certificates And N1QL"},"content":{"rendered":"

Authentication and authorization to the N1QL query service in Couchbase works in multiple ways –\u00a0<\/span><\/p>\n

    \n
  1. Passing credentials through a rest request – curl https:\/\/localhost:8093\/query\/service?pretty=true -d “statement=select * from system:keyspaces” -u Admin:pwd<\/span><\/li>\n
  2. Passing credentials using the creds named parameter and\/or query parameter –\u00a0<\/span>curl https:\/\/localhost:8093\/query\/service?pretty=true -d “statement=select * from system:keyspaces&creds=[{user:\u201cAdministrator\u201d,\u201dpassword\u201d:\u201dpass\u201d}]”<\/li>\n
  3. Using basic auth in the request\u00a0<\/span><\/li>\n
  4. Request from cbq (similar to 1,2) using the -u -p -creds options and \\SET command.\u00a0<\/span><\/li>\n
  5. X.509 Certificates for TLS<\/span><\/li>\n
  6. Node to Node encryption<\/li>\n<\/ol>\n

    With the addition of RBAC, the creds query parameter was made redundant but is still supported for backward compatibility.<\/p>\n

    The goal of adding X509 certificates support is to enhance client-server encryption using a certificate that is trusted by the certificate authority.<\/p>\n

    X.509 certificates enable server authentication and encryption for client-server communications. Couchbase supports both server and client authentication using X509 certificates and you have to be a full Admin or Security Admin to manage certificates. This article talks about server-side X.509 certificate support for authorization in Couchbase. Clients can also verify the identity of Couchbase Server but that will be discussed in another article.\u00a0<\/span><\/p>\n

    The most common scenarios for which X509 certificates are used are when clients have to go through the internet, <\/span>when transferring sensitive data on the wire between application and Couchbase Server, or between data centers (XDCR) or when mandated by compliance regulations.\u00a0<\/span><\/p>\n

    What is an X.509 Certificate ? <\/span><\/h2>\n

    It is a public key certificate that is used to distribute a public key, signed by a trusted certificate authority verifying the identity of the server. Using it a client is assured that the request is not being sent to an unknown server. These certificates are signed by a third party also known as a Certificate authority. <\/span>CAs are entities that issue digital certificates. A CA is actually made up of a series of CAs called a CA hierarchy. This CA hierarchy constructs a chain of trust that all node or end entity certificates rely on. The chain does not contain the root CA public key.\u00a0<\/span><\/p>\n

    In a hierarchical public key infrastructure (PKI) there are typically 3 kinds of hierarchy. One-tier, Two-tier and N-tier. The CA at the top of this hierarchy is known as the Root-CA. All subsequent CA\u2019s are the Intermediate CA, and the nth (last) CA is known as the Node CA.\u00a0<\/span><\/p>\n

    An important point to note is <\/span>that to trust a certificate used to establish a secure connection it must have been issued by a CA that is included in the trusted store of the device that is connecting.<\/span><\/p>\n

    One-tier \/ Single-tier CA authority <\/b><\/h3>\n

    This consists of a single CA is the simplest form of CA hierarchy but is not usually used in production as a<\/span> compromise of this root CA results in a compromise of the entire PKI. <\/span>Here the root CA is the issuing CA as well and <\/span>all certificates immediately below the root certificate inherit its trustworthiness.<\/span><\/p>\n

    \"\"<\/p>\n

    Two-tier CA authority<\/b>\u00a0<\/span><\/h3>\n

    This consists of a Root CA that has issued a certificate for one subordinate known as the Intermediate CA. The difference here is that the issued certificates are trusted as they come from a trusted authority via the intermediate CA.\u00a0<\/span><\/p>\n

    \"\"<\/p>\n

    Root CA signs-><\/span> Intermediate CA signs<\/span> -> Issuing CA \/ Cluster CA<\/span><\/p>\n

    N-Tier CA authority <\/b><\/h3>\n

    \u00a0In most production deployments, a hierarchy has multiple CAs.<\/span> The root CA issues certificates to the intermediate CAs, which in turn generate <\/span>intermediate certificates<\/span><\/i>: these are used to sign client certificates, such as a cluster certificate:<\/span><\/p>\n