Users Guide

Security profile settings used by X.509v3 authentication
When you log in with an X.509v3 certificate, OS10 validates the certificate before granting access. The options to control the
applied validation are determined by the specific security profile that you configured for X.509v3 SSH authentication.
The following table describes each of the available security profile options, and how they are applied to X.509v3 SSH
authentication.
Table 88. Security profile settings used by X.509v3 authentication
Security profile
setting
Description
certificate At initialization of the session, the SSH protocol exchanges host keys between the SSH server and
client. The keys are used both to authenticate the SSH server and client, and to secure the initial session
setup. OS10 supports both traditional SSH host keys and X.509v3 certificate host keys.
In OS10 SSH, authentication works with or without a PKI host certificate that is associated with the
security profile. If you configure a certificate name in the security profile and the certificate is installed,
the SSH daemon exchanges the X.509v3 certificate with the client during the client/server
authentication. This configuration enables the client to authenticate the server using a PKI certificate
authority.
key-usage-check When you configure the key-usage-check setting in the security profile, the OS10 SSH server validates
the key usage and extended key usage fields in the user certificate. The key usage field must contain
the digital signature purpose. If the extended key usage field is present in the user certificate, it must
include the client authentication purpose. key-usage-check is disabled by default in security profiles, but
Dell Technologies recommend using X509v3 SSH authentication.
ocsp-check If you configure the ocsp-check option in the security profile and the user certificate contains an OCSP
responder URL in the Authority Information Access section, the OS10 SSH server verifies the revocation
status of the user certificate with the OCSP responder in the certificate.
If you configure an OCSP responder URL in the security profile when verifying the revocation status, the
OCSP responder URL is used instead of the OCSP URL in the certificate. In this way, you can configure
the OCSP responder URL that is used as a proxy for the OCSP responder associated with a CA.
peer-name-check When you configure the peer-name-check option, the OS10 SSH server verifies if the certificate
presented by the user is associated with the username for the login attempt. The verification matches
either the common name (CN) value from the distinguished name (DN) field or the user principal name
from the subject alternative name (SAN) field of the certificate with the login username. Alternatively,
if there is a configured user certificate in OS10 for this username, it is matched against the appropriate
field in the user certificate.
The configured user certificate validates user certificates that use different names when compared with
the login name. The peer-name-check option is enabled by default and is not displayed in the running-
configuration unless disabled.
revocation-check If you configure the revocation-check option in the security profile, the OS10 SSH server verifies the
revocation status of the user certificate in the installed or dynamically downloaded certificate revocation
list (CRL) associated with the CA that signed the certificate.
Example: Configure RADIUS over TLS with X.509v3 certificates
This example shows how to install a trusted X.509v3 CA and a host certificate-key pair that supports RADIUS over TLS
authentication.
1. Install a trusted CA certificate.
OS10# copy tftp://CAadmin:secret@172.11.222.1/GeoTrust_Universal_CA.crt home://
GeoTrust_Universal_CA.crt
OS10# crypto ca-cert install home://GeoTrust_Universal_CA.crt
Processing certificate ...
Installed Root CA certificate
CommonName = GeoTrust Universal CA
IssuerName = GeoTrust Universal CA
1396
Security