Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

What Are Digital Certificates?

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

You can think of a digital certificate as the electronic counterpart of an ID card, such as a driver's license or passport. The validity of a digital certificate is based on similar systems to those used to issue physical ID cards. You provide information about yourself to a trusted public body call a certification authority, such as VeriSign, Inc. or Thawte Consulting. The certification authority validates your information and then issues your digital certificate. The digital certificate contains information about who the certificate was issued to, as well as the certifying authority that issued it. Additionally, some certifying authorities may themselves be certified by a hierarchy of one or more certifying authorities, and this information is also part of the certificate. When a digital certificate is used to sign documents and software, this ID information is stored with the signed item in a secure and verifiable form so that it can be displayed to a user to establish a trust relationship.

Digital certificates use a cryptographic technology called public-key cryptography to sign software publications and to verify the integrity of the certificate itself. Public key cryptography uses a matched pair of encryption and decryption keys called a public key and a private key. The public-key cryptography algorithms perform a one-way transformation of the data they are applied to, so that data that is encrypted with one key can only be decrypted by the other key. Additionally, each key uses a sufficiently large value to make it computationally infeasible to derive a private key from its corresponding public key. For this reason, a public key can be made widely available without posing a risk to security.

To further reduce the possibility that someone will derive a private key from its public key, the certifying authority timestamps the key pair so that they must be replaced periodically, and provides an additional mechanism to assure that a signature was applied before the certificate expired. Any signature applied during the active lifetime of the digital certificate will remain valid for an unlimited time (unless the signed item is tampered with or the signature is removed). Any signature applied after the digital certificate expires is invalid.

To understand how public-key cryptography works, it helps to first describe how it is used to encrypt email messages. To do this, the sender obtains the recipient's public key from a directory service and uses it to encrypt the message before sending it. When the message is received, the recipient uses his or her private key to decrypt the message. As long as the private key is kept secure, no other user can decrypt the message and the recipient is assured that the transmission hasn't been tampered with.

A similar system is used to digitally sign documents and software, but instead of encrypting the entire file, first the file is passed through a one-way hashing algorithm to produce what is called a message digest. The message digest is a unique value that can be thought of as a "digital fingerprint" of the file. Microsoft Office uses the MD5 hashing algorithm to produce a message digest. Producing a message digest increases the efficiency of the process of creating and later verifying the signature for larger documents and software files. The message digest is then encrypted by using the signer's private key to produce the digital signature that is attached to the file.

To verify the integrity of the file, the application opening the file first uses the same hashing function to produce a message digest of the file. It then decrypts the signature attached to the file by using the signer's public key to recover the message digest produced when the file was originally signed. The two message digests are compared, and if any part of the file has been modified or corrupted, the digests will not match and the contents of the file can't be trusted. The verification process will fail regardless of how the file was modified - whether through corruption, a macro virus, or programmatic changes made by an add-in or Office solution. The verification process will also fail if the file wasn't signed with a valid certificate; that is, if the certificate had expired, or had been forged, altered, or corrupted. If another user modifies the VBA project, the Office 2000 application removes the current signature and prompts the user to re-sign the VBA project; if the user doesn't sign the VBA project or signs it with another certificate, the file may fail the verification process.

Important   While the previous description describes the process used to digitally sign both documents and software, Office 2000 applications provide only the ability to sign VBA projects contained within documents. Office 2000 applications don't provide the ability to sign documents themselves to ensure that text and other contents (other than macros) haven't been altered. However, Microsoft Outlook does provide the ability to digitally sign and encrypt the contents of messages. For more information about signing and encrypting messages in Outlook, search the Microsoft Outlook Help index for "security."

For a summary of the digital-signing process, see Figure 17.1.

Figure 17.1 Overview of the Digital-Signing Process


This same digital-signing process is also used within the digital certificate itself to identify it as being produced by the certifying authority and to ensure that the certificate has not been altered or forged.

For added security, a digital certificate has an expiration date that is enforced by the certification authority. Typically a digital certificate expires one year from the time it was issued. The reason for doing this is to greatly reduce the possibility that a malicious individual could derive a signature's private key from its public key. While deriving a private key from a public key is extremely unlikely because of the vast number of possible combinations that would need to be calculated for large key values, it is still not theoretically impossible. Additionally, adding an expiration date limits the lifetime of the certificate in the event that it is stolen. The certificate's expiration date ensures that any signature made after a certificate expires is invalid.

If the certification authority that issued the certificate provides a timestamping service, a hash of the code to be signed is sent over an Internet or intranet connection to a timestamping server maintained by the certification authority to be verified. If the code is being signed within the valid lifetime of the signature, a timestamp is added to the signature, and the signature will remain valid even after the certificate expires. If the certification authority that issues your digital certificate doesn't support timestamping, all signatures made with your certificate become invalid after the certificate expires.

For more information about digital signing and Microsoft Authenticode technology, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnauth/html/msdn_codewp.asp.

© 2015 Microsoft