Red Hat Certificate System 8.1

Using End User Services

for regular users to request and retrieve certificates

Ella Deon Lackey

dlackey@redhat.com

Legal Notice

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

All other trademarks are the property of their respective owners.

1801 Varsity Drive
Raleigh, NC 27606-2072 USA
Phone: +1 919 754 3700
Phone: 888 733 4281
Fax: +1 919 754 3701

January 31, 2012

Abstract

This guide contains easy to follow information for end users who use Red Hat Certificate System certificate authority and registration authority services to generate or submit certificate requests, check on request status, receive certificates, and revoke certificates.

1. A Look at End User Services in Red Hat Certificate System

1.1. About Certificates and Cryptography
1.2. About CA Services
1.3. About RA Services
1.4. Supported Web Browsers
1.5. Supported Charactersets
1.6. Configuring Internet Explorer to Enroll Certificates

2. Getting and Managing Certificates through CA Services

2.1. Opening the CA Services Page
2.2. Generating Certificate Requests
2.3. Requesting Certificates
2.4. Checking on Your Request Status
2.5. Retrieving Your Certificates
2.6. Listing and Searching for Certificates
2.7. Renewing Certificates
2.8. Revoking Certificates
2.9. Downloading CA Certificates and Certificate Chains

3. Getting and Managing Certificates through RA Services

3.1. Opening the RA Services Page
3.2. Requesting Certificates
3.3. Checking on Your Request Status
3.4. Retrieving and Importing Certificates
3.5. Renewing User Certificates

4. Additional Reading

5. Giving Feedback

6. Document History

1. A Look at End User Services in Red Hat Certificate System

Red Hat Certificate System provides a simple way for people to obtain certificates that they need to protect common Internet-based actions, like sending email, logging into a computer, or accessing a protected website. Any user can access Certificate System's web-based certificate management interface to request or receive a certificate.

1.1. About Certificates and Cryptography

Red Hat Certificate System provides a way for a company or group to create and manage certificates locally.

A certificate is a file which proves the identity of a person, server, router, website, or other entity. Certificates can also be used to encrypt and decrypt information; this is a vital function which protects sensitive communication — from online shopping to email — by safely encoding the traffic using mathematical algorithms to create a cipher.

A certificate is part of an overall strategy for secure (encrypted) communication. Some web protocols such as Secure Sockets Layer (SSL) and Transport Layer Security (TLS) use encryption to secure Internet communications, as do VPNs, some intranets, email, and web browsers.

Secure communications are built around an SSL handshake. An SSL handshake is when a server reaches out to a client (user) with some proof of its identity, such as a certificate; this is server authentication. The client can then accept that certificate to continue with the connection. The server may require some proof back from the user to verify his identity; this is client authentication. After the server and client are shown to be authentic, then they can continue with their transactions.

The transactions are encoded using agreed upon methods, called ciphers. The cipher is used in conjunction with a special number, called a key, to encrypt and decrypt the data being sent. A certificate, along with identifying the user and the authority which issued it, defines what kind of ciphers it supports and the public key for encrypting information.

There are a number of different ways that the information can be encrypted for safe sending and then decrypted for safe reading: asymmetric keys, symmetric keys, and shared keys. A key, in broad terms, is combined with a mathematical algorithm to scramble data; if someone knows the matching key, then they can use it to unscramble the data. A key, then, locks and unlocks data. A public key is known to both groups in a secure connection, while a private key is held by one group. The public key encrypts data; the private key is used to decrypt it.

A certificate is created out of several pieces of information:

The identity of the entity (such as its name)
A public key
The name and digital signature of the certificate authority which issued the certificate
The day that the certificate expires (called the validity period)
A serial number

This information creates a fingerprint for the certificate.

Figure 1. Certificate Fingerprint

Some clients may require additional information, such as the issuing authority's certificate (CA certificate). The CA certificate verifies the server which issued the user's certificate and provides some key information. Sometimes, a series of authorities issues certificates; Server 1 issues a certificate to Server 2 which issues a certificate to Server 3. All of those successive CA certificates can be downloaded and installed together; that's a certificate chain.

A certificate is issued or enrolled by a certificate authority (CA). (In Red Hat Certificate System, the CA is performed by a system called the Certificate Manager.)

Figure 2. The Process for Issuing a Certificate

A user first generates a certificate request by supplying certain information.
This request is then given to the CA, and the CA validates that it is a legitimate request. This can happen in different ways: a real person may review it, it could be guaranteed automatically, or it could require that the user supply some other kind of credentials, such as login information for a local directory or an existing certificate.
Assuming that the request is approved, the certificate is generated. A Certificate System Certificate Manager uses certificate profiles to define the settings for a certificate. The profiles, to users, are simple forms available through the CA services pages. In the Certificate Manager server, these profiles define all kinds of information about the certificate, such as how long the certificate is valid, what kind of ciphers it allows, what kind of certificate it is and how it can be used, and limits set on the certificate information.
The information in the certificate request must match the requirements in the certificate profile; otherwise, the certificate is rejected by the Certificate Manager.
If the certificate request conforms to the profile, then the Certificate Manager signals the browser to generate the public/private key pair.
After generating the keys, the Certificate Manager generates the certificate.
The user retrieves the new certificate. This varies depending on how the local Red Hat Certificate System is setup; the user may receive an email notification or the certificate could be immediately available through the Certificate Manager services page. The certificate can always be retrieved by searching the request ID and following the status link.
The certificate can be imported into a web browser, email program, site, server, router, or other client (depending on the type of certificate) and it's ready for use.

After the certificate is created, it is valid for a certain amount of time, until the expiration date. Some types of certificates can be renewed, which creates a new certificate using the same key pair, but with a new expiration date and serial nu,ber. The renewed certificate is functionally identical to the original certificate.

Alternatively, there can be a reason to invalidate a certificate before its expiration date, maybe because it was compromised or because of a change in the user's situation. In that case, the certificate can be revoked before its expiration date. When a certificate is revoked, the Certificate Manager adds it to a list of revoked certificates called a certificate revocation list (CRL). When a certificate is validated during authentication, the server checks its validity date (to make sure its current) and its revocation status (by checking the CRL published by the CA).

1.2. About CA Services

A certificate authority (CA) is a trusted entity that issues certificates, verifies the certificate validity, renews certificates, and publishes certificate revocation lists (CRLs). The CA performs all certificate management functions. In Red Hat Certificate System, the CA is called the Certificate Manager.

The Certificate Manager's web services pages offer a number of different services for users:

Submit requests for a large number of different certificate types through different certificate enrollment forms (listed in Table 1, “Available Certificate Profiles”)
Check the status of certificate requests
List all submitted certificate requests
Perform basic and advanced searches of certificate requests, issued certificates, CRLs, and expired certificates
Retrieve and import issued certificates
Search CRLs for revoked certificates
Download, import, or view CRLs
Download, import, or view CA certificates and CA certificate chains

The Certificate Manager's end user web services offer a large number of default certificate submission forms (called certificate enrollment forms or certificate profiles). These forms allow you to submit new certificate requests to the CA. Along with the default profiles in Table 1, “Available Certificate Profiles”, custom profiles can also be created that are specific for your group.

The Certificate Manager web services have a very flexible search feature to list and search all certificate requests. The CA web services also allow you to import CA certificates and CA chains, revoke certificates and check certificate revocation status, and import CRLs.

Table 1. Available Certificate Profiles

Profile Name	Description
Security Domain Administrator Certificate Enrollment	Enrolls Security Domain Administrator's certificates with LDAP authentication against the internal LDAP database.
Agent-Authenticated File Signing	This certificate profile is for file signing with agent authentication.
Agent-Authenticated Server Certificate Enrollment	Enrolls server certificates with agent authentication.
Manual Certificate Manager Signing Certificate Enrollment	Enrolls Certificate Authority certificates.
Signed CMC-Authenticated User Certificate Enrollment	Enrolls user certificates by using the CMC certificate request with CMC Signature authentication.
Directory-Authenticated User Dual-Use Certificate Enrollment	Enrolls user certificates with directory-based authentication.
Directory-Authenticated User Certificate Self-Renew profile	Renews user certificates which were previously enrolled with the caDirUserCert profile.
Manual User Signing & Encryption Certificates Enrollment	Enrolls dual user certificates. It works only with Netscape 7.0 or later.
Signed CMC-Authenticated User Certificate Enrollment	Enrolls user certificates by using the CMC certificate request with CMC Signature authentication.
Manual Security Domain Certificate Authority Signing Certificate Enrollment	Enrolls Security Domain Certificate Authority certificates.
Audit Signing Certificate Enrollment	Enrolls a signing certificate to use for signing audit logs; used automatically during any subsystem configuration, with the exception of the RA.
Security Domain DRM Storage Certificate Enrollment	Enrolls DRM storage certificates for DRMs within a security domain; used automatically during a DRM configuration.
Security Domain OCSP Manager Signing Certificate Enrollment	Enrolls Security Domain OCSP Manager certificates.
Security Domain Server Certificate Enrollment	Enrolls Security Domain server certificates.
Security Domain Subsystem Certificate Enrollment	Enrolls Security Domain subsystem certificates.
Security Domain Data Recovery Manager Transport Certificate Enrollment	Enrolls Security Domain Data Recovery Manager transport certificates.
Renew certificate to be manually approved by agents	Renews a certificate that was generated with the caUserCert profile and must be manually renewed by agents.
Manual OCSP Manager Signing Certificate Enrollment	Enrolls OCSP Manager certificates.
Other Certificate Enrollment	Enrolls other certificates.
Manual Registration Manager Signing Certificate Enrollment	Enrolls Registration Manager certificates.
One Time Pin Router Certificate Enrollment	Enrolls router certificates using an automatically-generated, one-time PIN that the router can use to retrieve its certificate.
Manual Server Certificate Enrollment	Enrolls server certificates.
Manual Log Signing Certificate Enrollment	Enrolls audit log signing certificates.
Simple CMC Enrollment	Enrolls user certificates by using the CMC certificate request with CMC Signature authentication.
Self-renew user SSL client certificates	Renews SSL client certificates issued by the caUserCert profile.
Temporary Device Certificate Enrollment	Enrolls temporary keys to be used by servers or other network devices on a token; used by the TPS for smart card enrollment operations. These are temporary keys, valid for about a week, and intended to replace a temporarily lost token.
Enrolls an encryption key on a token; used by the TPS for smart card enrollment operations. These are temporary keys, valid for about a week, and intended to replace a temporarily lost token.
Temporary Token User Signing Certificate Enrollment	Enrolls a signing key on a token; used by the TPS for smart card enrollment operations. These are temporary keys, valid for about a week, and intended to replace a temporarily lost token.
Token Device Key Enrollment	Enrolls keys to be used by servers or other network devices on a token; used by the TPS for smart card enrollment operations.
Token User MS Login Certificate Enrollment	Enrolls key to be used by a person for logging into a Windows domain or PC; used by the TPS for smart card enrollment operations.
Token User Encryption Certificate Enrollment	Enrolls an encryption key on a token; used by the TPS for smart card enrollment operations.
smart card token encryption cert renewal profile	Renews an encryption key that was enrolled on a token using the caTokenUserEncryptionKeyEnrollment profile; used by a TPS subsystem.
Token User Signing Certificate Enrollment	Enrolls a signing key on a token; used by the TPS for smart card enrollment operations.
smart card token signing cert renewal profile	Renews a signing that was enrolled on a token using the caTokenUserSigningKeyEnrollment profile; used by a TPS subsystem.
Manual TPS Server Certificate Enrollment	Enrolls TPS server certificates.
Manual Data Recovery Manager Transport Certificate Enrollment	Enrolls Data Recovery Manager transport certificates.
Manual User Dual-Use Certificate Enrollment	Enrolls user certificates.
Manual device Dual-Use Certificate Enrollment to contain UUID in SAN	Enrolls certificates for devices which must contain a unique user ID number (UUID) as a component in the certificate's subject alternate name extension.
Domain Controller	Enrolls certificates to be used by a Windows domain controller.

1.3. About RA Services

The Red Hat Certificate System Registration Authority (RA), similar to the Certificate Manager, can accept certificate requests. The RA doesn't issue or enroll the certificates; instead, it authenticates the entity making the request locally, then forwards the request to the CA to generate the certificate. The RA is in essence a load balancer for certificate management.

The RA web services page offers several different options:

Submit certificate requests and renew certificates (through enrollment forms listed in Table 2, “Available RA Certificate Profiles”)
Check the status of pending certificate requests
Retrieve issued certificates

The RA has fewer certificate enrollment options than the Certificate Manager, and the RA interface is more simple than the Certificate Manager's web services pages. The benefit of the RA interface is that it can be quicker to submit requests, receive approval, check request status, and retrieve issued certificates.

The RA is essentially a load balancer for a CA, since the CA still issues the certificates but the process of approving the certificate request is handled separately.

Table 2. Available RA Certificate Profiles

Profile Name	Description
User Enrollment	Enrolls and renews user certificates.
Server Certificate Enrollment	Enrolls server certificates.
RA Agent Enrollment	Enrolls certificates for RA agents.
SCEP Enrollment	Enrolls router certificates, complying with Cisco SCEP standards.

1.4. Supported Web Browsers

The services pages for the subsystems require a web browser that supports SSL. Two browsers are supported:

Mozilla Firefox 1.0 and higher
Microsoft Internet Explorer 6 and higher

NOTE

Browsers for Mac, such as Safari, and other types of web browsers, such as Opera, are not supported for the end-entities pages. This means that some operations may not complete successfully or forms may not be displayed properly.

If DNS is properly configured, then an IPv4 or IPv6 address can be used to connect to the services pages. For example:

https://1.2.3.4:9444/ca/services
https://[00:00:00:00:123:456:789:00:]:9444/ca/services

1.5. Supported Charactersets

Red Hat Certificate System fully supports UTF-8 characters in the CA end users forms for specific fields. This means that end users can submit certificate requests with UTF-8 characters in those fields and can search for and retrieve certificates and CRLs in the CA and retrieve keys in the DRM when using those field values as the search parameters.

Four fields fully-support UTF-8 characters:

Common name (used in the subject name of the certificate)
Organizational unit (used in the subject name of the certificate)
Requester name
Additional notes (comments appended by the agent to the certificate)

NOTE

This support does not include supporting internationalized domain names, like in email addresses.

1.6. Configuring Internet Explorer to Enroll Certificates

Because of the security settings in Microsoft Windows Vista, requesting and enrolling certificates through the end entities pages using Internet Explorer 7 and 8 requires extra browser configuration. The browser has to be configured to trust the CA before it can access the CA's secure end entities pages.

NOTE

This configuration is not necessary to use Internet Explorer 7 and 8 on Microsoft Windows 2000, 2003, or XP.

Open Internet Explorer.
Import the CA certificate chain.
1. Open the unsecure end services page for the CA.
```
http://server.example.com:9180/ca/ee/ca
```
2. Click the Retrieval tab.
3. Click Import CA Certificate Chain in the left menu, and then select Download the CA certificate chain in binary form.
4. When prompted, save the CA certificate chain file.
5. In the Internet Explorer menu, click Tools, and select Internet Options.
6. Open the Content tab, and click the Certificates button.
7. Click the Import button. In the import window, browse for and select the imported certificate chain.
  The import process prompts for which certificate store to use for the CA certificate chain. Select Automatically select the certificate store based on the type of certificate.
8. Once the certificate chain is imported, open the Trusted Root Certificate Authorities tab to verify that the certificate chain was successfully imported.
After the certificate chain is imported, Internet Explorer can access the secure end services pages. Open the secure site.
```
https://server.example.com:9443/ca/ee/ca
```
There is probably a security exception when opening the end services pages. Add the CA services site to Internet Explorer's Trusted Sites list.
1. In the Internet Explorer menu, click Tools, and select Internet Options.
2. Open the Security tab, and click Sites to add the CA site to the trusted list.
3. Set the Security level for this zone slider for the CA services page to Medium; if this security setting is too restrictive in the future, then try resetting it to Medium-low.
Close the browser.

To verify that Internet Explorer can be used for enrollments, try enrolling a user certificate, as described in Section 2.3, “Requesting Certificates”.