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.