Administrator Guide

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)
Use the Online Certicate Status Protocol (OSCP) to obtain the revocation status of a X.509v3 certicate.
A device or a Certicate Authority (CAs) 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 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 takes 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
installs 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 OCSP responders are unreachable, the switch accepts the certicate. This action is the default behavior. You can
also congure an alternate system behavior when all OCSP responders are unreachable. However, the switch 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—for example, cannot verify the signed response with an installed CA certicate.
• Rejection of a certicate due to OCSP
Conguring OCSP setting on CA
You can congure the CA to contact multiple OCSP servers.
To congure OCSP server for a CA, perform the following step:
In the certicate mode, enter the following command:
ocsp-server URL [nonce] [sign-requests]
1030
X.509v3