What communication does TLS protect in NCache?

TLS protects client-to-server, server-to-server, and Bridge communication in NCache.

What certificate options does NCache support for TLS?

NCache supports NCache-provided certificates and custom certificates issued by an organization's own Certificate Authority.

How are NCache-provided server certificates issued?

Each server node generates its own key pair and CSR locally. The customer-specific Intermediate CA signs the CSR, while the private key remains on the server node.

How does mutual TLS work in NCache?

With mutual TLS, the client also presents a valid certificate to the server. The client must trust the server certificate's issuing Root CA, and the server must trust the client certificate's issuing Root CA.

How are NCache-provided TLS certificates renewed?

NCache-provided server certificates are valid for two years. Each server node checks expiration every 12 hours and starts renewal when 30 days or fewer remain. Failed attempts are logged and retried, and renewed certificates are loaded without restarting the server.

TLS Encryption

NCache supports Transport Layer Security (TLS) to encrypt data transmitted between clients, cache servers, cluster nodes, Bridges, and other NCache components. Unlike Data Encryption, which protects cached data, TLS secures communication while data travels over the network. NCache provides a unified TLS configuration for Windows and Linux using PEM-formatted certificates.

NCache supports two server certificate options:

NCache-provided certificates: NCache automatically generates, signs, stores, and renews server certificates. Each server node receives its own certificate without requiring manual certificate provisioning or distribution between nodes.
Custom certificates: Your organization supplies PEM-formatted certificates issued by its Certificate Authority (CA) and manages their provisioning, trust, private-key protection, and renewal.

Both options can be used with TLS, which encrypts communication and authenticates the server, or Mutual TLS (mTLS), which additionally requires connecting clients to authenticate using certificates. TLS protects supported communication channels, including client-to-server, server-to-server within a cache cluster, and Bridge communication.

NCache-Provided Certificates

NCache-provided certificates are managed through NCache's certificate-signing service. Each participating server node obtains a unique certificate and retains its private key locally. The public NCache Root CA certificate is included with NCache Server and Client SDK installations, allowing NCache components to validate these certificates without manually distributing the Root CA between nodes.

Certificate Architecture

NCache uses a three-level certificate hierarchy to establish trust between its components:

NCache Root CA → Customer Intermediate CA → Server Leaf Certificate

Root CA: Alachisoft maintains the NCache Root CA, which signs customer Intermediate CA certificates. Its public certificate is included with NCache Server and Client SDK installations.
Intermediate CA: Each customer is assigned a separate Intermediate CA when their NCache license is issued. The same Intermediate CA is reused across that customer's deployments, and its private signing key remains protected within Alachisoft's signing infrastructure.
Leaf certificate: Each NCache server node receives a unique certificate signed by the customer's Intermediate CA. The node generates its private key locally, and that key is not shared with other nodes or sent to Alachisoft.

When TLS communication is established, the server presents its leaf certificate and Intermediate CA certificate. The connecting NCache component validates this chain against the trusted NCache Root CA. This trust arrangement applies to NCache components with the Root CA installed; external clients must independently trust the relevant issuing CA.

Certificate Issuance and Private-Key Protection

When NCache-provided certificates are selected, each server node generates a private key and Certificate Signing Request (CSR). Only the CSR is sent to the NCache certificate-signing service, which returns a leaf certificate signed by the customer's Intermediate CA and the corresponding Intermediate certificate. NCache stores the private key, signed leaf certificate, and Intermediate chain in the local leaf.pem file, in that order.

Server private keys remain on their respective nodes, while Intermediate CA private keys remain within Alachisoft's signing infrastructure. Only public certificates and certificate issuance or renewal metadata are stored centrally. As a result, NCache can issue certificates for multiple nodes without transferring their private keys.

Automatic Certificate Renewal

NCache-provided server leaf certificates are valid for two years. A background renewal process on each node checks its certificate expiration every 12 hours and initiates renewal when 30 days or fewer remain before expiration. During renewal, the node generates a new key pair and CSR, obtains a signed certificate, and loads the renewed certificate without restarting the server.

If renewal fails, NCache logs the failure and retries during the next scheduled check. The existing certificate remains in use while valid, and each node renews independently of other nodes in the cluster.

Custom Certificates

NCache also supports server certificates issued by your organization's CA. This option allows organizations to use their existing certificate-management infrastructure and security policies instead of NCache's certificate-signing service.

A custom certificate must be provided as a PEM file containing the private key, server leaf certificate, and Intermediate certificates, in that order. The file must be accessible at the configured absolute path on each applicable server node. The issuing Root CA must be trusted through the operating-system trust store or by placing its certificate alongside the custom certificate in the configured directory.

Custom PEM files can contain an encrypted private key. When the key is encrypted, configure its password alongside the custom certificate path in the NCache Management Center or with Enable-NCacheTLS -CustomCertificatePassword. Unencrypted private keys do not require a password. NCache validates the supplied password when loading the certificate and does not include it in error messages or log files.

Unlike NCache-provided certificates, custom certificates are not automatically issued or renewed by NCache. Your organization is responsible for provisioning, protecting, distributing, and renewing them. The same PEM-based configuration model applies on Windows and Linux.

TLS Protocol Versions

NCache supports TLS 1.2, TLS 1.3, and Auto protocol selection. Select tls12 to use TLS 1.2 exclusively, tls13 to use TLS 1.3 exclusively, or auto to let the operating system negotiate the highest mutually supported TLS version. These values can be configured through the NCache Management Center, the Enable-NCacheTLS -ProtocolVersion parameter, or the <protocol-version> element in tls.ncconf. For configuration steps, see Configure TLS Encryption in Windows and Linux.

TLS and Mutual TLS

The server certificate source and the TLS authentication mode are separate choices. Either NCache-provided or custom server certificates can be used with TLS or Mutual TLS.

TLS

With TLS, the server presents its certificate chain and the connecting client validates it against a trusted issuing Root CA. Once validation succeeds, communication is encrypted. The client does not need to present its own certificate.

Mutual TLS (mTLS)

With Mutual TLS, both endpoints authenticate using certificates. The client validates the server certificate, and the server also requires and validates a client certificate. NCache supports client certificates generated using the New-NCacheTlsCertificate PowerShell cmdlet or issued by your organization's CA.

For client-to-server mTLS, the client must trust the Root CA that issued the server certificate, and the server must trust the Root CA that issued the client certificate. Each client must have access to its configured certificate and private key. .NET Core and modern .NET clients use PEM certificates; .NET Framework clients can use PFX certificates. Configure tlsCertPath and, for password-protected keys or PFX files, tlsCertPassword in the application's ncache configuration or use ConnectionOptions.TLSCertPath and TLSCertPassword in code. Install the issuing Root CA certificate in the operating-system trust store on the machine running the ASP.NET Core or .NET Framework application. Client certificates issued by New-NCacheTlsCertificate contain unencrypted private keys. For server-to-server communication, NCache nodes present and validate their respective certificate chains without sharing private keys.

Certificate Trust and Validation

Certificate trust depends on which certificate is presented during the TLS handshake:

NCache-provided server certificates: NCache components validate the server certificate chain using the NCache Root CA public certificate included with NCache Server and Client SDK installations. Install the issuing Root CA certificate in the operating-system trust store on machines running ASP.NET Core or .NET Framework applications.
Custom server certificates: Connecting components must trust the organization's issuing Root CA through the applicable trust store or configured certificate location.
Mutual TLS client certificates: The NCache server must also trust the CA that issued the connecting client's certificate, regardless of which server certificate source is selected.

For configuration steps, certificate paths, protocol settings, and verification procedures, see Configure TLS Encryption in Windows and Linux.