Certificate architecture

The Conjur Leader, Standbys, and Followers use TLS certificates to secure communication as follows:

Certificate used by

Needed for
Users or applications Requests to Conjur HTTPS REST APIs
Standbys and Followers Replicating data from the Leader
Leader and Standbys Coordinating auto-failover
Followers Forwarding audit records to the Leader

The TLS certificates are critical to the secure operation of Conjur. The overhead of managing these certificates can be reduced by carefully configuring the certificate architecture and individual certificate properties to support strong identities, seamless failover, and regular certificate rotation.

SNI (Server Name Indication) is an extension to the TLS protocol, where the client indicates the hostname it is trying to connect to at the start of the SSL handshake process. This allows a server to present multiple possible certificates on the same IP address and TCP port.

  • SNI should be used with TLS version 1.2 or later. E-SNI is currently not supported.

  • For simplicity, we recommend generating certificates from a trusted CA.

Common Certificate Authority (CA)

The typical certificate architecture for a Conjur Enterprise deployment consists of:

CA certificate

A common shared CA (this may be an intermediate CA) is used to issue and verify all Conjur cluster node certificates. When using third-party certificates, this CA certificate is imported into the Leader using evoke during configuration, and is shared with all Standbys and Followers through their seed files.

Leader and Standby certificates

The Leader and Standbys share a single certificate representing the whole Conjur cluster.

When a single certificate and private key are shared across all Leader and Standby nodes, this certificate must use the Leader load balancer DNS name as the certificate Common Name (CN), and include each individual node's DNS name in the Subject Alternative Names (SAN).

This simplifies the deployment of the Conjur cluster.

Follower certificates

Similar to Standbys, Followers use shared certificates to represent Follower clusters behind a load balancer.

The certificates for Followers should include only the name of the Follower load balancer in the Common Name (CN).

If a load balancer is not being used, the certificate should use the Follower's own DNS name for the Common Name (CN).

Certificate use in Conjur

This section describes how certificates are used by Conjur in a typical deployment.

Certificate usage by node

Node

Certificate usage

Leader

  • The HTTPS server certificate for the Conjur API.

  • The HTTPS server certificate for the Conjur UI (this is the same certificate as the Conjur API certificate).

  • The server certificate for Postgres (mTLS).

  • The server certificate for syslog-ng audit collection (mTLS).

  • The server and client certificate for etcd (mTLS through nginx proxy).

Standby

  • The client certificate for Postgres data replication (mTLS).

  • The server and client certificate for etcd (mTLS through nginx proxy).
Follower

  • The HTTPS server certificate for the Conjur API.

  • The client certificate for Postgres data replication (mTLS).

  • The client certificate for syslog-ng audit forwarding (mTLS).
Postgres database

The server certificate for TLS transport, for example, conjur.pem.
Syslog

The server certificate for syslog communication, for example, conjur.pem.
Kubernetes Authenticator

The certificate and key are in the Kubernetes Authenticator policy. With this pair, Conjur creates the client certificate and injects it back to the Kubernetes container. The client used to communicate with the K8s API server uses the hostname specified under the KUBERNETES_SERVICE_HOST environment variable. 

$ export KUBERNETES_SERVICE_HOST='api.test.com'

The Kubernetes service port is 443.

export KUBERNETES_SERVICE_PORT=443