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 trac overhead due to public
key cryptographic operations and handshake trac. However, the maximum time allowed for a TLS session to resume without repeating
the TLS authentication or handshake process is congurable with a default of 1 hour. You can also disable session resumption.
Syslog over TLS
Syslog over TLS mandates that a client certicate must be presented, to ensure that all Syslog entries written to the server are from a
trusted client.
Online certicate status protocol (OSCP)
The Online Certicate Status Protocol (OSCP) is used to obtain the revocation status of a X.509v3 certicate.
A device or a Certicate Authority can check the status of a X.509v3 certicate by sending an OCSP request to an OCSP server or
responder. An OCSP responder, a server typically run by the certicate issuer, returns a signed response signifying that the certicate
specied in the request is 'good', 'revoked', or 'unknown'. The OCSP response indicates whether the presented certicate is valid.
OCSP provides a way for Certicate Authorities (CAs) to revoke signed certicates before the expiration date. In a CA certicate, OCSP
Responder information is specied in the authorityInfoAccess extension.
A CA can verify the revocation status of a certicate with multiple OCSP responders. When multiple OCSP responders exist, you can
congure the order or preference the CA should take while contacting various OCSP responders for verication.
Upon receiving a presented certicate, the system sends an OCSP request to an OCSP responder through HTTP. The system then veries
the OCSP response using either a trusted public key or the OCSP responder’s own self-signed certicate. This self-signed certicate is
installed on the device's trusted location even before an OCSP request is made. The system accepts or rejects the presented certicate
based on the OCSP response.
In a scenario where all the OCSP responders are unreachable, the system accepts the certicate. This behavior is the default behavior. You
can also congure an alternate system behavior when all OCSP responders are unreachable. However, the system may become vulnerable
to denial-of-service attack if you congure the system to deny the certicate 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 certicate.
• Rejection of a certicate due to OCSP
X.509v3
1125