Print this pagePrint this page

Email this topicEmail this topic

View PDFView PDF

Download EPUBDownload EPUB

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 22.7 Command Reference Guide):
  • 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} cert_file 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

    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} cert_file 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} cert_file with the ssl-cert option, and download ssl ipaddress privkey key_file .
Published March 2020prev | next

Email this topicEmail this topic

Print this pagePrint this page