ON THIS PAGE
 

Understanding TACACS+ over TLS

Understand how TACACS+ over TLS secures AAA exchanges for administrative access, using TLS sessions with X.509 certificate validation against a trusted CA group, and optional mutual TLS for client authentication.

Understand how TACACS+ over TLS secures AAA exchanges for administrative access, using TLS sessions with X.509 certificate validation against a trusted CA group, and optional mutual TLS for client authentication.

TACACS+ over TLS secures authentication, authorization, and accounting (AAA) exchanges for administrative access. The device establishes a Transport Layer Security (TLS) session to each configured TACACS+ authentication server and TACACS+ accounting destination before it sends TACACS+ protocol data. TLS provides confidentiality and integrity for the exchange and uses X.509 certificates to authenticate peers. The device validates the server certificate against a trusted certificate authority (CA) group. If required by policy, you can enable mutual TLS so the device also presents a client certificate identity.

You can configure a mix of TLS and non-TLS TACACS+ servers in the same server list. The device continues to use the configured server iteration and fallback behavior, including interactions with RADIUS and local authentication. TACACS+ over TLS supports IPv4 and IPv6 and can operate in the default or a non-default routing instance, which lets you send AAA traffic over management or WAN paths while keeping consistent operational behavior.

Benefits of TACACS+ over TLS for AAA

  • Protects TACACS+ credentials and AAA exchanges in transit by using TLS confidentiality and integrity instead of TACACS+ MD5-based obfuscation.

  • Validates the identity of TACACS+ servers through certificate validation, reducing the risk of sending administrator credentials to an untrusted or impersonated server.

  • Supports mutual TLS when required, allowing the device and the server to authenticate each other with certificates.

  • Preserves configured AAA server iteration and fallback behavior during outages, including lists that mix TLS and non-TLS servers and fallback interactions with RADIUS and local authentication.

  • Supports IPv4 or IPv6 and use of the default or a non-default routing instance to align administrative authentication paths with segmentation and routing design.

Overview

When you enable TACACS+ over TLS, the device negotiates a TLS session to each configured TACACS+ authentication server and each TACACS+ accounting destination before it sends TACACS+ protocol data. This sequencing ensures that the TLS handshake establishes the cryptographic context first. All subsequent TACACS+ messages then use TLS confidentiality and integrity while TACACS+ request and response behavior at the AAA layer remains unchanged.

You configure TLS on a per-server basis under the TACACS+ and accounting configuration. This approach lets you mix TACACS+ over TLS and TACACS+ over TCP in the same server list. To enable TLS and configure trust for a TACACS+ server, specify a trusted CA group so the device validates the server X.509 certificate during the handshake, for example:

  • set system tacplus-server server-ip tls trusted-ca-group trusted-ca-group

If policy requires mutual TLS, configure a client identity so the device presents a certificate to the server:

  • set system tacplus-server server-ip tls mutual-authentication certificate-id certificate-id

Configure TLS for TACACS+ accounting destinations under system accounting by using the same pattern:

  • set system accounting destination tacplus server server-ip tls trusted-ca-group trusted-ca-group

  • set system accounting destination tacplus server server-ip tls mutual-authentication certificate-id certificate-id

TACACS+ over TLS uses a configurable destination port. Configure the port explicitly (when supported) instead of assuming a default.

After you deploy TACACS+ over TLS, the device uses the same AAA decision flow and failure handling across TLS and non-TLS servers. If a server is unreachable or an exchange fails, the device tries the next configured TACACS+ server even if the next entry uses a different transport. If you configure authentication-order with multiple methods, the device proceeds through the configured order (for example, TACACS+ then RADIUS then local password). Authorization behavior remains consistent with the configured authorization rules.

Certificate and TLS validation prerequisites

For TACACS+ over TLS to work reliably, ensure that certificate material matches the TLS validation performed during the handshake. When you configure tls trusted-ca-group, the device validates the server certificate chain against the configured trust anchors. If the chain is incomplete, the certificate is expired or not yet valid, or the presented identity does not match what the device expects, the TLS handshake fails and the device tries the next configured server.

When you enable mutual-authentication certificate-id, the device presents the referenced client certificate and key so the server can authenticate the device. If the server requires client authentication and you do not configure a valid certificate-id, the handshake fails and TACACS+ is not started. To confirm operation or isolate failures, review AAA- and TLS-related syslog messages and verify reachability to the configured server and port before troubleshooting certificate trust and identity mismatches.