Certificates are digital documents which map a public key to an entity. The certificate verifies the public key belongs to an individual entity. It also prevents an entity using the key to impersonate another entity.
Certificates are used to generate confidence in the legitimacy of a public key. An entity verifying a signature can also verify the signer’s certificate to ensure that no forgery or false representation occurred. Before sending a message, the user requests a certificate be presented. The certificate contains the recipient’s identity and public key. This information is then used to encrypt the message.
In their simplest form, a certificate contains a public key and a name. The certificate may also contain an expiration date, the name of the certifying authority that issued the certificate, a serial number and optional additional information. Most importantly, it contains the digital signature of the certificate issuer.
The most widely accepted format for certificates is X.509. Because X.509 is an International Standard, any application complying with X.509 can read and write certificates.
The problem with certificates is determining which entity the public key refers to. Certificates solve this problem by ensuring each certificate is signed by an entity that is either directly or indirectly trusted.
A CA is a trusted third party that vouches for the identity of individuals and organizations. Essentially the certificate authorities maintain a large database of public keys which are distributed as requested.
Normally a CA certificate is embedded in the application, or is located in a trusted database. When a certificate is presented, the Distinguished Name (DN) is used to lookup the certificate containing the public key that signed the certificate. If the presented certificate is valid, the certificate used to verify the signature must be checked. This operation continues recursively until a certificate that is trusted is read.
A Certificate Request is used to obtain a CA signed Server Certificate or Client Certificate from a Certification Authority. The SEAGULL Security Server creates Certificate Requests that may be sent to a Certification Authority for fulfillment.
A Server Certificate is digital certificate used to identify the server to clients when they connect. The public and private keys associated with the server certificate are also used to encrypt the SSL session key information. Public key lengths of at least 768 bits must be used to be considered secure. The key length is specified in the Certificate Request used to generate a Digital Certificate.
Server Certificates may be obtained from a Certification Authority (CA) signed with their trusted root certificate, or created by the SEAGULL Security Server as a Self-Signed Certificate.
Server Certificates obtained from a CA cost several hundred dollars and must be renewed annually. Self-signed certificates are free.
A Client Certificate is a digital certificate used to identify individuals when they connect to an SSL server. Public key lengths of at least 768 bits must be used to be considered secure. The key length is specified in the Certificate Request used to generate a Digital Certificate.
Client Certificates may be obtained from a Certification Authority (CA) signed with their trusted root certificate, or created by the SEAGULL Security Server as a Self-Signed Certificate.
Client Certificates obtained from a CA carry a per user charge and must be renewed annually. Self-Signed certificates are free.
A Self-Signed Certificate is one that is not signed by a Certification Authority, but created by the Security Server administrator and signed using a SEAGULL Security Server Signing Certificate.
Self-Signed Server Certificates are as cryptographically secure as CA signed certificates but are generally not "trusted" by client programs. Client programs must be configured to accept "invalid" or "un-trusted" server certificates. Self-signed Client Certificates will be accepted by the requesting server if the client has been added to the user list and the Client Certificate meets the authentication requirements and is not expired or revoked.
A Signing Certificate is used to digitally sign a client or server certificate during the certificate generation process. Signing a client certificate ensures authenticity of the certificate when it is presented to the server by providing information about the root certificate any certificates in the chain.
A Root Certificate is the starting certificate in a certificate hierarchy. All certificates contain information tracing their origin back to a Root Certificate. A Trusted Root Certificate is one where the root certificate is known to the requester. The Trusted Root Certificate must be installed at the client when authenticating a Server Certificate. A Trusted Root Certificate must be installed at the server when authenticating a Client Certificate.
A Certificate Chain the a set of certificates that link any certificate to its Root Certificate. This chain includes the end certificate and any intervening Signing Certificates.
A Certificate Private Key is used to decrypt messages encrypted using the Certificate Public Key contained in a digital certificate. The Private Key is generally password protected using the Private Key Password to prevent unauthorized use of the Private Key. If the Private Key Password is compromised, the Certificate must be uninstalled and a new one generated.