Taking Advantage of NetWare's Public Key Infrastructure with Novell Certificate Server 2.0
Articles and Tips: article
Technical Writer
Novell Developer Information
01 Jan 2000
This AppNote discusses the new Certificate Server that allows NetWare 5 customers to generate their own security certificates and manage them in NDS.
- Introduction
- Public Key Cryptography
- Novell Certificate Server Components
- Setting Up Novell Certificate Server
- Managing Novell Certificate Server
- Conclusion
Introduction
Novell Certificate Server 2.0 is an enhancement to the set of Public Key Infrastructure Services (PKIS) that originally shipped with NetWare 5. In the NetWare 5 release, the product was called PKIS 1.0, or just PKIS. PKIS 1.0 provided users with the ability to freely mint an unlimited number of digital certificates for servers with the primary purpose of enabling these servers to engage in Secure Sockets Layer (SSL) sessions. The intent of Novell Certificate Server 2.0 is to provide PKI natively integrated into Novell Directory Services (NDS) that supports the minting, issuing, and managing of both user and server certificates, and to provide a single point of management and administration for an organization operating their own Certificate Authority (CA).
In Novell Certificate Server 2.0, user certificates and private keys are generated on the server and stored securely in NDS, then downloaded over an encrypted session to the user's workstation to enable S/MIME digital certificates for e-mail clients for sending and receiving digitally signed and encrypted e-mail. User certificates can also be used for user authentication against servers supporting this feature.
Currently, in order to use certificates, companies must purchase encryption key pairs and certificates from a CA, which can become expensive. Novell Certificate Server allows customers to create and manage certificates specific to their organization, and the product is free and available for download at http://www.novell.com/products/certserver.
This AppNote provides an introduction to Novell Certificate Server 2.0, how to set it up for cryptography services, and how to manage its services.
Public Key Cryptography
As an introduction, this section provides a look at some current public key cryptography issues. The PKI technology included in Novell Certificate Server is intended to provide secure electronic data transmissions by the use of key pairs and certificates. In order for transmissions to be secure, they need to be authenticated and encrypted by the recipient and sender. This is done through the use of mathematically-related pairs of digital codes or keys. Each pair of keys consists of a public key and private key, generated by a public key cryptography system. Key pairs are only used in combination with one another, ensuring security.
The public key is open to any party needing validation to a signature from a key pair owner or for privately communicating with the owner. Using cryptography-enabled software and the public key allows:
Validation of signatures from the key pair owner.
Encryption of data for private transmission to the key pair owner.
The private key is closely guarded by either the owner or the cryptography system acting on the owner's behalf. Using cryptography-enabled software and the private key allows:
Creation of digital signatures.
Decryption of data that was encrypted by the key pair owner.
In a real-world situation, if a sender and receiver know and trust each other, they can simply exchange public keys and establish secure data transmission by using each other's public keys and their own private keys. To prove their identities to other parties in a public key cryptography environment, senders or receivers can enlist the services of a trusted third-party known as a CA.
The primary purpose of the CA is to verify that a party is who or what it claims to be and then to issue a public key certificate for that party to use. The public key certificate verifies that the public key contained in the certificate belongs to the party named in the certificate. It's very much like a passport issued by the government, that can be used by the issue to identify himself or herself to others with security measures that require identification. Without the certificate or passport, access or privileges are denied.
Novell Certificate Server Components
This section discusses the primary components and capabilities of the Novell Certificate Server 2.0. The public key cryptography components available in the Novell Certificate Server 2.0 include the Novell Certificate Server and Novell International Cryptographic Infrastructure (NICI). Combined, these components help network administrators meet the unique challenges that public key cryptography presents by providing the following capabilities:
Certificate Ownership. You can create an Organizational CA within your NDS tree, allowing you to issue an unlimited number of user and server certificates. You can also use the services of an external CA, or use a combination of both as your needs dictate.
Better Cost Management. Because you can create an Organizational CA, generate key pairs, and issue public key certificates through the Organizational CA, you have greater control over the costs of obtaining key pairs and managing public key certificates.
Public Key and Certificate Protection. Your public keys and public key certificates can be openly available to users and also amply protected against tampering because the key pairs are stored in NDS and take advantage of NDS replication and access control features.
Private Key Limits to Specific Software Routines. Private keys are encrypted by NICI and made available only to the software routines using them for signing and decrypting operations.
Secure Backup of Private Keys. Private keys are encrypted by NICI, stored in NDS, and backed up using standard NDS backup utilities.
Central Administration of Certificates. Using a ConsoleOne snap-in allows you to centrally manage certificates issued from either a Novell CA or from the Entrust CA product.
User Administration of Personal Certificates. Users can use the Novell Certificate Console utility to export keys for use in cryptography- enabled applications without system administrator intervention.
Support of Popular E-mail Clients and Browsers. Novell Certificate Server allows you to create and manage user certificates for securing e-mail and supports GroupWise 5.5, Microsoft Outlook98 and Outlook2000, Netscape Messenger, and other popular e-mail clients. It's also compatible with both Netscape Navigator and Microsoft Internet Explorer browsers.
Note: The cryptography services available in this product depend on the country in which your network is located. Novell Certificate Server will not function if cryptography services are not fully installed. For example, the mass-market exportable version of NICI is limited to 512-bit RSA keys for data encryption. The U.S. and Canadian version of NICI supports key sizes up to 2,048 bits for all types of keys. To ensure that you have the highest level of cryptography services available in your area, contact your Novell Authorized Reseller.
Novell Certificate Server
Novell Certificate Server consists of the PKI.NLM (NetWare) and a snap-in module to ConsoleOne, which is the administration point for Novell Certificate Server. Novell Certificate Server allows you to request, manage, and store public key certificates and their associated key pairs in the NDS tree, and to establish an Organizational CA that is specific to your NDS tree and organization.
Novell Certificate Server derives all supported cryptography and signature algorithms, as well as supported key sizes from NICI. Therefore, a single version of Novell Certificate Server can be used in installations throughout the world.
After installing Novell Certificate Server, you will manage it using ConsoleOne running on a client. (Novell Certificate Server cannot be managed using ConsoleOne running on a NetWare server console.) Through the client side ConsoleOne, you can perform the following tasks:
Create an Organizational CA for Your Organization. During the installation, you can elect to create an Organizational CA if one does not already exist in the NDS tree. Using ConsoleOne, you may also create or recreate the Organizational CA after the installation is completed.
The Organizational CA object contains the public key, private key, certificate, certificate chain, and other configuration information for the Organizational CA. The Organizational CA object resides in the Security container in NDS. Once a server is configured to provide the certificate authority service, it performs that service for the entire NDS tree.
Create a Server Certificate Object for Each Cryptography-Enabled Application. During the installation, you can elect to create a Server Certificate object. You may also create other Server Certificate objects after the installation is completed.
The Server Certificate object contains the public key, private key, certificate, and certificate chain that enables SSL security services for server applications. A server can have many Server Certificate objects associated with it. Any cryptography-enabled applications running on a particular server can be configured to use any one of the Server Certificate objects for that server. Multiple applications running on a given server can use the same Server Certificate object; however, a Server Certificate object cannot be shared between servers.
You can create Server Certificate objects only in the container where the server resides. If the Server object is moved, all Server Certificate objects belonging to that server must be moved as well. You should not rename a Server Certificate object. You can determine which Server Certificate objects belong to a server by searching for the server's name in the Server Certificate object name.
Note: The key pair stored in the Server Certificate object is referenced by the name you enter when the key pair is created. The key pair name is not the name of the Server Certificate object. When configuring cryptography-enabled applications to use key pairs, you reference those keys by their key pair name, not by the Server Certificate object name.
Request Public Key Certificates from the Organizational CA or an External CA. A public key certificate contains a public key, a name, and a signature. The signature is created by the CA and provides a cryptographic binding between the public key and a name.
Public key certificates contain, at minimum, a public key, a subject name, an issuer name, a validity period, a serial number, and a certificate authority- generated signature. They may also contain specific extensions, for example, to further clarify the use of the certificate.
Create a User Certificate. A user certificate is intended to allow users to send and receive digitally signed and encrypted e-mail using the S/MIME standard. Users have access to their own user certificates and private keys, which can be used for authentication, data encryption/decryption, digital signing, and secure e-mail.
Generally, only the CA administrator has sufficient rights to create user certificates. However, only the user has rights to export or download the private key from NDS. Any user can export any other user's public key certificate. The user certificate is created from the Security tab of the user's property page and is signed by the Organizational CA. Multiple certificates can be stored on the user's object.
Create a Trusted Root Container. A trusted root provides the basis for trust in public key cryptography. Trust roots are used to validate certificates signed by the CA. Trusted roots enable security for SSL and secure e-mail and certificate-based authentication. A Trusted Root Container is an NDS object that contains Trusted Root objects. You must create the Trusted Root Container in the Security Container.
Create a Trusted Root Object. A Trusted Root object is an NDS object that contains a CA's Trusted Root certificate that is known to be authentic and valid. The Trusted Root Certificate can be exported and used as needed. Applications that are configured to use the Trusted Root Certificate will consider a certificate valid only if it has been signed by one of the CAs in the Trusted Root Container. The Trusted Root object must reside in a Trusted Root Container.
Novell International Cryptographic Infrastructure
NICI is the underlying cryptographic infrastructure that provides the cryptography for Novell Certificate Server, Novell Authentication Service, and other applications. NICI must be installed on the server in order for Novell Certificate Server to work properly, because all Novell services that consume cryptography are written to NICI. NICI version 1.3.1 ships with Novell Certificate Server. If you are already running NICI, you need to upgrade if it's a later version than 1.3.0.
To determine which NICI version you are running, at the NetWare console, type: "MODULES XENG*". If you see "US/Canada", you are running with full-strength cryptography that provides key sizes up through 2048 bits. If you see "WorldWide", you are running with exportable cryptography that provides key sizes up through 512 bits. If you see "NULL", you are running with no cryptography; PKIS will not run with Null cryptography.
Note: The XENG file is controlled by US Law. DOMXENG.XLM must not be provided to Novell offices or customers outside the US or Canada. EXPXENG.XLM may be provided world wide unless a local regulations disallow its import (currently France). Each NetWare media box contains an appropriate XENG file.
Also, if you have NICI version 1.3.0 or greater, you can find out what version you are running by loading NWCONFIG at the server console. Select "Product Options" from the menu, then select "View/Configure/Remove Installed Products". If you see NICIU0 listed, this means you are running domestic-grade NICI and that it needs to be removed. If you see NICIW1 listed, this means you are running export-grade NICI and it can be upgraded to version 1.3.1.
Setting Up Novell Certificate Server
This section explores some of the setup options and requirements of the Novell Certificate Server including a listing of the system requirements, how to decide which type of CA to use, how to create an Organizational CA object, how to create a Certificate Server object, and how to configure cryptography-enabled applications. For information about installing Novell Certificate Server, see the online product documentation.
Note: Novell Certificate Server can be installed either as a standalone or as an integrated product installation. This section covers only the standalone setup options; for information about an integrated installation, see the installation instructions for that specific product.
System Requirements
Novell Certificate Server 2.0 requires installation on a NetWare 5.01 server with 60 MB of free hard disk space and the following system requirements:
Server
NetWare 5 with Support Pack 1, 2, or 3 installed
NICI 1.3.0 or 1.3.1 (exportable NICI v1.3.1 is included with Novell Certificate Server 2.0)
The version of NDS that shipped with NetWare 5, or NDS-SE or above (NDS 8 is not yet supported)
Administrator Workstation
Windows NT version 4 with Service Pack 3 or above, or Windows 95/98
Novell Client for NT version 4.5 or above, or Novell Client for DOS/Windows version 3.0 or above
ConsoleOne 1.2b13 (included with Novell Certificate Server 2.0 and also downloadable from http://www.novell.com/download/#Management)
User Workstation
Windows NT version 4.0 with Service Pack 3 or later, or Windows 95/98
Novell Client for NT version 4.5 or above, or Novell Client for DOS/Windows version 3.0 or above
Internet Explorer version 4 or 5 and GroupWise 5.5 Enhancement Pack Client, Internet Explorer version 4 and Outlook98, Internet Explorer 5 and Outlook2000, or Netscape Messenger 4.6 or later
Deciding Which CA to Use
There are two types of CAs your organization can use: an Organizational CA or an external CA (or both simultaneously). Both CAs allow you to manage public key certificates, Server Certificate objects, and their associated components, as well as sign public key certificates, but during the Server Certificate object creation process, you need to decide which CA will sign the Server Certificate.
The Organizational CA is specific to your organization and uses an organizational-specific public key for signing operations. The private key is created when you create the Organizational CA. An external CA is managed by a third-party outside of the NDS tree, such as the services offered by VeriSign.
Novell Certificate Server allows you to create certificates for both servers and end users. Server Certificates can be signed by either the Organizational CA or by an external or third-party CA. User certificates can be signed by only the Organizational CA for this release only.
Listed in the following table are some of the benefits offered by each CA type.
|
Organizational CA Benefits
|
External CA Benefits
|
|
Compatibility. Is compatible with other applications that share a common trusted root in NDS, including BorderManager, LDAP Services, and future products using Novell security. Cost Savings. Lets you create an unlimited number of public key certificates at no cost; obtaining a single public key certificate through an external CA might cost hundreds of dollars. Component of Complete Solution. Allows you to use the complete cryptographic system built into NDS without having to rely on any external services. Attribute and Content Control. An Organizational CA is managed by the network administrator who decides the public key certificate attributes such as certificate life span, key size, and signature algorithm. |
Liability. Offers possibly some liability protection if, through the fault of the CA, your private key was exposed or your public key certificate was misrepresented. Availability. May be more widely available and compatible with applications outside of NDS. |
Creating an Organizational CA Object
The Novell Certificate Server installation process, by default, will create the Organizational CA for you. You will be prompted to specify an Organizational CA name. When you finish, the Organizational CA will be created with the default parameters and placed in the Security container. If you want more control over the creation of the Organizational CA, you can create the Organizational CA manually or recreate it if you delete it.
The process to create an Organizational CA object in NDS is similar to creating any other object. You need to be logged in to the NDS tree as an administrator with appropriate rights. Then, within the Security container you can create the object using ConsoleOne (the schema name of the NDS object is NDSPKI:Certificate Authority).
Note: There can be only one Organizational CA for the entire NDS Tree.
During the creation process, you will be prompted to name the Organizational CA object and to choose a server on which the CA service will run. Select a server that is physically secure, that will be available when needed to perform signing operations, that runs a protocol that is compatible with the other servers in your organization (for example, IP, IPXTM, IP/IPX), and that only runs software that you trust. It is important that your server meet these conditions, because the Organizational CA object is the centerpiece of your PKI system and if the server that contains the object is compromised, your entire PKI system could be compromised as well.
Creating Server Certificate Objects
Server Certificate objects are created in the container that holds the server's NDS object. Depending on your needs, you may create a separate Server Certificate object for each cryptography-enabled application on the server. Or you may create one Server Certificate object for all applications used on that server.
The Novell Certificate Server installation process can create a Server Certificate object for you. You will be prompted to specify a Server Certificate object name. When you finish, the Server Certificate object will be created with the default parameters and placed in the container where the target server resides. If you want more control over the creation of the Server Certificate object, you can create it manually.
The process to create a Server Certificate object in NDS is similar to creating any other object. You need to be logged in to the NDS tree as an administrator with appropriate rights. Then, within the container that contains the server that will run your cryptography-enabled applications, you can create the object using ConsoleOne (the schema name of the NDS object is NDSPKI:Key Material).
During the Server Certificate object creation process, you will be prompted to name the key pair and choose the server that the key pair will be associated with. The Server Certificate object is generated by Novell Certificate Server and its name is based on the key pair name that you choose. If you choose the Custom creation method, you will also be prompted to specify whether the Server Certificate object will be signed by your organization's Organizational CA or by an external CA. If you decide to use your organization's Organizational CA, the server that the Server Certificate object is associated with must be able to communicate with the server that hosts the Organizational CA, or it must be the same server. These servers must be running the same protocol (IP/IPX).
If you decide to use an external CA to sign the certificate, the server that the Server Certificate object is associated with will generate a certificate signing request that you will need to submit to the external CA. After the certificate is signed and returned to you, you will need to install it into the Server Certificate object, along with the trusted root for the external CA. Once you have created the Server Certificate object, you can configure your applications to use them. Keys are referenced in the application's configuration by the key pair name that you entered when you created the Server Certificate object.
Configuring Cryptography-Enabled Applications
Once you have configured Novell Certificate Server, you must configure your individual cryptography-enabled applications so that they can use the Novell certificates that you created. The configuration procedures are unique to the individual applications, so it is recommended that you consult the application's documentation for specific instructions.
Managing Novell Certificate Server
Most of the common Novell Server Certificate management tasks can be categorized into CA tasks, Server Certificate Object tasks, User Certificate tasks, and Trusted Root Certificate Object tasks. This section looks at some of these common tasks as it relates to successfully managing your certificate server.
Certificate Authority Tasks
Common CA tasks include issuing certificates, viewing the Organizational CA's properties, and exporting self-signed public key certificates.
Issuing a Public Key Certificate. By issuing a public key certificate, you can generate certificates for cryptography-enabled applications that do not recognize Server Certificate objects. Your Organizational CA works the same way as an external CA, in that it has the ability to issue certificates from Certificate Signing Requests (CSRs). You can issue certificates using your Organizational CA when a user sends a CSR to you for signing. The user requesting the certificate can then take the issued certificate and import it directly into the cryptography-enabled application.
Viewing the Organizational CAs Properties. ConsoleOne allows you to view the Organizational CA's properties. Besides the NDS rights and properties that are viewable with any NDS object, you can also view properties specific to the Organizational CA, including the properties of the public key certificate and the self-signed certificate associated with it. These properties provide you with the information that you need to perform any task related to this object.
Exporting the Organizational CA's Self-Signed Public Key Certificate. The self-signed public key certificate can be used for verifying the identity of the Organizational CA and the validity of a certificate signed by the Organizational CA. From the Organizational CA's property page, you can view the certificates and properties associated with this object. From the self-signed certificate property page, you can export the self-signed certificate to a file for use in cryptography-enabled applications.
The self-signed certificate that resides in the Organizational CA provides the same verification of the CA's identity as a trusted root certificate that is exported from a server certificate. Any service that recognizes the Organizational CA as a trusted root will accept the self-signed or trusted root certificate as valid.
Server Certificate Object Tasks
Common Server Certificate Object management tasks include: importing a public key certificate, exporting a trusted root certificate, deleting a Server Certificate object, and viewing any of the Server Certificate object's properties.
Importing a Public Key Certificate. You import a public key certificate after you have issued a CSR and the CA has returned a signed public key certificate to you. This task applies when you have created a Server Certificate object using the Custom option with the External CA signing option.
The CA will return two certificates: a signed public key certificate, which verifies your identity, and a trusted root certificate, which verifies the CA's identity. These certificates can then be imported and stored in the Server Certificate object. The cryptography-enabled application that is linked to this Server Certificate object can then use this information to perform secure transactions.
Exporting a Trusted Root Certificate. You export a trusted root certificate to a file so that a client (such as an Internet browser) can use it to verify the certificate chain sent by a cryptography-enabled application. You can export a trusted root certificate in two file formats: DER encoded (.DER) and Base64 encoded (.B64). The .CRT extension can also be used for DER-encoded certificates.
If you export to the system clipboard, you can then paste the certificate directly into a cryptography-enabled application, if supported. The certificate exists on the clipboard in Base64 encoded format. If you export to a file, you can specify either format. DER encoded format is the default format. It is the same as CRT format and can be used with applications that accept CRT formats.
Deleting a Server Certificate Object. You should delete a Server Certificate object if you suspect that the private key has been compromised, if you no longer want to use the key pair, or if the trusted root in the Server Certificate object is no longer trusted. You can re-create a Server Certificate Object, but you will have to reconfigure any applications that referenced the old object.
Note: Once the Server Certificate object is deleted, you will not be able to recover it. Before you delete this object, make sure that no cryptography-enabled applications still need to use it.
Viewing a Server Certificate Object's Properties. ConsoleOne allows you to view the Server Certificate object's properties. Besides the NDS rights and properties that are viewable with any NDS object, you can also view properties specific to the Server Certificate object, including the properties of the public key certificate and the trusted root certificate associated with it, if they exist. These properties provide you with the information you need to perform any task related to this object.
User Certificate Tasks
Common user certificate management tasks include viewing a user certificate's properties and exporting a user certificate using ConsoleOne or the Novell Certificate Console.
Viewing a User Certificate's Properties. ConsoleOne allows you to view the user certificate's properties. Besides the NDS rights and properties that are viewable with any NDS object, you can also view properties specific to the user certificate, including the issuer, the certificate status, the private key status, and the validation period. These properties provide you with the information you need to perform any task related to this object.
Exporting a User Certificate Using ConsoleOne. This task allows a user or network administrator to use ConsoleOne to export a user certificate for use in secure e-mail. The user certificate can be exported with or without the private key. The network administrator or another user with sufficient rights can export a user certificate. However, only the user who owns the user certificate can export the user certificate with the private key. No other user, not even the network administrator, has rights to export a user's private key.
Exporting a User Certificate Using Novell Certificate Console. This task allows a user to use Novell Certificate Console to export a user certificate for use in secure e-mail. Only the user can export his or her private key. Again, no other user, not even the network administrator, has rights to export a user's private key.
Note: You can also configure ZENworks to automate the distribution of Novell Certificate Console by using the ZENworks files that ship with Novell Certificate Server. The file CERTCNSL ZENWORKS.EXE, found in the install directory\CERTCONSOLE directory, is a self-extracting file that contains all the files you will need to distribute Novell Certificate Server using ZENworks.
Trusted Root Certificate Object Tasks
Common Trusted Root Certificate object management tasks include viewing a trusted root object's properties and replacing a trusted root certificate.
Viewing a Trusted Root Object's Properties. ConsoleOne allows you to view the Trusted Root object's properties. Besides the NDS rights and properties that are viewable with any NDS object, you can also view properties specific to the Trusted Root object, including the issuer, the certificate status, and the validation period. These properties provide you with the information you need to perform any task related to this object.
Replacing a Trusted Root Certificate. This task allows you to replace a Trusted Root Certificate that is stored in the Trusted Root object. This task should be performed if the Trusted Root Certificate has expired. You can replace a Trusted Root Certificate from the Trusted Root object's property page.
Conclusion
Leveraging NDS technology, the Novell Certificate Server enables support for even the largest demands of digital signatures and ensures a higher level of security by storing the certificate data in a secure, central location in NDS that only the user can download. The Novell Certificate Server also enables network administrators to efficiently manage both in-house and third-party digital certificates that companies may wish to purchase.
Developers can also leverage Novell Certificate Server technology by obtaining the software developer kit (SDK) through Novell Developer Services. Software developers can also take advantage of NDS functionality to further enhance or customize their security solutions and easily build on the certificates issued by Novell Certificate Server without the need to re-write their own technology.
For additional information about this and other Novell security products and technologies, see the following Web sites:
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.