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 Switch Engine 32.2 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 in the following scenarios:
- 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:-----BEGIN CERTIFICATE----- MIICgTCCAeqgAwIBAgIJAMng4JQ0MOeIMA0GCSqGSIb3DQEBBQUAMGAxCzAJBgNV BAYTAlVTMRIwEAYDVQQKEwlFbnRlcmFzeXMxDDAKBgNVBAsTA0RvRDEMMAoGA1UE CxMDUEtJMSEwHwYDVQQDExhFc3lzIEpJVEMgT0NTUCBSZXNwb25kZXIwHhcNMTIw MjE3MTg0MzEwWhcNMjIwMjE0MTg0MzEwWjBgMQswCQYDVQQGEwJVUzESMBAGA1UE ChMJRW50ZXJhc3lzMQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEhMB8GA1UE AxMYRXN5cyBKSVRDIE9DU1AgUmVzcG9uZGVyMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCuyC9QHBpP/n6aOS+Cx0mbgsQTS1LAUUCwxjvJdILGVfdjFB8PKG+o W4jm7FKuRHR7uzBvAFzD9DbVkziHl2yIsy4SeiSBTQpNvHPjvUcec3rTlw7saiTw B+CTqEm1pxcEdRKTvawK2k1ujHML1MABP2CA3SEptO+Ude4UkXMBywIDAQABo0Mw QTAdBgNVHQ4EFgQUYFhsLiklZh0riJ1Hg7d4HPcLlBUwCwYDVR0PBAQDAgGGMBMG A1UdJQQMMAoGCCsGAQUFBwMJMA0GCSqGSIb3DQEBBQUAA4GBADU4aQ6f8pHWLd7z vZ8pJ8e8UCvKok1LmdXbax5TBonyyLmb7AjLrOWjZ7LKSufJL1KOBsetd5Q49LFK h70V2fRWpGNQszpAV60WfidkNvQ0koZczEjYRQOCtMDUqxMHxsMv2MLEVE9QuGLt +NWjeeF03E1DT3C4mnbVsTyWPZij -----END CERTIFICATE----- -----BEGIN TRUSTED CERTIFICATE----- MIICgTCCAeqgAwIBAgIJAMng4JQ0MOeIMA0GCSqGSIb3DQEBBQUAMGAxCzAJBgNV BAYTAlVTMRIwEAYDVQQKEwlFbnRlcmFzeXMxDDAKBgNVBAsTA0RvRDEMMAoGA1UE CxMDUEtJMSEwHwYDVQQDExhFc3lzIEpJVEMgT0NTUCBSZXNwb25kZXIwHhcNMTIw MjE3MTg0MzEwWhcNMjIwMjE0MTg0MzEwWjBgMQswCQYDVQQGEwJVUzESMBAGA1UE ChMJRW50ZXJhc3lzMQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEhMB8GA1UE AxMYRXN5cyBKSVRDIE9DU1AgUmVzcG9uZGVyMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCuyC9QHBpP/n6aOS+Cx0mbgsQTS1LAUUCwxjvJdILGVfdjFB8PKG+o W4jm7FKuRHR7uzBvAFzD9DbVkziHl2yIsy4SeiSBTQpNvHPjvUcec3rTlw7saiTw B+CTqEm1pxcEdRKTvawK2k1ujHML1MABP2CA3SEptO+Ude4UkXMBywIDAQABo0Mw QTAdBgNVHQ4EFgQUYFhsLiklZh0riJ1Hg7d4HPcLlBUwCwYDVR0PBAQDAgGGMBMG A1UdJQQMMAoGCCsGAQUFBwMJMA0GCSqGSIb3DQEBBQUAA4GBADU4aQ6f8pHWLd7z vZ8pJ8e8UCvKok1LmdXbax5TBonyyLmb7AjLrOWjZ7LKSufJL1KOBsetd5Q49LFK h70V2fRWpGNQszpAV60WfidkNvQ0koZczEjYRQOCtMDUqxMHxsMv2MLEVE9QuGLt +NWjeeF03E1DT3C4mnbVsTyWPZijMAwwCgYIKwYBBQUHAwk= -----END 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 .
- Beginning with software release
32.2, you can configure SSH x509v3 OCSP attributes (enable/disable, nonce, override, and
ocsp-nocheck, respectively) using the following commands:
- configure ssh2 x509v3 ocsp [on | off]
- configure ssh2 x509v3