January 21, 2021
Hot Topics:

Digital Document Signing in Java-Based Web Applications

  • By Svetlin Nakov
  • Send Email »
  • More Articles »

Certificate Chains and Verification

When a top-level certification authority issues a certificate to a client, it signs it with its Root certificate. In this way, a certification chain consisting of two certificates is formed: the certification authority's certificate standing before the certificate of the client. A certification chain is a sequence of certificates in which each certificate is signed by the one after it. At the beginning of the chain usually stands some certificate issued to an end-client, and at the end of the chain is the Root certificate of some certification authority. In the middle of the chain stand the certificates of some intermediate certification authorities. The common practice is for the top-level certification authorities to issue certificates to the intermediate certification authorities and to specify in these certificates that they can be used to issue other certificates. The intermediate certification authorities issue certificates to their clients or to other certification authorities. The rights set to the end-client certificates do not allow them to use the certificates to sign other certificates, but this restriction does not apply to the certificates issued to intermediate certification authorities.

A certificate at the beginning of a certification chain can be trusted only if this certification chain can be successfully verified. In this case, it is said to be a verified certificate. The verification of a certification chain includes the verification that every certificate in it is signed by the next certificate in the chain. As for the last certificate, it is verified that it is on the list of unconditionally trusted Root certificates. Every software system that performs certificates verification maintains a list of trusted Root certificates, which it unconditionally trusts. These are the Root certificates of worldly acknowledged certification authorities. For example, the Web browser Internet Explorer, by default, comes with a list of about 150 trusted Root certificates, and the browser Mozilla in its initial installation contains about 70 trusted certificates. Certification chain verification includes not only the verification that each certificate is signed by the next one and that the certificate at the end of this chain is on the list of trusted Root certificates. It is also necessary to verify that each certificate in the chain is still valid, and also that each certificate except the first one has the right to be used to sign other certificates. If the verification of the last condition is omitted, it would be possible for end clients to issue a certificate to whomever they want and the verification of the issued certificate to be successful. In the verification of a given certification chain, it is checked also whether some certificate in it is revoked. The purpose of the combination of all described verifications is to determine whether a certificate can be trusted. If the verification of a certification chain is unsuccessful, it does not necessarily mean that there is a forgery attempt. It is possible that the list of trusted Root certificates used in the verification does not contain the Root certificate at the end of the chain, although it is real. Generally, a certificate cannot be verified if the whole its certification chain is not present or if the Root certificate at the beginning of the chain is not on the list of trusted certificates. The certification chain of a given certificate can be programmatically constructed, in case it is not present; but for that purpose, all certificates in it must be present.

Protected Keystores and Certificate Files

In the systems for electronic signing of documents, protected stores for keys and certificates (protected keystores) are used. Such stores can contain three kinds of elements: certificates, certification chains, and private keys. As the information stored in protected stores is confidential due to security considerations, it is accessed using two-level passwords: a password to the store and separate passwords for the private keys in it. Thanks to these passwords, in case of eventual stealing of a protected keystore, the confidential information stored there can not be easily read. In practice, the private keys, as a particularly important and confidential piece of information, are never stored outside the keystores and are always protected with access passwords.

There are several developed standards for protected keystores. The most widespread is the PKCS#12 standard, in which the store is a file with the standard extension .PFX (or the more rarely used extension .P12). A PFX file usually contains a certificate, a private key corresponding to it, and a certification chain proving the certificate authenticity. The presence of a certification chain is not necessary and sometimes the PFX files contain only a certificate and a private key. In most cases, to facilitate the user, the password to access a PFX file is the same as the password to access the private key stored in it. Due to this reason, when using PFX files most frequently only a single access password is required.

When a certification authority issues a digital certificate to a client, the client ultimately gets a protected keystore, which contains the issued certificate, its corresponding private key, and the whole certification chain, proving the certificate's authenticity. The protected store is given to the client either in the form of a PFX file, as a smart card, or is directly installed in his or her Web browser.

Usually, when a certificate is issued over the Internet, independent of how the user confirms his or her identity, in the issuance procedure the user's Web browser plays an important part. In a request for a certificate issuance sent to a given certification authority from its Web site, the user's Web browser generates a public/private key pair and sends the public key to the authority's server. The browser keeps the private key a secret and does not send it to the authority. The certification authority, after verifying the authenticity of its client's personal identity data, issues him or her certificate in which it records the public key received by the client's Web browser and his or her confirmed identity data. For some types of certificates, the identity data can consist only of a verified e-mail address, while for others the data can contain full information about the person: name, address, identity card's number, and so on. The personal data verification is done using a procedure, determined by the respective certification authority. After the certification authority's server issues the certificate to its client, it redirects him or her to the Web page from which this certificate can be installed in the client's Web browser. In reality, the user somehow receives his or her newly issued certificate from the certification authority along with the complete certification chain. Meanwhile, the Web browser has stored the private key corresponding to the certificate and, at the end, the user obtains a certificate and its corresponding private key, along with the certification chain of the certificate, installed in his or her Web browser. The method of storing private keys varies with the different browsers, but in any case such confidential information is protected at least with a password. In the described mechanism for issuing a certificate, the user's private key remains unknown to the certification authority and in that way the user can be sure that no one else has access to his or her private key.

Most Web browsers can use the certificates and private keys stored in them for authentication before secure SSL servers. Many e-mail clients can also use the certificates stored in the Web browsers for signing, encrypting, and decrypting electronic mail. However, some applications cannot directly use the certificates from the users' Web browsers, but can work with PFX keystores. In such cases, the users can export their certificates from their Web browsers, along with their corresponding private keys in PFX files and to use them in any other application. In Internet Explorer, the certificate and private key are exported from the main menu by using the commands Tools | Internet Options | Contents | Certificates | Export; and in Netscape and Mozilla, by using the commands Edit | Preferences | Privacy & Security | Certificates | Manage Certificates | Backup. By default, when exporting a certificate and a private key in a PFX file, Internet Explorer does not include the complete certification chain in the output file, but the user can specify them using an additional option.

There are several standards for storing X.509 digital certificates. Most frequently, ASN.1 DER encoding is used, in which the certificates are stored in files with a .CER extension (or more rarely with .CRT or .CA extensions). A CER file contains a public key, information about its owner, and a digital signature of some certification authority, certifying that this public key really belongs to that person. The certification authorities distribute from their sites their Root certificates in CER files. A CER file can be stored in binary format or text format, encoded with Base64.

Page 3 of 4

This article was originally published on September 25, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date