SSL Keys and Certificates

The key store contains keys and certificate-key pairs. The key store can contain a maximum of 1000 key pairs.

A particular key in the key store can be selected only for decryption (inbound deployment) or for re-signing and decryption (outbound deployment).

Starting in software version 5.2, encrypted or password protected PEM is supported for fetching or downloading a private key.

Starting in software version 5.6.00, ECDSA keys are supported for both inbound and outbound deployments.

 

A Key Store certificate can be setup to be auto- enabled, auto-deleted and auto-retained to an inline-SSL profile. The configuration can be done as follows:

1. On the top navigation pane, click Physical.

2. In the Physical Nodes page, select the node for which you want to configure Key Store settings.

3. Go to GigaSMART>Inline SSL >Key Store .

4. Click Settings.Configure from the given Key Store settings which are as follows:

•

Auto Enable New Certificates – Associates new certificates to an inline-SSL profile, if the new certificate shares a common name with an existing certificate(s) of the inline-SSL profile. The setting will be triggered as and when a new certificate is uploaded or pushed by a third-party tool.

•

Auto Delete Expired Certificates – Deletes expired certificates automatically. This setting will be triggered once a day at 12:00:00 UTC. Specify the number of days to retain an expired certificate in the 'Number of days to retain expired certificates' field. The default value would be 30 days.

•

Auto Delete Certificates with same entity – Deletes expired certificates with similar name associated to an inline-SSL profile. Once the setting is updated; the oldest certificate will be deleted as and when the maximum number of allowed certificates are crossed. Specify the maximum number of days to retain an expired certificate with same entity in the 'Max number of Certificates to retain for the same Entity' field.

To generate and add an inline-SSL signing certificate to key store for outbound deployment, perform the following steps:

1.

Create an internal root CA (for example, using Microsoft AD, or OpenSSL, or any other CA implementation).

2.

Push this CA root certificate to all devices.

3.

Issue a sub-CA certificate for Gigamon.

4.

Upload the sub-CA certificate to Gigamon with the private key of only the sub-CA.

The key store certificates added would be displayed in Key Store page. The following table describes the fields :

Component	Description
Key Alias	The alias name of the Key certificate.
Type	Defines whether the Key Store is a Certificate or a Private Key .
Common name	A common name given to group the key based on domain.
Health Status	The health indicator of a certificate used in traffic flow. The three major indicators with their respective color legend are as follows: Green - The key certificate is attached to an inline-SSL profile and the profile is part of the inline-SSL GSOP which is used in a traffic map. This will also indicate a certificate which is being used as a signing CA in outbound deployment . Blue - The key certificate is not actively participating in any traffic flow. Red - The key certificate has been expired .
Organization	Organization name that provided the key .
.Organization Unit	Organization unit name that provided the key.
Expiry Date	Date on which the key certificate would get expired.
Installed On	Date on which the key certificate was installed.

You can control the key store certificates display by utilizing the filters provided such as ; Key Alias, Common Name, Organization, Organization Unit, Health Status, Expiry Date and Installation Date.

The trust store contains a trusted certificate authority (CA) for server validation. A default trust store from Mozilla is included with this GigaVUE-OS software version. The trust store is updated periodically. You can also fetch a trust store file containing certificates in PEM format if you want to replace the default trust store.

Starting in software version 5.2, CA certificates can be appended to the trust store or specific certificates can be deleted from the trust store. Also, the trust store can be queried for a specific certificate by its fingerprint. The query includes the hex representation of the first four octets of the certificate’s SHA1 fingerprint.

Gigamon needs to validate the server certificate so that an incoming untrusted certificate is not made legal by Gigamon re-signing the certificate.

The certificate validation process includes several steps as follows:

•

Certificate expiration date and validity period: The GigaVUE node compares the current date to the validity period listed in the certificate. If the expiration date has not passed and the current date is within the period, the certificate is good.

•

Certificate issued by trusted CA: The GigaVUE node maintains a list of trusted root CAs. This list determines the certificates that the client will accept. The trust store acts as a trust anchor during certificate validation. The GigaVUE node validates that each incoming certificate chain is trusted by one of the certificates in the trust store.

•

Server name: The GigaVUE node validates that the server certificate is valid for the hostname mentioned in the SNI. This validation is not performed if the client does not send SNI.

•

Certificate revocation check: The GigaVUE node validates the server certificate status using OCSP and CRL lists downloaded from the concerned CAs. Internet connectivity is required for this functionality. The certificate revocation check determines the revocation status of the server certificate.

Certificates that pass the validation are accepted. The primary MitM CA signs the forged certificate. Certificates that fail validation can be accepted if security exceptions are configured and the secondary MitM CA signs the corresponding forged certificate. For self-signed certificates, the forged certificate will also be self-signed.

Client applications will typically add the primary MitM CA to their trust store and not to the secondary. This will act as a mechanism to bubble up certificate validation errors on the client applications and provide the end users an opportunity to reject the connection.

If there are certificate validation errors, the SSL connection is dropped unless explicitly permitted by the security exceptions in the policy profile. The certificate validation errors are grouped into the following four categories:

•

Expired: The validity period of the certificate is in the past.

•

Self-signed: The certificate is self-signed, meaning that the subject and the issuer are the same. The validity period is current and the certificate signature is valid.

•

Unknown CA: The CA is not valid. The issuer certificate cannot be obtained from the certificate chain or is not in the trust store.

•

Invalid: The certificate is not valid for the given SNI (for the Client Hello containing the SNI). There might have been a failure to decrypt or decode the certificate signature or the fields, not and before/not, were not read.

For security exceptions for expired, unknown CA, and invalid certificates, the resulting certificate is signed (re-signed) by the secondary MitM CA, so the user can accept or reject the connection.

A server can challenge the client by requesting for a client certificate after the server responds with its Server Hello message. The client then respond with its certificate and the server validates the client certificate.

Gigamon does not support client authentication for outbound and inbound connections. If client authentication is detected during server handshake, then the connection is bypassed.

As a MitM, Gigamon re-signs certificates. The following fields are copied from the original certificate:

•

subject name

•

primary signing CA

•

certificate validity

The following fields are set in the re-signed certificate:

•

certificate type—v3

•

serial number—randomly generated

•

v3 extensions:

•

basicConstraints CA—True

Note:  As this is a CA certificate, basicConstraints is set to True. For leaf certificates, basicConstraints is set to False.

•

keyUsage—digitalSignature and keyEncipherment

•

extendedkeyUsage—serverAuth

•

subjectKeyIdentifier—hash

•

authorityKeyIdentifier—keyid,issuer:always

All server certificates for decrypted outbound connections are issued by the GigaVUE node. The issuing CA is imported into the client’s browsers as a trusted CA. Thus, the clients will trust all certificates signed by the GigaVUE node. This interferes with the ability of the clients to check for the revocation status of the certificates. Thus the burden is upon the node to perform the revocation checks on the original server certificates before regenerating the certificates to the clients.

If revocation check is enabled with soft fail, decryption will continue even if the revocation status is not already known, whereas with hard fail, traffic will not be decrypted unless the revocation status is determined for certain.

If revocation check is enabled, once the GigaVUE node determines that the server certificate is revoked, further SSL connections to the server are dropped.

By default, revocation check is disabled.

There are two methods to check the revocation status of the certificates as follows:

•

using a Certificate Revocation List (CRL) from the issuing Certificate Authorities (CAs). Refer to Certificate Revocation List (CRL).

•

using the Online Certificate Status Protocol (OCSP). Refer to Online Certificate Status Protocol (OCSP).