SSL Certificates

The key to understanding how SSL works is to understand the elements that take part in the process. A key element of SSL is the SSL certificate. A public-key certificate (usually just called a certificate) is a digitally-signed document that ties the value of the public key to the identity of the server service that holds the corresponding private key.

Typically, a certificate contains the following information:

Many certificate types or standards exist, and EFT supports the most common ones. EFT can import into its certificate store any client-provided certificate of type PKCS 7 or 12, and the X.509 DER encoded standard. For the certificate that EFT itself provides (to the connecting client during the SSL handshake), it supports X.509 and PKCS #12 only. Note that PKCS #12 embeds both the certificate AND private key into a single file. The default type that is created by EFT is x.509 base-64 standard DER encoded.

Before a certificate can be used for securing connections, it must be created (generated) and signed (or vouched for). Certificates can be created directly from EFT, or by a trusted Certificate Authority (CA), which is an independent and trustworthy entity responsible for issuing and managing digital certificates, including revocation of certificates that are expired or are otherwise unauthorized. Once created, a certificate should be signed. By digitally "signing" a newly issued certificate, the signer guarantees the authenticity of the data held in the signee’s certificate. EFT can sign its own certificates; however, it is recommended that the certificate be signed by a trusted 3rd-party CA.

When generating a new certificate, EFT creates a self-signed certificate and a certificate signing request (or CSR) file that you can send to a CA for signing and then import into EFT.

Files created by EFT:

SSL Certificate Chain-of-Trust

Trust in a certificate is established when you have a copy of the signing certificate in your certificate store (for example, EFT’s store or Internet Explorer's Trusted Root Certification Authority for clients). The certificate does not necessarily have to be signed by a root CA; it can be signed by subordinate intermediate CA, as long as there is a valid certification path from the signing certificate to a trusted root certificate, meaning that none of the certificates in the certification path have been revoked or is expired.

Related Topics