Brocade Communications Systems 12.4.00a Manual De Usuario

Descargar
Página de 226
ServerIron ADX Security Guide
139
53-1002440-03
SSL acceleration on the ServerIron ADX
6
ServerIron 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 ServerIron ADX or 
import a pre-existing key pair, using secure copy (SCP).The key pair is stored in the flash memory 
and is not deleted during a power cycle. The ServerIron ADX supports keys in PEM (Privacy 
Enhanced Mail) or PKCS12 (Public Key Cryptography Standard 12) formats.
NOTE
ServerIronADX 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 
ServerIron ADX does not accept the connection.
If the public key in the certificate file does not match the key in the keypair file, a ServerIron ADX 
does not accept the command and displays the following error message: 
"Error reading certificate from file <certfile-name>"
The certificate file specifies the location for retrieving the digital certificate the ServerIron ADX 
presents to the client for every new SSL handshake request. The certificate is stored in the flash 
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
Four level chain
CA ---> 1st level Intermediate CA ---> 2nd level Intermediate CA ---> server certificate   
The end clients, including Mozilla, Firefox and Internet Explorer, always have a copy of the 
well-known parent CA's certificate. They, however, may not have the intermediate CA's certificates.