Page 1 Red Hat Certificate System 8 Deployment Guide Ella Deon Lackey Publication date: July 22, 2009, updated on September 24, 2009...
Page 2 Deployment Guide Red Hat Certificate System 8 Deployment Guide Author Ella Deon Lackey Copyright © 2009 Red Hat, Inc. Copyright © 2009 Red Hat, Inc. 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").
Page 3: Table Of Contents
About This Guide 1. Examples and Formatting ....................vii 1.1. Formatting for Examples and Commands ............. vii 1.2. Tool Locations ....................viii 1.3. Guide Formatting ....................viii 2. Additional Reading ......................viii 3. Giving Feedback ......................ix 4. Document History ......................x 1.
Page 4 Deployment Guide 4.4. CRLs ......................... 50 4.5. Publishing ........................50 4.6. Notifications ....................... 50 4.7. Jobs .......................... 50 4.8. Dual Key Pairs ......................50 4.9. Cross-Pair Certificates ....................50 4.10. Logging ........................50 4.11. Auditing ........................51 4.12. Self-Tests ......................... 51 4.13.
Page 5 6.5.1. Usage Assumptions ..................83 6.5.2. Organizational Policies ..................84 6.5.3. Potential Threats ..................... 84 6.5.4. Security Objectives ..................85 6.6. Features Not Covered by Common Criteria Evaluation` ..........87 Glossary Index...
Page 7: About This Guide
About This Guide This guide explains how to install and configure Red Hat Certificate System subsystems. This guide is intended for experienced system administrators planning to deploy the Certificate System. Certificate System agents should refer to the Certificate System Agent's Guide for information on how to perform agent tasks, such as handling certificate requests and revoking certificates.
Page 8: Tool Locations
About This Guide 1.2. Tool Locations All of the tools for Red Hat Certificate System are located in the /usr/bin directory. These tools can be run from any location without specifying the tool location. 1.3. Guide Formatting Certain words are represented in different fonts, styles, and weights. Different character formatting is used to indicate the function or purpose of the phrase being highlighted.
Page 9: Giving Feedback
If there is any error in this Deployment Guide or there is any way to improve the documentation, please let us know. Bugs can be filed against the documentation for Red Hat Certificate System through Bugzilla, http://bugzilla.redhat.com/bugzilla. Make the bug report as specific as possible, so we can be more effective in correcting any issues:...
Page 10: Document History
We appreciate receiving any feedback — requests for new sections, corrections, improvements, enhancements, even new ways of delivering the documentation or new styles of docs. You are welcome to contact Red Hat Content Services directly at docs@redhat.com. 4. Document History Revision 8.0.4...
Page 11: Introduction To Public-Key Cryptography
Chapter 1. Introduction to Public-Key Cryptography Public-key cryptography and related standards underlie the security features of many products such as signed and encrypted email, single sign-on, and Secure Sockets Layer (SSL) communications. This chapter covers the basic concepts of public-key cryptography. Internet traffic, which passes information through intermediate computers, can be intercepted by a third party: •...
Page 12: Symmetric-Key Encryption
Chapter 1. Introduction to Public-Key Cryptography with the algorithm to produce an encrypted result or to decrypt previously encrypted information. Decryption with the correct key is simple. Decryption without the correct key is very difficult, if not impossible. 1.1.1. Symmetric-Key Encryption With symmetric-key encryption, the encryption key can be calculated from the decryption key and vice versa.
Page 13: Key Length And Encryption Strength
Key Length and Encryption Strength Figure 1.2, “Public-Key Encryption” The scheme shown in allows public keys to be freely distributed, while only authorized people are able to read data encrypted using this key. In general, to send encrypted data, the data is encrypted with that person's public key, and the person receiving the encrypted data decrypts it with the corresponding private key.
Page 14: Digital Signatures
Chapter 1. Introduction to Public-Key Cryptography Because it is relatively trivial to break an RSA key, an RSA public-key encryption cipher must have a very long key — at least 1024 bits — to be considered cryptographically strong. On the other hand, symmetric-key ciphers are reckoned to be equivalently strong using a much shorter key length, as little as 80 bits for most algorithms.
Page 15: Certificates And Authentication
Certificates and Authentication A digital signature is similar to a handwritten signature. Once data have been signed, it is difficult to deny doing so later, assuming the private key has not been compromised. This quality of digital signatures provides a high degree of nonrepudiation; digital signatures make it difficult for the signer to deny having signed the data.
Page 16 Chapter 1. Introduction to Public-Key Cryptography a server. Server authentication refers to the identification of a server (the organization assumed to be running the server at the network address) by a client. Client and server authentication are not the only forms of authentication that certificates support. For example, the digital signature on an email message, combined with the certificate that identifies the sender, can authenticate the sender of the message.
Page 17 Authentication Confirms an Identity 2. The client sends the name and password across the network, either in plain text or over an encrypted SSL connection. 3. The server looks up the name and password in its local password database and, if they match, accepts them as evidence authenticating the user's identity.
Page 18 Chapter 1. Introduction to Public-Key Cryptography a Server” Figure 1.5, “Using a Certificate to Authenticate a Client to a Server” requires SSL. also assumes that the client has a valid certificate that can be used to identify the client to the server. Certificate-based authentication is preferred to password-based authentication because it is based on the user both possessing the private key and knowing the password.
Page 19: How Certificates Are Used
How Certificates Are Used 1.3.3. How Certificates Are Used Certificates have a purpose: to establish trust. Their usage varies depending on the kind of trust they are used to ensure. Some kinds of certificates are used to verify the identity of the presenter; others are used to verify that an object or item has not been tampered with.
Page 20 Chapter 1. Introduction to Public-Key Cryptography messages loses the private key and does not have access to a backup copy of the key, the encrypted messages can never be decrypted. 1.3.3.1.3. Single Sign-on Network users are frequently required to remember multiple passwords for the various services they use.
Page 21 How Certificates Are Used This list is not exhaustive; there are certificate enrollment forms for dual-use certificates for LDAP directories, file-signing certificates, and other subsystem certificates. These forms are available through the Certificate Manager's end-entities page, at https://server.example.com:9444/ ca/ee/ca. For more detailed information about the different certificates that can be created, see the Certificate System Agent's Guide.
Page 22 Chapter 1. Introduction to Public-Key Cryptography Certificate Type CA certificates Object-signing certificates Table 1.1. Common Certificates Section 1.3.3.2.1, “CA Signing Certificates” • Section 1.3.3.2.2, “Other Signing Certificates” • Section 1.3.3.2.3, “SSL Server and Client Certificates” • Section 1.3.3.2.4, “User Certificates” •...
Page 23: Contents Of A Certificate
Contents of a Certificate 1.3.3.2.2. Other Signing Certificates Other services, such as the OCSP responder service and CRL publishing, can use signing certificates other than the CA certificate. For example, a separate CRL signing certificate can be used to sign the revocation lists that are published by a CA instead of using the CA signing certificate.
Page 24 Chapter 1. Introduction to Public-Key Cryptography Users do not usually need to be concerned about the exact contents of a certificate. However, system administrators working with certificates may need some familiarity with the information contained in them. 1.3.4.1. Certificate Data Formats Certificate requests and certificates can be created, stored, and installed in several different formats.
Page 25 Contents of a Certificate DNs may include a variety of other name-value pairs. They are used to identify both certificate subjects and entries in directories that support the Lightweight Directory Access Protocol (LDAP). The rules governing the construction of DNs can be complex; for comprehensive information about DNs, see A String Representation of Distinguished Names at http://www.ietf.org/rfc/rfc4514.txt.
Page 26: How Ca Certificates Establish Trust
Chapter 1. Introduction to Public-Key Cryptography ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c9:de:dc:85:19:22: 43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00: 98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9: 73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e: 9d:3b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0: 7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54: 91:f4:15 Public Exponent: 65537 (0x10001) Extensions: Identifier: Certificate Type Critical: no Certified Usage: SSL Client Identifier: Authority Key Identifier Critical: no Key Identifier: f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36: 26:c9 Signature: Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06: 30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb:...
Page 27 How CA Certificates Establish Trust Section 1.3.5.1, “CA Hierarchies” • Section 1.3.5.2, “Certificate Chains” • Section 1.3.5.3, “Verifying a Certificate Chain” • 1.3.5.1. CA Hierarchies In large organizations, responsibility for issuing certificates can be delegated to several different CAs. For example, the number of certificates required may be too large for a single CA to maintain; different organizational units may have different policy requirements;...
Page 28 Chapter 1. Introduction to Public-Key Cryptography Figure 1.6, “Example of a Hierarchy of Certificate the root CA, based on the CA hierarchy shown in Authorities”. Figure 1.7. Example of a Certificate Chain A certificate chain traces a path of certificates from a branch in the hierarchy to the root of the hierarchy.
Page 29 How CA Certificates Establish Trust 1. The certificate validity period is checked against the current time provided by the verifier's system clock. 2. The issuer's certificate is located. The source can be either the verifier's local certificate database on that client or server or the certificate chain provided by the subject, as with an SSL connection. 3.
Page 30 Chapter 1. Introduction to Public-Key Cryptography Figure 1.9. Verifying a Certificate Chain to an Intermediate CA Expired validity dates, an invalid signature, or the absence of a certificate for the issuing CA at any Figure 1.10, “A Certificate Chain That Cannot point in the certificate chain causes authentication to fail.
Page 31: Managing Certificates
Managing Certificates Figure 1.10. A Certificate Chain That Cannot Be Verified 1.4. Managing Certificates Certificates are used in many applications, from encrypting email to accessing websites. There are two major stages in the lifecycle of the certificate: the point when it is issued (issuance and enrollment) and the period when the certificates are no longer valid (renewal or revocation).
Page 32: Key Management
Chapter 1. Introduction to Public-Key Cryptography library card are different than the ones to get a driver's license. Similarly, different CAs have different procedures for issuing different kinds of certificates. Requirements for receiving a certificate can be as simple as an email address or username and password to notarized documents, a background check, and a personal interview.
Page 33: Overview Of Red Hat Certificate System Subsystems
Chapter 2. Overview of Red Hat Certificate System Subsystems Every common PKI operation — issuing, renewing and revoking certificates; archiving and recovering keys; publishing CRLs and verifying certificate status — are carried out by interoperating subsystems within Red Hat Certificate System. The functions of each individual subsystem and the way that they work together to establish a robust and local PKI is described in this chapter.
Page 34: About The Certificate Manager (Ca)
Chapter 2. Overview of Red Hat Certificate System Subsystems 2.1.1. About the Certificate Manager (CA) As stated, the Certificate Manager is the heart of the Certificate System. It manages certificates at every stage, from requests through enrollment (issuing), renewal, and revocation. The CA also publishes certificates and lists of revoked certificates for use by clients like the OCSP or web servers.
Page 35 About the Certificate Manager (CA) When an end entity enrolls in a PKI by requesting a certificate, the following events can occur, depending on the configuration of the PKI and the subsystems installed: 1. The end entity provides the information in one of the enrollment forms and submits a request. The information gathered from the end entity is customizable in the form depending on the information collected to store in the certificate or to authenticate against the authentication method associated with the form.
Page 36: About The Registration Manager (Ra)
Chapter 2. Overview of Red Hat Certificate System Subsystems • If the notification feature is set up, the link where the certificate can be obtained is sent to the end user. 10. An automatic notice can be sent to the end entity when the certificate is issued or rejected. 11.
Page 37: About Ocsp Services
About OCSP Services RAs remove some of the load from CAs by handling the validation part of a certificate request. For example, offices or organizations can validate requests locally, according to their predefined standards, using RA agents. This requires fewer CAs and allows the organization to group all of the CAs in a separate, secure location.
Page 38 Chapter 2. Overview of Red Hat Certificate System Subsystems • A responder with a public key trusted by the client. Such a responder is called a trusted responder. • A responder that holds a specially marked certificate issued to it directly by the CA that revokes the certificates and publishes the CRL.
Page 39: About The Data Recovery Manager (Drm)
About the Data Recovery Manager (DRM) NOTE If the CRL is large, the Certificate Manager can take a considerable amount of time to publish the CRL. The Online Certificate Status Manager stores each Certificate Manager's CRL in its internal database and uses it as the CRL to verify certificates.
Page 40 Chapter 2. Overview of Red Hat Certificate System Subsystems The DRM stores private encryption keys in a secure key repository in its internal database; each key is encrypted and stored as a key record and is given a unique key identifier. The archived copy of the key remains wrapped with the DRM's storage key.
Page 41 About the Data Recovery Manager (DRM) a. The end entity, using a client which can generate dual key pairs, submits a request through the Certificate Manager enrollment form. b. The client detects the JavaScript in the enrollment form and exports only the private encryption key, not the private signing key.
Page 42: About The Token Processing System (Tps)
Chapter 2. Overview of Red Hat Certificate System Subsystems NOTE The page that the first agent used to initiate the key recovery request keeps refreshing until all agents required to authorize have performed the authorization. It is important that the first agent does not close this browser session until the authorization is complete. Otherwise, the key recovery request needs to be started again.
Page 43: About The Token Key Service (Tks)
About the Token Key Service (TKS) 2.1.6. About the Token Key Service (TKS) The Certificate System Token Management System consists of three components, the Token Processing System (TPS), the Token Key Service (TKS), and the Enterprise Security Client. This section explains the TKS, which manages the master keys required set up a secure communication channel between the TPS and the client.
Page 44 Chapter 2. Overview of Red Hat Certificate System Subsystems 2.2.1.1. The Java Administrative Console for CA, OCSP, DRM, and TKS Subsystems The Java console is used by four subsystems: the CA, OCSP, DRM, and TKS. The console is accessed using a locally-installed pkiconsole utility. It can access any subsystem because the command requires the hostname, the subsystem's administrative SSL port, and the specific subsystem type.
Page 45 Interfaces for Administrators based authentication. The other subsystems used separate SSL ports for the agent and administrative services, along with certificate-based authentication. The HTML admin interface is much more limited than the Java console; the primary administrative function is managing the subsystem users; all other administrative tasks are done by manually editing the CS.cfg file.
Page 46: Agent Interfaces
Chapter 2. Overview of Red Hat Certificate System Subsystems Figure 2.4. TPS Admin Page 2.2.2. Agent Interfaces The agent services pages are where almost all of the certificate and token management tasks are performed. These services are HTML-based, and agents authenticate to the site using a special agent certificate.
Page 47: End User
End User Pages Figure 2.5. Certificate Manager's Agent Services Page The operations vary depending on the subsystem: • The Certificate Manager agent services include approving certificate requests (which issues the certificates), revoking certificates, and publishing certificates and CRLs. All certificates issued by the CA can be managed through its agent services page.
Page 48: Enterprise Security Client
Chapter 2. Overview of Red Hat Certificate System Subsystems The end-user services are accessed over standard HTTP using the server's hostname and the standard port number; they can also be accessed over HTTPS using the server's hostname and the specific end-entities SSL port. For CAs, each type of SSL certificate is processed through a specific online submission form, called a profile.
Page 49 Enterprise Security Client • Supports JavaCard 2.1 or higher cards and Global Platform 2.01-compliant smart cards like Safenet's 330J smart card • Supports Global Platform 2.01-compliant smart cards like Gemalto e-gate 32K and Gemalto TOP IM FIPS CY2 tokens, both the smart card and GemPCKey USB form factor key. •...
Page 51: Supported Standards And Protocols
Chapter 3. Supported Standards and Protocols Red Hat Certificate System is based on many public and standard protocols and RFCs, to ensure the best possible performance and interoperability. The major standards and protocols used or supported by Certificate System 8.0 are outlined in this chapter, to help administrators plan their client services effectively.
Page 52: Ssl/Tls, Ecc, And Rsa
Chapter 3. Supported Standards and Protocols • The default internal PKCS #11 module, which comes with two tokens: • The internal crypto services token, which performs all cryptographic operations such as encryption, decryption, and hashing. • The internal key storage token ("Certificate DB token"), which handles all communication with the certificate and key database files that store certificates and keys.
Page 53: Supported Cipher Suites For Rsa
Supported Cipher Suites for RSA NOTE Longer RSA keys are required to provide security as computing capabilities increase. The recommended RSA key-length is 2048 bits. Though many web servers continue to use 1024-bit keys, web servers should migrate to at least 2048 bits. For 64-bit machines, consider using stronger keys.
Page 54: Ipv4 And Ipv6 Addresses
Chapter 3. Supported Standards and Protocols Bits of Security RSA Key Length ECC Key Length 15360 512+ http:// The information in this table is from the National Institute of Standards and Technology (NIST). For more information, see csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf. Table 3.1. Comparison of RSA and ECC Cipher Strength Certificate System supports using ECC with all of its subsystems, so ECC certificate requests can be submitted to CAs through any of the enrollment profiles and ECC keys can be archived and restored in the DRM.
Page 55: Supported Pkix Formats And Protocols
Supported PKIX Formats and Protocols • Operations performed with Certificate System tools, including the Subject Alt Name Extension tool, HttpClient, and the Bulk Issuance Tool • Client communications, including both the pkiconsole and IPv6-enabled browsers for web services • Certificate request names and certificate subject names, including user, server, and router certificates •...
Page 56: Supported Security And Directory Protocols
Chapter 3. Supported Standards and Protocols Format or Protocol RFC or Draft Description Certificate Request Message RFC 4211 A message format to send a Format (CRMF) certificate request to a CA. Certificate Management Message formats to send Message Formats (CMMF) certificate requests and revocation requests from end entities to a CA and to return...
Page 57 Supported Security and Directory Protocols Protocol Description Lightweight Directory Access Protocol (LDAP) A directory service protocol designed to run over v2, v3 TCP/IP and across multiple platforms. LDAP is a simplified version of Directory Access Protocol (DAP), used to access X.500 directories. LDAP is under IETF change control and has evolved to meet Internet requirements.
Page 58 Chapter 3. Supported Standards and Protocols Protocol Description IPv4 and IPv6 Certificate System supports both IPv4 and IPv6 address namespaces for communications and operations with all subsystems and tools, as well as for clients, subsystem creation, and token and certificate enrollment, Table 3.3.
Page 59: Major Features In Certificate System
Chapter 4. Major Features in Certificate System This chapter covers some of the major features of Red Hat Certificate System, giving a brief rundown of the major functionality of the product. These summaries are meant to help administrators understand the capabilities of the Certificate System so they can effectively plan their subsystem deployments.
Page 60: Crls
Chapter 4. Major Features in Certificate System 4.4. CRLs The Certificate System can create certificate revocation lists (CRLs) from a configurable framework which allows user-defined issuing points so a CRL can be created for each issuing point. Delta CRLs can also be created for any issuing point that is defined. CRLs can be issued for each type of certificate, for a specific subset of a type of certificate, or for certificates generated according to a profile or list of profiles.
Page 61: Auditing
Red Hat Enterprise Linux Deployment Guide. Basically, SELinux identifies objects on a system, which can be files, directories, users, processes, sockets, or any other resource on a Linux host. These objects correspond to the Linux API objects. http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Deployment_Guide-en-US/ch-selinux.html...
Page 62 Chapter 4. Major Features in Certificate System Each object is then mapped to a security context, which defines the type of object and how it is allowed to function on the Linux server. Objects can be grouped into domains, and then each domain is assigned the proper rules. Each security context has rules which set restrictions on what operations it can perform, what resources it can access, and what permissions it has.
Page 63 Security-Enhanced Linux Support • Any access not specified in the SELinux policy is denied to the Certificate System instance. For Certificate System, each subsystem is treated as an SELinux object, and each subsystem has unique rules assigned to it. The defined SELinux policies allow Certificate System objects run with SELinux set in enforcing mode.
Page 65: Planning The Certificate System
Chapter 5. Planning the Certificate System Each Red Hat Certificate System subsystem is installed and configured separately. They can all be installed on the same machine, installed on separate servers, or have multiple instances installed across an organization. Before installing any subsystem, it is important to plan the deployment out: what kind of PKI services do you need? What are the network requirements? What people need to access the Certificate System, what are their roles, and what are their physical locations? What kinds of certificates do you want to issue and what constraints or rules need to be set for them?
Page 66 Chapter 5. Planning the Certificate System Figure 5.1. CA Only Certificate System All of the basic processing for requests and issuing certificates can handled by the Certificate Manager, and it is the only required subsystem. There can be a single Certificate Manager or many Certificate managers, arranged in many different relationships, depending on the demands of the organization.
Page 67: Planning For Lost Keys: Key Archival And Recovery
Planning for Lost Keys: Key Archival and Recovery 5.1.2. Planning for Lost Keys: Key Archival and Recovery One operation the CA cannot perform, though, is key archival and recovery. A very real scenario is that a user is going to lose his private key — for instance, the keys could be deleted from a browser database or a smart card could be left at home.
Page 68: Balancing Client Ocsp Requests
Chapter 5. Planning the Certificate System Another option, though is to distribute some of the tasks of a single CA to another subsystem. For example, Example Corp. has a manageable number of people requesting certificates for a single CA to issue. However, because of their security policies, each certificate request has to be verified in person by an agent, with supporting documentation.
Page 69: Planning For Smart Cards
Planning for Smart Cards Figure 5.4. CA and OCSP 5.1.5. Planning for Smart Cards Most certificates are enrolled through the CA. This is useful for certificates enrolled through an application such as a web browser or web server. For managing smart cards, or tokens, Certificate System uses interlocking subsystems to create a token management system which handles operations for certificates and keys stored on smart cards.
Page 70 Chapter 5. Planning the Certificate System Figure 5.5. How Certificate System Manages Smart Cards To use the tokens, the Token Processing System must be able to recognize and communicate with them. The tokens must first be enrolled to format the tokens with required keys and certificates and add the tokens to the Certificate System.
Page 71: Defining The Certificate Authority Hierarchy
Defining the Certificate Authority Hierarchy After installation, the TPS configuration can be edited to use additional CA, DRM, and TKS instances for failover support, so if the primary subsystem is unavailable, the TPS can switch to the next available system without interrupting its token services. 5.2.
Page 72: Subordination To A Public Ca
Chapter 5. Planning the Certificate System the certificate to be issued. Before deploying the full PKI, however, consider whether to have a root CA, how many to have, and where both root and subordinate CAs will be located. 5.2.1. Subordination to a Public CA Chaining the Certificate System CA to a third-party public CA introduces the restrictions that public CAs place on the kinds of certificates the subordinate CA can issue and the nature of the certificate chain.
Page 73: Planning Security Domains And Trust Relationships
Planning Security Domains and Trust Relationships Because clone CAs and original CAs use the same CA signing key and certificate to sign the certificates they issue, the issuer name in all the certificates is the same. Clone CAs and the original Certificate Managers issue certificates as if they are a single CA.
Page 74 Chapter 5. Planning the Certificate System OCSP, and other CAs — must become members of the security domain by supplying the security domain URL when configuring the subsystem. Each subsystem within the security domain shares the same trust policies and trusted roots which can be retrieved from different servers and browsers.
Page 75: Using Trusted Managers
Using Trusted Managers • The Certificate System security domain allows an offline CA to be set up. In this scenario, the offline root has its own security domain. All online subordinate CAs belong to a different security domain. • The security domain streamlines configuration between the CA and OCSP. The OCSP can push its information to the CA for the CA to set up OCSP publishing and also retrieve the CA certificate chain from the CA and store it in the internal database.
Page 76 Chapter 5. Planning the Certificate System Subsystem Table 5.1. Initial Subsystem Certificates There are some cautionary considerations about replacing existing subsystem certificates. • Generating new key pairs when creating a new self-signed CA certificate for a root CA will invalidate all certificates issued under the previous CA certificate.
Page 77: Ca Distinguished Name
CA Distinguished Name must be requested with the appropriate extensions. After installing the certificate, the publishing directory must be configured to use the new server certificate. • Any number of SSL server certificates can be issued for a subsystem instance, but it really only needs one SSL certificate.
Page 78: Using Certificate Extensions
Chapter 5. Planning the Certificate System SHA1withRSA is the default signing algorithm for CAs for RSA certificates. SHA1withEC is the default signing algorithm for CAs for ECC certificates. Along with a key type, each key has a specific bit length. Longer keys are considered cryptographically stronger than shorter keys.
Page 79 Using Certificate Extensions NOTE RFC 2459 RFC 3280 For more information on standard extensions, see , and 3279 The X.509 v3 standard for certificates allows organizations to define custom extensions and include them in certificates. These extensions are called private, proprietary, or custom extensions, and they carry information unique to an organization or business.
Page 80: Using And Customizing Certificate Profiles
Chapter 5. Planning the Certificate System • If the extension is critical and the certificate is sent to an application that does not understand the extension based on the extension's ID, the application must reject the certificate. • If the extension is not critical and the certificate is sent to an application that does not understand the extension based on the extension's ID, the application can ignore the extension and accept the certificate.
Page 81 Using and Customizing Certificate Profiles A set of certificate profiles have been predefined for the most common certificates issued. These certificate profiles define defaults and constraints, associate the authentication method, and define the needed inputs and outputs for the certificate profile. The parameters of the default certificate profiles the authentication method, the defaults, the constraints used in each profile, the values assigned to any of the parameters in a profile, the input,...
Page 82: Planning Authentication Methods
Chapter 5. Planning the Certificate System constraints. This validation procedure is only for verification and does not result in the request being submitted. The agent is bound by the constraints set; they cannot change the request in such a way that a constraint is violated.
Page 83: Publishing Certificates And Crls
Publishing Certificates and CRLs • In automatic enrollment, end-entity requests are authenticated using a plug-in, and then the certificate request is processed; an agent is not involved in the enrollment process. • In CMC enrollment, a third party application can create a request that is signed by an agent and then automatically processed.
Page 84: Renewing Or Reissuing Ca Signing Certificates
Chapter 5. Planning the Certificate System • If certificates are published to the directory, than every user or server to which a certificate is issued must have a corresponding entry in the LDAP directory. • If CRLs are published to the directory, than they must be published to an entry for the CA which issued them.
Page 85: Considering Physical Security And Location
Section 2.2, “Red Hat Certificate System Services” All of the service pages and interfaces described in are connected to using the instance's URL and the corresponding port number. For example: https://server.example.com:9444/ca/ee/ca To access the admin console, the URL specifies the admin port: http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Deployment_Guide/s1-fireall-ipt-act.html...
Page 86: Tokens For Storing Certificate System Subsystem Keys And Certificates
Chapter 5. Planning the Certificate System pkiconsole https://server.example.com:9445/ca All agent and admin functions require SSL client authentication. For requests from end entities, the Certificate System listens on both the SSL (encrypted) port and non-SSL ports. The ports for the different services to use are defined in the server.xml file for the CA, OCSP, DRM, and TKS and in the httpd.conf and nss.conf files for the RA and TPS.
Page 87 Tokens for Storing Certificate System Subsystem Keys and Certificates certificates. The Certificate System automatically generates these files in the filesystem of its host machine when first using the internal token. These files are created during the Certificate System subsystem configuration if the internal token was selected for key-pair generation. These security databases are located in the /var/lib/subsystem_name/alias directory.
Page 88: Questions For Planning The Certificate System
Chapter 5. Planning the Certificate System Administrators are allowed to select any of the tokens that are logged in as the default token, which is used to generate system keys. 5.7. Questions for Planning the Certificate System • Will the PKI allow replacement keys? Will it require key archival and recovery? •...
Page 89: Setting Up A Common Criteria Environment
Chapter 6. Setting up a Common Criteria Environment Setting up a secure environment according to Red Hat Certificate System's Common Criteria evaluation guidelines requires special planning for its subsystems and users. The actual installation and configuration process is covered in the Certificate System Administrator's Guide, but the concepts, security objectives, and considerations are covered in this chapter, as part of planning your Certificate System deployment.
Page 90: Required Features And Configurations For The Certificate System Subsystems
Chapter 6. Setting up a Common Criteria Environment • Secure password and certificate storage. Plan for the storage of any passwords and certificates. Also define the user password policy. Make sure everyone knows and adheres to these policies. In addition to the host configuration for passwords and timestamps, the Certificate System host server and its network environment must both offer protection from potential security issues: •...
Page 91: Users, Roles, And Access Control For Common Criteria
Users, Roles, and Access Control for Common Criteria messages, and other important or relevant information about the transaction, like the certificate serial number, DN, or authentication source. The only configurable option for the audit log content is the events which are logged. Certificate Profiles Any or all of the pre-defined certificate profiles can be used for certificate enrollment.
Page 92: Certificate System User Types
Chapter 6. Setting up a Common Criteria Environment 6.4.1. Certificate System User Types Each Certificate System subsystem has up to four roles. While the names of the user roles (administrator, agent, auditors, and trusted managers), the functions of each role is slightly different for each subsystem, according to the functions of the subsystem: •...
Page 93: Access Controls For Common Criteria
Access Controls for Common Criteria 6.4.2. Access Controls for Common Criteria All of the subsystems and supporting network environment must support and enforce an access control policy with the following restrictions: • Users are only granted access to the subsystem and its data if they meet the following requirements: •...
Page 94: Organizational Policies
Chapter 6. Setting up a Common Criteria Environment Objective Area Description Social engineering training General users, administrators, operators, officers and auditors are trained in techniques to Cooperative users Users need to accomplish some task or group of tasks that require a secure IT environme some of the information managed by Certificate System and are expected to act in a coop Communications protection The system is adequately physically protected against loss of communications i.e., availa...
Page 95: Security Objectives
Security Objectives Objective Area Description Modification of private/secret A secret/private key is modified. keys Sender denies sending The sender of a message denies sending the message to avoid accountability for information inaction. Hacker gains access A hacker masquerades as an authorized user to perform operations that will be at or gains undetected access to a system due to missing, weak and/or incorrectly im violations of integrity, confidentiality, or availability.
Page 96 Chapter 6. Setting up a Common Criteria Environment Objective Area Description Malicious code not signed Protect Certificate System from malicious code by ensuring all code is signed by a trusted Notify authorities of security Notify proper authorities of any security issues that impact their systems to minimize the p issues Physical protection Those responsible for Certificate System must ensure that the security-relevant compone...
Page 97: Features Not Covered By Common Criteria Evaluation
Features Not Covered by Common Criteria Evaluation` Objective Area Description Procedures for preventing Incorporate malicious code prevention procedures and mechanisms. malicious code Protect stored audit records Protect audit records against unauthorized access, modification, or deletion to ens Protect user and TSF data Ensure the integrity of user and TSF data transferred internally within the system.
Page 98 Chapter 6. Setting up a Common Criteria Environment • Running the internal LDAP database or any publishing LDAP database without SSL. • Adding a custom plug-in. All role users for a subsystem must carefully evaluate any custom plug-ins before making them part of the system. •...
Page 99: Glossary
Glossary access control The process of controlling what particular users are allowed to do. For example, access control to servers is typically based on an identity, established by a password or a certificate, and on rules regarding access control list (ACL).
Page 100 Glossary authentication module A set of rules (implemented as a Java™ class) for authenticating an end entity, agent, administrator, or any other entity that needs to interact with a Certificate System subsystem. In the case of typical end-user enrollment, after the user has supplied the information requested by the enrollment form, the enrollment servlet uses an authentication module associated with that form to validate the information and authenticate the user's identity.
Page 101 entity named in the issuer field of a certificate is always a CA. Certificate authorities can be independent third parties or a person or organization using certificate-issuing server software, such as Red Hat Certificate System. certificate-based Authentication based on certificates and public-key cryptography. See password-based authentication.
Page 102 Glossary certificate profile A set of configuration settings that defines a certain type of enrollment. The certificate profile sets policies for a particular type of enrollment along with an authentication method in a certificate profile. Certificate Request Format used for messages related to management of X.509 Certificate Message Format (CRMF) certificates.
Page 103 each other, and then store both cross-pair certificates as a certificate pair. Certificate Request Message Format (CRMF). CRMF cross-certification The exchange of certificates by two CAs in different certification hierarchies, or chains. Cross-certification extends the chain of trust certificate authority so that it encompasses both hierarchies.
Page 104 Glossary Unscrambling data that has been encrypted. See encryption. decryption Data Encryption Standard A FIPS-approved cryptographic algorithm required by FIPS 140-1 (DES) and specified by FIPS PUBS 46-2. DES, which uses 56-bit keys, is a standard encryption and decryption algorithm that has been used successfully throughout the world for more than 20 years.
Page 105 encryption key A private key used for encryption only. An encryption key and its signing key equivalent public key, plus a and its equivalent public key, dual key pair. constitute a enrollment The process of requesting and receiving an X.509 certificate for use public-key infrastructure (PKI).
Page 106 Glossary Java™ archive (JAR) format A set of conventions for associating digital signatures, installer scripts, and other information with files in a directory. Java™ Cryptography The API specification and reference developed by Sun Microsystems http://java.sun.com/products/jdk/1.2/ Architecture (JCA) for cryptographic services. See docs/guide/security/CryptoSpec.Introduction.
Page 107 authentication, a servlet forwards a certificate request to a request queue after successful authentication module processing. An agent with appropriate privileges must then approve each request individually before profile processing and certificate issuance can proceed. A message digest algorithm that was developed by Ronald Rivest. one-way hash.
Page 108 Glossary profile. Each output is set, which then dynamically creates the form from all outputs configured for this enrollment. password-based Confident identification by means of a name and password. See also authentication, certificate-based authentication. authentication PKCS #7 The public-key cryptography standard that governs signing and encryption.
Page 109 public key is published as part of a certificate, which associates that key with a particular identity. The corresponding private key is kept secret. Data encrypted with the public key can be decrypted only with the private key. public-key infrastructure The standards and services that facilitate the use of public-key (PKI) cryptography and X.509 v3 certificates in a networked environment.
Page 110 Pretending to be someone else. For example, a person can pretend to have the email address jdoe@example.com, or a computer can identify itself as a site called www.redhat.com when it is not. Spoofing is one form of impersonation. See also misrepresentation.
Page 111 subordinate CA A certificate authority that's certificate is signed by another certificate, root subordinate CA or by the root CA. See symmetric encryption An encryption method that uses the same cryptographic key to encrypt and decrypt a given message. tamper detection A mechanism ensuring that data received in electronic form entirely corresponds with the original version of the same data.
Page 113: Index
Index Status tab, 34 certificate-based authentication defined, 6 certificates authentication using, 7 accelerators, 77 CA certificate, 12 administrators chains, 18 tools provided contents of, 13 Certificate System console, 34 issuing of, 21 agent certificate, 13 renewing, 22 agents revoking, 22 authorizing key recovery, 31 S/MIME, 12 port used for operations, 76...
Page 114 Index defined, 77 root CA, 62 root versus subordinate CA, 62 RSA, 67 hardware accelerators, 77 hardware tokens, 76 S/MIME certificate, 12 See external tokens, 77, 77 self-signed certificate, 17 how to search for keys, 30 signing certificate CA, 67 signing key, for CA, 67 internal tokens, 77 client certificates, 11...

Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT Deployment Manual

Quick Links

Need help?

Questions and answers

Related Manuals for Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT

Summary of Contents for Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT

Table of Contents