Digital Certificates

In a public/private key system, the logistic problem of having to distribute a secret key and still maintaining the ability of keeping it secret has been resolved.  The public and private key pair makes up the entire secret key, but instead of distributing the entire key, only half is distributed while the other half is not.  In this case, the public key is distributed and the private key is not -- making the private key easier to secure.  The public key can be published and freely distributed without any concern of making it secret.  Together, the public/private key pair makes up one key because both are required to secure and un-secure the document.  For example, a document encrypted using the public key requires the private key to decrypt the same document.  A document signed using the private key requires the public key to verify the same document.  A secure transmission can be established between multiple trading partners just by distributing the public key between them.

However, a  problem can still arise when a public key is distributed by a malicious entity and impersonating a well known company.  When a trading partner of this well known company secures documents using this public key, the malicious entity can un-secure the document using the private key thereby exposing confidential data to this un-intended recipient.

A digital certificate store a public key and prevents the public key from being impersonated.  A digital certificate is manufactured by a third party entity called the Certificate Authority (CA), signed by the CA and is then furnished to a business entity or person - "stamped with certification" that the public key is valid and belongs to that business entity or person.  The "stamp of certification" is the CA digitally signing the certificate with its private key, and sets its name on the certificate specifying that it is the issuer of the certificate.  Any trading partner requiring verification of the certificate can easily obtain and use the public key of the CA to verify the certificate.

Self-Signed Certificates

Self-signed certificates are digital certificates that have been created without a CA.  The entity that created the certificate is the same entity that has signed and certified it.  The most important aspect about digital certificates is the presence of a CA, and, without it, the certificate is not secure.  Thus self-signed certificates should only be used for testing.  In some instances, self-signed certificates may be used between bi-lateral trading partners, where there are other outside form of communication and verification that can mitigate the risk of impersonation.

X.509 Digital Certificates and Cryptographic Service Providers

The Cryptographic Service Provider (CSP) system in Windows (R) operating systems (except Windows 95 (R)) supports the X.509 Digital Certificate format.  Framework EDI (FREDI) provides the capability to import and export valid digital certificates to certificate stores in the operating system.  The certificates can then be used for cryptographically encrypting, decrypting, signing and verifying documents.

Digital certificates can also be created using FREDI, but, absent of a CA, they can only be used for testing.  There are two ways to create a digital certificate:

  1. Using the eSecurityConsole utility.
  2. Programmatically creating the Test Certificate.

The principle method of creating the digital certificate is to take the public key from a key container in a CSP and storing it in a certificate.  The key container can contain at most two public/private key pairs.  The test certificate can use any of the public key in the public/private key pairs.

Procedure for Creating a Test X.509 Test Certificate