Using Public-Key Infrastructure (PKI) in Your Network

The ExtremeXOS implementation of public-key infrastructure (PKI) supports the secure authentication of Syslog server and SSH client to an Extreme Networks XOS device using an X.509 certificate. Below are primary aspects of a PKI configuration (for more information about each command listed in this topic, see ExtremeXOS 31.4 Command Reference Guide ):

Note

All the certificates mentioned below should be in PEM format.

Trusted CA—The X509v3 certificates of Certificate Authority (CA) should be downloaded using the CLI: download ssl ipaddress certificate {ssl-cert | trusted-ca | ocsp-signature-ca | {csr-cert {ocsp [on | off]}} file_name using the trusted-ca option. The CA certificate must satisfy the following criteria to successfully download:
- Basic constraints: CA = true
- Key usage must contain: KeyCertSign
Peer Certificate—X509v3 certificate of the peer, signed by one of the above trusted CAs. The following criteria must be met for successful authentication:
- Syslog server certificate: Extended key usage must contain ‘Server Authentication‘
- SSH Client certificate:
  - Common name (CN) of the certificate subject must be same as the username with which SSH session is tried out.
  - Extended key usage must contain ‘Client Authentication.‘
OCSP—Online Certificate Status Protocol used to find the revocation status of the peer certificate on the following scenario:
- Syslog server certificate‘s OCSP status is identified when a TLS session is to be established with the Syslog server. Only if the OCSP status is GOOD is the session established.
- SSH Client certificate‘s OCSP status is identified as part of authentication. Only if the OCSP status is GOOD is the session established.
Note
OCSP processes intermediate CA certificates iteratively, one by one.

The OCSP Server‘s address must be configured in the Authority Information Access (AIA) of the peer certificate. Otherwise, the PKI authentication fails. The supported OCSP responder models are: common issuer model, delegated trusted responder model, trusted responder model.

OCSP Signature CA—The certificates of OCSP responders must be configured as OCSP signature CA and trusted CA. To support Trusted Responder Model (TRM) of OCSP, the X509v3 certificate of the OCSP responder should be downloaded using the CLI: download ssl ipaddress certificate {ssl-cert | trusted-ca | ocsp-signature-ca | {csr-cert {ocsp [on | off]}} file_name using the ocsp-signature-ca and trusted-ca options. For example:

download ssl 10.120.89.79 certificate trusted-ca cacert.pem

The OCSP signature CA is only required for TRM; it is not used for DTM and common issuer. This certificate must contain a trusted use extension that permits OCSP signing. A “trusted use extension” can be appended to a certificate using OpenSSL.

The following example appends a trusted use extension specifying an original file and the trusted file: ocsp-sig-ca.pem is the original certificate file and the output file trusted-ocsp-sig-ca.pem is the trusted file: % openssl x509 -in ocsp-sig-ca.pem -addtrust OCSPSigning -out trusted-ocspsig- ca.pem

The following is an example of an original certificate followed by the OpenSSL command output trusted certificate:

ExtremeXOS X509v3 certificate—The certificate of the ExtremeXOS device. This is shared to the Syslog server to perform authentication there. Use the commands: download ssl ipaddress certificate {ssl-cert | trusted-ca | ocsp-signature-ca | {csr-cert {ocsp [on | off]}} file_name with the ssl-cert option, and download ssl ipaddress privkey key_file .