Brocade Virtual ADX Security Guide (Supporting ADX v03.1.00) - Manual (Page 112)

100 Brocade Virtual ADX Security Guide
53-1003250-01
SSL on the Brocade Virtual ADX
6
Brocade Virtual ADX SSL
This section describes the SSL features used in configuration of a Brocade Virtual ADX for SSL.
Brocade Virtual ADX keypair file
The keypair file specifies the location for retrieving the SSL asymmetric key pair, during an SSL
handshake. You can create a keypair file by generating a key pair locally on the Brocade Virtual ADX
or import a pre-existing key pair, using secure copy (SCP).The key pair is stored in the host
secondary memory and is not deleted during a power cycle. The Brocade Virtual ADX supports keys
in PEM (Privacy Enhanced Mail) or PKCS12 (Public Key Cryptography Standard 12) formats.
NOTE
Brocade Virtual ADX supports keys in PEM (Privacy Enhanced Mail) or PKCS12 (Public Key
Cryptography Standard 12) formats.
Digital certificate
A digital (electronic) signature authenticates the identity of the sender, ensures that the original
content of the message is unchanged, is easily transportable, cannot be easily repudiated, cannot
be imitated, and can be automatically time stamped. The certificate contains the public part of the
RSA key, which must be the same as the key in the keypair file. The public key used in the
certificate file must match the key pair that is associated with the profile.
If the public key of the certificate does not match the key pair defined under the profile, the
Brocade Virtual ADX does not accept the connection.
If the public key in the certificate file does not match the key in the keypair file, a Brocade Virtual
ADX does not accept the command and displays the following error message:
"Error key and certificate mismatch
Please delete the key and re-add the right key and certificate"
The certificate file specifies the location for retrieving the digital certificate the Brocade Virtual ADX
presents to the client for every new SSL handshake request. The certificate is stored in the
secondary memory, and is not deleted upon a power cycle.
You can create a certificate file locally or you can import it. You can also generate a certificate
signing request (CSR) and have it signed by a known CA to create a certificate and then import it.
See the section “certificate management” for an overview of each process.
Chained certificates
In an ideal world, a certificate authority signs and issues a certificate directly to a server. The server
loads this certificate and whenever a client makes a connection to it, this certificate is presented.
The client already has a copy of the CA's public certificate and verifies the server certificate against
it.
For manageability and security reasons, CAs may not sign server certificates directly. Many times,
the root CA signs an intermediate CA that in turn signs the server certificates. When this happens,
a certificate chain is created. There can be multiple levels of intermediate CA certificates.
Three level chain
CA ----> 1st level Intermediate CA ----> server certificate