Previous     Contents     Index     DocHome     Next     
Sun Java (tm) System Application Server Administrator's Guide to Security



Administering Certificates


This section describes how to set up and administer the trust database, certificates, and certificate-related lists for your Sun Java (tm) System Application Server 7 environment.

This section contains the following topics:



About Certificates and Authentication

Authentication is the process of confirming an identity. In the context of network interactions, authentication is the confident identification of one party by another party. Certificates are one way of supporting authentication.

A certificate consists of digital data that specifies the name of an individual, company, or other entity, and certifies that the public key, included in the certificate, belongs to that entity. Both clients and servers can have certificates.

A certificate is issued and digitally signed by a Certificate Authority (CA). The CA can be a company that sells certificates over the Internet, or it can be a department responsible for issuing certificates for your company's intranet or extranet. You decide which CAs you trust enough to serve as verifiers of other people's identities.



Note A server certificate must be installed before encryption can be activated.



In addition to a public key and the name of the entity identified by the certificate, a certificate also includes an expiration date, the name of the CA that issued the certificate, and the digital signature of the issuing CA. For more information regarding the content and format of a certificate, see Introduction to SSL.



Implementing the Trust Database



In the Sun Java (tm) System Application Server, the Administration Server and each server instance has its own certificate and key-pair file, referred to as a trust database. Before requesting a server certificate, you must create a trust database for identifying your trusted entities.

In the trust database you create and store the public and private keys, referred to as your key-pair file. The key-pair file is used for SSL encryption. You will use the key-pair file when you request and install your server certificate, which is stored in the trust database after installation. The key-pair file is stored encrypted in the config directory of the instance.

The Administration Server has only one trust database, while each server instance can have its own trust database. The certificate and key-pair database files are named after the server instance that uses them. Virtual servers are covered by the trust database created for their server instance.

As the administrator, you manage the trust database and its constituent certificates, including the server certificate and all the included CAs.

This section addresses the following:


Creating a Trust Database

When you create the trust database, you specify a password that will be used for a key-pair file. You will also need this password to start a server using encrypted communications.

To create a trust database on your local machine, perform the following steps:

  1. Access App Server Instances and select the server instance.

  2. Access Security.

  3. Click Manage Database.

  4. Click the Create Database link.

    The Initialize Trust Database page is displayed.

  5. Enter a password for the database.

  6. Repeat the password.

  7. Click OK.


Changing a Trust Database Password

To change an existing trust database password, perform the following steps:

  1. Access App Server Instances and select the server instance.

  2. Access Security.

  3. Click Manage Database.

  4. Click the Change Password link.

    The Change the Key Pair File Password page is displayed.

  5. Select the cryptographic module from the dropdown list.

  6. Enter the old password.

  7. Enter the new password.

  8. Repeat the new password.

  9. Click OK.



Requesting a Certificate

After creating a trust database for your server, you can request a certificate and submit it to a CA. If your company has its own internal CA, request your certificate from them. If you plan to purchase your certificate from a commercial CA, choose a CA and ask for the specific format of the information they require. A list of available certificate authorities, including links to their sites, is available on the Request a Certificate page.

The Administration Server can have only one server certificate, while a server instance can have its own server certificate. You can select a server instance certificate for each virtual server.

The following topics address guidelines for requesting certificates:


Required CA Information

Before you begin the request process, make sure you know what information your CA requires. Whether you are requesting a server certificate from a commercial CA or an internal CA, you need to provide the following information:

  • Common Name—The fully qualified hostname used in DNS lookups (for example, www.sun.com). This is the hostname in the URL that a browser uses to connect to your site. If these two names don't match, a client is notified that the certificate name doesn't match the site name, creating doubt about the authenticity of your certificate. Some CAs might have different requirements, so it's important to check with them.

    You can also enter wildcard and regular expressions in this field if you are requesting a certificate from an internal CA. However, most vendors will not approve a certificate request with a wildcard or regular expression entered for common name.

  • email Address—Your business email address. This is used for correspondence between you and the CA.

  • Organization—The official, legal name of your company, educational institution, partnership, and so on. Most CAs require that you verify this information with legal documents (such as a copy of your business license).

  • Organizational Unit—An optional field that describes an organization within your company. This can also be used to specify a less formal company name (without the Inc., Corp., and so on).

  • Locality—An optional field that usually describes the city, principality, or country for the organization.

  • State or Province—Usually a required field, but can be optional for some CAs. Most CAs won't accept abbreviations, but check with them to be sure.

  • Country—A required field that contains the two-character abbreviation of your country name, in ISO format. The country code for the United States is US.

All this information is combined as a series of attribute-value pairs called the distinguished name (DN), which uniquely identifies the subject of the certificate.

If you are purchasing your certificate from a commercial CA, you must contact the CA to find out what additional information they require before they issue a certificate. Most CAs require that you prove your identity. For example, they want to verify your company name and who is authorized by the company to administer the server. They might also ask whether you have the legal right to use the information you provide.

Some commercial CAs offer certificates with greater detail and veracity to organizations or individuals who provide more thorough identification. For example, you might be able to purchase a certificate stating that the CA has not only verified that you are the rightful administrator of the www.your_company.com computer, but that you are a company that has been in business for three years, and have no outstanding customer litigation.


Implementing a VeriSign Certificate

VeriSign is the preferred certificate authority (CA) of the Sun Java (tm) System Application Server. VeriSign's VICE protocol simplifies the certificate request process, plus VeriSign has the advantage of being able to return their certificates directly to your server.

The Administration Server can have only one server certificate, while a server instance can have its own server certificate. You can select a server instance certificate for each virtual server.

The following topics address implementing a Verisign Certificate:


Requesting a VeriSign Certificate

To request a VeriSign certificate, perform the following steps:

  1. Access App Server Instances and select the server instance.

  2. Access Security.

  3. Select Certificate Management.

    The Request a Server Certificate page is displayed. Click the list of available certificate authorities link to display all CAs.

  4. Click the Request VeriSign link.

    The Request a Verisign Certificate page is displayed.

  5. Review the steps required.

  6. Click Get Certificate.

  7. Follow the VeriSign procedure.


Installing a VeriSign Certificate

If you request and receive approval for a VeriSign certificate, it should appear in the drop-down list of the Install VeriSign Certificate page in one to three days. To install a VeriSign certificate, perform the following steps:

  1. Access App Server Instances and select the server instance.

  2. Access Security.

  3. Select Certificate Management.

  4. Click the Install VeriSign Certificate link.

    The Retrieve a Verisign Certificate page is displayed.

  5. Choose internal (software) from the drop-down list for the cryptographic module, unless you will use an external encryption module.

  6. Enter your Key Pair File Password or PIN.

  7. Select the Transaction ID to Retrieve from the drop-down list.

    You will usually want the last one.

  8. Click OK.


Implementing a Non-VeriSign Certificate

You can request and install certificates from other CAs other than VeriSign. Your company or organization may provide its own internal certificates. This section describes how you would request and install these other types of server certificates.

The Administration Server can have only one server certificate, while a server instance can have its own server certificate. You can select a server instance certificate for each virtual server.

The following topics address implementing server certificates other than VeriSign:


Requesting a Non-VeriSign Certificate

To request a certificate from CAs other than VeriSign, perform the following steps:

  1. Access App Server Instances and select the server instance.

  2. Access Security.

  3. Select Certificate Management.

  4. Click the Request link.

  5. Select if this is a new certificate or a certificate renewal.

    Many certificates expire after a set period of time, such as six months or a year. Some CAs will automatically send you a renewal.

  6. Perform the following steps to specify how you want to submit the request for the certificate:

    • If the CA expects to receive the request in an email message, check CA Email and enter the email address of the CA. For a list of CAs, click List of available certificate authorities.

    • If you are requesting the certificate from an internal CA that is using the Sun Java (tm) System Certificate Server, click CA URL and enter the URL for the Certificate Server. This URL should point to the certificate server's program that handles certificate requests.

  7. Select the cryptographic module for the key-pair file you want to use when requesting the certificate from the drop-down list.

  8. Enter the password for your key-pair file.

    This is the password you specified when you created the trust database, unless you selected a cryptographic module other than the internal module. The server uses the password to get your private key and encrypt a message to the CA. The server then sends both your public key and the encrypted message to the CA. The CA uses the public key to decrypt your message.

  9. Enter your identification information.

    The format of this information varies by CA. For a general description of these fields, a list of CAs is available through both Server Administrator, and through the Server Manager Security pages under Request a Certificate. Most of this information usually isn't required for a certificate renewal.

  10. Verify your work to ensure accuracy.

    The more accurate the information, the faster your certificate is likely to be approved. If your request is going to a certificate server, you'll be prompted to verify the form information before the request is submitted.

  11. Click OK.

The server generates a certificate request that contains your information. The request has a digital signature created with your private key. The CA uses a digital signature to verify that the request wasn't tampered with during routing from your server machine to the CA. In the rare event that the request is tampered with, the CA will usually contact you by phone.

If you choose to email the request, the server composes an email message containing the request and sends the message to the CA. Typically, the certificate is then returned to you using email. If instead you specified a URL to a certificate server, your server uses the URL to submit the request to the certificate server. You might get a response using email or other means, depending on the CA.

The CA will notify you if it agrees to issue you a certificate. In most cases, the CA will send your certificate using email. If your organization is using a certificate server, you may be able to search for the certificate by using the certificate server's forms.



Note Not everyone who requests a certificate from a commercial CA is given one. Many CAs require you to prove your identity before issuing you a certificate. Also, it can take anywhere from one day to two months to get approval. You are responsible for promptly providing all the necessary information to the CA.



Once you receive the certificate, you can install it. In the meantime, you can still use your server without SSL.


Installing a Non-VeriSign Certificate

When you receive your certificate back from the CA, it will be encrypted with your public key so that only you can decrypt it. After you enter the correct password for your trust database, you will be able to decrypt and install your certificate.

There are three types of certificates:

  • Your own server's certificate to present to clients

  • A CA's own certificate for use in a certificate chain

    A certificate chain is a hierarchical series of certificates signed by successive certificate authorities. A CA certificate identifies a CA and is used to sign certificates issued by that authority. A CA certificate can in turn be signed by the CA certificate of a parent CA, and so on, up to a root CA.

  • A trusted CA's certificate



    Note If your CA doesn't automatically send you their certificate, you should request it. Many CAs include their certificate in the email with your certificate, and your server installs both certificates at the same time.



When you receive a certificate from the CA, it will be encrypted with your public key so that only you can decrypt it. The server will use the key-pair file password you specify to decrypt the certificate when you install it. You can either save the email somewhere accessible to the server, or copy the text of the email and be ready to paste the text into the Install Certificate form, as described here.

To install a certificate from CAs other than VeriSign, perform the following steps:

  1. Access App Server Instances and select the server instance.

  2. Access Security.

  3. Select Certificate Management.

  4. Click the Install link.

    The Install a Server Certificate is displayed.

  5. Select the type of certificate you are installing:

    • This Server—for a single certificate associated only with your server

    • Server Certificate Chain—for a CA's certificate to include in a certificate chain

    • Trusted Certificate Authority (CA)—for a certificate of a CA that you want to accept as a trusted CA for client authentication

  6. Select the cryptographic module from the drop-down list.

  7. Enter the password for your key-pair file.

  8. Leave the name for the certificate field blank if it will be the only one used for this server instance, unless:

    • Multiple certificates will be used for virtual servers. In this case, enter a certificate name unique within the server instance.

    • Cryptographic modules other than internal are used. In this case, enter a certificate name unique across all server instances within a single cryptographic module.

    If a name is entered, it will be displayed in the Manage Certificates list, and should be descriptive. For example, "United States Postal Service CA" is the name of a CA, while "VeriSign Class 2 Primary CA" describes both a CA and the type of certificate.



    Note When no certificate name is entered, the default value is applied.



  9. Select either:

    • Message is in this file. In this case, enter the full pathname to the saved email

    • Message text (with headers). In this case, paste the email text.

      If you copy and paste the text, be sure to include the headers "Begin Certificate" and "End Certificate," including the beginning and ending hyphens.

  10. Click OK.

  11. Select one:

    • Add Certificate—to install a new certificate.

    • Replace Certificate—to install a certificate renewal.

The certificate is stored in the server's certificate database. The file name will be <alias>-cert7.db. For example:

https-serverid-hostname-cert7.db



Migrating Certificates When You Upgrade

If you are upgrading from an Enterprise Server 3.x, you will need to migrate your trust and certificate databases. Make sure that Sun Java (tm) System Application Server 7 Administration Server user has read and write permissions on the old 3.x database files. The files are <alias>-cert.db and <alias>-key.db, located in the <3.x_instance_dir>/config directory.

Sun Java (tm) System Web Server certificate files should work without change if you move them to the config directory for the instance.

Key-pair files and certificates are migrated only if your server has security enabled. You can also migrate keys and certificates by themselves using the Security tabs in the Administration Server.

The entire trust database associated with the server instance is migrated. All the CAs listed in your previous database are migrated to the new Sun Java (tm) System Application Server database.



Note If duplicate CAs occur, use the previous CA until it expires. Do not attempt to delete duplicate CAs.



The following topics address certificate migration:


Migrating a Certificate

To migrate a certificate, perform the following steps:

  1. Access App Server Instances and select the server instance.

  2. Access Security.

  3. Select Certificate Management.

  4. Click the Migrate link.

    The Migrate a 3X Cert page is displayed.

  5. Enter the 3.x Server Root.

  6. Enter the Alias.

  7. Enter the Password.

  8. Click OK.


Using the Built-in Root Certificate Module

The dynamically loadable root certificate module included with the Sun Java (tm) System Application Server contains the root certificates for many CAs, including VeriSign. The root certificate module simplifies upgrading your root certificates. To install well-known CA certificates, you can update the root certificate module file to a newer version as it becomes available through future versions of the Sun Java (tm) System Application Server, or in service packs.

Because the root certificate is implemented as a PKCS11 cryptographic module, you can never delete the root certificates it contains; the option to delete will not be offered when managing these certificates. To remove the root certificates from your server instances, you can disable the root certificate module by deleting the following in the server's alias file:

  • libnssckbi.so (on most Unix platforms)

  • libnssckbi.sl (on HP-UX)

  • nssckbi.dll (on Windows)

If you later want to restore the root certificate module, you can copy the extension from bin/https/lib (Unix and HP) or bin\https\bin (Windows) back into the alias subdirectory.



Note You can modify the trust information of the root certificates. The trust information is written to the certificate database for the server instance being edited, not back to the root certificate module itself.





Managing Certificates



You can view, delete, or edit the trust settings of the various certificates installed on your server. This includes your own certificate and certificates from CAs. Certificate information includes the owner and who issued it.

Trust settings allow you to set client trust or unset server trust. For LDAP server certificates, the server must be trusted.

To manage certificates, perform the following steps:

  1. Access App Server Instances and select the server instance.

  2. Access Security.

  3. Select Certificate Management.

  4. Click the Manage link.

    • If you are managing a certificate for a default configuration using the internal cryptographic module, a list of all installed certificates with their type and expiration date is displayed. All certificates are stored in the instance_dir/config directory

    • If you are using an external cryptographic module, such as a hardware accelerator, you will first need to enter your password for each specific module and click OK. The certificate list will update to include certificates in the module.

  5. Click the Certificate Name you want to manage.

    An Edit Server Certificate page is displayed with management options for that type of certificate.

  6. In the Edit Server Certificate window you may select:

    • For certificates obtained internally—Delete Certificate or Quit

    • For CA certificates—Set client trust, Unset server trust, or Quit



      Note Only CA certificates will allow you to set or unset client trust. Some external cryptographic modules will not allow certificates to be deleted.



  7. You are prompted to confirm your edits; select OK or Cancel.



Managing CRLs and CKLs

A certificate revocation list (CRL) and compromised key list (CKL) publishes any certificates and keys that either client users or server users should no longer trust. Typical situations include:

  • If data in a certificate changes, for example, a user changes offices or leaves the organization before the certificate expires, the certificate is revoked, and its data appears in a CRL.

  • If a key is tampered with or otherwise compromised, the key and its data appear in a CKL.

Both CRLs and CKLs are produced and periodically updated by a CA. As the administrator, you can install new CRLs or CKLs that you obtain from the CA, or delete existing CRLs or CKLs from your system.

The following topics address managing CRLs and CKLs:


Installing a CRL or CKL

To obtain a CRL or CKL from a CA, perform the following steps:

  1. Obtain the CA's URL for downloading CRLs or CKLs.

  2. Enter the URL in your browser to access the site.

  3. Follow the CA's instructions for downloading the CRL or CKL to a local directory.

  4. In the Admin interface, access App Server Instances and select the server instance.

  5. Access Security.

  6. Select CRL/CKL.

  7. Click the Install link.

    The Install a Certificate Revocation List/Compromised Key List page is displayed.

  8. Select one:

    • Certificate Revocation List

    • Compromised Key List

  9. Enter the full pathname to the associated file.

  10. Click OK.

    • If you selected Certificate Revocation List, the Add Certificate Revocation List page appears listing CRL information.

    • If you selected Compromised Key List, the Add Compromised Key List page appears listing CKL information.

      Note If a CRL or CKL list already exists in the database, a Replace Certificate Revocation List or Replace Compromised Key List page appears. In this case, click Replace.



  11. Click Add.

  12. Click OK.


Deleting a CRL or CKL

To delete a CRL or CKL, perform the following steps:

  1. Access App Server Instances and select the server instance.

  2. Access Security.

  3. Select CRL/CKL.

  4. Click the Manage link.

    The Manage a Certificate Revocation List/Compromised Key List page is displayed with all installed Server CRLs and CKLs listed along with their expiration dates.

  5. Select a Certificate Name from either the Server CRLs or Server CKLs list.

  6. Select one:

    • Delete CRL

    • Delete CKL


Previous     Contents     Index     DocHome     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated July 12, 2002