TLS client mode: Authenticating server certificate

TLS server certificate validation occurs during the TLS handshake according to the following rules:

Certificate validation and the certificate path validation support a minimum path length of three certificates.
The certificate path must terminate with a trusted CA certificate.
The certificate path should be validated by verifying the presence of the basicConstraints extension and that the CA flag is set to TRUE for all CA certificates.
The revocation status of the certificate should be validated using the Online Certificate Status Protocol (OCSP).
The extendedKeyUsage field should be validated according to the following rules:
- Certificates used for trusted updates and executable code integrity verification should have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field.
- Server certificates presented for TLS should have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
- Client certificates presented for TLS should have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
- OCSP certificates presented for OCSP responses should have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.
A certificate should only be treated as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE.

Users will be notified using Raslog/Auditlog with the reason for the TLS server certificate validation failure during TLS handshake, if applicable.

TLS cipher suites for client and server applications

The TLS cipher suites used by the client and server applications by the TOE are preset and cannot be changed through CLI commands. These supported cipher suites are as follows:

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS_DHE_RSA_WITH_AES_128_CBC_SHA

TLS_DHE_RSA_WITH_AES_256_CBC_SHA

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

Verify the revocation status of certificate using OCSP

The switch will always perform OCSP revocation-check on the certificate when the authorityInfoAccess extension is present and indicates that the accessMethod to use OCSP (1.3.6.1.5.5.7.48.1) specifying the accessLocation, which is the URI of the OCSP responder. Only when the revocation staus is 'good' will the certificate be accepted.

When the switch cannot establish a connection to determine the validity of a certificate, then it will not accept the certificate. If the digital certificate does not have authorityInfoAccess extension with an OCSP URI, then no revocation check is performed on that certificate.