Overview

The Clavister NetShield Firewall supports digital certificates that comply with the ITU-T X.509 standard. This involves the use of an X.509 certificate hierarchy with public-key cryptography to accomplish key distribution and entity authentication. References in this document to a certificate means an X.509 certificate.

A certificate is a digital proof of identity. It links an identity to a public key in order to establish whether a public key truly belongs to the presumed owner. By doing this, it prevents data transfer interception by a malicious third-party who might post a fake key with the name and user ID of an intended recipient.

Certificate Components

A certificate consists of the following:

By binding the above information together, a certificate is a public key with identification attached and is coupled with a stamp of approval by a trusted party.

Certificate Authorities

A certificate authority (CA) is a trusted entity that issues certificates to other entities. The CA digitally signs all certificates it issues. A valid CA signature in a certificate verifies the identity of the certificate holder, and guarantees that the certificate has not been tampered with by a third party.

A CA is responsible for making sure that the information in every certificate it issues is correct. It also has to make sure that the identity of the certificate matches the identity of the certificate holder.

Certificate Chains

A CA can also issue certificates to other intermediate authorities which themselves can issue host certificates, such as SSL server certificates. This leads to a chain-like certificate hierarchy. The highest certificate is called the Root Certificate and this is signed by the Root CA. Each certificate in the chain is signed by the CA of the certificate directly above it in the chain. However, the root certificate is signed by itself (it is "self-signed"). Any certificates in the chain between the root certificate and the end certificate are called Intermediate Certificates and are often packaged in a certificate chain file provided by intermediate issuing authorities.

A Certification Path refers to the path of certificates from one certificate to another. When verifying the validity of a user certificate, the entire path from the user certificate up to the trusted CA root certificate has to be examined before establishing the validity of the host certificate.

The maximum length of a certificate chain is 7 for cOS Stream. In VPN scenarios with roaming clients, the client's certificate will be the bottom of a certificate chain.

Certificate Validity Time

A certificate is not valid forever. Each certificate contains the dates between which the certificate is valid. When this validity period expires, the certificate can no longer be used, and a new certificate has to be issued.

Trusting Certificates

When using certificates, cOS Stream can trust any party whose certificate is signed by a given CA, either directly or via a chain. Before a certificate is accepted, the following steps are taken to verify its validity:

Uploading Certificates

Certificates are uploaded to cOS Stream using Secure Copy (SCP). When cOS Stream receives such files, it recognizes them as certificates and stores them until they are referenced in a CLI command to create a Certificate object.

The upload process will usually consist of a CA Root Certificate and Host Certificate upload plus any intermediate chain certificate files that will be required. The CA root certificate consists of a single certificate file. The host certificate has 2 parts added: a certificate file and a private key file. The files can be in either ASCII PEM format or binary DEM format. Using SCP is described further in Section 2.1.6, Secure Copy.

Self-signed certificates can also be used instead of CA signed certificates.

Creating Certificate Objects and Using Certificate Stores

Once certificate files are uploaded using SCP, Certificate configuration objects have to be created which are associated with these files. When a Certificate object is created, it is added as a child to a CertificateStore object.

By default, there is always a single CertificateStore called ipsec and this is the store that must be used for certificates used with IPsec tunnels. However, any number of other named CertificateStore objects can be created so that all the certificates for a particular purpose can be kept together in a single store.

Whenever a reference is made to a Certificate object in the firewall configuration, the reference must be qualified by the name of its parent CertificateStore object. For example, the reference to the Certificate object called my_ca_cert which is located in the store called ipsec would be ipsec/my_ca_cert.

An Example of Certificate Store and Certificate Object Creation

Assume that a CA root certificate file has the filename ca_cert.cer and the host certificate files have the filenames host_cert.cer and host_cert.key. Also assume that in this example there is also a certificate chain file called chain.cer because the host certificate has been issued by an intermediate authority and not a CA.

First, the individual files are uploaded to the firewall using SCP. A typical SCP console command on an external management computer might look like the following:

> scp ca_cert.cer admin@192.168.3.1:

Next, in the firewall configuration, create a CertificateStore for the certificates:

System:/> add CertificateStore mycerts

Change the CLI context to be the store:

System:/> cc CertificateStore mycerts
System:/CertificateStore/mycerts> 

Then add the Certificate objects as children of the store. The first object is the CA certificate which has its Type property set to Remote:

System:/CertificateStore/mycerts> add Certificate my_ca_cert
			Type=Remote
			CertificateData=file://ca_cert.cer

The second object is the host certificate which has its Type property set to Local:

System:/CertificateStore/mycerts> add Certificate my_host_cert
			Type=Local
			CertificateData=file://host_cert.cer
			PrivateKey=file://host_cert.key

The third object is the certificate chain which has its Type property set to Remote:

System:/CertificateStore/mycerts> add Certificate my_chain
			Type=Remote
			CertificateData=file://chain.cer

Finally, change the CLI context back to the default:

System:/CertificateStore/mycerts> cc
System:/> 

Any reference to these new Certificate objects in the configuration must now be qualified with the name of the CertificateStore that contains them. For example, the CA root certificate would be referenced as mycerts/my_ca_cert. Note that for use with IPsec tunnels, certificates must be placed in the predefined CertificateStore called ipsec. The ipsec store does not need to be created.

Deleting Certificate Stores

Like other object types, deleting a certificate store cannot be done without deleting all the children first. However, this behavior can be changed by using the delete command with the -force option, in which case any children will be deleted with the parent.

Certificates Can be Reused

Certificates are global objects that can be reused between, for example, VPN tunnels. Even though a certificate is associated with one VPN tunnel in cOS Stream, it can still be reused with any number of other, different VPN tunnels.

Encrypted Private Keys

The private key of a certificate can be encrypted and access to the key will then require a password. This means that software that uses the certificate will require the password to be entered before the private key can be accessed. Currently, cOS Stream does not provide the ability to allow an encrypted private key to be used.

Manually Creating Windows CA Server Requests

To request certificates from a CA server or CA company, the best method is to send a CA Certificate Request which is a file that contains a request for a certificate in a well known, predefined format.

It is possible to manually create the required files for a Windows CA server using the following procedure:

The detailed steps for the above procedure are as follows:

The saved .key and .cer files are now ready for upload.