Administrator Guide

TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
When not operating in FIPS mode, the system may support TLS 1.0 up to 1.2, and older ciphers and hashes:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA
TLS compression is disabled by default. TLS session resumption is also supported to reduce processor and traffic overhead due
to public key cryptographic operations and handshake traffic. However, the maximum time allowed for a TLS session to resume
without repeating the TLS authentication or handshake process is configurable with a default of 1 hour. You can also disable
session resumption.
Syslog over TLS
Syslog over TLS mandates that a client certificate must be presented, to ensure that all Syslog entries written to the server are
from a trusted client.
Online certificate status protocol (OSCP)
The Online Certificate Status Protocol (OSCP) is used to obtain the revocation status of a X.509v3 certificate.
A device or a Certificate Authority can check the status of a X.509v3 certificate by sending an OCSP request to an OCSP
server or responder. An OCSP responder, a server typically run by the certificate issuer, returns a signed response signifying
that the certificate specified in the request is 'good', 'revoked', or 'unknown'. The OCSP response indicates whether the
presented certificate is valid.
OCSP provides a way for Certificate Authorities (CAs) to revoke signed certificates before the expiration date. In a CA
certificate, OCSP Responder information is specified in the authorityInfoAccess extension.
A CA can verify the revocation status of a certificate with multiple OCSP responders. When multiple OCSP responders exist,
you can configure the order or preference the CA should take while contacting various OCSP responders for verification.
Upon receiving a presented certificate, the system sends an OCSP request to an OCSP responder through HTTP. The system
then verifies the OCSP response using either a trusted public key or the OCSP responder’s own self-signed certificate. This
self-signed certificate is installed on the device's trusted location even before an OCSP request is made. The system accepts or
rejects the presented certificate based on the OCSP response.
In a scenario where all the OCSP responders are unreachable, the system accepts the certificate. This behavior is the default
behavior. You can also configure an alternate system behavior when all OCSP responders are unreachable. However, the system
may become vulnerable to denial-of-service attack if you configure the system to deny the certificate when OCSP responders
are not reachable.
The system creates logs for the following events:
● Failures to reach OCSP responders
● Invalid OCSP responses—e.g. cannot verify the signed response with an installed CA certificate.
● Rejection of a certificate due to OCSP
Configuring OCSP setting on CA
You can configure the CA to contact multiple OCSP servers.
To configure OCSP server for a CA, perform the following step:
In the certificate mode, enter the following command:
ocsp-server URL [nonce] [sign-requests]
X.509v3
1101