A newer version of this documentation is available.

View Latest

Secure administrative access

Encrypted administrative access enables HTTPS access for the Couchbase Web Console and the REST API using SSL/TLS.

Couchbase Server client libraries support client-side encryption using the SSL/TLS protocol by encrypting data in-flight between the client and the server. This encryption establishes a secure channel between the remote machine and the server.

Couchbase Server generates a self-signed certificate for the initial node, which is propagated throughout the server nodes in the cluster. If the self-signed certificate is regenerated or updated, it must be obtained again before secure server communication is re-established. The secure connection is on the cluster level rather than on the bucket level. It is established through the dedicated HTTPS REST port 18091 or the HTTPS CAPI port 18092.

In case you want to force an SSL connection to the Couchbase cluster, you have to lock the non-SSL ports.

Connecting to the Couchbase Web Console

While an administrative console is typically protected via an HTTPS connection, the new administrative access on port 18091 allows connection to the Couchbase Web Console over SSL/TLS, which is enabled by default.

To talk over SSL/TLS to the Couchbase Web Console, connect to the following URL with your web browser: https://couchbase_server:18091

Select Settings  Cluster.

security ssl cert

The Cluster tab shows that a self-signed certificate has been deployed across the cluster. This certificate can be regenerated or replaced.

Configuring a secure administrative access to the web browser

  1. Connect to Couchbase Server through an encrypted port to communicate on a secure channel (18091 for REST HTTP or 18092 for CAPI HTTP).

  2. Log in with the administrator’s name and password.

  3. Once you are logged in, the URL shows a secure connection.

    The following is an example URL of a secure connection using the Safari web browser:

    ui ssl ip
Example 1. SSL certificate
-----BEGIN CERTIFICATE-----
MIIC/jCCAeigAwIBAgIIE3jc9BofgigwCwYJKoZIhvcNAQEFMCQxIjAgBgNVBAMT
GUNvdWNoYmFzZSBTZXJ2ZXIgOTRmYTE3YTUwHhcNMTMwMTAxMDAwMDAwWhcNNDkx
MjMxMjM1OTU5WjAkMSIwIAYDVQQDExlDb3VjaGJhc2UgU2VydmVyIDk0ZmExN2E1
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxaaXsKm06xxzzYqejDAO
3qW1x6vLz9jcLdZkNQgxGk4+/ulrfK4PSLHARf4vml8Ev3bcOzCwfyDCp2/TCSX0
qDTn4iBRp9CJtxVyY/xqWkYkld+GGtj28P0CtZ1UKOHCRB7KInzxesxITg/a0vsL
M8GrcwFpmZEJjeY7HGdUuBRcoMfm2Yn28drmr92SNSsz+npdfEFkQloYStqemOOG
h1Jn7ldU5rBj/B2zcvh6guDXKKz/bMMeCTX84BmkG3rmiKQwxyizuxtYi5u1BthC
X3aO58lC9uRMja1lA5TrJnZOCRT24G6VTh2bYhN98W6YmvF9l4ESDR4I7nE8E6Gt
eQIDAQABozgwNjAOBgNVHQ8BAf8EBAMCAKQwEwYDVR0lBAwwCgYIKwYBBQUHAwEw
DwYDVR0TAQH/BAUwAwEB/zALBgkqhkiG9w0BAQUDggEBAF0Bz2MpQoBEdOdDRix3
j0/XGKjH7kI5zDFiOlUvANMeErVZf9kM8xqS7Yd3bCa2rjT1Y8BM3Sciurtrd/Cy
iTVzpXjQOR/K1AFtiBtuNb2Hx5SXvgeW4p4uNmK74u1UUNmAyb3mwSQ+duuqK/Ef
D4wTolPTZP5gcricyWI3qUCi3pTeCz/2jcAWn3DI4KVtlAsOy9sFFo4RxBDgmOuS
klUAb8eu4e2XxcLJ++geYoum0VIKa3ygjpZ800PupwZZetjD8/6tfbYFuoBTXL+r
27M9ArsOxkVbh3fDQ8b8qnr5sam1P7IfSzqq/Lq4vjh1mvred62zuJlMvY9KmNJU
rqw=
-----END CERTIFICATE-----

Using REST for encrypted access

GET filepath /pools/default/certificate REST API HTTP method and URI retrieves the self-signed certificate from the cluster.

The following shows REST syntax with curl for retrieving the certificate:

curl -X GET  -u adminName:adminPassword
    http://localHost:Port/pools/default/certificate > ./<certificate_name>

The following examples use curl and wget to retrieve the certificate

curl http://10.5.2.54:8091/pools/default/certificate > clusterCertificate
wget http://10.5.2.54:8091/pools/default/certificate -O clusterCertificate

The following examples use curl and wget with the certificate to retrieve cluster information over an encrypted connection. The port used is the encrypted REST port 18091.

curl --cacert clusterCertificate https://10.5.2.54:18091/pools/default
wget --ca-certificate clusterCertificate  https://10.5.2.54:18091/pools/default -O output