Administrator Guide

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)
Use the Online Certificate Status Protocol (OSCP) to obtain the revocation status of a X.509v3 certificate.
A device or a Certificate Authority (CAs) 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 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 takes 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 installs 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 OCSP responders are unreachable, the switch accepts the certificate. This action is the default behavior. You can
also configure an alternate system behavior when all OCSP responders are unreachable. However, the switch may become vulnerable to
denial-of-service attack if you configure the system to deny the certificate when OCSP responders are not reachable. For more
information, see Configuring Revocation Behavior.
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 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]
NOTE:
If you have an IPv6 address in the URL, then enclose this address in square brackets. For example, http://
[1100::203]:6514.
Configuring OCSP behavior
You can configure how the OCSP requests and responses are signed when the CA or the device contacts the OCSP responders.
To configure this behavior, follow this step:
In CONFIGURATION mode, enter the following command:
crypto x509 ocsp {[nonce] [sign-request]}
Both the none and sign-request parameters are optional. The default behavior is to not use these two options. If your OCSP
responder uses pre-computed responses, you cannot use the none feature in the switch's communcations with the responder. If your
OCSP responder requires signed requests, you can use the sign-requests option.
X.509v3
985