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