You Can Be a Web Certification Authority

Ensure your company's security with Entrust/WebCA

The Web has opened great opportunities for doing business on the Internet. Whatever type of business you conduct over the Web­merchandising, information publishing, or customer service­you must ensure the security and privacy of sensitive information transferred between Web servers and browsers.

Digital certificates play a critical role in Web security. Digital certificates are electronic documents that computer systems use to identify and authenticate individuals participating in an application, such as Web browsing, email, and file transfer. Traditional user logons and firewalls can't protect sensitive information when systems transfer it between Web servers and browsers. However, combined with other security technologies­encryption, digital signatures, and the Secure Sockets Layer (SSL) protocol­digital certificates can prevent data eavesdropping, tampering, and repudiation (denial of involvement) over the Web.

A Certification Authority (CA) is a trusted entity responsible for issuing digital certificates to individuals or systems based on verification of applicants' identities. You can request certificates from a public CA, such as VeriSign. However, as companies demand more certificates for their Web servers and browsers from a third party, they are becoming more concerned about confidentiality, cost of ownership, quality of service, and other issues. To obtain third-party certificates, you must release confidential business information about employees, customers, suppliers, and partners. You must pay subscription fees of tens to hundreds of dollars per certificate per year; at $50 per certificate, a 1000-employee company spends $50,000 a year on certificates. If you use a third-party CA, you do not control the certificate process, such as generation, retrieval, and revocation of certificates. And the process can take months.

To address companies' concerns about the disadvantages of working with third-party CAs, Entrust Technologies (formerly Nortel Secure Networks) recently released Entrust/WebCA for Windows NT. With this software, you can be the Web CA and issue certificates for both Microsoft and Netscape Web servers and browsers for your company and customers. To be a Web CA, you must understand some underlying concepts: cryptographic keys, digital signatures, certificates, and Web certificates. I will use Entrust/WebCA 1.01 (WebCA) as an example to introduce these concepts, explain how to issue and manage Web certificates, and address some unresolved issues such as interoperability and integration. (For product details, see "A Look at Entrust/WebCA.")

Keys and Signatures
The computer industry uses cryptography to keep communications secure and protect sensitive data from attack. In a cryptographic system, you use a key to encrypt a sending message and a corresponding key to decrypt the received message. A key is a numeric value, which can be a few bits or thousands of bits. The two kinds of keys are symmetric keys and public keys.

In symmetric cryptography, the sender and the receiver use the same key to encrypt and decrypt a message. In public key cryptography, everyone has two keys, a public key and a private key. Senders use the receiver's public key to encrypt messages, and receivers use their private keys to decrypt messages. Public key cryptography is more secure than symmetric cryptography, because discovering a private key kept by one person is more difficult than discovering a shared secret key. Public key cryptography, however, is more complicated and slower than symmetric cryptography.

To improve the process, developers have combined symmetric key and public key cryptography. The rationale for combining the two types of keys is that you can use a symmetric key once to encrypt and decrypt messages in a session. The sender randomly generates a symmetric key, encrypts the key with the receiver's public key, and sends the encrypted key to the receiver. The receiver decrypts the encrypted key with a private key. The sender uses the original symmetric key to encrypt the message, and the receiver uses the recovered symmetric key to decrypt the message. The sender and receiver use this symmetric key only once and discard it when they finish the session.

Although public key cryptography works well for data encryption, developers use digital signatures to authenticate data transmitted from a sender to a receiver. With digital signatures, the sender signs a message before sending it. The receiver verifies the signature enclosed in the message to confirm that the message is from the expected sender and that no one has tampered with it during transmission. Let's see how digital signatures and public key cryptography work together.

When John wants to send a message to Beatrice, he creates the message and passes it through a hashing algorithm. The output is the message hash, or message digest. John uses his private key to encrypt the message hash. The result is a digital signature, or fingerprint, which looks something like A5:81:3D:49:57:E5:16:FF:33:18. John appends the signature to the message. He then generates a one-time symmetric key and uses Beatrice's public key to encrypt it. Finally, John sends the encrypted one-time symmetric key and the message bundled with the digital signature to Beatrice.

When Beatrice receives the encrypted message, she uses her private key to decrypt the symmetric key and then uses the symmetric key to decrypt the message. Beatrice uses John's public key to decrypt the signature into the original message hash. She passes the decrypted message through the same hashing algorithm that John used and obtains a new message hash. She compares the new message hash with the original message hash, and if they differ, she knows tampering or a transmission error has altered the message during transmission.

You can use digital signatures independently of data encryption. For instance, John can sign the message but not use public key cryptography to encrypt the message when he transmits it. John also can have different public and private key pairs for signing and encryption.

A digital certificate is an electronic ID; it contains an individual's name, an ID number, and a public key. When a CA issues a certificate, it signs the certificate by using its private key and encloses its signature in the certificate (in the same way that John signs his message in the previous example). The CA's signature makes the certificate trustworthy.

If you don't know the CA, you can verify a certificate by tracing the chain of signatures on the certificate until you find a common trusted authority. This capability is the basis of trust between companies. Tracing signatures follows roughly the same steps that Beatrice undertakes when she checks John's signature. When you validate the CA's signature, you can trust the certificate. For example, if Company A and Company B both trust Company C (i.e., if Company C has signed Company A's and Company B's public keys), a user in Company A can trust a user in Company B.

The most popular certificate is the X.509 certificate. The International Telecommunication Union (ITU) defined X.509 in 1988 as an international standard for public key certificates. X.509 is a subset of the X.500 open system standards for directory service. Most Web servers and browsers, including Microsoft's Internet Information Server (IIS) and Netscape's Enterprise Server, support X.509 certificates. The X.509 certificate contains a serial number, a subject, an issuer, a validity period, a public key, and the CA's signature.

The serial number specifies the unique number of the certificate. The subject is the X.500 distinguished name (DN) of the individual or system that holds the certificate. The DN includes the common name (CN--e.g., John Smith), an optional organization unit (OU--e.g., Sales), the organization (O--e.g., Acme), and the country (C--e.g., US). The issuer is the CA's X.500 DN. The validity period is the certificate's issue and expiration dates. The certificate includes the subject's public key, but not the corresponding private key. The CA signs the certificate through a public key algorithm and a hashing algorithm. The most common public key algorithm is RSA; the most common hashing algorithm is RSA Data Security's Message Digest-5 (MD-5). WebCA uses a 1024-bit RSA key for signing, and its default hashing algorithm is MD-5.

Version 3 of X.509 has an important new feature: flexible extensions that include additional information in the certificate. The X.509 certificate includes standard extensions such as a private key usage period that lets you specify the expiration date of the signing private key. You can also define nonstandard extensions for your business. For example, you can use a birthday extension in a Web browser certificate to prohibit users younger than a specific age from accessing certain contents on a Web server. WebCA supports this new X.509 feature.

Web Certificates
Web security requires three kinds of X.509 certificates: a CA certificate, a browser certificate, and a server certificate. WebCA automatically generates the CA certificate on the server, and the CA issues browser and server certificates. The CA can issue browser and server certificates either automatically (e.g., to all employees of a company) or in response to a client's application (e.g., to certain bank customers).

The CA certificate identifies a specific CA and contains its public key. Browser certificates identify the users who use that browser and contain the users' public key. To view your browser certificates in Internet Explorer (IE) 3.x, go to View, Options, Security, and click Sites. This procedure lets you view preinstalled public CA certificates (e.g., from AT&T, GTE, and VeriSign). If you click Personal on the Security tab, you can view the certificates that you can use to identify yourself to other servers. If you have not received a browser certificate, this list will be empty. The server certificate identifies the Web server and contains the server's public key.

Use of Web Certificates
Certain Internet security protocols use Web certificates to establish a secured Web session. The most popular Internet security protocol is Netscape Communications' SSL. This protocol uses the three Web certificates (CA, browser, and server) to identify and authenticate the server and the browser, and to establish a secured Web session between the server and the browser. The SSL protocol is an application-independent protocol working at the transport layer. SSL lets HTTP and FTP, Telnet, and other TCP applications operate on top. Netscape has submitted SSL 3.0 to the Internet Engineering Task Force (IETF) for approval as an Internet standard. Both Microsoft and Netscape Web servers and browsers support SSL 2.0 and SSL 3.0. Let's see how SSL works.

If John wants to view some secret information on Beatrice's Web server, his browser and her Web server can use SSL to authenticate each other to establish a secured session. They secure the session by authenticating the server and the browser and encrypting the data exchanged between the server and the browser. SSL has three major phases: server authentication, browser authentication, and session setup.

To authenticate the server, John's browser requests a secure session with Beatrice's Web server by issuing the Hypertext Transport Protocol Security command The server answers the request by sending its certificate to the browser. The browser uses the CA public key that the browser extracts from the CA certificate to verify the CA's signature in the server certificate.

To authenticate the browser, John's browser sends its certificate to Beatrice's Web server. The server uses the CA public key to validate the CA's signature and, therefore, to verify the browser certificate. (In SSL, browser authentication is optional. If you don't enable browser authentication in the Web server, the server won't check the browser certificate.)

If the browser and server authenticate each other, the browser generates a single-use symmetric key, which SSL calls a session key or a master key. The browser encrypts the session key using the server's public key extracted from the server certificate, and then sends the session key to the server. The server uses its private key to decrypt the session key. John's browser and Beatrice's Web server use this session key to encrypt and decrypt information transferred over the Web during the secured session.

Issuing Web Certificates
SSL works well for Web security. As a Web CA, however, you must issue Web certificates to your Web servers and browsers before they can use SSL. WebCA lets you issue browser certificates to IE 3.x and Netscape Navigator 3.x, and server certificates for IIS 3.0 and Enterprise Server 2.0. (For problem solving, see "Tips for Using Microsoft IIS and IE with WebCA and Certificates".) WebCA provides a client interface and an administrator interface for issuing certificates; you can access both interfaces from the Microsoft and Netscape browsers.

Before you issue browser certificates, you must distribute your CA certificate to the browsers. An easy way to distribute the certificate is to let clients connect their browsers to the WebCA's client interface and retrieve the CA certificate. WebCA stores the CA certificate in cacert.der, a certificate file in the webca\mgrent\queue directory. You can copy this file to a floppy and distribute it to your clients. Opening the CA certificate file in a browser imports the CA certificate into the browser.

WebCA provides two methods for issuing a browser certificate: the generated-secret method and the existing-secret method. In the generated-secret method, a client doesn't submit any secret information to you when the client requests a certificate. Creating a certificate generates an authorization code and a reference number. You must send this generated-secret information to the client through a secured method. Clients can retrieve the certificate to their browsers by using the authentication code and reference number.

In the existing-secret method, the client must provide some secret information, such as a PIN or employee number, as part of an application for a browser certificate. Screen 1 shows an example WebCA browser certificate application. When the client uses this number to retrieve the certificate from WebCA, as shown in Screen 2, the client uses this number to retrieve the certificate from WebCA. Screen 3, shows an example WebCA browser certificate.

You apply for a server certificate in a different way. A Web server administrator must create a key request file with a key generation utility (e.g., Key Manager in IIS) in the Web server. The file contains the server X.500's DN, the administrator's email address, and the server's public key. The administrator then submits the contents of the file to WebCA by cutting the contents from the file and pasting them into the server certificate application form. When WebCA creates the server certificate, the Web server administrator can retrieve the certificate through the client interface by cutting the contents of the issued server certificate from the retrieval page and pasting it into a file. The administrator then uses the file to install the certificate in the Web server. This method works for both Microsoft and Netscape Web servers.

Managing Web Certificates
Although issuing certificates in WebCA is easy, managing Web certificates effectively and securely is more difficult. Certificate management includes many tasks. You need to determine required client information, choose request processing procedures, set validity periods, revoke certificates, manage certificate storage, and ensure server security.

The information you require from clients when they request certificates depends on your business and its security requirements. Customers of an Internet shopping mall might submit only minimal information (e.g., just names) for certificates, so that they feel safe when they make purchases. Bank customers, however, might have to submit more information, such as names, account numbers, PIN numbers, and Social Security numbers.

WebCA provides default application forms for two types of browser certificates--Type 1 and Type 2--which are sufficient for most cases. Type 1 requires only a client's name and perhaps an email address. Type 2 requires more information, including a client's name, employee number, department, organization, location, email, phone number, and optional additional information. You can define custom application forms by modifying the initialization files and client HTML files in WebCA.

WebCA provides flexible ways to process requests. When you have accepted a request and generated a certificate, you can notify the client and let the client retrieve the certificate in the client interface. You can send clients an HTTP link to the certificate in an email message. If you have a list of your clients, such as the users in your intranet, you can create their browser certificates without their request. You can manually create certificates one by one in WebCA. You can even run a batch job by importing your clients' information to the main request queue (bulkload.txt in the webca\mgrent\queue directory). And finally, WebCA gives you the option of accepting all requests automatically.

WebCA bases a certificate's validity period on two elements. One element is the validity period parameter that you set in WebCA (24 months by default, with a range of 1 month to 48 months). The other element is the RSA key size that the browser or server uses. The key size can be 512 bits (12 months), 768 bits (24 months), or 1024 bits (48 months). WebCA chooses the shorter element. For example, if you use a 1024-bit RSA key in IIS but set the validity period parameter in WebCA to 24 months, the server certificate will be valid for 24 months.

When a certificate's private key becomes public or you can no longer trust the certificate, you must revoke the certificate. For instance, when an employee leaves the company or a customer cancels service, you must revoke the corresponding certificate. A CA stores revoked certificates in the Certificate Revocation List (CRL) and encloses a standard extension field (CRL distribution points) in the revoked certificates. The field points to the CRL in WebCA. However, Web servers and browsers using SSL don't automatically check the CRL, and the certificate will continue to work if no one checks it.

If a revoked browser certificate is in an in-house computer, you can manually remove the certificate. However, if a revoked browser certificate is in a remote computer outside your control, you must devise a way to check the certificate's status. For example, you can use Web server user accounts or a custom utility for your Web server to check the CRL when a browser connects to it. You can delete or renew a revoked or expired certificate, but you must reinstall the renewed certificate in a browser or server.

Because a private key resides in only the client computer, WebCA can't recover the private key if a computer loses or destroys it. WebCA, however, can revoke or delete the corresponding certificate and issue a new certificate to the client.

WebCA stores all issued certificates and all revoked certificates in a Lightweight Directory Access Protocol (LDAP) directory. When administrators want to list, view, revoke, renew, or delete a certificate, they can use WebCA's search engine to find a specific certificate, a group of certificates, or all certificates in the WebCA's LDAP directory. A client can search the directory to see whether a requested certificate is ready and then retrieve the certificate from the directory, as Screen 4 shows.

You must keep your Web CA server in a secure environment, so that no one can tamper with it. You also must carefully protect the webca\mgrent\manager directory on the server because that directory contains the Web CA's signing private key. If something compromises a Web CA's private key, all issued certificates signed by the key are compromised. At a minimum, use NTFS for the server file system and don't share that directory on the network. To obtain a high level of security, you can store your Web CA on a tamper-resistant device. If someone attacks the Web CA's private key, the device will destroy its contents or use electromagnetic radiation to protect against attacks.

You can manage WebCA from a remote workstation. Entrust recommends that you enable SSL on WebCA's admin interface (directory cgi-adm) to improve security. In the WebCA initialization files, you can enable the Cookie-secure setting to prevent administrators from connecting to the admin interface if SSL is turned off. After you have established your Web certificate management infrastructure and a secure CA system, make sure that you have a good backup and disaster recovery plan.

Interoperability and Integration
As a new technology, certificates present some unresolved issues. One issue is the lack of interoperability. For example, you can't interchange a certificate issued to IE with another certificate issued to Netscape Navigator. Microsoft and Netscape use different download file formats for certificate retrieval, which makes the two browsers incompatible.

Certificates currently are device-oriented rather than user-oriented. A certificate in one browser can't be used in another browser, because it is tied to the browser's private key. Unless you can move the private key and the certificate together, you can't move the certificate from one browser to another. Consequently, you need multiple certificates if you have multiple computers.

Fortunately, both Microsoft and Netscape are working on certificate interoperability. Microsoft's Internet Security Framework will let you transfer keys and certificates between computers. Microsoft's CryptoAPI will let applications share keys and certificates. Netscape has implemented certificate mobility in its new Communicator browser.

Another unresolved issue is integration. When you introduce CA software to your company, you add another directory to your network. Entrust/WebCA provides an LDAP directory as a certificate directory and even lets an LDAP-compliant directory replace the WebCA directory. You can integrate Netscape Directory Server, which includes certificate attributes in its directory schema, with WebCA; however, Microsoft's domain-based directory and Novell Directory Services (NDS) don't have room for certificates. The Network Applications Consortium (NAC) has proposed the Lightweight Internet Person Schema (LIPS) specification to IETF as a standard to define a common set of directory attributes, including digital certificates. Several leading vendors, including Microsoft and Novell, have promised to support LIPS in their directory services.

The Future of Web CAs
Digital certificates are important for securing Web communications. CA software, such as Entrust/WebCA, lets you be your company's Web CA and establish a trusted domain within your company and business. This trusted domain is isolated from other domains, similar to a LAN on an isolated island 10 years ago. CAs must have a mutual trust relationship before their users can exchange information across trust domains. As more businesses move to the Internet, corporations and organizations will develop trust based on their business relationships.

Entrust/WebCA 1.01
Contact: Entrust Technologies * 972-684-8604
Price: $500 for 500 certificate licenses
TAGS: Security
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.