1. Manuals
  2. Brands
  3. Red Hat Manuals
  4. Software
  5. CERTIFICATE SYSTEM 7.3 - ADMINISTRATION
  6. Administration manual

Red Hat CERTIFICATE SYSTEM 7.3 - ADMINISTRATION Administration Manual

Hide thumbs Also See for CERTIFICATE SYSTEM 7.3 - ADMINISTRATION:
1
2
Table Of Contents
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
Table of Contents

Advertisement

Quick Links

Download this manual See also: Manual
Red Hat Certificate
System 7.3
Administration Guide
Publication date: May 2007, updated March 25, 2010

Advertisement

Table of Contents
loading

Related Manuals for Red Hat CERTIFICATE SYSTEM 7.3 - ADMINISTRATION

Summary of Contents for Red Hat CERTIFICATE SYSTEM 7.3 - ADMINISTRATION

  • Page 1 Red Hat Certificate System 7.3 Administration Guide Publication date: May 2007, updated March 25, 2010...
  • Page 2 Administration Guide Red Hat Certificate System 7.3 Administration Guide 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"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/.

  • Page 3: Table Of Contents

    About This Guide xvii 1. Recommended Knowledge ................... xvii 2. What Is in This Guide ....................xvii 3. Examples and Formatting ....................xix 3.1. File Locations for Examples and Commands ............xix 3.2. Using Mozilla LDAP Tools .................. xix 3.3. Default Port Numbers ..................xix 3.4.
  • Page 4 Administration Guide 1.4.7. Management Tools ..................19 1.4.8. JRE ........................ 20 1.4.9. Internal Database .................... 20 1.4.10. SSL/TLS and Supported Cipher Suites ............20 1.5. Support for Open Standards ..................21 1.5.1. Certificate Management Formats and Protocols ..........21 1.5.2. Security and Directory Protocols ............... 21 2.
  • Page 5 2.11.2. Removing Certificate System Subsystems ............59 3. Administrative Basics 3.1. Administrative Console ....................61 3.2. Enabling SSL Client Authentication for the Certificate System Console ......62 3.3. System Passwords ..................... 64 3.3.1. Protecting the password.conf File ..............64 3.3.2. Password-Quality Checker ................66 3.4.
  • Page 6 Administration Guide 4. Certificate Manager 4.1. How the Certificate Manager Works ................109 4.1.1. Enrollment ..................... 109 4.1.2. Revocation ....................110 4.2. Certificate Manager Certificates ................. 111 4.2.1. CA Signing Key Pair and Certificate ..............111 4.2.2. OCSP Signing Key Pair and Certificate ............112 4.2.3.
  • Page 7 6.1.2. OCSP Responses ..................158 6.2. CA OCSP Services ....................158 6.2.1. The Certificate Manager's Internal OCSP Service ..........158 6.2.2. Online Certificate Status Manager ..............158 6.3. Online Certificate Status Manager Certificates ............159 6.3.1. OCSP Signing Key Pair and Certificate ............159 6.3.2.
  • Page 8 Administration Guide 8.5.6. Setting Token Types for Specified Smart Cards ..........196 8.6. Configuring LDAP Authentication ................198 8.7. Token Database ....................... 199 8.8. Configuring TPS Logging ..................199 8.8.1. Thread Correlation ..................199 8.9. TPS Configuration Parameters .................. 199 8.9.1.
  • Page 9 13.3. Setting up Certificate Profiles .................. 273 13.3.1. Modifying Certificate Profiles through the CA Console ........273 13.3.2. Modifying Certificate Profiles through the Command Line ........ 282 13.3.3. Populating Certificates with Directory Attributes ..........285 13.3.4. Customizing the Enrollment Form ..............288 13.4.
  • Page 10 Administration Guide 13.8.1. Basic Constraints Extension Constraint ............316 13.8.2. Extended Key Usage Extension Constraint ............ 317 13.8.3. Extension Constraint ..................317 13.8.4. Key Constraint ..................... 317 13.8.5. Key Usage Extension Constraint ..............317 13.8.6. No Constraint ....................319 13.8.7. Netscape Certificate Type Extension Constraint ..........319 13.8.8.
  • Page 11 15.7. Publishing Cross-Pair Certificates ................357 15.8. Testing Publishing to Files ..................357 15.9. Viewing Certificates and CRLs Published to File ............359 15.10. Configuring the Directory for LDAP Publishing ............359 15.10.1. Schema ..................... 360 15.10.2. Entry for the CA ..................360 15.10.3.
  • Page 12 Administration Guide 17.7.1. certServer.acl.configuration ................406 17.7.2. certServer.admin.certificate ................407 17.7.3. certServer.admin.request.enrollment .............. 407 17.7.4. certServer.auth.configuration ................. 408 17.7.5. certServer.ca.certificate ................408 17.7.6. certServer.ca.certificates ................409 17.7.7. certServer.ca.configuration ................409 17.7.8. certServer.ca.connector ................410 17.7.9. certServer.ca.clone ..................410 17.7.10. certServer.ca.crl ..................411 17.7.11.
  • Page 13 17.7.52. certServer.ocsp.crl ..................427 17.7.53. certServer.profile.configuration ..............427 17.7.54. certServer.publisher.configuration ..............428 17.7.55. certServer.registry.configuration ..............429 17.7.56. certServer.usrgrp.administration ..............429 18. Automated Notifications 18.1. About Automated Notifications ................. 431 18.1.1. Types of Automated Notifications ..............431 18.1.2. Determining End-Entity Email Addresses ............431 18.2.
  • Page 14 Administration Guide A.3.2. The authorityKeyIdentifier ................464 A.3.3. basicConstraints .................... 465 A.3.4. certificatePolicies ................... 465 A.3.5. CRLDistributionPoints ..................466 A.3.6. extKeyUsage ....................466 A.3.7. issuerAltName Extension ................467 A.3.8. keyUsage ...................... 467 A.3.9. nameConstraints ................... 469 A.3.10. OCSPNocheck .................... 469 A.3.11.
  • Page 15 Index...

  • Page 17: About This Guide

    About This Guide This guide explains how to install, configure, and maintain the Red Hat Certificate System and how to use it for issuing and managing certificates to end entities such as web browsers, users, servers, and virtual private network (VPN) clients. This guide is intended for experienced system administrators planning to deploy the Certificate System.
  • Page 18 About This Guide Chapter 6, Online Certificate Status Protocol Responder • provides information and instructions for configuring an Online Certificate Status Manager. Chapter 7, Data Recovery Manager • provides information and an overview of the configuration options for a Data Recovery Manager. Chapter 8, Token Processing System •...

  • Page 19: Examples And Formatting

    Examples and Formatting 3. Examples and Formatting 3.1. File Locations for Examples and Commands All of the examples for Red Hat Certificate System commands, file locations, and other usage are given for Red Hat Enterprise Linux 4 (32 bit) systems. Be certain to use the appropriate commands and files for your platform.

  • Page 20: Additional Reading

    About This Guide Formatting Style Purpose Monospace is used for commands, package names, files and Monospace font directory paths, and any text displayed in a prompt. This type of formatting is used for anything entered or returned Monospace in a command prompt. with a background Italicized text...

  • Page 21: Giving Feedback

    If there is any error in this Administrator's 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 22 Rewrote the section on issuing delta and full CRLs, per Bugzilla #510132. Changed PK12Export to pk12util in the cloning configuration overview, per Bugzilla #519058. Revision June 13, 2009 Ella Deon Lackey dlackey@redhat.com 7.3.13 Removing references to the CS SDK and Java SDK, per Bugzilla #491405. Revision March 7, 2009 Ella Deon Lackey dlackey@redhat.com...

  • Page 23: Overview

    Chapter 1. Overview This chapter provides an overview of Red Hat Certificate System, a highly configurable set of software components and tools for creating, deploying, and managing certificates. Based on open standards for certificate management, Certificate System provides a complete, customizable, robust, scalable, and high-performance certificate management solution for public-key infrastructure (PKI), extranets, and intranets.

  • Page 24: Interfaces

    Chapter 1. Overview 1.1.2. Interfaces Each of the subsystems contains interfaces for interaction with various portions of the subsystem. The CA, DRM, OCSP, and TKS subsystems have an administrative console to manage and configure the subsystem itself, such as adding users and certificates and viewing logs. The CA, OCSP, DRM, and TPS subsystems have an agent interface specific to that subsystem which allows agents to perform the tasks assigned to them.

  • Page 25: Self-Tests

    Self-Tests 1.1.5. Self-Tests The Certificate System provides the framework for system self-tests that are automatically run at startup and can be run on demand. A set of configurable self-tests are already included with the Section 3.10, “Self-Tests” Certificate System. See for details.

  • Page 26: Registration Authority

    Chapter 1. Overview 1.1.9. Registration Authority A Registration Authority (RA) is a subsystem that accepts enrollment requests and authenticates them in a local context (e.g., a department of an organization, or an organization within an association). Upon the successful authentication, the RA then forwards the enrollment request to the designated Certificate Authority (CA) to generate the certificate.

  • Page 27: Certificate Profiles

    For more information about certificates being issued through the Enterprise Security Client, see the Certificate System Enterprise Security Client Guide, which is available at http:// redhat.com/docs/manuals/cert-system/. For information about configuring subsystems to manage Chapter 8, Token Processing System.

  • Page 28: Dual Key Pairs

    Chapter 1. Overview 1.1.17. Dual Key Pairs The Certificate System supports generating dual key pairs, separate key pairs for signing and encrypting email messages and other data. To support separate key pairs for signing and encrypting data, dual certificates are generated for end entities, and the encryption keys are archived. If a client makes a certificate request for dual key pairs, the server issues two separate certificates.

  • Page 29: How The Certificate System Works

    How the Certificate System Works 1.2. How the Certificate System Works The Certificate System manages certificates through a flexible, scalable system for issuing and publishing certificates; creating and publishing CRLs; and providing key storage and retrieval capabilities. The Certificate Manager is the central point of the Certificate System; this subsystem accepts requests, generates and manages certificates, and generates and manages CRLs and revoked certificates.
  • Page 30 Chapter 1. Overview certificate chains outside the company certificate hierarchy. A Certificate Manager is chained to a third- party CA by requesting the Certificate Manager's CA signing certificate from the third-party CA. 1.2.1.1.3. CA Cloning Instead of creating a hierarchy of root and subordinate CAs, it is possible to create multiple clones of a Certificate Manager and configure each clone to issue certificates that fall within a distinct range of serial numbers.

  • Page 31: How The Certificate Manager Works

    How the Certificate Manager Works 1.2.1.5. Revocation and CRLs Revoking certificates can be initiated either by an agent or by the end user. An administrator can also revoke the certificates of any of the subsystems or agents. The Certificate System also supports CMC revocation. When the CMCAuth plug-in is enabled, CMC enrollment and CMC revocation are both enabled.
  • Page 32 Chapter 1. Overview certificate content. The default certificate profiles can be modified and new custom modules created. Chapter 13, Certificate Profiles for details. If the policies in the certificate profile are not met, the request is rejected. If they are met, the certificate is issued.

  • Page 33: Data Recovery Manager

    Data Recovery Manager 1.2.3. Data Recovery Manager The Data Recovery Manager (DRM) is an optional subsystem that acts as a Key Recovery Authority. When configured in conjunction with a Certificate Manager, the DRM stores private encryption keys as part of the certificate enrollment process. Private encryption keys archived in a DRM are recovered in a PKCS #12 file only after multiple key recovery agents approve the recovery request.

  • Page 34: Token Key Service

    Chapter 1. Overview When an OCSP responder is set up with a Certificate Manager, and publishing is set up to the OCSP responder, CRLs are published to the OCSP responder when they are issued or updated. 1.2.5. Token Key Service The Token Key Service (TKS) provides secure channels for communication between smart card tokens and a TPS instance.

  • Page 35: Certificate Manager And Drm

    Certificate Manager and DRM Figure 1.1. Single-Root Certificate Manager Figure 1.1, “Single-Root Certificate Manager” shows the relationships between a single Certificate Manager, end entities, and a publishing directory. The Certificate Manager can publish both end-entity certificates and CRLs to a directory. 1.3.2.

  • Page 36: Cloned Certificate Manager

    Chapter 1. Overview Figure 1.2. Certificate Manager and DRM in Different Instances NOTE The DRM is intended for archival and recovery of private encryption keys only. Therefore, end entities must use either a browser that supports dual-key generation. When determining the location of a DRM, consider possible firewall interactions, the physical security required for each subsystem, and the physical location of the Certificate Manager agent, DRM agent, and other people responsible for administering the Certificate Manager and recovering keys.

  • Page 37: Smart Card Enrollment

    For more information on managing subsystems for smart card tokens, see Processing System. For more information on performing token operations for users, see the Certificate System Enterprise Security Client Guide, which is available at http://redhat.com/docs/manuals/cert- system/. Figure 1.3. Token Management Configuration 1.4. System Architecture Figure 1.4, “Certificate System Architecture”...
  • Page 38 Chapter 1. Overview Figure 1.4. Certificate System Architecture...

  • Page 39: Certificate System Instance

    Certificate System Instance 1.4.1. Certificate System Instance Within the Certificate System component, a set of common modules, which can all be extended with custom Java™ plug-ins, are provided for all subsystems. Although some may not be used in the default setting, they are available for further customization. •...

  • Page 40: Jss And The Jni Layer

    Chapter 1. Overview NOTE The OCSP, DRM, TKS, and TPS subsystems do not have end-entity pages. • Agent Services Interface . The agent services page java servlets process HTML form submitted through the agent services HTTP pages. From the information in each submitted form, the agent servlets allow agents to perform agent tasks, such as editing and approving requests for issuing or revoking certificates and approving certificate profiles.

  • Page 41: Pkcs #11

    PKCS #11 cryptographic token interfaces. Red Hat uses NSS to support these features in a wide range http:// of products, including Certificate System. NSS documentation is available on-line at www.mozilla.org/projects/security/pki/nss/overview.html. 1.4.6. PKCS #11 Public-Key Cryptography Standard (PKCS) #11 specifies an API used to communicate with devices that hold cryptographic information and perform cryptographic operations.

  • Page 42: Jre

    • Bulk certificate issuance tool (bulkissuance) For more information about Certificate System command-line tools, see the Certificate System Command-Line Tools Guide, which is available at http://redhat.com/docs/manuals/cert-system/. 1.4.8. JRE The Java™ Runtime Environment (JRE) provides the Java™ Virtual Machine (JVM) and supporting class libraries needed to run the Certificate System.

  • Page 43: Support For Open Standards

    Support for Open Standards three times as long as the key for standard DES. Because the key size is so large, there are approximately 3.7 * 10^50 possible keys. This cipher suite is FIPS-compliant. • RC4 and RC2 and MD5 Message Authentication. The RC4 and RC2 ciphers have 128-bit encryption, which permits approximately 3.4 * 10^38 possible keys.
  • Page 44 Chapter 1. Overview that encrypts and decrypts data, creates and verifies digital signatures, and other cryptographics functions. • Hypertext Transport Protocol (HTTP) and Hypertext Transport Protocol Secure (HTTPS). Protocols used to communicate with web servers. • KEYGEN tag. An HTML tag that generates a key pair for use with a certificate. •...

  • Page 45: Installation And Configuration

    Chapter 2. Installation and Configuration The Certificate System is comprised of subsystems which can be independently installed on different servers, multiple instances installed on a single server, and other flexible configurations for availability, scalability, and failover support. The procedures for downloading, installing, and configuring instances of Certificate System subsystems are described in this chapter.

  • Page 46: Security Domains

    Chapter 2. Installation and Configuration • How many subsystems to install. • On which hosts to install the subsystems. • How and where to install an available Red Hat Directory Server. Only one Directory Server is required, although there can be more than one. It is recommended that the Directory Server only be used for certificate management.

  • Page 47: Prerequisites

    Prerequisites issue and the nature of the certificate chain. This may not be acceptable for some PKI deployments. One benefit of chaining to a public CA is that the third party is responsible for submitting the root CA certificate to a web browser or other client software, which is a major advantage for certificates that are accessed by different companies with browsers that cannot be controlled by the administrator.

  • Page 48: Required Programs And Dependencies

    Chapter 2. Installation and Configuration The services pages for the subsystems require a web browser that supports SSL. It is strongly recommended that users such as agents or administrators use Mozilla Firefox to access the agent services pages. End-entities should use Mozilla Firefox or Microsoft Internet Explorer. NOTE The only browser that is fully-supported for the HTML-based instance configuration wizard is Mozilla Firefox.
  • Page 49 SUNWj5rt, first, and then add the 64-bit package, SUNWj5rtx. • Java™ Development Kit (JDK). A JDK must be present on Red Hat Enterprise Linux systems. See http://kbase.redhat.com/faq/FAQ_54_4667.shtm for more information. While almost any JDK is sufficient, installing one of these JDKs is recommended: •...

  • Page 50: Packages Installed

    Chapter 2. Installation and Configuration • The Solaris version of Certificate System was tested on Sun Solaris 9 with patch level 118558-28. • The following package groups and packages must be installed on all Red Hat Enterprise Linux systems: • dialup (package group) •...
  • Page 51 Packages Installed RPMs for the Enterprise Security Client pcsc-lite-libs ifd-egate RPMs for Tomcat Web Services jakarta-commons-discovery avalon-framework jakarta-commons-el regexp avalon-logkit jakarta-commons-fileupload rhino axis jakarta-commons-httpclient3 tomcat5 bcel jakarta-commons-launcher tomcat5-jasper classpathx-jaf jakarta-commons-logging tomcat5-servlet-2.4-api classpathx-mail jakarta-commons-modeler velocity eclipse-ecj jakarta-commons-pool werken.xpath geronimo-specs jdom wsdl4j gnu-crypto-sasl-jdk1.4 xalan-j2 jakarta-commons-beanutils...
  • Page 52 Chapter 2. Installation and Configuration RPMs for Network Security Services (NSS) dirsec-nss-tools RPMs for Java™ java-1.5.0-ibm java-1.5.0-ibm-devel 2.2.3.2. Solaris Packages Solaris packages have the format VENDORpackage_name-version_number-release_number- architecture.pkg; only the package name is shown in the tables. NOTE Package names for 64-bit Sparc 9 packages always have an x at the end of the primary package name.
  • Page 53 Packages Installed Packages for Tomcat Web Services RHATgeronimo-specsx RHATjdomx RHATwsdl4jx RHATgnu-crypto-sasl-jdk1-4x RHATjmsx RHATxalan-j2x RHATjakarta-commons- RHATjpackage-utilsx RHATxerces-j2x beanutilsx RHATjakarta-commons- RHATldapjdkx RHATxml-commons-apisx collectionsx RHATjakarta-commons- RHATlog4jx RHATxml-commons-resolverx daemonx RHATjakarta-commons-dbcpx RHATmx4jx RHATxml-commonsx RHATjakarta-commons- RHAToldjdomx RHATxmlbeansx digesterx RHATjakarta-commons- RHATorox discoveryx Packages for Fortitude Web Services RHATfortitude-webx RHATmod-nssx RHATmod-revocatorx...

  • Page 54: Configuration Preparation

    Chapter 2. Installation and Configuration Packages for Java™ SUNWj5rtx (64-bit JRE) 2.3. Configuration Preparation Section 2.3.1, “Required Information” • Section 2.3.2, “Default Settings” • 2.3.1. Required Information When the Certificate System subsystems are configured, some outside information must be available. This includes the following: •...

  • Page 55: Default Settings

    Default Settings If the subsystem being configured is a clone of another subsystem, then the backup files for the master subsystem must be locally accessible. 2.3.2. Default Settings Table 2.1, “Default Subsystem Instance Ports and File Locations” The ports and file directories in show the default installation and configuration information.

  • Page 56: Configuration Setup Wizard

    Chapter 2. Installation and Configuration • Subsystem certificate • TPS • SSL server certificate • Subsystem certificate 2.4. Configuration Setup Wizard When the installation process is complete, either when installing the initial subsystems or running the pkicreate tool, the script returns a URL pointing to the configuration page of the new subsystem. This HTML configuration wizard is used to configure the subsystem settings like the instance name and security domain, to request and generate keys and certificates, and to configure which Directory Server to use.

  • Page 57: Subsystem Type Panel

    Subsystem Type Panel The first security domain for the Certificate System is created when the default CA is configured. Every subsystem must belong to a security domain; no system can be successfully configured without an existing security domain. The only subsystem which can host a security domain is a CA. Figure 2.1.

  • Page 58: Pki Hierarchy Panel

    Chapter 2. Installation and Configuration cloning an existing subsystem, select the master subsystem from the list provided, and give the name of the new cloned subsystem. The list of subsystems in the Clone section list is retrieved from the security domain provided in the Security Domain panel. Figure 2.3.

  • Page 59: Ca Information Panel

    CA Information Panel For a CA, there are two possible configuration options: • Root CA. A root CA signs its own CA signing certificate and, therefore, can set its own certificate issuance rules. • Subordinate CA. A subordinate CA receives its CA signing certificate from a root CA. The root CA must be referenced here;...

  • Page 60: Drm Information Panel

    Chapter 2. Installation and Configuration Figure 2.6. Selecting the TKS 2.4.6. DRM Information Panel This panel is only available when configuring a TPS subsystem. The TPS can be associated with an existing DRM subsystem to enable server-side key generation. Similarly to setting the CA information, the DRM is selected from a list of all configured DRM subsystems within the security domain.

  • Page 61: Authentication Directory Panel

    Authentication Directory Panel 2.4.7. Authentication Directory Panel This panel is only available when configuring a TPS subsystem. All subsystems are configured to use a Directory Server database for system certificates and users. The TPS subsystem has an additional database for certificates and keys and to authenticate users which access the Enterprise Security Client.

  • Page 62: Key Store Panel

    Chapter 2. Installation and Configuration Figure 2.9. Configuring the Internal LDAP Database Information NOTE Do not share the same suffix and database name for more than one Certificate System subsystem. The same instance can be used for more than one subsystem, but different suffix and database names must be specified.

  • Page 63: Key Pairs Panel

    Key Pairs Panel Figure 2.10. Selecting the Key and Certificate Location The LunaSA partitions, the nCipher slots, and the NSS internal software token are provided in this screen. The internal software token is logged in by default. The password to this database is stored in /var/ lib/instance_ID/conf/password.conf.

  • Page 64: Subject Names Panel

    Chapter 2. Installation and Configuration Figure 2.11. Setting the Key Pair Type 2.4.11. Subject Names Panel This panel lists the different certificate subject names for all of the certificates issued for the subsystem being installed. This panel also sets which CA will issue these certificates. If the certificates for the subsystem, including certificates for a subordinate CA, will be issued by an external CA such as VeriSign or a Certificate System CA which is outside the security domain, select External CA from the list.

  • Page 65: Requests And Certificates Panel

    Requests and Certificates Panel Figure 2.12. Setting the Certificate Subject Name If an existing subsystem is being cloned, all of these fields are grayed out except the Server Certificate name field because the server certificate is regenerated. 2.4.12. Requests and Certificates Panel This panel has links to the certificate requests and the issued certificates, if the certificates were issued successfully.

  • Page 66: Export Keys And Certificates Panel

    Chapter 2. Installation and Configuration Figure 2.13. Certificate Request and Certificate Links If the certificates are signed by an external CA, such as a third-party CA or a Certificate System CA which is outside the security domain, then action required is shown under the certificate name, and there are action links to submit the certificate.

  • Page 67: Administrator Panel

    Administrator Panel Figure 2.14. Exporting the Certificates and Keys 2.4.14. Administrator Panel This panel creates the first administrator user for the instance. This user also has agent privileges, so the agent certificates and keys for the agent certificate are generated on the browser used to go through the configuration wizard.

  • Page 68: Installing The Certificate System

    Chapter 2. Installation and Configuration Pressing Next causes the browser to generate a key pair which consists of a public key and a private key. The public key is packaged in a certificate request that is submitted to the CA. If the requests are submitted to a Certificate System CA, the CA approves and signs the certificate request automatically, and the certificate is returned in the browser in the next panel.
  • Page 69 The force option bypasses any confirmation prompts that may otherwise appear during the installation. For example, to install the CA and then the DRM, use the following commands: rhpki-install -pki_subsystem=ca -pki_package_path=/media/cdrom/RedHat/RPMS -force rhpki-install -pki_subsystem=drm -pki_package_path=/media/cdrom/RedHat/RPMS -force The rhpki-install script uses the rpm program on Red Hat Enterprise Linux systems and pkginfo and pkgadd programs on Solaris 9 systems.

  • Page 70: Installing Through Up2Date

    Chapter 2. Installation and Configuration NOTE When the first subsystem is installed on a machine, the installation process automatically creates a new user (pkiuser) and group (pkiuser). All default Certificate System instances will run as this user and group. 2.5.2. Installing through up2date NOTE There is an environment variable, DONT_RUN_PKICREATE, which will stop the pkicreate script from running automatically after the subsystems are installed.
  • Page 71 Configuring a CA http://server.example.com:9080/ca/admin/console/config/login?pin=kI7E1MByNIUcPJ6RKHmH Using this URL skips the login screen. Alternatively, log into the setup wizard through admin link on the services page and supply the preop.pin value from the CS.cfg file when prompted. http://server.example.com:9080/ca/services 2. Create a new security domain. The default CA instance must create a new security domain;...

  • Page 72: Configuring A Drm, Ocsp, Or Tks

    Chapter 2. Installation and Configuration 2.6.2. Configuring a DRM, OCSP, or TKS 1. Open the configuration wizard. When the instance is installed, the process returns a success message which includes a URL with the login PIN. For example: http://server.example.com:10080/kra/admin/console/config/login?pin=kI7E1MByNIUcPJ6RKHmH Using this URL skips the login screen. Alternatively, log into the setup wizard through admin link on the services page and supply the preop.pin value from the CS.cfg file when prompted.

  • Page 73: Configuring A Tps

    Configuring a TPS /etc/init.d/rhpki-kra restart 2.6.3. Configuring a TPS 1. Open the configuration wizard. When the instance is installed, the process returns a success message which includes a URL with the login PIN. For example: http://server.example.com:7888/tps/admin/console/config/login?pin=kI7E1MByNIUcPJ6RKHmH Using this URL skips the login screen. Alternatively, log into the setup wizard through admin link on the services page and supply the preop.pin value from the CS.cfg file when prompted.

  • Page 74: Creating Additional Subsystem Instances

    Chapter 2. Installation and Configuration 11. The next panels generate and show certificate requests, certificates, and key pairs. If an external CA is used to issue the certificates, configuration cannot go forward until they are received from the CA. When they are issued, paste the certificates into this panel to add them to the TPS database, and then proceed with the installation.

  • Page 75: Running Pkicreate With Port Separation

    Running pkicreate with Port Separation For more information on the pkicreate tool options, see the Certificate System Command-Line Tools Guide. 2. When the instance is successfully created, the process returns a URL for the HTML configuration page. For example: http://server.example.com:10180/kra/admin/console/config/login?pin=nt2z2keqcqAZiBRBGLDf Section 2.6, 3.
  • Page 76 Chapter 2. Installation and Configuration 2. Open the configuration wizard. 3. In the Security Domain panel, add the clone to the same security domain to which the master belongs. 4. The Subsystem Type panel sets whether to create a new instance or a clone; select the clone radio button.

  • Page 77: Silent Installation

    -admin_email "admin@redhat.com" -admin_password redhat -agent_name "rhpki-ca2 agent" -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject "ca agent cert" -ldap_host server -ldap_port 389 -bind_dn "cn=directory manager" -bind_password redhat -base_dn "o=rhpki-ca2" -db_name "rhpki-ca2" -key_size 2048 -key_type rsa -save_p12 true -backup_pwd redhat Example 2.1. Silent Installation of a CA...

  • Page 78: Updating Certificate System Packages

    -preop_pin fS44I6SASGF34FD76WKJHIW4 -domain_name "testca" -admin_user admin -admin_email "admin@redhat.com" -admin_password redhat -agent_name "rhpki-tks2 agent" -ldap_host server -ldap_port 389 -bind_dn "cn=directory manager" -bind_password redhat -base_dn "o=rhpki-tks2" -db_name "rhpki-tks2" -key_size 2048 -key_type rsa -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject "tks agent cert" -backup_pwd redhat Example 2.2.

  • Page 79: Updating Certificate System On Red Hat Enterprise Linux

    Updating Certificate System on Red Hat Enterprise Linux Section 2.10.2, “Updating Certificate System on Solaris” • 2.10.1. Updating Certificate System on Red Hat Enterprise Linux For Red Hat Enterprise Linux, and individual package can up updated either by installing the specific RPM or by running up2date to update the package.
  • Page 80 Chapter 2. Installation and Configuration /etc/init.d/instance_ID stop 2. Log in as root. 3. Use the following commands to remove the previous instances: pkiremove -pki_instance_root=/var/lib -pki_instance_name=rhpki-ca pkiremove -pki_instance_root=/var/lib -pki_instance_name=rhpki-ocsp pkiremove -pki_instance_root=/var/lib -pki_instance_name=rhpki-tks pkiremove -pki_instance_root=/var/lib -pki_instance_name=rhpki-tps 4. Remove all subsystem binaries using rhpki-uninstall: rhpki-uninstall -pki_subsystem=all 5.

  • Page 81: Uninstalling Certificate System Subsystems

    Uninstalling Certificate System Subsystems 2.11. Uninstalling Certificate System Subsystems It is possible to remove individual subsystem instances or to uninstall all packages associated with an entire subsystem. Instances and subsystems are installed and uninstalled individually. For example, it is possible to uninstall a DRM subsystem while leaving an installed and configured CA subsystem. It is also possible to remove a single CA instance while leaving other CA instances on the machine.
  • Page 82 Chapter 2. Installation and Configuration rpm -ev rhpki-manage...

  • Page 83: Administrative Basics

    Chapter 3. Administrative Basics This chapter discusses the Certificate System administrative console, the configuration files, and other basic administrative tasks such as starting and stopping the server, managing logs, changing port assignments, and changing the internal database. 3.1. Administrative Console The Certificate System provides a GUI-based administration tool called the Console that is used for administrative tasks such as managing users and maintaining the subsystem, performs daily operational and managerial duties for the subsystem, and configures the server.

  • Page 84: Enabling Ssl Client Authentication For The Certificate System Console

    Chapter 3. Administrative Basics • The Status tab allows the administrator to view the contents of various logs maintained by the Section 3.9, “Logs” Certificate System instance. See for more information. Figure 3.1. Certificate System Console 3.2. Enabling SSL Client Authentication for the Certificate System Console Certificate-based authentication to the Certificate System Console can be enabled so that administrators must authenticate using a client certificate before logging into the Certificate System...
  • Page 85 Enabling SSL Client Authentication for the Certificate System Console failure (14290): Error receiving connection SEC_ERROR_INADEQUATE_CERT_TYPE - Certificate type not approved for application.) 2. Stop the subsystem. /etc/init.d/instance_ID stop 3. Open the instance configuration directory, /var/lib/instance_ID/conf. 4. Open the file CS.cfg. 5.

  • Page 86: System Passwords

    Chapter 3. Administrative Basics If the procedure is successful, the command prints the following: pk12util: PKCS12 IMPORT SUCCESSFUL 3. Start the Console; now, it prompts for a certificate. 3.3. System Passwords The Certificate System stores passwords used to bind to servers or to unlock tokens when the server starts in a plain text file, password.conf.
  • Page 87 Protecting the password.conf File However, storing passwords in clear text can be dangerous. Setting proper file permissions protects this file. Alternatively, the password.conf file can be by-passed by doing the following: 1. Back up the password.conf file. 2. Remove the password.conf file. rm password.conf 3.

  • Page 88: Password-Quality Checker

    Chapter 3. Administrative Basics 3.3.2. Password-Quality Checker A Certificate System plug-in, password-quality checker, monitors the quality of passwords set within the Certificate System. All passwords used in the Certificate System are checked by the password- quality checker, which by default checks that the length of a password is at least 8 characters long. There are no checks regarding which characters are valid or invalid.

  • Page 89: Restarting A Subsystem After A Machine Restart

    HTML services page and the administrative console. 1. Restart the Directory Server Administration Server. cd /opt/redhat-ds/ ./start-admin 2. Restart the Directory Server. cd /opt/redhat-ds/slapd-instance_ID ./start-slapd...

  • Page 90: Locating The Configuration File

    Chapter 3. Administrative Basics An ASCII file, named CS.cfg, is created and populated with the appropriate configuration parameters when a subsystem is first installed. The way the instance functions are modified is by making changes through the subsystem console, which is the recommended method. The changes made in the administrative console are reflected in the configuration file.
  • Page 91 Guidelines for Editing the Configuration File • Comment lines begin with the pound (#) character. Comment lines, blank lines, unknown parameters, or misspelled parameters are ignored by the server. • Subsystem-specific parameters are distinguished by a prefix identifying the subsystem as follows: •...

  • Page 92: Duplicating Configuration From One Instance To Another

    Chapter 3. Administrative Basics • Each job or configured instance of a job module is identified by the name specified when the job was created. • There can be as many instances of an implementation as desired; each instance must have a unique name.
  • Page 93 Other File Locations Directory Location Contents bit Red Hat Enterprise Linux AS and ES i386 machines only. JNI security Java™ archive files shared by the /usr/lib/java/dirsec CA, RA, DRM, OCSP, and TKS subsystems. For 32-bit Red Hat Enterprise Linux AS and ES i386 machines only.

  • Page 94: Default Server Instance Locations

    Chapter 3. Administrative Basics Directory Location Contents For TPS subsystems only. Mozilla LDAP SDK /usr/lib/mozldap tools shared by TPS subsystems. For 32-bit Red Hat Enterprise Linux AS and ES i386 machines only. For TPS subsystems only. Apache modules /usr/lib64/httpd/modules shared by TPS subsystems. For 64-bit Red Hat Enterprise Linux AS and ES x86_64 machines only.
  • Page 95 Default Server Instance Locations 3.6.6.2. DRM Default Instance Location Default Location Type of Description Object File The script used to start, stop, or restart the /etc/init.d/rhpki-kra DRM instance. Directory Contains the configuration file for the DRM /etc/rhpki-kra instance. Directory Contains the user-specific default and /var/lib/rhpki-kra customized forms and data for the DRM instance.

  • Page 96: Using Security-Enhanced Linux

    Chapter 3. Administrative Basics Default Location Type of Description Object Directory Contains the user-specific default and /var/lib/rhpki-tks customized forms and data for the TKS instance. Directory Contains the log files for the TKS instance. /var/log/rhpki-tks File A log file containing the configuration steps /var/log/rhpki-tks- performed to create the TKS instance.

  • Page 97: Using Java Servlets

    Using Java Servlets SELINUXTYPE=targeted ########################################### NOTE All of the instances run in un-confined mode with no security-enhanced policies in effect for the server. 3.8. Using Java Servlets Each subsystem Java™ servlet supports a parameter called xml, which can have a value of either true or false.

  • Page 98: About Logs

    Chapter 3. Administrative Basics Section 3.9.11, “Registering a Log Module” • Section 3.9.12, “Deleting a Log Module” • 3.9.1. About Logs The Certificate System subsystems create log files that record events related to activities, such as administration, communications using any of the protocols the server supports, and various other processes employed by the subsystems.
  • Page 99 About Logs wQEAwIF4DAzMBUGCSsGAQUFBwUBAQwIcmVnVG9rZW4wGgYJKwYBBQUHBQECDA1hdXRoZW50aWNhdG9yoYGTMA0GCSqGSIb3DQEBBQUAA4G +ck/ xW0Nj8H32krmv7DzWzXkLBD2MSMTmxBORX5dCsxkCdiHCEgCfTOnxCJpdmjHPuSPOaQmtKBpAEVaQoUwnEytOqDkCkhlZ1nt02w1 [06/Jun/2008:14:59:38][http-9443-Processor24]: ProfileSubmitServlet: key=$request.profile$ value=true [06/Jun/2008:14:59:38][http-9443-Processor24]: ProfileSubmitServlet: key= $request.cert_request_type$ value=crmf [06/Jun/2008:14:59:38][http-9443-Processor24]: ProfileSubmitServlet: key= $request.requestversion$ value=1.0.0 [06/Jun/2008:14:59:38][http-9443-Processor24]: ProfileSubmitServlet: key=$request.req_locale$ value=en [06/Jun/2008:14:59:38][http-9443-Processor24]: ProfileSubmitServlet: key=$request.requestowner $ value=RA-test4.redbudcomputer.local-4747 [06/Jun/2008:14:59:38][http-9443-Processor24]: ProfileSubmitServlet: key=$request.dbstatus$ value=NOT_UPDATED [06/Jun/2008:14:59:38][http-9443-Processor24]: ProfileSubmitServlet: key=$request.subject$ value=uid=jsmith, e=jsmith@example.com [06/Jun/2008:14:59:38][http-9443-Processor24]: ProfileSubmitServlet: key= $request.requeststatus$ value=begin [06/Jun/2008:14:59:38][http-9443-Processor24]: ProfileSubmitServlet: key= $request.auth_token.user$ value=uid=RA-...
  • Page 100 Chapter 3. Administrative Basics 3.9.1.4. Installation Logs Every time a subsystem is created either through the initial installation or creating additional instances with pkicreate, an installation file with the complete debug output from the installation, including any errors and, if the installation is successful, the URL and PIN to the configuration interface for the instance.

  • Page 101: Services That Are Logged

    Services That Are Logged 3.9.2. Services That Are Logged Table 3.8, All major components and protocols of Certificate System log messages to log files. “Services Logged” lists services that are logged by default. To view messages logged by a specific Section 3.9.9, “Monitoring Logs”.
  • Page 102 Chapter 3. Administrative Basics NOTE All of the Certificate System subsystems (CA, RA, DRM, TKS, and OCSP) have seven log levels, 0 to 6, except for the TPS subsystem, which has eleven log levels (0 to 10). Log levels are represented by numbers 0 to 6 (0 to 10 for TPS), each number indicating the level of logging to be performed by the server.

  • Page 103: Buffered Versus Unbuffered Logging

    Buffered Versus Unbuffered Logging Log level Message Description category PDU related These messages relate transactions and rules processed on a events PDU, such as creating MAC tokens. PDU related This log levels gives verbose log messages for events events processed on a PDU, such as creating MAC tokens. All logging This log level enabled all logging levels for the TPS logs.

  • Page 104: Configuring Logs In The Console

    Chapter 3. Administrative Basics • The age limit for the corresponding file is reached. The corresponding log file is equal to or older than the interval specified by the rolloverInterval configuration parameter. The default value for this parameter is 2592000 seconds (every thirty days). When a log file is rotated, the old file is named using the name of the file with an appended time stamp.

  • Page 105: Configuring Logs In The Cs.cfg File

    Configuring Logs in the CS.cfg File • enabled . Select to enable; deselect to disable. Only enabled logs actually record events. • level . Sets the log level. The choices are Debug, Information, Warning, Failure, Misconfiguration, Catastrophe, and Security. The level field does not have a drop-down list.

  • Page 106: Configuring Tps Logs

    Chapter 3. Administrative Basics 4. To configure a log instance, modify the parameters associated with that log. These parameters begin with log.instance and include the following: • bufferSize . Specify the buffer size in kilobytes (KB) for the log. The default size is 512 KB. Section 3.9.4, “Buffered Versus Unbuffered Logging”.

  • Page 107: Monitoring Logs

    Monitoring Logs Additionally, certain log features that are available to the other subsystems' logs do not apply to TPS logging: • Log rotation • Log signing • Registering and deleting log modules • Buffered logging For each log generated by a TPS instance, there are three parameters which can be configured: •...

  • Page 108: Signing Log Files

    Chapter 3. Administrative Basics • Source . Select the Certificate System component or service for which log messages are to be displayed. Choosing All means messages logged by all components that log to this file are Section 3.9.2, “Services That Are Logged”.

  • Page 109: Registering A Log Module

    Registering a Log Module • output specifies the name of the JAR file (a signed zip file). • input specifies the path to the directory that contains the log files. 3.9.11. Registering a Log Module New log plug-in modules can be registered through the Console. Registering a new module involves specifying the name of the module and the full name of the Java™...
  • Page 110 Chapter 3. Administrative Basics NOTE The audit logs for a TPS subsystem cannot be signed. A log is set to a signed audit log by setting the logSigning parameter to enable and providing the nickname of the certificate used to sign the log. When a log is set as a signed audit log, only a user with auditor privileges can access and view the log.
  • Page 111 Signed Audit Log Logging Event Type of Log Messages Generated CONFIG_ENCRYPTION A change is made to the encryption settings, including certificate settings and SSL cipher preferences. CONFIG_TRUSTED_PUBLIC_KEY The Certificate Setup Wizard is used to import certificates into the certificate database or any activity in Manage Certificates.
  • Page 112 Chapter 3. Administrative Basics Logging Event Type of Log Messages Generated CERT_STATUS_CHANGE_REQUEST_PROCESSED Shows when a certificate status change is processed. AUTHZ_SUCCESS Shows when a user is successfully processed by the authorization servlets. AUTHZ_FAIL Shows when a user is not successfully processed by the authorization servlets.

  • Page 113: Self-Tests

    Self-Tests 6. Assign auditor users by creating the user and assigning that entry to the auditor group. Members of the auditor group are the only users who can view and verify the signed audit log. See Section 17.2, “Creating Users” for details about setting up auditors.

  • Page 114: Self-Test Logging

    Chapter 3. Administrative Basics 5. The On-Demand Self Tests Results window appears, showing the logged events for this run of the self-tests. 3.10.1. Self-Test Logging A new log, selftest.log, is added to the log directory that contains reports for both the start up self-tests and the on-demand self-tests.

  • Page 115: Ports

    Ports it reaches this size, the file is copied to a rotated file, and a new log file is started. For more Section 3.9.5, “Log File Rotation”. information, see • register . If this variable is set to false (the default value), the self-test messages are only logged to the log file specified by selftests.container.logger.fileName.
  • Page 116 Chapter 3. Administrative Basics Figure 3.2. Certificate System Ports 3.11.1.1. Port Considerations When choosing ports for a subsystem, consider the following: • Choose ports that are unique on the host system. To verify that a port is available for use, check the appropriate file for the operating system; port numbers for network-accessible services are usually maintained in a file named services.
  • Page 117 About Ports 3.11.1.2. Web Port The HTML-based services, such as the agent and end-entities' services pages and the Console, are accessed through the web. The Tomcat web server is used for the CA, RA, DRM, OCSP, and TKS subsystem services, and the Apache web server is used for the TPS subsystem services. 3.11.1.3.

  • Page 118: Changing A Port Number

    Chapter 3. Administrative Basics 3.11.2. Changing a Port Number To change a port number for a CA, RA, DRM, OCSP, or TKS subsystem: 1. Stop the subsystem instance. 2. Open the instance's configuration directory. cd /var/lib/instance_ID/conf 3. Open the server.xml file, and edit the appropriate port numbers. For example: #Define a non-SSL HTTP/1.1 Connector on port 8080<Connector port="9080"...
  • Page 119 Configuring Port Separation Only the subsystems which have separate services interfaces (CA, OCSP, DRM, and TKS) can be configured for port separation. The other subsystems (RA and TPS) cannot. NOTE Errata RHBA-2010:0170 Port separation is required to apply and resolve a vulnerability in the TLS/SSL protocols.
  • Page 120 Chapter 3. Administrative Basics <Connector port="9445" /> <Engine name="CatalinaAdmin" defaultHost="localhost"> <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/> <Host name="localhost" appBase="webapps.admin" unpackWARs="true" autoDeploy="false" xmlValidation="false" xmlNamespaceAware="false"> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/> </Host> </Engine> </Service> ... end-entities services entry ... <Service name="CatalinaEE"> <Connector port="9443" ... /> <Engine name="CatalinaEE"...

  • Page 121: Redirecting Subsystem Communications To Secure End-Entities Port

    Redirecting Subsystem Communications to Secure End-Entities Port cd webapps.ee mv agent agent.orig mv admin admin.orig Do this for all three services. 7. Still in the webapps.ee/ directory, open the WEB-INF directory. cd WEB-INF/ 8. Edit the web.xml file and comment out the caauths servlet mapping. <!-- <servlet-mapping>...
  • Page 122 2. Before making any edits to the CA configuration, back up the following files: • /var/lib/instance_name/conf/server.xml • /var/lib/instance_name/web-apps.ee/ca/ee/ca/ProfileSelect.template 3. Open the server.xml file. vim /var/lib/instance_name/conf/server.xml 4. In the server.xml file, change the clientAuth directive in the agent connector to true. <Connector name="Agent" port="9443" maxHttpHeaderSize="8192" https://rhn.redhat.com/errata/RHBA-2010-0170.html https://rhn.redhat.com/errata/RHBA-2010-0165.html...
  • Page 123 Redirecting Subsystem Communications to Secure End-Entities Port maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="true" sslProtocol="SSL" 5. Open the profile selection template. vim /var/lib/instance_name/web-apps.ee/ca/ee/ca/ProfileSelect.template 6. Replace value in the uri line with the URL to the agent port. The original line is: uri = 'profileSubmitSSLClient';...
  • Page 124 Chapter 3. Administrative Basics <Connector name="Agent" port="10443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="true" sslProtocol="SSL" 5. Restart the subsystem. For example: /etc/init.d/rhpki-kra restart 3.11.4.3. Updating the OCSP and TKS 1. Update the NSS packages by installing the system nss packages. up2date nss 2.

  • Page 125: The Internal Ldap Database

    The Internal LDAP Database LD_PRELOAD="/usr/lib64/libssl3.so ${LD_PRELOAD}" On 32-bit systems, the path is /usr/lib/. 4. Restart the subsystem. For example: /etc/init.d/rhpki-tps restart 3.11.4.5. Updating the RA 1. Update the NSS packages by installing the system nss packages and install the new RA packages.

  • Page 126: Changing The Internal Database Configuration

    Chapter 3. Administrative Basics To fulfill these functions, the Certificate System is incorporated with a Red Hat Directory Server, referred to as the internal database or local database. The Directory Server is referenced as part of the Certificate System configuration; when the Certificate System subsystem is configured, a new database is created within the Directory Server.

  • Page 127: Enabling Ssl Client Authentication With The Internal Database

    Enabling SSL Client Authentication with the Internal Database The DN should be the Directory Manager DN. The Certificate System subsystem uses this DN when it accesses the directory tree to communicate with the directory. 4. Click Save. The configuration is modified. If the changes require restarting the server, a prompt appears with that message.

  • Page 128: Restricting Access To The Internal Database

    Chapter 3. Administrative Basics 3.12.3. Restricting Access to the Internal Database The Red Hat Directory Server Console displays an entry or icon for the Directory Server instance that the Certificate System uses as its internal database. Unlike the Certificate System Console, in which access is restricted to users with Certificate System administrator privileges, the Directory Server Console can be accessed by any user.
  • Page 129 Backing up and Restoring Certificate System data. If the information is stored in the default directories in the instance alias directory, then it is backed up with the instance directory. To back it up separately, use a utility such as tar or zip. •...
  • Page 130 Chapter 3. Administrative Basics /etc/init.d/instance_ID start NOTE Stop the subsystem instance before restoring the instance or the security databases.

  • Page 131: Certificate Manager

    Chapter 4. Certificate Manager The Certificate Manager subsystem serves as a Certificate Authority (CA) in the PKI. It can issue and revoke certificates; create and issue CRLs; and publish certificates and CRLs. This chapter discusses the Certificate Manager subsystem. It provides an overview of the subsystem including an overview of processes, information about cross-signed CA certificates, and other information for maintaining the Certificate Manager.

  • Page 132: Revocation

    Chapter 4. Certificate Manager Automatic notification can be set up so an email is sent to an agent any time a request appears in the queue. Also, an automated job can be set to send a list of the contents of the queue to Chapter 18, Automated Notifications Chapter 19, agents on a preconfigured schedule.

  • Page 133: Certificate Manager Certificates

    Certificate Manager Certificates An agent can revoke any certificate issued by the Certificate Manager by searching for the certificate in the agent services interface and then marking it revoked. Once a certificate is revoked, it is marked revoked in the database and in the publishing directory, if the Certificate is set up for publishing. If the internal OCSP service has been configured, the service determines the status of certificates by looking them up in the internal database.

  • Page 134: Ocsp Signing Key Pair And Certificate

    Chapter 4. Certificate Manager 4.2.2. OCSP Signing Key Pair and Certificate The key type, key size, key algorithm, and validity period provided for the CA signing key pair are used to generate the OCSP signing key pair. The subject name of the OCSP signing certificate is in the form cn=OCSP cert-instance_ID, and it contains extensions, such as OCSPSigning and OCSPNoCheck, required for signing OCSP responses.

  • Page 135: Cross-Pair Certificates

    Cross-Pair Certificates cn=demoCA, o=Example Corporation, ou=Engineering, c=US Many combinations of name-value pairs are possible for the Certificate Manager's DN. The DN must be unique and readily identifiable, since any end entity can examine it. 4.2.4.2. CA Signing Certificate Validity Period Every certificate, including a Certificate Manager signing certificate, must have a validity period.

  • Page 136: Subordination To A Public Ca

    Chapter 4. Certificate Manager a CA which functions as a root CA within the Certificate System deployment can be subordinate to a third-party CA. A Certificate Manager (or CA) is subordinate to another CA because its CA signing certificate, the certificate that allows it to issue certificates, is issued by another CA. The CA that issued the subordinate CA signing certificate controls the CA through the contents of the CA signing certificate.

  • Page 137: The Domain.xml File

    The domain.xml File registry. The security domain service in Certificate System manages both the registration of PKI services for Certificate System subsystems and a set of shared trust policies. The registry provides a complete view of all PKI services provided by the subsystems within that domain.

  • Page 138: Security Domain Roles

    Chapter 4. Certificate Manager <CAList> <CA> <SubsystemName>rhpki-ca</SubsystemName> <Host>server.example.com</Host> <SecurePort>9543</SecurePort> <DomainManager>true</DomainManager> <Clone>false</Clone> </CA> <SubsystemCount>1</SubsystemCount> </CAList> </DomainInfo> The URL to the CA uniquely identifies the security domain. The security domain is also given a friendly name, such as Example Corp Intranet PKI. All other subsystems -- DRM, TPS, TKS, OCSP, and other CAs -- must become members of the security domain by supplying the security domain URL when configuring the subsystem.

  • Page 139: Creating A Security Domain

    Creating a Security Domain Role Description Enterprise CA Administrators • Automatically approve any sub-CA, server, and subsystem certificate from any CA in the domain. • Register and unregister CA subsystem information in the security domain. Enterprise DRM Administrators • Automatically approve any transport, storage, server, and subsystem certificate from any CA in the domain.

  • Page 140: Joining A Security Domain

    Chapter 4. Certificate Manager By default, the CA administrator is assigned as the security domain administrator, with the privileges to manage the domain. A domain.xml file is created in the CA instance conf/ directory. This file contains all the important information about the domain.
  • Page 141 Configuring the Certificate Manager Instance database information, self-tests, and other administrative tasks. General subsystem configuration is Table 4.2, “General Subsystem Configuration Links”. outlined in Configuration Section Section 2.7, “Creating Additional Subsystem Adding additional CA instances. Instances” Chapter 3, Administrative Basics General configuration and management such as changing port numbers, setting up logging, running self-tests, and managing the internal...

  • Page 142: Ca Certificate Reissuance

    Chapter 4. Certificate Manager Configuration Section Chapter 20, Configuring the Certificate System Configuring cloning. for High Availability Table 4.2. General Subsystem Configuration Links 4.6. CA Certificate Reissuance When a CA signing certificate expires, all certificates signed with the CA's corresponding signing key become invalid.
  • Page 143 Changing the Rules for Issuing Certificates Figure 4.1. The General Settings Tab 3. The General Setting tab of the Certificate Manager tab contains the following fields: • Override validity nesting requirement. This checkbox sets whether the Certificate Manager can issue certificates with validity periods longer than the CA signing certificate validity period. If this checkbox is not selected and the CA receives a request with validity period longer than the CA signing certificate's validity period, it automatically truncates the validity period to end on the day the CA signing certificate expires.

  • Page 144: Setting Restrictions On Ca Certificates Through Certificate Extensions

    Chapter 4. Certificate Manager The serial number range allows multiple CAs to be deployed and balances the number of certificates each CA issues. The combination of an issuer name and a serial number uniquely identifies a certificate. To ensure that two distinct certificates issued by the same authority do not contain the same serial number, make sure the serial number ranges do not overlap among cloned CAs.
  • Page 145 Setting Restrictions on CA Certificates through Certificate Extensions Extensions Present A certificate chain generally consists of an entity certificate, zero or more intermediate CA certificates, and a root CA certificate. Typically, the root CA certificate is self-signed and is loaded into a certificate database as a trusted CA.

  • Page 146: Creating Certificate Manager Agents And Administrators

    Chapter 4. Certificate Manager CA to issue server certificates and email certificates; cRLSign, which allows a CA to sign CRLS; and then several options for encrypting data. For the Extended Key Usage extension, there are several OIDs which can be set for email, server authentication, or client authentication. For more Section 13.7.8, “Key Usage Extension Default”...

  • Page 147: Checking The Revocation Status Of Agent Certificates

    Checking the Revocation Status of Agent Certificates Figure 4.2. Creating a New User The group to which the user belongs determines what privileges the user has. Assign agents and administrators to the appropriate subsystem group. 4. Store the user's certificate. a.
  • Page 148 Chapter 4. Certificate Manager NOTE The subsystem CS.cfg configuration file includes a parameter, jss.ocspcheck.enable, which sets whether a Certificate Manager should use an OCSP to verify the revocation status of the certificate it receives as a part of SSL client or server authentication.

  • Page 149: Crl Signing Key Pair And Certificate

    CRL Signing Key Pair and Certificate 4.11. CRL Signing Key Pair and Certificate A Certificate Manager uses the key pair corresponding to the CA signing certificate for signing certificates and certificate revocation lists (CRLs). To use a different key pair to sign the CRLs that the Certificate Manager generates, then a CRL signing certificate can be created.

  • Page 150: Dns In The Certificate System

    Chapter 4. Certificate Manager SHA1withRSA, if the key type is RSA; and token_name is the name of the token used for generating the key pair and the certificate. If the internal/software token is used, use Internal Key Storage Token as the value. For example, the entries might look like this: ca.crl_signing.cacertnickname=crlSigningCert cert-rhpki-ca ca.crl_signing.defaultSigningAlgorithm=MD5withRSA...

  • Page 151: Extending Attribute Support

    Extending Attribute Support Attribute Value Type Object Identifier 1.2.840.113549.1.9.8 unstructuredaddress PrintableString Table 4.3. Allowed Characters for Value Types 4.12.1. Extending Attribute Support Table 4.3, “Allowed Characters By default, the Certificate System supports the attributes identified in for Value Types”. This list of supported attributes can be extended by creating or adding new attributes.
  • Page 152 Chapter 4. Certificate Manager 3. Open the configuration file, CS.cfg. 4. Add the new attributes to the configuration file. For example, to add three proprietary attributes, MYATTR1 that is a DirectoryString, MYATTR2 that is an IA5String, and MYATTR3 that is a PrintableString, add the following lines at the end of the configuration file: X500Name.attr.MYATTR1.oid=1.2.3.4.5.6 X500Name.attr.MYATTR1.class=netscape.security.x509.DirStrConverter...
  • Page 153 Extending Attribute Support • Printable • IA5String • UniversalString • BMPString • UTF8String For example, the DER-encoding ordered can be listed as follows: X500Name.dirEncodingOrder=Printable,BMPString To change the DirectoryString encoding, do the following: 1. Stop the Certificate Manager. /etc/init.d/rhpki-ca stop 2. Open the /var/lib/rhpki-ca/conf/ directory. 3.

  • Page 155: Registration Authority

    Chapter 5. Registration Authority A registration authority is a subsystem which processes and validates certificate requests, before sending them to a certificate authority to issue the certificate. RAs lighten the load on CAs by performing request approval separately from certificate issuance, and also allow for more localized control over request approval criteria.

  • Page 156: Roles

    Chapter 5. Registration Authority The RA also supports a range of reusable Perl objects. This enables administrators to build their own enrollment work flow. 5.1.3. Roles The RA currently supports the following roles: • End Users — people who submit enrollment requests •...

  • Page 157: Installation And Configuration

    Installation and Configuration Enrolling an Agent Certificate In this scenario, you use the RA's EE interface to request a PIN. The request is approved by an existing agent, and the PIN generated. The agent returns the PIN to the user, who then accesses the enrollment page to enter their information, one-time PIN.

  • Page 158: Configuration

    Installing: rhpki-ra ######################### [8/8] PKI instance creation Utility ... PKI instance creation completed ... Starting rhpki-ra: PKI service(s) are available at https://dhcp-87.brisbane.redhat.com:12889 Server can be operated with /etc/init.d/rhpki-ra start | stop | restart Please start the configuration by accessing: http://dhcp-87.brisbane.redhat.com:12888/ra/admin/console/config/login? pin=QgSU3EZSgISshGrKtYPa Install finished.
  • Page 159 URL of the Security Domain that you are going to join. In this example, the Security Domain is available at https:// willow.brisbane.redhat.com:9443. Figure 5.1. Specifying the Security Domain Click Next to move to the Display Certificate Chain page.
  • Page 160 Chapter 5. Registration Authority Figure 5.2. Specifying the Subsystem Type Click Next to move to the CA Information page. On the CA Information page, you need to select the CA that is responsible for issuing certificates. Select the appropriate CA from the list. Click Next to move to the Internal Database page.
  • Page 161 Configuration Figure 5.3. Specifying the Subject Names Click Next to generate the Certificate Requests and to move to the Certificate Requests page. 11. The Certificate Requests page provides information about the status of the Certificate Signing Requests (CSRs). Refer to the help text on the page for more information about these CSRs. Click Next to move to the Administrator page.

  • Page 162: Directory Structure

    Chapter 5. Registration Authority • Server Certificate — this is used to communicate with RA users. (This is the server identity of the RA.) • Subsystem Certificate — this is used to communicate with the CA. (This is the client identity of the RA.) Multiple RA instances can communicate with a single CA.
  • Page 163 Specifies the filename of the error log file. logging.error.level Specifies the level to which error logging should occur. The following example shows the set of parameters used to specify the connection from the RA to the conn.ca1.clientNickname=subsystemCert cert-rhpki-ra conn.ca1.hostport=water.sfbay.redhat.com:9443 conn.ca1.keepAlive=true conn.ca1.retryConnect=3 conn.ca1.servlet.enrollment=/ca/ee/ca/profileSubmitSSLClient...

  • Page 164: Ra Request Queue Plugins

    Specifies which plugins to call when a request is canceled. request.<request_type>.create_request Specifies which plugins to call when a request is created. For example, you may see the following for SCEP enrollment: request.scep.approve_request.0.pinFormat=$site_id request.scep.approve_request.0.plugin=PKI::Request::Plugin::CreatePin request.scep.approve_request.num_plugins=1 request.scep.cancel_request.num_plugins=0 request.scep.create_request.0.assignTo=agents request.scep.create_request.0.plugin=PKI::Request::Plugin::AutoAssign request.scep.create_request.1.mailTo=nkwan@redhat.com request.scep.create_request.1.plugin=PKI::Request::Plugin::EmailNotification request.scep.create_request.1.templateDir=/usr/share/rhpki/ra/conf request.scep.create_request.1.templateFile=mail_create_request.vm request.scep.create_request.num_plugins=2 request.scep.profileId=caAgentServerCert request.scep.reqType=pkcs10...

  • Page 165: Libraries

    Libraries 5.2.5. Libraries The RA also provides the following Perl libraries to facilitate the creation of custom enrollment workflows: Library Description Perl interface to access the certificate store in the RA. PKI::Base::CertStore (/var/lib/rhpki-ra/ lib/perl/PKI/Base/ CertStore) PKI::Base::PinStore (/ Perl interface to access the one-time PIN store. var/lib/rhpki-ra/lib/ perl/PKI/Base/PinStore) Perl interface to access the user and group database.
  • Page 166 Chapter 5. Registration Authority A particular site might require more than one RA instance, each having its own set of RA agents. If the site policy is to disallow cross-management between the RA instances, then extra configuration is needed to ensure that the policy is not violated. The following procedure describes how to add a new RA instance to an existing security domain.
  • Page 167 Configuring Additional RA Instances cp caDualRAuserCert.cfg caDualRAi2userCert.cfg Edit the new file to suit the new profile: vi caDualRAi2userCert.cfg Search for "raCertAuth" and change it to "ra2CertAuth" Save and close the file. Change to the CA configuration directory, and edit the CS.cfg file cd /var/lib/rhpki-ca/conf vi CS.cfg Search for "profile.list"...
  • Page 168 Chapter 5. Registration Authority Change "/admin/ca/registerRaUser" to "/admin/ca/registerRa2User". Save and close the file. Use the following command to restart the CA: /etc/rc.d/init.d/rhpki-ca restart The following procedure describes how to create a new RA instance, and must be performed on the server that hosts the RA.

  • Page 169: Customizing The Subject Dn In The Csr

    Customizing the Subject DN in the CSR When you have finished configuring the new RA, restart the instance using the command above. Note If any errors occurred and you need to recreate the RA2 instance, you can remove the existing RA2 instance using the pkiremove command, as follows: # pkiremove -pki_instance_root=/var/lib -pki_instance_name=rhpki-ra2 You can then run the pkicreate procedure again.

  • Page 170: Using The End Users Services Interface

    Chapter 5. Registration Authority WARNING The Subject DN must match the pattern specified in the Subject Name Constraint definition of the enrollment profile. The default user enrollment profile is specified by / var/lib/rhpki-ca/profiles/ca/caDualRAuserCert.cfg. Consider the following example: policyset.userCertSet.1.constraint.name=Subject Name Constraint policyset.userCertSet.1.constraint.params.pattern=UID=.* policyset.userCertSet.1.constraint.params.accept=true Using this definition, certificates are only issued if the subject name matches the pattern "UID=.*".
  • Page 171 Using the End Users Services Interface 5.3.3.1.1. Configuration CA Configuration If the router communicates directly with the CA, the administrator must add the following to the /var/ lib/rhpki-ca/conf/flatfile.txt file (one-time PIN file) on the CA: UID:<IP address of the router> PWD:<One-time PIN>...
  • Page 172 Chapter 5. Registration Authority Note Use the following command to retrieve the Cisco router IP address: scep>show ip interface ethernet0/0 This command should return information similar to the following (irrelevant output has been trimmed): Ethernet0/0 is up, line protocol is up Internet address is 10.14.1.94/24 Broadcast address is 255.255.255.255 Address determined by setup command...
  • Page 173 Using the End Users Services Interface Procedure 5.8. Submitting a Server CSR On the Services page on the RA, click SSL End Users Services. Click Server Enrollment to display the Server Enrollment page, and then click Request Submission - Administrator. Enter the required details for the Server ID, Site ID and other fields, and then click Submit.
  • Page 174 Chapter 5. Registration Authority Requesting a one-time PIN The first step in becoming an RA Agent is for the user to apply for a PIN and have it approved by the RA. This PIN is then used to apply for an Agent Certificate. Procedure 5.10.

  • Page 175: Using The Agent Services Interface

    Using the Agent Services Interface Upon successful enrollment, the base64 encoding of the certificate is displayed and can be copied. 5.3.3.5. Requesting Status Checks You use the Request Status page to request the status of any submitted CSR. To request the status of a CSR, enter the request ID in the Request Id field and click Check. This returns a page with the status of the CSR, including any error messages.
  • Page 176 Chapter 5. Registration Authority On the Administrator interface, click Add New User or Add New Group, and enter the required details. When you have entered all of the required details, click Add User or Add Group, as appropriate. Note If you are adding a new user, this user must have already enrolled for and received a certificate.

  • Page 177: Command-Line Operations

    Procedure 5.20. To query the database using SQL: Launch sqlite3 from command line, as follows: [redhat@willow ~]$ sqlite3 /var/lib/rhpki-ra/conf/dbfile When a connection is established to the database, you should see the sqlite prompt: sqlite> You can now use standard sqlite commands to query the database, for example:...
  • Page 178 Chapter 5. Registration Authority • To display all user information, use the following command: sqlite> select * from users; • To display all request information, use the following command: sqlite> select * from requests; • To display a list of available tables, use the following command: sqlite>...

  • Page 179: Online Certificate Status Protocol Responder

    Chapter 6. Online Certificate Status Protocol Responder This chapter provides an overview of an Online Certificate Status Protocol (OCSP) service and explains how the OCSP service verifies the current status of the certificates issued by the Certificate Manager. The chapter also explains how to configure the Online Certificate Status Managers to publish CRLs.

  • Page 180: Ocsp Responses

    Chapter 6. Online Certificate Status Protocol Responder as an OCSP responder certificate. The required certificate extensions, such as OCSPNoCheck and Extended Key Usage, can be added to the certificate when the certificate request is submitted. Section 6.3, For more information about the certificates associated with the OCSP Manager, see “Online Certificate Status Manager Certificates”.

  • Page 181: Online Certificate Status Manager Certificates

    Online Certificate Status Manager Certificates Online Certificate Status Manager. The Online Certificate Status Manager stores each Certificate Manager's CRL in its internal database and uses the appropriate CRL to verify the revocation status of a certificate when queried by an OCSP-compliant client. The Certificate Manager can generate and publish CRLs whenever a certificate is revoked and at specified intervals.

  • Page 182: Recognizing Online Certificate Status Manager Certificates

    Chapter 6. Online Certificate Status Protocol Responder The Online Certificate Status Manager uses a single server certificate for authentication purposes. Additional server certificates can be installed and used for different purposed. For instructions, see Section 11.5, “Configuring the Server Certificate Use Preferences”.

  • Page 183: Creating Online Certificate Status Manager Agents And Administrators

    Creating Online Certificate Status Manager Agents and Administrators Configuration Section Section 17.6, “Authorization for Certificate Managing the access control lists (ACLs) for user System Users” authorization. Section 11.2, “Requesting and Receiving Requesting and installing certificates and • Certificates” managing tokens. Section 11.4.1, “Installing Certificates in the •...

  • Page 184: Configuring The Certificate Manager's Internal Ocsp Service

    Chapter 6. Online Certificate Status Protocol Responder Figure 6.1. Creating a New User The group to which the user belongs determines what privileges the user has. Assign agents and administrators to the appropriate subsystem group. 4. Store the user's certificate. a.

  • Page 185: Setting Up The Ocsp Responder

    Setting up the OCSP Responder 1. Go to the CA's end-entities page. For example: https://server.example.com:9443/ca/ee/ca/ 2. Find the CA signing certificate. 3. Look for the Authority Info Access extension in the certificate, and note the Location URIName value, such as http://server.example.com:9080/ca/ocsp. 4.

  • Page 186: Identifying The Ca To The Ocsp Responder

    Chapter 6. Online Certificate Status Protocol Responder 3. The certificate profiles must be configured to include the Authority Information Access extension, pointing to the location at which the Certificate Manager listens for OCSP service requests. See Section 6.6, “Configuring the Certificate Manager's Internal OCSP Service” for more information.

  • Page 187: Verify Certificate Manager And Online Certificate Status Manager Connection

    Verify Certificate Manager and Online Certificate Status Manager Connection 1. Get the Certificate Manager's base-64 CA signing certificate from the end-entities page of the CA. 2. Open the Online Certificate Status Manager agent page. The URL has the format https://hostname:SSLport/ocsp/agent/ocsp. 3.

  • Page 188: Testing The Ocsp Service Setup

    Chapter 6. Online Certificate Status Protocol Responder 4. For defStore, fill in the following values: • notFoundAsGood. Sets the OCSP service to return an OCSP response of GOOD if the certificate in question cannot be found in any of the CRLs. If this is not selected, the response is UNKNOWN, which, when encountered by a client, results in an error message.

  • Page 189: Submitting Ocsp Requests Using The Get Method

    Submitting OCSP Requests Using the GET Method Open the Online Certificate Status Manager agent services page, and click the List Certificate Authorities link. The page should show information about the Certificate Manager configured to publish CRLs to the Online Certificate Status Manager. The page also summarizes the Online Certificate Status Manager's activity since it was last started.
  • Page 190 Chapter 6. Online Certificate Status Protocol Responder 2. Paste the URL in the address bar of a web browser to return the status information. The browser must be able to handle OCSP requests. https://server.example.com:11443/ocsp/ee/ocsp/MEIwQDA +MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewd Dnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE= 3. The OCSP Manager responds with the certificate status which the browser can interpret. The possible statuses are GOOD, REVOKED, and UNKNOWN.

  • Page 191: Setting Up A Redirect For Certificates Issued In Certificate System 7.1 And Earlier

    Setting up a Redirect for Certificates Issued in Certificate System 7.1 and Earlier 6.11. Setting up a Redirect for Certificates Issued in Certificate System 7.1 and Earlier The location for the OCSP user pages, specified in the URL with the file root /ocsp/ee/ocsp/, is different in Certificate System 7.3 than the location in Certificate System 7.1, which was simply / ocsp/.
  • Page 192 Chapter 6. Online Certificate Status Protocol Responder 7. Move up to the main web application directory. For example: cd /var/lib/rhpki-ocsp/webapps/ 8. Rename the current instance (ocsp) directory. For example: mv /var/lib/rhpki-ocsp/webapps/ocsp /var/lib/rhpki-ocsp/webapps/ocsp2 9. Open the WEB-INF/ directory in the original ocsp/ directory. For example: cd /var/lib/rhpki-ocsp/webapps/ocsp/WEB-INF 10.
  • Page 193 Setting up a Redirect for Certificates Issued in Certificate System 7.1 and Earlier <init-param> <param-name>matchURIStrings</param-name> <param-value>/ocsp/registry,/ocsp/acl,/ocsp/jobsScheduler,/ocsp/ug,/ocsp/server,/ocsp/log, /ocsp/auths,/ocsp/start,/ocsp/ocsp,/ocsp/services,/ocsp/agent,/ocsp/ee, /ocsp/admin</param-value> </init-param> <init-param> <param-name>destServletOnNoMatch</param-name> <param-value>/ee/ocsp</param-value> </init-param> <init-param> <param-name>appendPathInfoOnNoMatch</param-name> <param-value>/ocsp</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>ocspProxy</servlet-name> <url-pattern>/ocsp</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>ocspOther</servlet-name> <url-pattern>/ocsp/*</url-pattern> </servlet-mapping> </web-app> 12. Edit the /var/lib/rhpki-ocsp/conf/context.xml, changing the following line: <Context>...

  • Page 195: Data Recovery Manager

    Chapter 7. Data Recovery Manager This chapter explains how to use the Data Recovery Manager (DRM) to archive private keys and to recover these archived keys to restore encrypted data. NOTE Server-side key generation is an option provided for smart card enrollments performed through the TPS subsystem.

  • Page 196: Transport Key Pair And Certificate

    Chapter 7. Data Recovery Manager Section 7.2.2, “Storage Key Pair” • Section 7.2.3, “SSL Server Certificate” • 7.2.1. Transport Key Pair and Certificate Every DRM has a transport certificate. The public key of the key pair that is used to generate the transport certificate is used by the client software to encrypt an end entity's private encryption key before it is sent to the DRM for archival;...

  • Page 197: Overview Of Archiving Keys

    Overview of Archiving Keys 7.4. Overview of Archiving Keys The DRM automatically archives private encryption keys if archiving is configured. For instructions on Section 7.6, “Configuring Key Archival and setting up a key archival and recovery infrastructure, see Recovery Process”. 7.4.1.
  • Page 198 Chapter 7. Data Recovery Manager Figure 7.1, “How the Key Archival Process Works” illustrates how the key archival process occurs when an end entity requests a certificate. Figure 7.1. How the Key Archival Process Works 1. The client requests and generates a dual key pair. a.

  • Page 199: Overview Of Key Recovery

    Overview of Key Recovery Both subsystems subject the request to configured certificate profile constraints at appropriate stages. If the request fails to meet any of the profile constraints, the subsystem rejects the request. 7.5. Overview of Key Recovery The DRM supports agent-initiated key recovery. Agent-initiated recovery is when designated recovery agents use the key recovery form on the DRM agent services page to process and approve key recovery requests.

  • Page 200: Key Recovery Agent Scheme

    Chapter 7. Data Recovery Manager The DRM informs the agent who initiated the key recovery process of the status of the authorizations. 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.

  • Page 201: Setting Up Key Recovery

    Setting up Key Recovery For the CA to be able to request key archival of the DRM, the two subsystems must be configured to recognize, trust, and communicate with each other. Verify that the Certificate Manager has been set up as a privileged user, with an appropriate SSL client authentication certificate, in the internal database of the DRM.

  • Page 202: Testing The Key Archival And Recovery Setup

    Chapter 7. Data Recovery Manager Key recovery agents need an appropriate page to initiate the key recovery process. By default, the DRM's agent services page includes the appropriate HTML form to allow key recovery agents to initiate key recovery, authorize key recovery requests, and retrieve the encryption keys. If this form is customized, do not to delete any of the information that is vital to the functioning of the form;...

  • Page 203: Creating Data Recovery Manager Agents And Administrators

    Creating Data Recovery Manager Agents and Administrators the agents receive this key recovery authorization number, they can authorize this request by going to the DRM agent services page and clicking the Authorize Recovery link. e. Once all the agents have authorized the recovery, the next screen returns a link to download a PKCS #12 blob containing the recovered key pair.
  • Page 204 Chapter 7. Data Recovery Manager Figure 7.2. Creating a New User The group to which the user belongs determines what privileges the user has. Assign agents and administrators to the appropriate subsystem group. 4. Store the user's certificate. a. Request and approve an SSL client certificate for the user if one has not already been generated.

  • Page 205: Token Processing System

    Chapter 8. Token Processing System The Token Processing System (TPS) serves as the conduit between the Enterprise Security Client and the other subsystems (CA, TKS, DRM) in the Certificate System and is the only means for the client to communicate with the other subsystems. It provides the following functionalities for users managing their smart cards through the Enterprise Security Client: •...

  • Page 206: Configuring Failover Support

    Chapter 8. Token Processing System • To perform different operations under different policies. The TPS can route its jobs to different subsystem instances when there are different types of tokens or operations. For example, enrollment requests for temporary tokens can be sent to one CA with one set of policies while Section 8.1.2, enrollments for regular tokens are sent to a different CA.
  • Page 207 Configuring Multiple Instances for Different Functions conn.ca2.keepAlive=true conn.ca2.retryConnect=3 conn.ca2.servlet.enrollment=/ca/ee/ca/profileSubmitSSLClient conn.ca2.servlet.revoke=/ca/subsystem/ca/doRevoke conn.ca2.servlet.unrevoke=/ca/subsystem/ca/doUnrevoke conn.ca2.timeout=100 3. Set up the operation parameters to use the different instances to perform the different TPS functions. The parameters for the different operations set the type of operation, the type of token profile, the subsystem type, and other parameters specific to the operation and the subsystem type.

  • Page 208: Formatting Smart Cards

    Chapter 8. Token Processing System Table 8.7, “Mapping and Filters”. The mapping and filter parameters are listed in 8.2. Formatting Smart Cards When the TPS is contacted by a smart card for a format operation, there are several different operations the TPS can perform, depending on the status of the smart card. •...

  • Page 209: Enrolling Smart Cards Through The Enterprise Security Client

    Enrolling Smart Cards through the Enterprise Security Client card. Similarly, an old applet can be replaced with a new applet. Any keys or certificates created or managed with the old applet are destroyed. To upgrade the applet in the TPS, put the new applet in the applet directory, and set the update.applet.enable parameter in the CS.cfg file to true.

  • Page 210: Enabling Ssl In The Tps

    Chapter 8. Token Processing System Section 8.5.1, “Enabling SSL in the TPS” • Section 8.5.2, “Configuring Server-Side Key Generation and Archival of Encryption Keys” • Section 8.5.3, “Looking at Smart Card Certificate Enrollment Profiles” • Section 8.5.4, “Automating Encryption Key Recovery” •...

  • Page 211: Configuring Server-Side Key Generation And Archival Of Encryption Keys

    Configuring Server-Side Key Generation and Archival of Encryption Keys </VirtualHost> 3. Restart the TPS instance. /etc/init.d/rhpki-tps restart 4. The Enterprise Security Client needs to be configured to communicate with the TPS over SSL; this is done by setting the Phone Home URL, which is the default URL the Enterprise Security Client uses to connect to the TPS.
  • Page 212 Chapter 8. Token Processing System 4. Select the TPS user, click Certificates, and import the TPS susbsystem certificate. 8.5.2.2. Step 2: Importing the DRM Transport Key into the TKS Several different keys are used to encrypt the communications between the TKS, TPS, DRM, and token, and all of these certificates and keys are secured, at some point, by the DRM's transport key.

  • Page 213: Looking At Smart Card Certificate Enrollment Profiles

    Looking at Smart Card Certificate Enrollment Profiles 8.5.2.3. Step 3: Configuring the TPS to Generate and Archive Keys 1. Stop the TPS. /etc/init.d/instance_ID stop 2. Edit the following parameters in the TPS CS.cfg file to use the appropriate DRM connection information: conn.drm.totalConns=1 conn.drm1.hostport=DRM_HOST:DRM_SSLPORT...

  • Page 214: Automating Encryption Key Recovery

    Chapter 8. Token Processing System policyset.set1.p1.default.params.dnpattern=UID=$request.uid$, O=Token Key User policyset.set1.p1.default.params.ldap.enable=true policyset.set1.p1.default.params.ldap.basedn=ou=people,dc=host,dc=example,dc=com policyset.set1.p1.default.params.ldapStringAttributes=uid,mail policyset.set1.p1.default.params.ldap.ldapconn.host=localhost.example.com policyset.set1.p1.default.params.ldap.ldapconn.port=389 These CA profiles come with LDAP lookup disabled by default. The ldapStringAttributes parameter tells the CA which LDAP attributes to retrieve from the company directory. For example, if the directory contains uid as an LDAP attribute name, and this will be used in the subject name of the certificate, then uid must be listed in the ldapStringAttributes parameter, and request.uid listed as one of the components in the dnpattern.
  • Page 215 Automating Encryption Key Recovery op.enroll.userKey.keyGen.encryption.recovery.destroyed.revokeCert=false op.enroll.userKey.keyGen.encryption.recovery.destroyed.revokeCert.reason=0 op.enroll.userKey.keyGen.encryption.recovery.destroyed.scheme=RecoverLast • For tokens which are permanently lost: op.enroll.userKey.keyGen.recovery.keyCompromise.keyType.num=2 op.enroll.userKey.keyGen.recovery.keyCompromise.keyType.value.0=signing op.enroll.userKey.keyGen.recovery.keyCompromise.keyType.value.1=encryption op.enroll.userKey.keyGen.signing.recovery.keyCompromise.revokeCert=true op.enroll.userKey.keyGen.signing.recovery.keyCompromise.revokeCert.reason=1 op.enroll.userKey.keyGen.signing.recovery.keyCompromise.scheme=GenerateNewKey op.enroll.soKey.keyGen.encryption.recovery.keyCompromise.revokeCert=true op.enroll.soKey.keyGen.encryption.recovery.keyCompromise.revokeCert.reason=1 op.enroll.soKey.keyGen.encryption.recovery.keyCompromise.scheme=GenerateNewKey • For tokens which are temporarily lost: op.enroll.userKey.keyGen.recovery.onHold.keyType.num=2 op.enroll.userKey.keyGen.recovery.onHold.keyType.value.0=signing op.enroll.userKey.keyGen.recovery.onHold.keyType.value.1=encryption op.enroll.userKey.keyGen.signing.recovery.onHold.revokeCert=true op.enroll.userKey.keyGen.signing.recovery.onHold.revokeCert.reason=6 op.enroll.userKey.keyGen.signing.recovery.onHold.scheme=GenerateNewKey op.enroll.soKey.keyGen.encryption.recovery.onHold.revokeCert=true op.enroll.soKey.keyGen.encryption.recovery.onHold.revokeCert.reason=6 op.enroll.soKey.keyGen.encryption.recovery.onHold.scheme=GenerateNewKey Set revokeCert=true to revoke certificates if a token's certificates are replaced after being lost. for the signing key op.enroll.userKey.keyGen.signing.recovery.destroyed.revokeCert=true op.enroll.userKey.keyGen.signing.recovery.destroyed.revokeCert.reason=0...

  • Page 216: Configuring Symmetric Key Changeover

    Chapter 8. Token Processing System 8.5.4.1. Replacing Lost or Stolen Smart Cards If the smart card loss is temporary, the user can be enrolled for a temporary replacement. The profile for the replacement smart card is defined in the userKeyTemporary parameter in the TPS CS.cfg file.
  • Page 217 Configuring Symmetric Key Changeover cd /var/lib/instance_ID/alias/ b. Generate the new master key. For example: tksTool -M -n new_master -d /var/lib/rhpki-tks/alias -h token_name Section 9.2, “Using Master Generating a new master key on the TKS is described in more detail in Keys”.

  • Page 218: Setting Token Types For Specified Smart Cards

    Chapter 8. Token Processing System requiredVersion is the numeric key set identifier required for the operation to proceed. If the smart card does not have the key set specified by the requiredVersion parameter, key changeover will occur, and the operation process continues. The TPS audit log shows whether the key changeover worked successfully.
  • Page 219 Setting Token Types for Specified Smart Cards op.format.mapping.0.filter.tokenCUID.end=1000000000000100 ########################################################################## op.format.mapping.1.filter.tokenCUID.start=2000000000000000 op.format.mapping.1.filter.tokenCUID.end=20000000000001000 ########################################################################## # Profile for DevKey ########################################################################## op.format.devKey.update.applet.emptyToken.enable=true op.format.devKey.update.applet.requiredVersion=1.3.427BDDB8 op.format.devKey.update.applet.directory=/usr/share/rhpki/tps/applets op.format.devKey.update.applet.encryption=true op.format.devKey.update.symmetricKeys.enable=false op.format.devKey.update.symmetricKeys.requiredVersion=1 op.format.devKey.revokeCert=true op.format.devKey.ca.conn=ca1 op.format.devKey.loginRequest.enable=true op.format.devKey.tks.conn=tks1 op.format.devKey.auth.id=ldap-dev op.format.devKey.auth.enable=true ########################################################################## # Profile for QAKey ########################################################################## op.format.qaKey.update.applet.emptyToken.enable=true op.format.qaKey.update.applet.requiredVersion=1.3.427BDDB8 op.format.qaKey.update.applet.directory=/usr/share/tps/applets op.format.qaKey.update.applet.encryption=true op.format.qaKey.update.symmetricKeys.enable=false op.format.qaKey.update.symmetricKeys.requiredVersion=1 op.format.qaKey.revokeCert=true op.format.qaKey.ca.conn=ca1...

  • Page 220: Configuring Ldap Authentication

    Chapter 8. Token Processing System auth.instance.1.baseDN=o=qa auth.instance.1.ui.title.en=LDAP Authentication auth.instance.1.ui.description.en=This authenticates user against the QA LDAP directory. auth.instance.1.ui.id.UID.name.en=LDAP User ID auth.instance.1.ui.id.PASSWORD.name.en=LDAP Password auth.instance.1.ui.id.UID.description.en=QA LDAP User ID auth.instance.1.ui.id.PASSWORD.description.en=QA LDAP Password ########################################################################## • The two format operation profiles are devKey and qaKey. • The two mapping order 0 refers to the devKey and 1 refers to the qaKey. •...

  • Page 221: Token Database

    Token Database Like configuring multiple subsystem instances, there can be multiple LDAP directories configured. Additional LDAP parameters, such as the base DN under which to search for entries and the Directory Table 8.5, “LDAP Authentication”. Server hostname and port, are listed in 8.7.
  • Page 222 Chapter 8. Token Processing System Parameter Description logging.debug.enable Enables debug logging. The valid values are true|false. logging.debug.filename The full path to the debug log file name. For example, /tmp/tps-debug.log. logging.debug.level The debug log levels. The levels range from 0 to •...
  • Page 223 TPS Configuration Parameters Parameter Description • 0 - No logging. • 4 - LL_PER_SERVER. Messages that happen only during startup or shutdown. • 6 - LL_PER_CONNECTION. Messages that happen per connection. • 8 - LL_PER_PDU. Messages that happen for every transaction. •...
  • Page 224 Chapter 8. Token Processing System Parameter Description conn.can.SSLOn Sets if SSL needs to be turned on to connect to the CA. This value must be true. conn.can.keepAlive Sets whether to keep the connection to the CA alive or terminate it after every operation. The valid values are true|false.
  • Page 225 TPS Configuration Parameters Parameter Description the DRM, and the client should be a configured DRM agent. conn.drmn.retryConnect The number of times the TPS tries to reconnect to the DRM after a connection attempt fails. The valid values are integers. For example, 3. conn.drmn.SSLOn Sets whether SSL needs to be turned on for the connection to the DRM.
  • Page 226 Chapter 8. Token Processing System Parameter Description auth.instance.n.retryConnect The number of times the TPS tries to reconnect to the LDAP server after a connection attempt fails. The valid values are integers. For example, auth.instance.n.baseDN The base DN from which to start the LDAP search.
  • Page 227 TPS Configuration Parameters Parameter Description op.Operation.mapping.n.filter.tokenCUID.start The filter based on the CUID range. The target tokenType will be matched if the CUID falls within the start-end range. op.Operation.mapping.n.filter.tokenCUID.end The filter based on the CUID range. The target tokenType will be matched if the CUID falls within the start-end range.
  • Page 228 Chapter 8. Token Processing System Parameter Description • 3 - Affiliation changed. • 4 - Certificate superseded. • 5 - Cessation of operation. • 6 - Certificate is on hold. op.enroll.tokenType.keyGen.encryption.recovery.destroyed.scheme Specifies the encryption certificate recovery scheme for destroyed tokens. The default value is RecoverLast.
  • Page 229 TPS Configuration Parameters Parameter Description • 2 - CA key compromised. • 3 - Affiliation changed. • 4 - Certificate superseded. • 5 - Cessation of operation. • 6 - Certificate is on hold. op.enroll.tokenType.keyGen.encryption.recovery.keyCompromise.scheme Specifies encryption certificate recovery scheme for tokens whose key is compromised.
  • Page 230 Chapter 8. Token Processing System Parameter Description • 1 - Key compromised. • 2 - CA key compromised. • 3 - Affiliation changed. • 4 - Certificate superseded. • 5 - Cessation of operation. • 6 - Certificate is on hold. op.enroll.tokenType.keyGen.encryption.recovery.onHold.scheme The recovery scheme for encryption certificates for tokens that are to be put on hold.
  • Page 231 TPS Configuration Parameters Parameter Description • op.enroll.tokenType.keyGen.signing.public.keyCapabilities.sign • op.enroll.tokenType.keyGen.signing.public.keyCapabilities.signRecover • op.enroll.tokenType.keyGen.signing.public.keyCapabilities.decrypt • op.enroll.tokenType.keyGen.signing.public.keyCapabilities.derive • op.enroll.tokenType.keyGen.signing.public.keyCapabilities.unwrap • op.enroll.tokenType.keyGen.signing.public.keyCapabilities.wrap • op.enroll.tokenType.keyGen.signing.public.keyCapabilities.verifyRecover • op.enroll.tokenType.keyGen.signing.public.keyCapabilities.verify • op.enroll.tokenType.keyGen.signing.public.keyCapabilities.sensitive • op.enroll.tokenType.keyGen.signing.public.keyCapabilities.private • op.enroll.tokenType.keyGen.signing.public.keyCapabilities.token • op.enroll.tokenType.keyGen.signing.private.keyCapabilities.encrypt • op.enroll.tokenType.keyGen.signing.private.keyCapabilities.sign • op.enroll.tokenType.keyGen.signing.private.keyCapabilities.signRecover • op.enroll.tokenType.keyGen.signing.private.keyCapabilities.decrypt • op.enroll.tokenType.keyGen.signing.private.keyCapabilities.derive • op.enroll.tokenType.keyGen.signing.private.keyCapabilities.unwrap • op.enroll.tokenType.keyGen.signing.private.keyCapabilities.wrap •...
  • Page 232 Chapter 8. Token Processing System Parameter Description op.enroll.tokenType.keyGen.signing.ca.profileId The CA profile that should be used for creating the signing certificate. The default is caTokenUserSigningKeyEnrollment. op.enroll.tokenType.keyGen.signing.ca.conn The CA connection to use. The default value is ca1. op.enroll.tokenType.keyGen.encryption.keySize The key size for the encryption key. The default is 1024.
  • Page 233 TPS Configuration Parameters Parameter Description • op.enroll.tokenType.keyGen.encryption.private.keyCapabilities.token op.enroll.tokenType.keyGen.encryption.label The token label for the encryption certificate. The valid values are $pretty_cuid$, $cuid$, $msn$, $userid$, and $profileId$. These variables are replaced by the user-supplied information when the certificate is generated. op.enroll.tokenType.keyGen.encryption.cuid_label The CUID to show in the certificate. op.enroll.tokenType.keyGen.encryption.overwrite Specifies if the encryption certificate on the token should be overwritten.
  • Page 234 Chapter 8. Token Processing System Parameter Description op.enroll.tokenType.tks.conn The TKS connection to use. op.enroll.tokenType.auth.id The LDAP authentication instance to use. The default value is ldap1. op.enroll.tokenType.auth.enable Specifies whether to authenticate the user information. The valid values are true|false. Table 8.8. Enrollment Operation Preferences Parameter Description op.pinReset.tokenType.update.applet.emptyToken.enable...
  • Page 235 TPS Configuration Parameters Parameter Description op.format.tokenType.update.applet.requiredVersionThe version of the applet to use. It should be the file name of the applet without the .ijc extension. op.format.tokenType.update.applet.directory The local filesystem directory where the applets are located op.format.tokenType.update.symmetricKeys.enableSpecifies if the key changeover feature should be enabled.
  • Page 236 Chapter 8. Token Processing System Parameter Description tokendb.bindPassPath The path to a local password file which contains the subsystem passwords. The default file is /var/lib/rhpki-tps/conf/ password.conf. tokendb.templateDir The directory where the templates for the TPS agent page are located. tokendb.userBaseDN The LDAP suffix where the user entries are.

  • Page 237: Tks Configuration File Parameters

    TKS Configuration File Parameters Parameter Description • tokendb.doTokenTemplate • tokendb.doTokenConfirmTemplate • tokendb.revokeTemplate • tokendb.editAdminTemplate • tokendb.editAdminResultTemplate • tokendb.searchAdminTemplate • tokendb.searchAdminResultTemplate tokendb.defaultPolicy The default policy to use. The valid values are PIN_RESET=YES|NO; and RE_ENROLL=YES| NO;. Table 8.11. Token Database Preferences 8.9.1. TKS Configuration File Parameters There are several parameters which should be set in the TKS configuration file to use the TPS for Table 8.12, “TKS Configuration server-side key generation and for key updates.

  • Page 239: Token Key Service

    Chapter 9. Token Key Service 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 chapter explains the TKS, which manages the master keys required set up a secure communication channel between the TPS and the client.
  • Page 240 Chapter 9. Token Key Service 3. Create a transport key called transport. tksTool -T -d . -n transport -p certDBPrefix -p certDBPrefix The tksTool utility prints out the KCV values for each of the three session keys that are generated. Save them to file since these are all necessary to regenerate the transport key if it is lost.

  • Page 241: Configuring The Tks To Associate The Master Key With Its Version

    Configuring the TKS to Associate the Master Key with Its Version Using the tksTool is explained in more detail in the Certificate System Command-Line Tools Guide. 9.3. Configuring the TKS to Associate the Master Key with Its Version Master keys have a numeric identifier such as 01. The TKS maps these IDs to PKCS #11 object nicknames specified in masterKeyId.

  • Page 242: Creating Token Key Service Agents And Administrators

    Chapter 9. Token Key Service # useSoftToken tells whether to use software token or no. by default it's true, # even if it's not settks.useSoftToken=false # mk_mappings maps key version to key name on token name # in this example, #02 is the version number, nethsm is the token name, # and new_master is the key name tks.mk_mappings.#02#01=nethsm:new_master It is not necessary to change the defaultSlot value;...
  • Page 243 Creating Token Key Service Agents and Administrators Figure 9.1. Creating a New User The group to which the user belongs determines what privileges the user has. Assign agents and administrators to the appropriate subsystem group. 4. Store the user's certificate. a.

  • Page 245: Enterprise Security Client

    Chapter 10. Enterprise Security Client The Enterprise Security Client is a cross-platform client for end users to register and manage keys and certificates on smart cards or tokens. This is the final component in the Certificate System token management system, with the Token Processing System (TPS) and Token Key Service (TKS). NOTE For more information on using the Enterprise Security Client, see the Certificate System Enterprise Security Client Guide.

  • Page 247: Managing Certificates

    Chapter 11. Managing Certificates This chapter gives an overview of using certificates: what types and formats are available, how to request and create them through the HTML end-entity forms and through the Certificate System Console, and how to install certificates in the Certificate System and on different clients. Additionally, there is information on managing certificates through the Console and configuring the servers to use them.
  • Page 248 Chapter 11. Managing Certificates 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://hostname:SSLport/ca/ee/ca. For more detailed information about the different certificates that can be created, see the Certificate System Agent's Guide.

  • Page 249: Determining Which Certificates To Install

    Determining Which Certificates to Install 11.1.1.3. SSL Server and Client Certificates Server certificates are used for secure communications, such as SSL, and other secure functions. Server certificates are used to authenticate themselves during operations and to encrypt data; client certificates authenticate the client to the server. NOTE CAs which have a signing certificate issued by a third-party may not be able to issue server certificates.
  • Page 250 Chapter 11. Managing Certificates Subsystem Certificates • SSL server certificate • Subsystem certificate • User's (agent/administrator) certificate OCSP • OCSP signing certificate • SSL server certificate • Subsystem certificate • User's (agent/administrator) certificate • Transport certificate • Storage certificate • SSL server certificate •...

  • Page 251: Certificate Data Formats

    Certificate Data Formats 11.1.3. Certificate Data Formats Certificate requests and certificates can be created, stored, and installed in several different formats. All of these formats conform to X.509 standards. 11.1.3.1. Binary The following binary formats are recognized: • DER-encoded certificate. This is a single binary DER-encoded certificate. •...

  • Page 252: Requesting And Receiving Certificates

    Chapter 11. Managing Certificates Open the wizard by clicking Add or Add/Renew in the System Keys and Certificates Console menu item. The Local Certificates-based wizard has the option to request or install a certificate. The CA Certificate-based wizard has the option to install a trusted or untrusted certificate chain. To install certificates, except for self-signed CA certificates, the wizard must be run twice: once to request the certificate and once to install the certificate.

  • Page 253: Requesting Certificates

    Requesting Certificates Section 11.2.1, “Requesting Certificates” • Section 11.2.2, “Submitting Certificate Requests” • Section 11.2.3, “Retrieving Certificates from the End-Entities Page” • 11.2.1. Requesting Certificates The different methods of requesting certificates allow different types of certificates which can be requested. End users can request client certificates, either agent or user certificates for the Certificate System or for use with other applications.
  • Page 254 Chapter 11. Managing Certificates required, the user can also use a hardware token, such as a smart card, to store the key pair and the certificate. To create a user certificate, do the following: 1. Open the Certificate Manager's end-entities page. https://server.example.com:9443/ca/ee/ca 2.
  • Page 255 Requesting Certificates 11.2.1.2. Requesting a Subsystem, Server, or Signing Certificate through the Console The Certificate Setup Wizard for the different subsystems creates requests for any of the certificates used by that subsystem. These certificates can be a server certificate, OCSP signing certificate, or subsystem-specific certificate, such as a CA signing certificate or DRM transport certificate.
  • Page 256 Chapter 11. Managing Certificates 5. Select the Request a certificate radio button. 6. Choose the certificate type to request. The types of certificates that can be requested varies depending on the subsystem: • For a CA: • CA signing certificate •...
  • Page 257 Requesting Certificates Figure 11.3. Selecting the Certificate Type 7. For requests submitted through a Certificate Manager, after selecting the type of certificate, select which type of CA will sign the request: • For a CA signing certificate, the options are to use a root CA or a subordinate CA. •...
  • Page 258 Chapter 11. Managing Certificates 8. Set the key-pair information. Figure 11.4. Generating the Key Pair • Set the token, either the security database directory (internal) or one of the listed external tokens. • Generate a new key pair. Set the key algorithm and size. The key algorithm must be RSA. The recommended length for an RSA key is 2048 bits or higher to be crytpographically strong.
  • Page 259 Requesting Certificates Figure 11.5. Setting the Hashing Algorithm 10. Give the subject name. Either enter values for individual DN attributes to build the subject DN or enter the full string.
  • Page 260 Chapter 11. Managing Certificates Figure 11.6. Setting the Subject Name NOTE For an SSL server certificate, the common name must be the fully-qualified host name of the Certificate System in the format machine_name.domain.domain. 11. Only when requesting a certificate through the Certificate Manager Console and submitting the request to the Certificate Manager automatically.
  • Page 261 Requesting Certificates Figure 11.7. Setting the Validity Period The default validity period is five years. 12. Only when requesting a certificate through the Certificate Manager Console submitting the request to the Certificate Manager automatically. Set the standard extensions for the certificate. The required extensions are chosen by default.
  • Page 262 Chapter 11. Managing Certificates Figure 11.8. Setting the Certificate Extensions NOTE Certificate extensions are required to set up a CA hierarchy. Subordinate CAs must have certificates that include the extension identifying them as either a subordinate SSL CA (which allows them to issue certificates for SSL) or a subordinate email CA (which allows them to issue certificates for secure email).
  • Page 263 Requesting Certificates • Key Usage. The digital signature (bit 0), non-repudiation (bit 1), key certificate sign (bit 5), and CRL sign (bit 6) bits are set by default. The extension is marked critical as recommended by the http://www.ietf.org/rfc/rfc2459.txt PKIX standard and RFC 2459. See for a description of the Key Usage extension.
  • Page 264 Chapter 11. Managing Certificates Figure 11.9. Getting the Certificate Request The request is in base-64 encoded PKCS #10 format and is bounded by the marker lines -----BEGIN NEW CERTIFICATE REQUEST----- and -----END NEW CERTIFICATE REQUEST-----. For example: -----BEGIN NEW CERTIFICATE REQUEST----- MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBC6SAwHgYDVQQKExdOZXRzY2FwZSBDb21tdW5pY2...
  • Page 265 Requesting Certificates F0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDA wMnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFz AVBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3Dbndg JARYUc3Vwcml5Yhvfggsvwryw4y7214vAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEBAQHBAQDAgCAM A0GCSqGSIb3DQEBBAUAA4GBAFi9FzyJlLmS+kzsue0kTXawbwamGdYql2w4hIBgdR+jWeLmD4CP4x -----END NEW CERTIFICATE REQUEST----- The wizard also copies the certificate request to a text file it creates in the configuration directory, which is located at /var/lib/instance_id/conf/. The name of the text file depends on the type Table 11.2, “Files Created for Certificate of certificate requested.
  • Page 266 Chapter 11. Managing Certificates 1. Open the certificate database directory of the instance for which the certificate is being requested. cd /var/lib/instance_ID/alias 2. Run the certutil command, defining the key settings, subject name, validity period, and extentions. certutil -R -k rsa -g 2048 -s "CN=example cert server.example.com,O=Example Domain" -o request.cert -v 12 -d .

  • Page 267: Submitting Certificate Requests

    Submitting Certificate Requests 11.2.2. Submitting Certificate Requests There are three ways to submit a certificate request. The best method for submitting a request depends on how the request was created. • Through the Console's Certificate Wizard. The final screen when creating a certificate request through the subsystem administrative console has the option to submit the request automatically to a specified Certificate System CA.
  • Page 268 Chapter 11. Managing Certificates Figure 11.10. Submitting the Certificate Request • Host name . The fully-qualified host name of the Certificate System CA. • EE port number . The end-entity port number. • Yes, it's the SSL secure server port . Indicates that the end entity port number specified is the SSL port.
  • Page 269 Submitting Certificate Requests certificate and contacts the email address in the request. Once the certificate has been issued, use the request ID to import the certificate into the wizard. Alternatively, install the certificate as described in Section 11.4.1.1, “Installing Certificates through the Console”.
  • Page 270 Chapter 11. Managing Certificates Figure 11.11. Submitting the Certificate Request The standard requirements are as follows: • Certificate Request Type . This is either PKCS#10 or CRMF. Certificate requests created through the subsystem administrative console are PKCS #10; those created through the certutil tool and other utilities are usually PKCS #10.

  • Page 271: Retrieving Certificates From The End-Entities Page

    Retrieving Certificates from the End-Entities Page When the CA issues the certificate, save the certificate to a file, and install it following the instructions Section 11.4.1.1, “Installing Certificates through the Console”. 11.2.2.3. Submitting a Certificate Request to a Third-Party CA An external CA is any public or third-party CA.
  • Page 272 Chapter 11. Managing Certificates Figure 11.12. Retrieval Search 3. Fill in the request ID number that was created when the certificate request was submitted, and click Submit. 4. The next page shows the status of the certificate request. If the status is complete, then there is a link to the certificate.

  • Page 273: Managing User Certificates

    Managing User Certificates Figure 11.14. Certificate Information There are two actions that can be taken through this page: • To install this certificate on a server or other application, scroll down to the Installing This Certificate in a Server section, which contains the base-64 encoded certificate. •...

  • Page 274: Managing Certificate System User And Agent Certificates

    Chapter 11. Managing Certificates Section 11.4.1, For information on importing subsystem certificates into the security databases, see “Installing Certificates in the Certificate System Database”. 11.3.1. Managing Certificate System User and Agent Certificates Certificates for a user must be stored in the certificate database of the subsystem to which the user belongs.

  • Page 275: Importing Certificates Into Mozilla Firefox

    Importing Certificates into Mozilla Firefox 11.3.2. Importing Certificates into Mozilla Firefox Some client certificates, such as agent certificates, must be imported into a web browser for the user to perform necessary operations, including Certificate System agent services. Mozilla Firefox can import certificates. There are several MIME content types that are used to indicate what type of certificate is being imported;...

  • Page 276: Managing The Certificate Database

    Chapter 11. Managing Certificates 7. Click OK. The new certificate is listed in the Your certificates tab. NOTE If there are multiple client certificates installed, the Certificate System subsystem may not automatically find the appropriate client certificate. Set the Ask every time in the Client certificate selection section of the Firefox Advanced tab, which will prompt for the user to select the client certificate every time a website requests one.
  • Page 277 Installing Certificates in the Certificate System Database 11.4.1.1. Installing Certificates through the Console The Certificate Setup Wizard can install or import the following certificates into either an internal or external token used by the Certificate System instance: • Any of the certificates used by a Certificate System subsystem •...
  • Page 278 Chapter 11. Managing Certificates c. Paste in the certificate body, including the -----BEGIN CERTIFICATE----- and ----- END CERTIFICATE-----, into the text area, or specify the absolute file location; this must be a local file. The certificate will look like the following: -----BEGIN CERTIFICATE----- MIICKzCCAZSgAwIBAgIBAzANgkqkiG9w0BAQQFADA3MQswCQYDVQQGEw JVUzERMA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncy...
  • Page 279 Installing Certificates in the Certificate System Database NOTE If the Certificate System instance's certificates and keys are stored on an HSM, then specify the token name using the -h option. For example: certutil -A -n "ServerCert cert-example" -t u,u,u -d . -a -i /tmp/example.cert http://www.mozilla.org/projects/security/pki/ For information about using the certutil command, see nss/tools/certutil.html.

  • Page 280: Viewing Database Content

    Chapter 11. Managing Certificates Section 15.7, “Publishing Cross-Pair Certificates”. For information on publishing cross-pair certificates, 11.4.2. Viewing Database Content The certificates stored in the subsystem certificates database, cert8.db, can be viewed through the subsystem administrative console. Alternatively, the certificates can be listed using the certutil utility.
  • Page 281 Viewing Database Content Figure 11.15. Certificate Database Tab 4. The Certificate Database Management table lists the all of the certificates installed on the subsystem. The following information is supplied for each certificate: • Certificate Name • Serial Number • Issuer Names , the common name (cn) of the issuer of this certificate. •...

  • Page 282: Deleting Certificates From The Database

    Chapter 11. Managing Certificates To view the keys stored in the subsystem databases using certutil, run the certutil with the -K option. For example: cd /var/lib/instance_ID/aliascertutil -K -d . Enter Password or Pin for "NSS Certificate DB": <0> subsystemCert cert-rhpki-tks <1>...

  • Page 283: Changing The Trust Settings Of A Ca Certificate

    Changing the Trust Settings of a CA Certificate certutil -L -d . Certificate Authority - Example Domain CT,c, subsystemCert cert-subsystem u,u,u Server-Cert cert-example u,u,u 3. Delete the certificate by running the certutil with the -D option. certutil -D -d . -n certificate_nickname For example: certutil -D -d .

  • Page 284: Configuring The Server Certificate Use Preferences

    Chapter 11. Managing Certificates 5. A prompt opens which reads The Certificate chain is (un)trusted, are you sure you want to (un)trust it? Clicking yes changes the trust setting of the certificate chain; pressing no preserves the original trust relationship. 11.4.4.2.
  • Page 285 Configuring the Server Certificate Use Preferences • The version of SSL used during SSL communication. The latest version is SSL version 3, but many older clients use SSL version 2. Because client authentication is required for performing privileged operations, enable SSL version 3 ciphers.

  • Page 287: Managing Tokens

    Chapter 12. Managing Tokens This chapter gives an overview of using hardware security modules, also called HSMs or tokens, to generate and store Certificate System instance certificates and keys. This chapter includes installation and usage considerations for supported HSMs, describes different tasks for managing tokens, and contains other information for using hardware tokens with Certificate System.

  • Page 288: Using Hardware Security Modules With Subsystems

    Chapter 12. Managing Tokens has to be able to create certificates and keys on the slot with default nicknames. If not properly cleaned up, the names of these objects may collide with previous instances. • Before restarting the server when completing the configuration wizard, do the following: 1.

  • Page 289: Chrysalis Lunasa Hsm

    Chrysalis LunaSA HSM hardware-lunasa2-ca=caPassword 12.2.1. Chrysalis LunaSA HSM To make sure that the LunaSA HSM works with Red Hat Certificate System, add this configuration parameter to /etc/Chrystoki.conf: Misc { NetscapeCustomize=1023; } 12.2.2. Installing External Tokens and Unsupported HSM To use HSMs which are not officially supported by the Certificate System, the modutil tool can be used to add that module to the subsystem database manually.

  • Page 290: Managing Tokens Used By The Subsystems

    Chapter 12. Managing Tokens • For an nCipher HSM, do the following: modutil -dbdir . -nocertdb -add nethsm -libfile /opt/nfast/toolkits/pkcs11/ libcknfast.so 12.3. Managing Tokens Used by the Subsystems There are two main tasks involved in managing the tokens used by Certificate System: •...

  • Page 291: Hardware Cryptographic Accelerators

    Hardware Cryptographic Accelerators TokenInfo This utility will return all tokens which can be detected by the Certificate System, not only tokens which are installed in the Certificate System. 12.5. Hardware Cryptographic Accelerators The Certificate System can use hardware cryptographic accelerators with external tokens. Many of the accelerators provide the following security features: •...

  • Page 293: Certificate Profiles

    Chapter 13. Certificate Profiles The Certificate System provides a customizable framework to apply policies for incoming certificate requests and to control the input request types and output certificate types; these are called certificate profiles. Certificate profiles set the required information for certificate enrollment forms in the Certificate Manager end-entities page.

  • Page 294: How Certificate Profiles Work

    Chapter 13. Certificate Profiles requirements. A profile handles one certificate request, but a single request can contain information for multiple certificates. A PKCS#10 request contains a single public key. One CRMF request can contain multiple public keys, meaning multiple certificate requests. A profile may contain multiple sets of policies, with each set specifying how to handle one certificate request within a CRMF request.

  • Page 295: Setting Up Certificate Profiles

    Setting up Certificate Profiles 13.3. Setting up Certificate Profiles Certificate profiles are managed by changing the existing certificate profiles, deleting an existing certificate profile, or adding another certificate profile. Maintaining certificate profiles includes the following process: • Deciding which certificate profiles are needed in the PKI. There should be at least one profile for each type of certificate issued.
  • Page 296 Chapter 13. Certificate Profiles Figure 13.1. Certificate Profile Instances Management Tab 3. To create a new certificate profile, click Add. In the Select Certificate Profile Plugin Implementation window, select the type of certificate for which the profile is being created. Figure 13.2.
  • Page 297 Modifying Certificate Profiles through the CA Console Figure 13.3. Certificate Profile Instance Editor • Certificate Profile Instance ID. This is the ID used by the system to identify the profile. • Certificate Profile Name. This is the user-friendly name for the profile. •...
  • Page 298 Chapter 13. Certificate Profiles 6. Configure the policies, inputs, and outputs for the new profile. Select the new profile from the list, and click Edit/View. 7. Set up policies in the Policies tab of the Certificate Profile Rule Editor window. The Policies tab lists policies that are already set by default for the profile type.
  • Page 299 Modifying Certificate Profiles through the CA Console Figure 13.5. Certificate Profile Editor: Defaults Tab c. Fill in the policy set ID. When issuing dual key pairs, separate policy sets define the policies associated with each certificate. Then fill in the certificate profile policy ID, a name or identifier for the certificate profile policy.
  • Page 300 Chapter 13. Certificate Profiles Figure 13.6. Certificate Profile Editor: Constraints Tab Defaults defines attributes that populate the certificate request, which in turn determines the content of the certificate. These can be extensions, validity periods, or other fields contained in the certificates. Constraints defines valid values for the defaults. Section 13.7, “Defaults Reference”...
  • Page 301 Modifying Certificate Profiles through the CA Console Figure 13.7. Certificate Profile Inputs b. Choose the input from the list, and click OK. See Section 13.5, “Input Reference” for complete details of the default inputs. c. The New Certificate Profile Editor window opens. Set the input ID, and click OK.
  • Page 302 Chapter 13. Certificate Profiles Figure 13.8. Setting Inputs Inputs can be added and deleted. It is possible to select edit for an input, but since inputs have no parameters or other settings, there is nothing to configure. To delete an input, select the input, and click Delete. 9.
  • Page 303 Modifying Certificate Profiles through the CA Console Figure 13.9. Certificate Profile Outputs Outputs can be added and deleted. It is possible to select edit for an output, but since outputs have no parameters or other settings, there is nothing to configure. a.

  • Page 304: Modifying Certificate Profiles Through The Command Line

    Chapter 13. Certificate Profiles NOTE The profile instance ID cannot be modified. Once a certificate profile is enabled by an agent, that certificate profile is marked enabled in the Certificate Profile Instance Management tab, and the certificate profile cannot be edited in any way.
  • Page 305 Modifying Certificate Profiles through the Command Line Parameter Description desc Gives a free text description of the certificate profile, which is shown on the end-entities page. For example, desc=This certificate profile is for enrolling server certificates with agent authentication. enable Sets whether the profile is enabled, and therefore accessible through the end-entities page.
  • Page 306 Chapter 13. Certificate Profiles Parameter Description policyset.rule_id.policy_number.constraint.params.attribute Specifies a value for an allowed attribute for the constraint. The possible attributes vary depending on the type of constraint. For example, policyset.serverCertSet.1.constraint.params.pattern=CN=.*. policyset.rule_id.policy_number.default.class_id Gives the java class name for the default set in the profile rule. For example, policyset.serverCertSet.1.default.class_id=userSubjectNameDefaultIm policyset.rule_id.policy_number.default.name G ives the user-defined name of the default.

  • Page 307: Populating Certificates With Directory Attributes

    Populating Certificates with Directory Attributes This extension can be removed so that the server accepts the key usage set in the request. In this example, the key extension constraint is removed and replaced by no constraint, and the default is updated to allow user-supplied key extensions: policyset.cmcUserCertSet.6.constraint.class_id=noConstraintImpl policyset.cmcUserCertSet.6.constraint.name=No Constraint to keep it simple...
  • Page 308 Chapter 13. Certificate Profiles b. Select Authentication in the left navigation tree. c. In the Authentication Instance tab, click Add, and add an instance of the UidPwdDirAuth authentication plug-in. d. Set the information for the LDAP directory. e. Set the LDAP attributes to populate. Save the new plug-in instance.
  • Page 309 Populating Certificates with Directory Attributes Identifier: Subject Alternative Name - 2.5.29.17 Critical: no Value: RFC822Name: jsmith@example.com There are many attributes which can be automatically inserted into certificates by being set as a token Table 13.2, “Tokens Used to Populate Certificates”. in the policy set.

  • Page 310: Customizing The Enrollment Form

    Chapter 13. Certificate Profiles Policy Set Token Description $request.profileSetId$ This inserts the name of the policy set which processed the certificate request. Table 13.2. Tokens Used to Populate Certificates 13.3.4. Customizing the Enrollment Form To customize enrollment forms, create new pages with a custom design rather than editing the default enrollment form pages.

  • Page 311: Input Reference

    Input Reference • caTransportCert. For a transport signing certificate, used by the DRM. • caUserCert. For enrolling end user certificates. 13.5. Input Reference An input puts certain fields on the enrollment page associated with a particular certificate profile. The inputs set for a certificate profile are used to generate the enrollment page dynamically with the appropriate fields;...

  • Page 312: Image Input

    Chapter 13. Certificate Profiles • Text Being Signed. This gives the filename. 13.5.5. Image Input The Image input sets the field to sign an image file. The only field which this input creates is Image URL, which gives the location of the image which is to be signed. 13.5.6.

  • Page 313: Submitter Information Input

    Submitter Information Input This input puts the following fields into the enrollment form: • UID (the LDAP directory user ID) • Email • Common Name (the name of the user) • Organizational Unit (the organizational unit (ou) to which the user belongs) •...

  • Page 314: Defaults Reference

    Chapter 13. Certificate Profiles 13.7. Defaults Reference Defaults are used to define the contents of a certificate. This section lists and defines the predefined defaults. 13.7.1. Authority Info Access Extension Default This default attaches the Authority Info Access extension. This extension specifies how an application validating a certificate can access information, such as online validation services and CA statements, about the CA that has issued the certificate.

  • Page 315: Authority Key Identifier Extension Default

    Authority Key Identifier Extension Default Parameter Location_n Enable_n Table 13.3. Authority Info Access Extension Default Configuration Parameters 13.7.2. Authority Key Identifier Extension Default This default attaches the Authority Key Identifier extension to the certificate. The extension identifies the public key that corresponds to the private key used by a CA to sign certificates. This default has no parameters.

  • Page 316: Basic Constraints Extension Default

    Chapter 13. Certificate Profiles 13.7.3. Basic Constraints Extension Default This default attaches the Basic Constraint extension to the certificate. The extension identifies whether the Certificate Manager is a CA. The extension is also used during the certificate chain verification process to identify CA certificates and to apply certificate chain-path length constraints. Section A.3.3, “basicConstraints”.

  • Page 317: Crl Distribution Points Extension Default

    CRL Distribution Points Extension Default Parameter Table 13.4. Basic Constraints Extension Default Configuration Parameters 13.7.4. CRL Distribution Points Extension Default This default attaches the CRL Distribution Points extension to the certificate. This extension identifies locations from which an application that is validating the certificate can obtain the CRL information to verify the revocation status of the certificate.
  • Page 318 Chapter 13. Certificate Profiles Parameter IssuerType_n IssuerName_n...

  • Page 319: Extended Key Usage Extension Default

    Extended Key Usage Extension Default Parameter Table 13.5. CRL Distribution Points Extension Configuration Parameters 13.7.5. Extended Key Usage Extension Default This default attaches the Extended Key Usage extension to the certificate. Section A.3.6, “extKeyUsage”. For general information about this extension, see The extension identifies the purposes, in addition to the basic purposes indicated in the Key Usage extension, for which the certified public key may be used.

  • Page 320: Freshest Crl Extension Default

    Chapter 13. Certificate Profiles The EFS recovery certificate is used by a recovery agent when a user loses the private key and the data encrypted with that key needs to be used. Certificate System supports these two OIDs and allows certificates to be issued containing the Extended Key Usage extension with these OIDs.
  • Page 321 Freshest CRL Extension Default Parameter PointName_n PointIssuerName_n...

  • Page 322: Issuer Alternative Name Extension Default

    Chapter 13. Certificate Profiles Parameter PointType_n Table 13.8. Freshest CRL Extension Default Configuration Parameters 13.7.7. Issuer Alternative Name Extension Default This default attaches the Issuer Alternative Name extension to the certificate. The Issuer Alternative Name extension is used to associate Internet-style identities with the certificate issuer. The following constraints can be defined with this default: Section 13.8.3, “Extension Constraint”.

  • Page 323: Key Usage Extension Default

    Key Usage Extension Default Parameter issuerAltExtPattern Table 13.9. Issuer Alternative Name Extension Default Configuration Parameters 13.7.8. Key Usage Extension Default This default attaches the Key Usage extension to the certificate. The extension specifies the purposes for which the key contained in a certificate should be used, such as data signing, key encryption, or data encryption, which restricts the usage of a key pair to predetermined purposes.

  • Page 324: Name Constraints Extension Default

    Chapter 13. Certificate Profiles Parameter keyEncipherment dataEncipherment keyAgreement keyCertsign cRLSign encipherOnly decipherOnly Table 13.10. Key Usage Extension Default Configuration Parameters 13.7.9. Name Constraints Extension Default This default attaches a Name Constraints extension to the certificate. The extension is used in CA certificates to indicate a name space within which the subject names or subject alternative names in subsequent certificates in a certificate chain should be located.
  • Page 325 Name Constraints Extension Default Parameter PermittedSubtreesmax_n PermittedSubtreeNameChoice_n PermittedSubtreeNameValue_n...
  • Page 326 Chapter 13. Certificate Profiles Parameter PermittedSubtreeEnable_n ExcludedSubtreesn.min ExcludedSubtreeMax_n ExcludedSubtreeNameChoice_n...
  • Page 327 Name Constraints Extension Default Parameter ExcludedSubtreeNameValue_n ExcludedSubtreeEnable_n Table 13.11. Name Constraints Extension Default Configuration Parameters...

  • Page 328: Netscape Certificate Type Extension Default

    Chapter 13. Certificate Profiles 13.7.10. Netscape Certificate Type Extension Default WARNING This extension is obsolete. Use the Key Usage or Extended Key Usage certificate extensions instead. This default attaches a Netscape Certificate Type extension to the certificate. The extension identifies the certificate type, such as CA certificate, server SSL certificate, client SSL certificate, or S/MIME certificate.

  • Page 329: Policy Constraints Extension Default

    Policy Constraints Extension Default The following constraints can be defined with this default: Section 13.8.3, “Extension Constraint”. • Extension Constraint; see Section 13.8.6, “No Constraint”. • No Constraints; see Parameter critical Table 13.13. OCSP No Check Extension Default Configuration Parameters 13.7.14.

  • Page 330: Policy Mappers Extension Default

    Chapter 13. Certificate Profiles Parameter Table 13.14. Policy Constraints Extension Default Configuration Parameters 13.7.15. Policy Mappers Extension Default This default attaches a Policy Mappings extension to the certificate. The extension lists pairs of OIDs, each pair identifying two policy statements of two CAs. The pairing indicates that the corresponding policies of one CA are equivalent to policies of another CA.

  • Page 331: Subject Alternative Name Extension Default

    Subject Alternative Name Extension Default The following constraints can be defined with this default: Section 13.8.8, “Signing Algorithm Constraint”. • Signing Algorithm Constraint; see Section 13.8.6, “No Constraint”. • No Constraints; see Parameter signingAlgsAllowed signingAlg Table 13.16. Signing Algorithm Default Configuration Parameters 13.7.17.
  • Page 332 Chapter 13. Certificate Profiles policyset.serverCertSet.9.default.params.subjAltExtType_0=RFC822Name policyset.serverCertSet.9.default.params.subjAltExtType_1=DNSName policyset.serverCertSet.9.default.params.subjAltExtType_2=URIName policyset.serverCertSet.9.default.params.subjAltExtType_3=RFC822Name policyset.serverCertSet.9.default.params.subjAltExtType_4=RFC822Name policyset.serverCertSet.9.default.params.subjAltNameExtCritical=false policyset.serverCertSet.9.default.params.subjAltNameNumGNs=3 Example 13.1. Default Subject Alternative Name Extension Configuration The Subject Alternative Name extension profile checks the certificate request for the policy attributes. If the request contains an attribute, the profile reads its value and sets it in the extension. The extension added to the certificates contain all the configured attributes.

  • Page 333: Subject Directory Attributes Extension Default

    Subject Directory Attributes Extension Default Parameter Table 13.17. Subject Alternative Name Extension Default Configuration Parameters 13.7.18. Subject Directory Attributes Extension Default This default attaches a Subject Directory Attributes extension to the certificate. The Subject Directory Attributes extension conveys any desired directory attribute values for the subject of the certificate. The following constraints can be defined with this default: Section 13.8.3, “Extension Constraint”.

  • Page 334: Subject Key Identifier Extension Default

    Chapter 13. Certificate Profiles Parameter Enable Table 13.18. Subject Directory Attributes Extension Default Configuration Parameters 13.7.19. Subject Key Identifier Extension Default This default attaches a Subject Key Identifier extension to the certificate. The extension identifies certificates that contain a particular public key, which identifies a certificate from among several that have the same subject name.

  • Page 335: Token Supplied Subject Name Default

    Token Supplied Subject Name Default 13.7.21. Token Supplied Subject Name Default This default profile populates subject names based on the attribute values in the authentication token (AuthToken) object. This default plug-in works with the directory-based authentication manager. The Directory-Based User Dual-Use Certificate Enrollment certificate profile has two input parameters, UID and password.

  • Page 336: User Supplied Key Default

    Chapter 13. Certificate Profiles • If this extension is set on a profile with a corresponding OID (Extension Constraint), then any certificate request processed through that profile must carry the specified extension or the request is rejected. A certificate request that contains the user-defined extensions must be submitted to the profile. The certificate enrollment forms, however, do not have any input fields for users to add user-supplied extensions.

  • Page 337: User Signing Algorithm Default

    User Signing Algorithm Default 13.7.24. User Signing Algorithm Default This default implements an enrollment default profile that populates a user-supplied signing algorithm in the certificate request. If included in the certificate profile, this allows a user to choose a signing algorithm for the certificate, subject to the constraint set.

  • Page 338: Constraints Reference

    Chapter 13. Certificate Profiles Parameter range Table 13.20. Validity Default Configuration Parameters 13.8. Constraints Reference Constraints are used to define the allowable contents of a certificate and the values associated with that content. This section lists the predefined constraints with complete definitions of each. 13.8.1.

  • Page 339: Extended Key Usage Extension Constraint

    Extended Key Usage Extension Constraint Parameter Table 13.21. Basic Constraints Extension Constraint Configuration Parameters 13.8.2. Extended Key Usage Extension Constraint The Extended Key Usage extension constraint checks if the Extended Key Usage extension on the certificate satisfies the criteria set in this constraint. Parameter Critical exKeyUsageOIDs...
  • Page 340 Chapter 13. Certificate Profiles Parameter keyEncipherment dataEncipherment keyAgreement keyCertsign cRLSign encipherOnly decipherOnly Table 13.24. Key Usage Extension Constraint Configuration Parameters...

  • Page 341: No Constraint

    No Constraint 13.8.6. No Constraint This constraint implements no constraint. When chosen along with a default, there are not constraints placed on that default. 13.8.7. Netscape Certificate Type Extension Constraint WARNING This constraint is obsolete. Instead of using the Netscape Certificate Type extension constraint, use the Key Usage extension or Extended Key Usage extension.

  • Page 342: Unique Subject Name Constraint

    Chapter 13. Certificate Profiles like uid=user, o=Example, c=US satisfies the pattern uid=.*. The subject name cn=user, o=example,c=US does not satisfy the pattern. uid=.* means the subject name must begin with the uid attribute; the period-asterisk (.*) wildcards allow any type and number of characters to follow uid.

  • Page 343: Revocation And Crls

    Chapter 14. Revocation and CRLs The Certificate System provides methods for revoking certificates and for producing lists of revoked certificates, called certificate revocation lists (CRLs). This chapter describes the methods for revoking a certificate, describes CMC revocation, and provides details about CRLs and setting up CRLs. 14.1.

  • Page 344: Cmc Revocation

    Chapter 14. Revocation and CRLs To change the form appearance to suit an organization's requirements, edit the UserRevocation.html, the form that allows SSL client authenticated revocation of client or personal certificates. The file is the in /var/lib/instance_ID/webapps/subsystem_type/ ee/subsystem_type directory. 14.2. CMC Revocation CMC revocation allows users to set up a revocation client, sign the revocation request with an agent certificate, and then send the signed request to the Certificate Manager.

  • Page 345: Testing Cmc Revoke

    Testing CMC Revoke NOTE Surround values that include spaces in quotation marks. 14.2.2. Testing CMC Revoke 1. Create a CMC revocation request for an existing certificate. revoker -d /instance/alias -n nickname -i issuerName -s serialName -m reason -c comment For example, if the directory containing the agent certificate is /var/lib/rhpki-ca/alias, the nickname of the certificate is AgentCert, and the serial number of the certificate is 22, the command is as shown: revoker -d "/var/lib/rhpki-ca/alias"...

  • Page 346: Reasons For Revoking A Certificate

    Chapter 14. Revocation and CRLs One of the standard methods for conveying the revocation status of certificates is by publishing a list of revoked certificates, known a certificate revocation list (CRL). A CRL is a publicly available list of certificates that have been revoked. The Certificate Manager can be configured to generate CRLs.

  • Page 347: Publishing Crls

    Publishing CRLs 14.3.2. Publishing CRLs The Certificate Manager can publish the CRL to a file, an LDAP-compliant directory, or to an OCSP responder. Where and how frequently CRLs are published are configured in the Certificate Manager. Chapter 15, Publishing. For information about setting up CRL publishing, see 14.3.3.

  • Page 348: Issuing Crls

    Chapter 14. Revocation and CRLs NOTE When changes are made to the extensions for an issuing point, no delta CRL is created with the next full CRL for that issuing point. A delta CRL is created with the second full CRL that is created, and then all subsequent full CRLs.
  • Page 349 Issuing CRLs Figure 14.1. Default CRL Issuing Point Section 14.4.1, “Configuring Issuing Additional issuing points for the CRLs can be created. See Points” for details. There are four types of CRLs the issuing points can create, depending on the options set when configuring the issuing point to define what the CRL will list: •...

  • Page 350: Configuring Issuing Points

    Chapter 14. Revocation and CRLs 14.4.1. Configuring Issuing Points Issuing points define which certificates are included in a new CRL. A master CRL issuing point is created by default for a master CRL containing a list of all revoked certificates for the Certificate Manager.

  • Page 351: Configuring Crls For Each Issuing Point

    Configuring CRLs for Each Issuing Point extensions. All the CRLs created appear on the Update Revocation List page of the agent services pages. 14.4.2. Configuring CRLs for Each Issuing Point Information, such as the generation interval, the CRL version, CRL extensions, and the signing algorithm, can all be configured for the CRLs for the issuing point.
  • Page 352 Chapter 14. Revocation and CRLs • The Update Frequency section sets the different intervals when the CRLs are generated and published to the directory. • Every time a certificate is revoked or released from hold. This sets the Certificate Manager to generate the CRL every time it revokes a certificate. The Certificate Manager attempts to publish the CRL to the configured directory whenever it is generated.
  • Page 353 Configuring CRLs for Each Issuing Point Figure 14.3. CRL Cache Tab • Enable CRL cache. This checkbox enables the cache, which is used to create delta CRLs. If the cache is disabled, delta CRLs will not be created. For more information about the cache, see Section 14.3.5, “How CRLs Work”.
  • Page 354 Chapter 14. Revocation and CRLs Figure 14.4. CRL Format Tab • The CRL Format section has two options: • Revocation list signing algorithm , which is a drop down list of allowed ciphers to encrypt the CRL. • Allow extensions for CRL v2 , a checkbox which enabled CRL v2 extensions for the issuing Section 14.4.3, “Setting point.

  • Page 355: Setting Crl Extensions

    Setting CRL Extensions 7. Click Save. Section 14.4.3, “Setting 8. Extensions are allowed for this issuing point and can be configured. See CRL Extensions” for details. 14.4.3. Setting CRL Extensions NOTE Extensions only need configured for an issuing point if the Allow extensions for CRLs v2 checkbox is selected for that issuing point.

  • Page 356: Setting Full And Delta Crl Schedules

    Chapter 14. Revocation and CRLs Figure 14.5. CRL Extensions 4. To modify a rule, select it, and click Edit/View. 5. Most extensions have two options, enabling them and setting whether they are critical. Some Section A.5, “Standard X.509 v3 require more information. Supply all required values. See CRL Extensions”...

  • Page 357: Configuring Extended Updated Intervals For Crls In The Console

    Configuring Extended Updated Intervals for CRLs in the Console A full CRL is also called an extended update. By default, every CRL publishing period has an extended update. However, this can be configured so that not every publishing period is an extended update and to set the interval of when the extended updates are published.

  • Page 358: Configuring Extended Updated Intervals For Crls In Cs.cfg

    Chapter 14. Revocation and CRLs 5. Save the changes. 14.5.2. Configuring Extended Updated Intervals for CRLs in CS.cfg Two parameters need to be configured for setting the full/delta CRL publishing interval in the CS.cfg file, ca.crl.extendedNextUpdate and ca.crl.MasterCRL.updateSchema. 1. Stop the CA server. /etc/init.d/rhpki-ca stop 2.

  • Page 359: Publishing

    Chapter 15. Publishing Red Hat Certificate System includes a customizable publishing framework for the Certificate Manager, enabling certificate authorities to publish certificates, certificate revocation lists (CRLs), and other certificate-related objects to any of the supported repositories: an LDAP-compliant directory, a flat file, and an online validation authority.

  • Page 360: About Rules

    Chapter 15. Publishing 15.1.3. About Rules Rules for file, LDAP, and OCSP publishing tell the server whether and how a certificate or CRL is to be published. A rule first defines what is to be published, a certificate or CRL matching certain characteristics, by setting a type and predicate for the rule.

  • Page 361: Ocsp Publishing

    OCSP Publishing 15.1.6. OCSP Publishing There are two forms of Certificate System OCSP services, an internal service for the Certificate Manager and the Online Certificate Status Manager. The internal service checks the internal database of the Certificate Manager to report on the status of a certificate. The internal service is not set for publishing;...

  • Page 362: Setting Up Publishing

    Chapter 15. Publishing When a certificate is revoked, the server uses the publishing rules to locate and delete the corresponding certificate from the LDAP directory or from the filesystem. When a certificate expires, the server can remove that certificate from the configured directory. The server does not do this automatically;...

  • Page 363: Configuring Publishers

    Configuring Publishers rule which it matches is activated. The same certificate can be published to a file and to an LDAP directory by matching a file-based rule and matching a directory-based rule. Rules can be set for each object type: CA certificates, CRLs, user certificates, and cross-pair certificates.
  • Page 364 Chapter 15. Publishing Figure 15.1. Using the Publishers Management Tab to Create Publishers 3. Click Add to open the Select Publisher Plug-in Implementation window, which lists registered publisher modules. Figure 15.2. Select Publisher Plug-in Implementation Window 4. Select the FileBasedPublisher module, then open the editor window. This is the module that enables the Certificate Manager to publish certificates and CRLs to files.

  • Page 365: Configuring Publishers For Publishing To Ocsp

    Configuring Publishers for Publishing to OCSP Figure 15.3. Publisher Editor Window 5. Set the publisher ID, an alphanumeric string with no spaces like PublishCertsToFile, and the directory, the complete path to the directory in which the Certificate Manager should create the DER-encoded files;...
  • Page 366 Chapter 15. Publishing pkiconsole https://server.example.com:9443/ca 2. In the Configuration tab, select Certificate Manager from the navigation tree on the left. Select Publishing, and then Publishers. The Publishers Management tab, which lists configured publisher instances, opens on the right. Figure 15.4. Publishers Management Tab 3.

  • Page 367: Configuring Publishers For Ldap Publishing

    Configuring Publishers for LDAP Publishing This is the publisher module that enables the Certificate Manager to publish CRLs to the Online Certificate Status Manager. Figure 15.6. Publisher Editor Window 5. Set the publisher ID, an alphanumeric string with no spaces like PublishCertsToOCSP; the fully- qualified domain name, such as ocspResponder.example.com, and port number of the Online Certificate Status Manager;...

  • Page 368: Configuring Mappers

    Chapter 15. Publishing Publisher Description Used to publish Delta CRLs to the LDAP LdapDeltaCrlPublisher directory. Used to publish all types of end-entity certificates LdapUserCertPublisher to the LDAP directory. Used to publish cross-signed certificates to the LdapCrossCertPairPublisher LDAP directory. Table 15.1. LDAP Publishers The publishers are enabled and configured using the X.500 standard attributes for storing certificates and CRLs.
  • Page 369 Configuring Mappers Figure 15.7. Mappers Management Tab 3. In the mapper list, select a mapper to modify. 4. To edit an existing mapper, click Edit/View. The editor window opens.
  • Page 370 Chapter 15. Publishing Figure 15.8. Mapper Editor Window 5. To create a new mapper instance, click Add. The Select Mapper Plugin Implementation window opens, which lists registered mapper modules. Select a module, and edit it. For complete Section 15.13.2, “Mapper Plug-in Modules ”.
  • Page 371 Configuring Mappers Figure 15.9. Selecting a New Mapper Type 6. Edit the mapper instance, and click OK.

  • Page 372: Rules

    Chapter 15. Publishing Figure 15.10. Creating a New Mapper Section 15.13.2, “Mapper Plug-in Modules ” for detailed information about each mapper. 15.5. Rules Rules determine what certificate object is published in what location. Rules work independently, not in tandem. A certificate or CRL that is being published is matched against every rule. Any rule which it matches is activated.

  • Page 373: Modifying Publishing Rules For Certificates And Crls

    Modifying Publishing Rules for Certificates and CRLs 15.5.1. Modifying Publishing Rules for Certificates and CRLs Rules are created for each type of certificate the Certificate Manager issues. Modify publishing rules by doing the following: 1. Log into the Certificate Manager Console. pkiconsole https://server.example.com:9443/ca 2.
  • Page 374 Chapter 15. Publishing Figure 15.12. Using the Rule Editor Window to Edit an Existing Rule 4. To create a rule, click Add. This opens the Select Rule Plug-in Implementation window.
  • Page 375 Modifying Publishing Rules for Certificates and CRLs Figure 15.13. Select Rule Plugin Implementation Window Select the Rule module. This is the only default module. If any custom modules have been been registered, they are also available. 5. Edit the rule.
  • Page 376 Chapter 15. Publishing Figure 15.14. Rule Editor Window • type. This is the type of certificate for which the rule applies. For a CA signing certificate, the value is cacert. For a cross-signed certificate, the value is xcert. For all other types of certificates, the value is certs.

  • Page 377: Predicates Used In Publishing Rules

    Predicates Used in Publishing Rules 15.5.2. Predicates Used in Publishing Rules Table 15.3, “Predicate Expressions” lists the predicates that can be used to identify CRL issuing points and delta CRLs and certificate profiles. Predicate Type Predicate CRL Issuing Point issuingPointId==Issuing_Point_Instance_ID &&...
  • Page 378 Chapter 15. Publishing Figure 15.15. Enabling Publishing In the Destination section, set the information for the Directory Server instance. • Host name. If the Directory Server is configured for SSL client authenticated communication, the name must match the cn component in the subject DN of the Directory Server's SSL server certificate.

  • Page 379: Publishing Cross-Pair Certificates

    Publishing Cross-Pair Certificates • Authentication. The way the Certificate Manager authenticates to the Directory Server. The choices are Basic authentication and SSL client authentication. If the Directory Server is configured for basic authentication or for SSL communication without client authentication, select Basic authentication and specify values for the Directory manager DN and password.
  • Page 380 Chapter 15. Publishing 2. Approve the request through the agent services page, if required. 3. Retrieve the certificate from the end-entities page, and download the certificate into the browser. 4. Check whether the server generated the DER-encoded file containing the certificate. Open the directory to which the binary blob of the certificate is supposed to be published.

  • Page 381: Viewing Certificates And Crls Published To File

    Viewing Certificates and CRLs Published to File BtoA input_file output_file 12. Convert the base 64-encoded CRL to readable form using the Pretty Print CRL tool. PrettyPrintCrl input_file [output_file] 13. Compare the output. 15.9. Viewing Certificates and CRLs Published to File Certificates and CRLs can be published to two types of files: base-64 encoded or DER-encoded.

  • Page 382: Schema

    Chapter 15. Publishing 15.10.1. Schema For a Certificate Manager to publish certificates and CRLs to a directory, it must be configured with specific attributes and object classes. This section discusses those basic schema requirements. 15.10.1.1. Required Schema for Publishing End-Entity Certificates The Certificate Manager publishes an end entity's certificate to the userCertificate;binary attribute within the end entity's or subject's directory object.

  • Page 383: Bind Dn

    Bind DN 15.10.3. Bind DN The Certificate Manager accesses the Directory Server using a DN that has read-write permissions to the directory. To publish certificates and CRLs to the directory, the Certificate Manager needs to use a directory user entry that has write access to the directory. This enables the Certificate Manager to modify the user entries with certificate-related information and the CA entry with CA's certificate and CRL related information.

  • Page 384: Manually Updating Certificates In The Directory

    Chapter 15. Publishing • Publish certificates that were issued while the Directory Server was down. Similarly, unpublish certificates that were revoked or that expired while Directory Server was down. • Publish or unpublish a range of certificates based on serial numbers, from serial number xx to serial number yy.

  • Page 385: Manually Updating The Crl In The Directory

    Manually Updating the CRL in the Directory 15.11.2. Manually Updating the CRL in the Directory The Certificate Revocation List form in the Certificate Manager agent services page manually updates the directory with CRL-related information. Manually update the CRL information by doing the following: 1.

  • Page 386: Module Reference

    Chapter 15. Publishing 15.13. Module Reference The following sections list and describe the publisher, mapper, and rule modules that are contained by default with the Certificate Manager. Section 15.13.1, “Publisher Plug-in Modules” • Section 15.13.2, “Mapper Plug-in Modules ” • Section 15.13.3, “Configuring Rule Instances”...
  • Page 387 Publisher Plug-in Modules 15.13.1.2. LdapCaCertPublisher The LdapCaCertPublisher plug-in module configures a Certificate Manager to publish or unpublish a CA certificate to the caCertificate;binary attribute of the CA's directory entry. The module converts the object class of the CA's entry to a certificationAuthority, if it is not used already.
  • Page 388 Chapter 15. Publishing 15.13.1.5. LdapDeltaCrlPublisher The LdapDeltaCrlPublisher plug-in module configures a Certificate Manager to publish or unpublish a delta CRL to the deltaRevocationList;binary attribute of a directory entry. During installation, the Certificate Manager automatically creates an instance of the LdapDeltaCrlPublisher module for publishing CRLs to the directory. Parameter Description Specifies the directory attribute of the mapped...

  • Page 389: Mapper Plug-In Modules

    Mapper Plug-in Modules Parameter Description Specifies the path for publishing the CRL. This path must be the default path, /ocsp/addCRL. Table 15.10. OCSPPublisher Parameters 15.13.2. Mapper Plug-in Modules This section describes the mapper plug-in modules provided for the Certificate Manager. These modules configure a Certificate Manager to enable and configure specific mapper instances.
  • Page 390 Chapter 15. Publishing Parameter Description Creates a CA's entry, if selected (default). createCAEntry If selected, the Certificate Manager first attempts to create an entry for the CA in the directory. If the Certificate Manager succeeds in creating the entry, it then attempts to publish the CA's certificate to the entry.
  • Page 391 Mapper Plug-in Modules This mapper creates an entry for the CA in the directory and maps the CA certificate to the CA's entry in the directory. By default, the mapper is configured to create an entry for the CA in the directory, The default DN pattern for locating the CA's entry is as follows: uid=$subj.cn,ou=people,o=$subj.o 15.13.2.1.2.
  • Page 392 Chapter 15. Publishing • Example 1: uid=CertMgr, o=Example Corporation • Example 2: cn=$subj.cn,ou=$subj.ou,o=$subj.o,c=US • Example 3: uid=$req.HTTP_PARAMS.uid, e= $ext.SubjectAlternativeName.RFC822Name,ou=$subj.ou In the examples, $req takes the attribute from the certificate request, $subj takes the attribute from the certificate subject name, and $ext takes the attribute from the certificate extension. 15.13.2.4.
  • Page 393 Mapper Plug-in Modules components match, an error is returned. If none of the DN components and filter components match, an error is returned. If the filter components are null, a base search is performed. Both the DNComps and filterComps parameters accept valid DN components or attributes separated by commas.
  • Page 394 Chapter 15. Publishing For the dnComps parameter, enter those DN components that the Certificate Manager can use to form the LDAP DN exactly. In certain situations, however, the subject name in a certificate may match more than one entry in the directory. Then, the Certificate Manager might not get a single, distinct matching entry from the DN.

  • Page 395: Configuring Rule Instances

    Configuring Rule Instances Parameter Description where org and country are replaced with values from the DN in the certificate. If the dnComps field is empty, the server checks the baseDN field and searches the directory tree specified by that DN for entries matching the filter specified by filterComps parameter values.
  • Page 396 Chapter 15. Publishing Parameter Value Description LdapCaCertMap S pecifies the mapper used with the rule. See mapper Section 15.13.2.1.1, “LdapCaCertMap” for details on the mapper. Specifies the publisher used with the rule. See publisher LdapCaCertPublisher Section 15.13.1.2, “LdapCaCertPublisher” for details on the publisher.
  • Page 397 Configuring Rule Instances Parameter Value Description Enables the rule. enable Specifies the mapper used with the rule. See mapper LdapCrlMap Section 15.13.2.1.2, “LdapCrlMap” for details on the mapper. Specifies the publisher used with the rule. See publisher LdapCrlPublisher Section 15.13.1.4, “LdapCrlPublisher” for details on the publisher.

  • Page 399: Authentication For Enrolling Certificates

    Chapter 16. Authentication for Enrolling Certificates This chapter covers how to enroll end entity certificates, how to create and manage server certificates, the authentication methods available in the Certificate System to use when enrolling end entity certificates, and how to set up those authentication methods. 16.1.

  • Page 400: Agent-Approved Enrollment

    Chapter 16. Authentication for Enrolling Certificates successfully authenticated, the request is processed without being sent to an agent's queue. If the request passes the certificate profile configuration of the Certificate Manager, the certificate is issued and stored in the internal database. It is delivered to the end entity immediately through the HTML forms.

  • Page 401: Setting Up Directory-Based Authentication

    Setting up Directory-Based Authentication • AgentCertAuth. Agents who are successfully issued server certificates through an automated process are automatically authenticated when they present the agent certificate. If the certificate presented is the agent certificate stored in the database for the user ID, the request for the server certificate is automatically processed.

  • Page 402: Setting Up Pin-Based Enrollment

    Chapter 16. Authentication for Enrolling Certificates • ldapByteAttributes. Specifies the list of LDAP byte (binary) attributes that should be considered authentic for the end entity. If specified, the values corresponding to these attributes will be copied from the authentication directory into the authentication token for use by other modules, such as adding additional information to users' certificates.
  • Page 403 Setting up PIN-based Enrollment • Adds the necessary schema for PINs to the LDAP directory. • Adds a PIN manager user who has read-write permissions to the PINs that are set up. • Sets up ACIs to allow for PIN removal once the PIN has been used, giving read-write permissions for PINs to the PIN manager, and preventing users from creating or changing PINs.
  • Page 404 Chapter 16. Authentication for Enrolling Certificates g. Use the output file for delivering PINs to users after completing setting up the required authentication method. After confirming that the PIN-based enrollment works, deliver the PINs to users so they can use them during enrollment. To protect the privacy of PINs, use a secure, out-of-band delivery method.
  • Page 405 Setting up PIN-based Enrollment • ldap.ldapconn.host. Specifies the fully-qualified DNS host name of the authentication directory. • ldap.ldapconn.port. Specifies the TCP/IP port on which the authentication directory listens to requests from the Certificate System. • ldap.ldapconn.secureConn. Specifies the type, SSL or non-SSL, of the port on which the authentication directory listens to requests.

  • Page 406: Setting Up Cmc Enrollment

    Chapter 16. Authentication for Enrolling Certificates Click OK. 4. Customize the enrollment forms by configuring the inputs in the certificate profiles. Include the information that will be needed by the plug-in to authenticate the user. If the default inputs do not contain all of the information that needs to be collected, submit a request created with a third-party tool.

  • Page 407: Setting Up The Server For Multiple Requests In A Full Cmc Request

    Setting up the Server for Multiple Requests in a Full CMC Request CMCEnroll -d /certificate/directory -h password -n cert_nickname -r certrequest.file -p certDB_passwd [-c] Parameter Description The location of the directory containing the cert8.db, key3.db, and secmod.db files associated with the agent certificate. Password to the database specified in the d option.

  • Page 408: Certificate-Based Enrollment

    Chapter 16. Authentication for Enrolling Certificates 2. Create a certificate request using the certutil tool. 3. Copy the PKCS #10 ASCII output to a text file. 4. Run the CMCEnroll utility. For example, if the input file called request34.txt, the agent certificate is stored in the directory /var/lib/rhpki-ca/alias, the certificate common name of the agent certificate is CertificateManagerAgentsCert, and the password for the certificate database is 1234pass, the command is as follows:...

  • Page 409: Setting Up Certificate-Based Enrollment

    Setting up Certificate-Based Enrollment One way to achieve this is to initialize hardware tokens in bulk and preload them with dual certificates issued by the Certificate System for dual key pairs. These certificates are generated with generic common names, such as hardwaretoken1234. This way, there is no one-to-one relation between users and the hardware tokens initially.

  • Page 410: Testing Enrollment

    Chapter 16. Authentication for Enrolling Certificates NOTE All three enrollment forms work by default with the directory-based authentication Section 16.3.1, “Setting up Directory-Based module, UidPwdDirAuth, explained in Authentication”. Certificate-based enrollment forms can be used with any of the authentication modules, such as directory- and PIN-based authentication modules. In general, the following three hidden variables distinguish certificate-based enrollment forms from other enrollment forms: •...

  • Page 411: Managing Authentication Plug-Ins

    Managing Authentication Plug-ins 6. Verify that the certificate is installed in the browser's certificate database. 7. If directory- or PIN-based authentication was configured with PIN removal, re-enroll for another certificate using the same PIN. The request should be rejected. 16.7. Managing Authentication Plug-ins Custom authentication plug-in modules can be registered through the CA Console.

  • Page 413: User And Group Authorization

    Chapter 17. User and Group Authorization This chapter explains how to set up authorization for access to the administrative, agent services, and end-entities pages. 17.1. About Authorization Authorization is the process of allowing access to certain tasks associated with the Certificate System. Access can be limited to allow certain tasks to certain areas of the subsystem for certain users or groups and different tasks to different users and groups.
  • Page 414 Chapter 17. User and Group Authorization • Auditors. This group is given access to view the signed audit logs. This group does not have any other privileges. • Enterprise administrators. Each subsystem instance is automatically assigned a subsystem-specific role as an enterprise administrator when it is joined to a security domain during configuration. These roles automatically provide trusted relationships among subsystems in the security domain, so that each subsystem can efficiently carry out interactions with other subsystems.
  • Page 415 Default Groups • The Data Recovery Manager Agents group. • The Online Certificate Status Manager Agents group. • The Token Key Service Agents group. • The Token Processing System Agents group. Each Certificate System subsystem has its own agents with roles defined by the subsystem. Each subsystem must have at least one agent, but there is no limit to the number of agents a subsystem can have.

  • Page 416: Creating Users

    Chapter 17. User and Group Authorization The trusted manager relationship is set up in the following way: • The subsystem trusts the other subsystem as a trusted manager by creating a user ID for the subsystem, adding it to the trusted manager group, and storing its SSL client authentication certificate.

  • Page 417: Setting Up A Trusted Manager

    Setting up a Trusted Manager Figure 17.1. Creating a New User The group to which the user belongs determines what privileges the user has. Assign agents and administrators to the appropriate subsystem group. 4. Store the user's certificate. a. Request and issue an SSL client certificate for the user if one has not already been generated. b.
  • Page 418 Chapter 17. User and Group Authorization 1. Log into the administrative console for the subsystem to which the trusted manager is being added. pkiconsole https://host:SSLport/subsystemType 2. In the Configuration tab, select Users and Groups. Click Add. 3. Fill in the identifying information. The information is to help keep track of the trusted manager entry;...
  • Page 419 Setting up a Trusted Manager c. In the text area of the dialog, paste the Certificate Manager's certificate in base-64 encoded form. Include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines. d. To view the certificate, select it, and click View. Next, configure the connector settings of the Certificate Manager.

  • Page 420: Modifying Certificate System User Entries

    Chapter 17. User and Group Authorization Figure 17.4. Setting Connector Information 17.4. Modifying Certificate System User Entries This section describes how to change a user entry, delete the user, or change the certificate associated with the user. 17.4.1. Changing a Certificate System User's Login Information Change a Certificate System user's login information by doing the following: 1.

  • Page 421: Changing A Certificate System User's Certificate

    Changing a Certificate System User's Certificate pkiconsole https://host:SSLport/subsystemType 2. Select Users and Groups. 3. Select the user to edit from the list of user IDs, and click Edit. 4. Make the appropriate modifications. 17.4.2. Changing a Certificate System User's Certificate To change a user's certificate, do the following: 1.

  • Page 422: Creating A New Group

    Chapter 17. User and Group Authorization Delete a privileged user from the internal database by doing the following: 1. Log into the administrative console. 2. Select Users and Groups from the navigation menu on the left. 3. Select the user from the list of user IDs, and click Delete. 4.

  • Page 423: Authorization For Certificate System Users

    Authorization for Certificate System Users 17.6. Authorization for Certificate System Users Authorization is the mechanism that checks whether a user is allowed to perform an operation. Authorization points are defined in certain groups of operations that require an authorization check. 17.6.1.
  • Page 424 Chapter 17. User and Group Authorization allow (read) group="Administrators" || group="Auditors" The administrative console can create or modify ACIs. The interface sets whether to allow or deny the operation in the Allow and Deny field, sets which operations are possible in the Operations field, and then lists the groups, users, or IP addresses being granted or denied access in the Syntax field.
  • Page 425 How ACIs Are Formed http://java.sun.com/j2se/1.4.2/ For more information on supported regular expression patterns, see docs/api/java/util/regex/Pattern.html#sum. 17.6.4.3.2. User Syntax The syntax to include a user in the ACL is user="userID". The syntax to exclude the user is user! ="userID", which allows any user ID except for the user ID named. For example: user="BobC"...

  • Page 426: Editing Acls

    Chapter 17. User and Group Authorization 17.6.5. Editing ACLs ACLs are stored in the internal database and can only be modified in the administrative console. To edit the existing ACLs, do the following: 1. Log into the administrative console. 2. Select Access Control List in the left navigation menu. Figure 17.6.
  • Page 427 Editing ACLs Figure 17.7. The ACL Editor Window 4. To add an ACI, click Add, and supply the ACI information. To edit an ACI, select the ACI from the list in the ACI entries text area of the ACL Editor window. Click Edit.

  • Page 428: Acl Reference

    Chapter 17. User and Group Authorization Figure 17.8. Creating and Editing ACIs a. Select the allow or deny radio button from the Access field to allow or deny the operation to the groups, users, or IP addresses specified. For more information about allowing or denying Section 17.6.4.1, “Allow and Deny”.

  • Page 429: Certserver.admin.certificate

    certServer.admin.certificate 17.7.1.1. Operations Operations read modify 17.7.1.2. Default ACIs allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Data Recovery Manager Agents" || group="Online Certificate Status Manager Agents" || group=Auditors allow (modify) group="Administrators" Agents, administrators, and auditors can read ACL configuration; only administrators can modify ACL configuration.

  • Page 430: Certserver.auth.configuration

    Chapter 17. User and Group Authorization Operations execute 17.7.3.2. Default ACIs allow (submit) user="anybody" allow (read,execute) group="Certificate Manager Agents" Anyone can submit an enrollment request; only Certificate Manager agents may read or execute request. 17.7.4. certServer.auth.configuration Controls operations on the authentication configuration. 17.7.4.1.

  • Page 431: Certserver.ca.certificates

    certServer.ca.certificates Operations unrevoke revoke read 17.7.5.2. Default ACIs allow (import,unrevoke,revoke,read) group="Certificate Manager Agents" Certificate Manager agents can import, unrevoke, revoke, and read a certificate. 17.7.6. certServer.ca.certificates Controls revoke or list operations for certificates in the agent services interface. 17.7.6.1. Operations Operations revoke list...

  • Page 432: Certserver.ca.connector

    Chapter 17. User and Group Authorization Operations 17.7.7.2. Default ACIs allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Data Recovery Manager Agents" || group="Online Certificate Status Manager Agents" || group="Auditors" allow (modify) group="Administrators" Administrators, auditors, and agents are allowed to read CA configuration; only administrators are allowed to modify CA configuration.

  • Page 433: Certserver.ca.crl

    certServer.ca.crl allow (submit) group="Certificate Manager Agents" A trusted manager can submit requests through the subsystem interface. 17.7.10. certServer.ca.crl Controls read or update operations for CRLs in the agent services interface. 17.7.10.1. Operations Operations read update 17.7.10.2. Default ACIs allow (read,update) group="Certificate Manager Agents" Certificate Manager agents can read or update CRLs.

  • Page 434: Certserver.ca.ocsp

    Chapter 17. User and Group Authorization 17.7.12.2. Default ACIs allow (add) group="Administrators" Only administrators are allowed to add groups. 17.7.13. certServer.ca.ocsp Controls read operations for OCSP information in the agent services interface. 17.7.13.1. Operations Operations read 17.7.13.2. Default ACIs allow (read) group="Certificate Manager Agents" Only Certificate Manager agents can read OCSP usage statistics.

  • Page 435: Certserver.ca.requests

    certServer.ca.requests Operations approve 17.7.15.2. Default ACIs allow (read,approve) group="Certificate Manager Agents" Certificate Manager agents can view and approve certificate profiles. 17.7.16. certServer.ca.requests Controls list operations for requests in the agents services interface. 17.7.16.1. Operations Operations list 17.7.16.2. Default ACIs allow (list) group="Certificate Manager Agents" Only Certificate Manager agents can list requests.

  • Page 436: Certserver.ca.request.profile

    Chapter 17. User and Group Authorization Anyone can submit an enrollment request; only Certificate Manager agents can read or execute enrollment requests. 17.7.18. certServer.ca.request.profile Controls approve or read operations for certificate profile-based requests. 17.7.18.1. Operations Operations approve read 17.7.18.2. Default ACIs allow (approve,read) group="Certificate Manager Agents"...

  • Page 437: Certserver.ee.certificates

    certServer.ee.certificates Operations Description read Retrieve and view certificates based on the certificate serial number or request ID. import Import a certificate into a client. 17.7.20.2. Default ACIs allow (revoke,read,import) user="anybody" Anyone can request a revocation and import and read a certificate. 17.7.21.

  • Page 438: Certserver.ee.crl

    Chapter 17. User and Group Authorization 17.7.23. certServer.ee.crl Controls read and add operations for CRLs in the end-entities page. 17.7.23.1. Operations Operations read 17.7.23.2. Default ACIs allow (read,add) user="anybody" Anyone can add or read a CRL. 17.7.24. certServer.ee.profile Controls submit and read operations for certificate profiles in the end-entities page. 17.7.24.1.

  • Page 439: Certserver.ee.facetofaceenrollment

    certServer.ee.facetofaceenrollment Anyone can list certificate profiles. 17.7.26. certServer.ee.facetofaceenrollment Controls list operations for certificate profiles to read face-to-face enrollment pages. 17.7.26.1. Operations Operations read 17.7.26.2. Default ACIs allow (read) user="anybody" Anyone can read the face-to-face enrollment page. 17.7.27. certServer.ee.request.enrollment Controls submit operations for certificate enrollment in the end-entities page. 17.7.27.1.

  • Page 440: Certserver.ee.request.ocsp

    Chapter 17. User and Group Authorization Anyone can submit face-to-face enrollment. 17.7.29. certServer.ee.request.ocsp Controls submitting OCSP requests. 17.7.29.1. Operations Operations submit 17.7.29.2. Default ACIs allow (submit) user="anybody" Any clients can submit OCSP requests. 17.7.30. certServer.ee.request.revocation Controls submit operations for certificate revocation requests in the end-entities page. 17.7.30.1.

  • Page 441: Certserver.general.configuration

    certServer.general.configuration allow (read) user="anybody" Anyone can read a request status. 17.7.32. certServer.general.configuration Controls operations on the general configuration of the subsystem. 17.7.32.1. Operations Operations read modify 17.7.32.2. Default ACIs allow (read) group="Administrators" || group="Auditors" || group="Certificate Manager Agents" || group="Data Recovery Manager Agents" || group="Online Certificate Status Manager Agents"...

  • Page 442: Certserver.kra.certificate.transport

    Chapter 17. User and Group Authorization 17.7.33.2. Default ACIs allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Data Recovery Manager Agents" || group="Online Certificate Status Manager Agents" || group="Auditors" allow (modify) group="Administrators" Administrators, agents, and auditors are allowed to read job configuration; only administrators are allowed to modify job configuration.

  • Page 443: Certserver.kra.connector

    certServer.kra.connector || group="Certificate Manager Agents" || group="Data Recovery Manager Agents" || group="Online Certificate Status Manager Agents" allow (modify) group="Administrators" Administrators, auditors, and agents are allowed to read DRM general configuration; only administrators are allowed to modify DRM configuration. 17.7.36. certServer.kra.connector Controls request submissions.

  • Page 444: Certserver.kra.request

    Chapter 17. User and Group Authorization 17.7.38.1. Operations Operations list 17.7.38.2. Default ACIs allow (list) group="Data Recovery Manager Agents" Only DRM agents can list keys. 17.7.39. certServer.kra.request Controls read operation for a DRM request. 17.7.39.1. Operations Operations read 17.7.39.2. Default ACIs allow (read) group="Data Recovery Manager Agents"...

  • Page 445: Certserver.kra.systemstatus

    certServer.kra.systemstatus 17.7.41.1. Operations Operations read 17.7.41.2. Default ACIs allow (read) group="Data Recovery Manager Agents" Only DRM agents can get the status of key archival requests. 17.7.42. certServer.kra.systemstatus Controls read operations to display the system status of a DRM. 17.7.42.1. Operations Operations read 17.7.42.2.

  • Page 446: Certserver.log.configuration.signedaudit.expirationtime

    Chapter 17. User and Group Authorization || group="Online Certificate Status Manager Agents" allow (modify) group="Administrators" Administrators, agents, and auditors are allowed to read the log configuration; only administrators are allowed to modify the log configuration. 17.7.44. certServer.log.configuration.SignedAudit.expirationTime Controls operations on the expirationTime parameter of a log instance. 17.7.44.1.

  • Page 447: Certserver.log.content.signedaudit

    certServer.log.content.SignedAudit deny (modify) user=anybody Administrators, agents, and auditors can view the value of the fileName parameter; no one is allowed to modify the fileName parameter. 17.7.46. certServer.log.content.SignedAudit Controls read operations to the signed audit log. 17.7.46.1. Operations Operations read 17.7.46.2. Default ACIs deny (read) group="Administrators"...

  • Page 448: Certserver.ocsp.ca

    Chapter 17. User and Group Authorization 17.7.48. certServer.ocsp.ca Controls add operations for adding a CA to an Online Certificate Status Manager. 17.7.48.1. Operations Operations 17.7.48.2. Default ACIs allow (add) group="Online Certificate Status Manager Agents" Only Online Certificate Status Manager agents can add CAs. 17.7.49.

  • Page 449: Certserver.ocsp.configuration

    certServer.ocsp.configuration allow (validate) group="Online Certificate Status Manager Agents" Only Online Certificate Status Manager agents can validate certificate status. 17.7.51. certServer.ocsp.configuration Controls operations on the OCSP configuration. 17.7.51.1. Operations Operations read modify 17.7.51.2. Default ACIs allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Data Recovery Manager Agents"...

  • Page 450: Certserver.publisher.configuration

    Chapter 17. User and Group Authorization 17.7.53.1. Operations Operations read modify 17.7.53.2. Default ACIs allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Data Recovery Manager Agents" || group="Online Certificate Status Manager Agents" || group="Auditors" allow (modify) group="Administrators" Administrators, agents, and auditors are allowed to read certificate profile configuration; only administrators are allowed to modify certificate profile configuration.

  • Page 451: Certserver.registry.configuration

    certServer.registry.configuration || group="Certificate Manager Agents" || group="Data Recovery Manager Agents" || group="Online Certificate Status Manager Agents" allow (modify) group="Administrators" Administrators, auditors, and agents are allowed to read publisher configuration; only administrators are allowed to modify publisher configuration. 17.7.55. certServer.registry.configuration Controls operations on the administration registry, the file that is used to register plug-in modules. Currently, this is only used to register certificate profile plug-ins.
  • Page 452 Chapter 17. User and Group Authorization allow (read) group="Administrators" || group="Auditors" || group="Certificate Manager Agents" || group="Data Recovery Manager Agents" || group="Online Certificate Status Manager Agents" allow (modify) group="Administrators" Administrators, auditors, and agents are allowed to read user and group configuration; only administrators are allowed to modify user and group configuration.

  • Page 453: Automated Notifications

    Chapter 18. Automated Notifications The Certificate System can be configured to send automatic email notifications to end users when certificates are issued and revoked or to an agent when a new request has arrived in the agent request queue. This chapter describes automated notifications and details how to enable, configure, and customize the notification email messages that are sent.

  • Page 454: Setting Up Automated Notifications

    Chapter 18. Automated Notifications 18.2. Setting Up Automated Notifications To configure a Certificate Manager to send automated notifications, do the following: 1. Open the Certificate Manager Console. pkiconsole https://server.example.com:9443/ca 2. Open the Configuration tab. 3. Open the Certificate Manager heading in the navigation tree on the left. Then select Notification. The Notification tabs appear in the right side of the window.

  • Page 455: Configuring Specific Notifications By Editing The Configuration File

    Configuring Specific Notifications by Editing the Configuration File 5. To enable certificate revocation notifications, go to the Certificate Revoked tab, select the enable checkbox, and specify information in the following fields: • Enable Certificate Revoked notification . Select this checkbox to enable certificate revoked notifications.

  • Page 456: Testing Configuration

    Chapter 18. Automated Notifications 3. Edit all of the configuration parameters for the notification type being enabled. For certificate issuing notifications, there are four parameters: ca.notification.certIssued.emailSubject ca.notification.certIssued.emailTemplate ca.notification.certIssued.enabled ca.notification.certIssued.senderEmail For certificate revocation notifications, there are four parameters: ca.notification.certRevoked.emailSubject ca.notification.certRevoked.emailTemplate ca.notification.certRevoked.enabled ca.notification.certRevoked.senderEmail For certificate request notifications, there are five parameters: ca.notification.requestInQ.emailSubject...

  • Page 457: Customizing Notification Messages

    Customizing Notification Messages When the server issues a certificate, the user receive a certificate-issued email notification to the address listed in the request. Check the message to see if it has the correct information. 4. Log into the agent interface, and revoke the certificate. The user email account should contain an email message reading that the certificate has been revoked.
  • Page 458 Chapter 18. Automated Notifications The name and location of these messages can be changed; make the appropriate changes when configuring the notification. All template names can be changed except for the certificate rejected templates; these names must remain the same. The templates associated with certificate issuance and certificate rejection must be located in the same directory and must use the same extension.

  • Page 459: Token Definitions

    Token Definitions Filename Description Uses the publishCertsItem.html template to format the items in the table. Template for formatting the items included in the publishCertsItem.html summary table. Template for the report or table that summarizes ExpiredUnpublishJob removal of expired certificates from the directory. Uses the ExpiredUnpublishJobItem template to format the items in the table.
  • Page 460 Chapter 18. Automated Notifications Token Description Gives the date the certificate was revoked. $RevocationDate Gives the email address of the sender; this $SenderEmail is the same as the one specifified in the Sender's E-mail Address field in the notification configuration. Gives the serial number of the certificate that has $SerialNumber been issued;...

  • Page 461: Automated Jobs

    Chapter 19. Automated Jobs The Certificate System provides a customizable Job Scheduler that supports various mechanisms for scheduling cron jobs. This chapter explains how to configure Certificate System to use specific job plug-in modules for accomplishing jobs. 19.1. About Automated Jobs The Certificate Manager Console includes a Job Scheduler option that can execute specific jobs at specified times.

  • Page 462: Setting Up The Job Scheduler

    Chapter 19. Automated Jobs 19.1.2.3. unpublishExpiredCerts Expired certificates are not automatically removed from the publishing directory. If a Certificate Manager is configured to publish certificates to an LDAP directory, over time the directory will contain expired certificates. The unpublishExpiredCerts job checks for certificates that have expired and are still marked as published in the internal database at the configured time interval.

  • Page 463: Setting Up Specific Jobs

    Setting up Specific Jobs Figure 19.1. General Settings Tab 3. Click the Enable Jobs Schedule checkbox to enable or disable the Job Scheduler. Disabling the Job Scheduler turns off all the jobs. 4. Set the frequency which the scheduler checks for jobs in the Check Frequency field. The frequency is how often the Job Scheduler daemon thread wakes up and calls the configured jobs that meet the cron specification.

  • Page 464: Configuring Specific Jobs Using The Certificate Manager Console

    Chapter 19. Automated Jobs 19.3.1. Configuring Specific Jobs Using the Certificate Manager Console To enable and configure an automated job using the Certificate Manager Console, do the following: 1. Open the Certificate Manager Console. pkiconsole https://server.example.com:9443/ca Section 19.2, “Setting up the Job Scheduler” 2.
  • Page 465 Configuring Specific Jobs Using the Certificate Manager Console Figure 19.3. Job Configuration 5. Select Enable to turn on the job. 6. Set the configuration settings by specifying them in the fields for this dialog. Section 19.3.3, “Configuration Parameters of • For requestInQueueNotifier, see requestInQueueNotifier”.

  • Page 466: Configuring Jobs By Editing The Configuration File

    Chapter 19. Automated Jobs 7. Click OK. 8. Click Refresh to view any changes in the main window. 9. If the job is configured to send automatic messages, check that a mail server is set up correctly. Section 3.5, “Mail Server”.

  • Page 467: Configuration Parameters Of Publishcerts

    Configuration Parameters of publishCerts Parameter Description Sets whether the job is enabled (true) or enabled disabled (false). Sets the time schedule for when the job cron should run. This is the time at which the Job Scheduler daemon thread checks the queue for pending requests.

  • Page 468: Configuration Parameters Of Unpublishexpiredcerts

    Chapter 19. Automated Jobs Parameter Description Section 19.3.6, “Frequency Settings for Automated Jobs”. For example: 00**6 Specifies whether a summary of the certificates summary.enabled removed by the job should be compiled and sent. The value true enables the summaries; false disables them.

  • Page 469: Frequency Settings For Automated Jobs

    Frequency Settings for Automated Jobs Parameter Description Specifies whether a summary of the certificates summary.enabled removed by the job should be compiled and sent. The value true enables the summaries; false disables them. If enabled, set the remaining summary parameters; these are required by the server to send the summary report.

  • Page 470: Managing Job Plug-Ins

    Chapter 19. Automated Jobs 15 * * * * The following example sets a job to run at noon on April 12: 0 12 12 4 * The day-of-month and day-of-week options can contain a comma-separated list of values to specify more than one day.
  • Page 471 Registering or Deleting a Job Module Supply the following information: • Plugin name. Type a name for the plug-in module. • Class name. Type the full name of the class for this module; this is the path to the implementing Java™...

  • Page 473: Configuring The Certificate System For High Availability

    Chapter 20. Configuring the Certificate System for High Availability This chapter explains how to create and configure the Red Hat Certificate System for high availability. Certificate System subsystems can be cloned, or duplicated, and run on different machines. This provides failover support by ensuring that Certificate System services continue even if the master instance was goes offline.

  • Page 474: Load Balancing

    Chapter 20. Configuring the Certificate System for High Availability Figure 20.1. Certificate System Example Section 20.4, “Clone- As this diagram indicates, only one of the CAs can generate the CRLs. See Master Conversion” for more information about configuring a clone for CRL generation during cloning. 20.1.2.

  • Page 475: Diagnostics

    Diagnostics its operations. Before installing and configuring the clone, the master subsystem must be installed, fully configured, and running. A cloned subsystem is configured through standard configuration wizard. Before going through the setup process, some manual preparation is required. To prepare for cloning, do the following: •...

  • Page 476: Clone-Master Conversion

    Chapter 20. Configuring the Certificate System for High Availability 1. Set up OCSP publishing in the master CA so that the CRL is published to the master OCSP. 2. Once the CRL is successfully published, check both the master and cloned OCSP's List Certificate Authorities link in the agent pages.

  • Page 477: Converting A Master Ca Into A Cloned Ca

    Converting a Master CA into a Cloned CA Subsystem Differences single CA should generate CRLs, and this task is always left to the master CA. OCSP Clones have a unique configuration parameter, OCSP.Responder.store.defStore.refreshInSec. There are no configurable differences between a master and a clone.

  • Page 478: Converting A Cloned Ca Into A Master Ca

    Chapter 20. Configuring the Certificate System for High Availability • Enable CRL generation requests redirection by adding the following two lines: master.ca.agent.host=hostname master.ca.agent.port=port number 20.4.2. Converting a Cloned CA into a Master CA After converting the existing offline master CA into an offline cloned CA, one of the online cloned CAs must be converted into the new online master CA.

  • Page 479: Converting A Master Ocsp Into A Cloned Ocsp

    Converting a Master OCSP into a Cloned OCSP g. Disable CRL generation requests redirection by removing the following two lines: master.ca.agent.host=hostname master.ca.agent.port=port number 4. Start the new master CA server. /etc/init.d/instance_ID start 20.4.3. Converting a Master OCSP into a Cloned OCSP Since only one master OCSP Responder can exist for a Certificate System installation, the offline master must first be converted into a cloned OCSP Responder before one of the cloned OCSPs becomes the new master OCSP.
  • Page 480 Chapter 20. Configuring the Certificate System for High Availability 4. Start the new master OCSP responder server. /etc/init.d/instance_ID start...

  • Page 481: Certificate And Crl Extensions

    Appendix A. Certificate and CRL Extensions This appendix explains both the standard certificate extensions defined by X.509 v3 and the extensions defined by Netscape that were used in versions of products released before X.509 v3 was finalized. It provides recommendations for extensions to use with specific kinds of certificates, including PKIX Part 1 recommendations.

  • Page 482: Structure Of Certificate Extensions

    Appendix A. Certificate and CRL Extensions • CRL checking . Since it is not always possible to check a certificate's revocation status against a directory or with the original certificate authority, it is useful for certificates to include information about where to check CRLs. The X.509 v3 specification addressed these issues by altering the certificate format to include additional information within a certificate by defining a general format for certificate extensions and specifying extensions that can be included in the certificate.

  • Page 483: Sample Certificate Extensions

    Sample Certificate Extensions critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING The means a certificate extension consists of the following: • The object identifier (OID) for the extension. This identifier uniquely identifies the extension. It also determines the ASN.1 type of value in the value field and how the value is interpreted. When an extension appears in a certificate, the OID appears as the extension ID field (extnID) and the corresponding ASN.1 encoded structure appears as the value of the octet string (extnValue);...

  • Page 484: Note On Object Identifiers

    Appendix A. Certificate and CRL Extensions Signature Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5 Issuer: CN=Certificate Manager,OU=netscape,O=aol,L=MV,ST=CA,C=US Validity: Not Before: Friday, February 21, 2005 12:00:00 AM PST America/Los_Angeles After: Monday, February 21, 2007 12:00:00 AM PST America/Los_Angeles Subject: CN=Certificate Manager,OU=netscape,O=aol,L=MV,ST=CA,C=US Subject Public Key Info: Algorithm: RSA - 1.2.840.113549.1.1.1 Public Key: Exponent: 65537...

  • Page 485: Standard X.509 V3 Certificate Extensions

    Standard X.509 v3 Certificate Extensions extension-specific profile plug-in modules which enable X.509 certificate extensions to be added to the certificates the server issues. Some of the extensions contain fields for specifying OIDs. The PKIX standard recommends that all objects, such as extensions and profile statements, that are used in certificates be included in the form of an OID.

  • Page 486: Authorityinfoaccess

    Appendix A. Certificate and CRL Extensions A.3.1. authorityInfoAccess A.3.1.1. OID 1.3.6.1.5.5.7.1.1 A.3.1.2. Criticality This extension must be noncritical. A.3.1.3. Discussion The Authority Information Access extension indicates how and where to access information about the issuer of the certificate. The extension contains an accessMethod and an accessLocation field.

  • Page 487: Basicconstraints

    basicConstraints If this extension is not present, then the issuer name alone is used to identify the issuer certificate. PKIX Part 1 requires this extension for all certificates except self-signed root CA certificates. Where a key identifier has not been established, PKIX recommends that the authorityCertIssuer and authorityCertSerialNumber fields be specified.

  • Page 488: Crldistributionpoints

    Appendix A. Certificate and CRL Extensions A.3.5. CRLDistributionPoints A.3.5.1. OID 2.5.29.31 A.3.5.2. Criticality PKIX recommends that this extension be marked noncritical and that it be supported for all certificates. A.3.5.3. Discussion This extension defines how CRL information is obtained. It should be used if the system is configured to use CRL issuing points.

  • Page 489: Issueraltname Extension

    issuerAltName Extension Table A.1, “PKIX Extended Key Usage Extension Uses” lists the uses defined by PKIX for this Table A.2, “Private Extended Key Usage Extension Uses” extension, and lists uses privately defined by Netscape. Server authentication Client authentication Code signing Email Timestamping OCSP Signing...
  • Page 490 Appendix A. Certificate and CRL Extensions A.3.8.3. Discussion The Key Usage extension defines the purpose of the key contained in the certificate. The Key Usage, Extended Key Usage, and Basic Constraints extensions act together to specify the purposes for which a certificate can be used.

  • Page 491: Nameconstraints

    nameConstraints If the keyUsage extension is present, critical or not, it is used to select from multiple certificates for a given operation. For example, it is used to distinguish separate signing and encryption certificates for users who have separate certificates and key pairs for operations. A.3.9.

  • Page 492: Policymappings

    Appendix A. Certificate and CRL Extensions A.3.11.2. Criticality This extension may be critical or noncritical. A.3.11.3. Discussion This extension, which is for CA certificates only, constrains path validation in two ways. It can be used to prohibit policy mapping or to require that each certificate in a path contain an acceptable policy identifier.

  • Page 493: Subjectaltname

    subjectAltName A.3.14. subjectAltName A.3.14.1. OID 2.5.29.17 A.3.14.2. Criticality If the certificate's subject field is empty, this extension must be marked critical. A.3.14.3. Discussion The Subject Alternative Name extension includes one or more alternative (non-X.500) names for the identity bound by the CA to the certified public key. It may be used in addition to the certificate's subject name or as a replacement for it.

  • Page 494: Introduction To Crl Extensions

    Appendix A. Certificate and CRL Extensions A.3.16.3. Discussion The Subject Key Identifier extension identifies the public key certified by this certificate. This extension provides a way of distinguishing public keys if more than one is available for a given subject name. The value of this extension should be calculated by performing a SHA-1 hash of the certificate's DER- encoded subjectPublicKey, as recommended by PKIX.

  • Page 495: Sample Crl And Crl Entry Extensions

    Sample CRL and CRL Entry Extensions • If the extension is not critical and the CRL 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 CRL.

  • Page 496: Standard X.509 V3 Crl Extensions

    Appendix A. Certificate and CRL Extensions A.5. Standard X.509 v3 CRL Extensions In addition to certificate extensions, the X.509 proposed standard defines extensions to CRLs, which provide methods for associating additional attributes with Internet CRLs. These are one of two kinds: extensions to the CRL itself and extensions to individual certificate entries in the CRL.
  • Page 497 Extensions for CRLs A.5.1.2. CRLNumber A.5.1.2.1. OID 2.5.29.20 A.5.1.2.2. Criticality This extension must not be critical. A.5.1.2.3. Discussion The CRLNumber extension specifies a sequential number for each CRL issued by a CA. It allows users to easily determine when a particular CRL supersedes another CRL. PKIX requires that all CRLs have this extension.
  • Page 498 Appendix A. Certificate and CRL Extensions Parameter critical Table A.6. DeltaCRL Configuration Parameters A.5.1.4. FreshestCRL A.5.1.4.1. OID 2.5.29.27 A.5.1.4.2. Criticality PKIX requires that this extension must be noncritical. A.5.1.4.3. Discussion The freshestCRL extension identifies how delta CRL information is obtained. The freshestCRL extension is placed in the full CRL to indicate where to find the latest delta CRL.
  • Page 499 Extensions for CRLs Parameter Description example, http://testCA.example.com/ get/crls/here/. Table A.7. FreshestCRL Configuration Parameters A.5.1.5. issuerAltName A.5.1.5.1. OID 2.5.29.18 A.5.1.5.2. Discussion The Issuer Alternative Name extension allows additional identities to be associated with the issuer of the CRL, like binding attributes such as a mail address, a DNS name, an IP address, and a uniform resource indicator (URI), with the issuer of the CRL.
  • Page 500 Appendix A. Certificate and CRL Extensions Parameter namen Table A.8. IssuerAlternativeName Configuration Parameters...
  • Page 501 Extensions for CRLs A.5.1.6. issuingDistributionPoint A.5.1.6.1. OID 2.5.29.28 A.5.1.6.2. Criticality PKIX requires that this extension be critical if it exists. A.5.1.6.3. Discussion The Issuing Distribution Point CRL extension identifies the CRL distribution point for a particular CRL and indicates what kinds of revocation it covers, such as revocation of end-entity certificates only, CA certificates only, or revoked certificates that have a limited set of reason codes.

  • Page 502: Crl Entry Extensions

    Appendix A. Certificate and CRL Extensions Parameter onlyContainsCACerts indirectCRL Table A.9. IssuingDistributionPoint Configuration Parameters A.5.2. CRL Entry Extensions The sections that follow lists the CRL entry extension types that are defined as part of the Internet X.509 v3 Public Key Infrastructure proposed standard. All of these extensions are noncritical. A.5.2.1.
  • Page 503 CRL Entry Extensions Parameter critical instruction Table A.10. HoldInstruction Configuration Parameters A.5.2.3. invalidityDate A.5.2.3.1. OID 2.5.29.24 A.5.2.3.2. Discussion The Invalidity Date extension provides the date on which the private key was compromised or that the certificate otherwise became invalid. A.5.2.3.3. Parameters Parameter enable critical...

  • Page 504: Netscape-Defined Certificate Extensions

    Appendix A. Certificate and CRL Extensions A.5.2.4.3. Parameters Parameter enable critical Table A.12. CRLReason Configuration Parameters A.6. Netscape-Defined Certificate Extensions Netscape defined certain certificate extensions for its products. Some of the extensions are now obsolete, and others have been superseded by the extensions defined in the X.509 proposed standard.
  • Page 505 netscape-comment A.6.2.2. Discussion The value of this extension is an IA5String. It is a comment that can be displayed to the user when the certificate is viewed.

  • Page 507: Introduction To Public-Key Cryptography

    Appendix B. 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. Section B.1, “Internet Security Issues”...

  • Page 508: Encryption And Decryption

    Appendix B. Introduction to Public-Key Cryptography • Encryption and decryption allow two communicating parties to disguise information they send to each other. The sender encrypts, or scrambles, information before sending it. The receiver decrypts, or unscrambles, the information after receiving it. While in transit, the encrypted information is unintelligible to an intruder.

  • Page 509: Public-Key Encryption

    Public-Key Encryption provides a degree of authentication, since information encrypted with one symmetric key cannot be decrypted with any other symmetric key. Thus, as long as the symmetric key is kept secret by the two parties using it to encrypt communications, each party can be sure that it is communicating with the other as long as the decrypted messages continue to make sense.

  • Page 510: Key Length And Encryption Strength

    Appendix B. Introduction to Public-Key Cryptography a recommended practice to encrypt sensitive data, however, because it means that anyone with the public key, which is by definition published, could decrypt the data. Nevertheless, private-key encryption is useful because it means the private key can be used to sign data with a digital signature, an important requirement for electronic commerce and other commercial applications of cryptography.

  • Page 511: Certificates And Authentication

    Certificates and Authentication Figure B.3. Using a Digital Signature to Validate Data Integrity Figure B.3, “Using a Digital Signature to Validate Data Integrity” shows two items transferred to the recipient of some signed data: the original data and the digital signature, which is a one-way hash of the original data encrypted with the signer's private key.

  • Page 512: Authentication Confirms An Identity

    Appendix B. Introduction to Public-Key Cryptography provides generally recognized proof of a person's identity. Public-key cryptography uses certificates to address the problem of impersonation. To get personal ID such as a driver's license, a person has to present some other form of identification which confirms that the person is who he claims to be.
  • Page 513 Authentication Confirms an Identity and the signed data across the network. The server validates the signature and confirms the validity of the certificate. B.4.2.1. Password-Based Authentication Figure B.4, “Using a Password to Authenticate a Client to a Server” shows the process of authenticating a user using a username and password.
  • Page 514 Appendix B. Introduction to Public-Key Cryptography not sent across the network, and allows the administrator to control user authentication centrally. This is called single sign-on. Figure B.5, “Using a Certificate to Authenticate a Client to a Server” shows how client authentication works using certificates and SSL.

  • Page 515: How Certificates Are Used

    How Certificates Are Used Figure B.5, “Using a Certificate to Authenticate a Client to These are the authentication steps shown in Server”: 1. The client software maintains a database of the private keys that correspond to the public keys published in any certificates issued for that client. The client asks for the password to this database the first time the client needs to access it during a given session, such as the first time the user attempts to access an SSL-enabled server that requires certificate-based client authentication.
  • Page 516 Appendix B. Introduction to Public-Key Cryptography Certificate Type Client SSL certificates Used for client authentication to servers over SSL. Typically, the identity of the client is assumed to be the same as the identity of a person, such as an employee. Section B.4.2.2, “Certificate-Based Authentication”...

  • Page 517: Single Sign-On

    Single Sign-on B.4.3.3. Signed and Encrypted Email Some email programs support digitally signed and encrypted email using a widely accepted protocol known as Secure Multipurpose Internet Mail Extension (S/MIME). Using S/MIME to sign or encrypt email messages requires the sender of the message to have an S/MIME certificate. An email message that includes a digital signature provides some assurance that it was sent by the person whose name appears in the message header, thus authenticating the sender.
  • Page 518 Appendix B. 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. B.4.5.1. Distinguished Names An X.509 v3 certificate binds a distinguished name (DN) to a public key.
  • Page 519 Contents of a Certificate • The CA's digital signature, obtained by hashing all of the data in the certificate together and encrypting it with the CA's private key. Here are the data and signature sections of a certificate shown in the readable pretty-print format: Certificate: Data: Version: v3 (0x2)

  • Page 520: How Ca Certificates Establish Trust

    Appendix B. Introduction to Public-Key Cryptography HSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBt I6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSMKvsuj/vwbf91o3j3 UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84 hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWfpRqjd1A== -----END CERTIFICATE----- B.4.6. How CA Certificates Establish Trust CAs validate identities and issue certificates. They can be either independent third parties or organizations running their own certificate-issuing server software, such as the Certificate System. Any client or server software that supports certificates maintains a collection of trusted CA certificates.
  • Page 521 How CA Certificates Establish Trust Figure B.6. Example of a Hierarchy of Certificate Authorities The root CA is at the top of the hierarchy. The root CA's certificate is a self-signed certificate; that is, the certificate is digitally signed by the same entity that the certificate identifies. The CAs that are directly subordinate to the root CA have CA certificates signed by the root CA.
  • Page 522 Appendix B. Introduction to Public-Key Cryptography Figure B.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. In a certificate chain, the following occur: •...
  • Page 523 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 524 Appendix B. Introduction to Public-Key Cryptography Figure B.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 B.10, “A Certificate Chain That cannot point in the certificate chain causes authentication to fail.

  • Page 525: Managing Certificates

    Managing Certificates Figure B.10. A Certificate Chain That cannot Be Verified B.5. Managing Certificates The standards and services that facilitate using public-key cryptography and X.509 v3 certificates in a network environment is called the public-key infrastructure (PKI). The sections that follow introduce some specific certificate management issues involved in managing the PKI.

  • Page 526: Certificates And The Ldap Directory

    Appendix B. Introduction to Public-Key Cryptography 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. Depending on an organization's policies, the process of issuing certificates can range from being completely transparent for the user to requiring significant user participation and complex procedures.

  • Page 527: Revoking Certificates

    Revoking Certificates B.5.4. Revoking Certificates Like a driver's license, a certificate specifies a period of time during which it is valid. Attempts to use a certificate for authentication before or after its validity period will fail. Managing certificate expirations is an essential part of the certificate management strategy.

  • Page 529: Enrolling A Certificate In A Cisco Router

    Enter Configuration Mode: scep# conf t Set up a CA identity: scep(config)# crypto ca identity CA scep(ca-identity)# enrollment url http://water.sfbay.redhat.com:9080/ca/cgi-bin scep(ca-identity)# crl optional scep(ca-identity)# exit Get the CA's certificate: scep(config)# crypto ca authenticate CA Certificate has the following attributes:...
  • Page 530 Please make a note of it. Password: 12345 Re-enter password: 12345 % The subject name in the certificate will be: scep.dsdev.sjc.redhat.com % Include the router serial number in the subject name? [yes/no]: yes % The serial number in the certificate will be: 57DE391C...

  • Page 531: Working With Chained (Subordinate) Cas

    Associated Identity: CA CLEANUP: Zeroize keys (necessary to re-enroll) scep(config)# crypto key zeroize rsa % Keys to be removed are named scep.dsdev.sjc.redhat.com. Do you really want to remove these keys? [yes/no]: yes CLEANUP: Removing a CA identity: scep(config)# no crypto ca identity CA % Removing an identity will destroy all certificates received from the related Certificate Authority.

  • Page 532: Debugging

    Appendix C. Enrolling a Certificate in a Cisco Router scep(config)# crypto ca trusted-root scep(ca-root)# root CEP http://paw.sfbay.redhat.com:12888/ee/scep/pkiclient.cgi scep(ca-root)# crl optional scep(ca-root)# exit scep(config)# cry ca authenticate 1 scep(config)# crypto ca trusted-root scep(ca-root)# root CEP http://paw.sfbay.redhat.com:12888/ee/scep/pkiclient.cgi scep(ca-root)# crl optional scep(ca-root)# exit...

  • Page 533: 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 534 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 535 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 536 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 537 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. See also (CA). cryptographic algorithm A set of rules or directions used to perform cryptographic operations encryption and decryption.
  • Page 538 Glossary 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. FIPS PUBS 140-1.
  • Page 539 certificate extensions. extensions field certificate fingerprint. fingerprint FIPS PUBS 140-1 Federal Information Standards Publications (FIPS PUBS) 140-1 is a US government standard for implementations of cryptographic modules, hardware or software that encrypts and decrypts data or performs other cryptographic operations, such as creating or verifying digital signatures.
  • Page 540 Glossary http:// such as C or C++ for a single platform to bind to Java™. See java.sun.com/products/jdk/1.2/docs/guide/jni/index.html. Java™ Security Services A Java™ interface for controlling security operations performed by (JSS) Netscape Security Services (NSS). Key Exchange Algorithm (KEA). cryptographic algorithm A large number used by a to encrypt or public...
  • Page 541 is really a site that takes credit-card payments but never sends any goods. Misrepresentation is one form of impersonation. See also spoofing. Netscape Security Services A set of libraries designed to support cross-platform development (NSS) of security-enabled communications applications. Applications built Secure Sockets Layer (SSL) using the NSS libraries support the protocol for authentication, tamper detection, and encryption, and the...
  • Page 542 Glossary PKCS #11 The public-key cryptography standard that governs cryptographic tokens such as smart cards. PKCS #11 module A driver for a cryptographic device that provides cryptographic services, such as encryption and decryption, through the PKCS #11 interface. A PKCS #11 module, also called a cryptographic module or cryptographic service provider, can be implemented in either hardware or software.
  • Page 543 comprised of five major subsystems that can be installed in different Certificate Certificate System instances in different physical locations: Manager, Online Certificate Status Manager, Data Recovery Manager, Token Key Service, and Token Processing System. See enrollment. registration certificate authority (CA) root CA with a self-signed certificate at the top of certificate,...
  • Page 544 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 545 public-key trust Confident reliance on a person or other entity. In a infrastructure (PKI), trust refers to the relationship between the certificate authority (CA) user of a certificate and the that issued the certificate. If a CA is trusted, then valid certificates issued by that CA can be trusted.
  • Page 547 Index See also server authentication, 491 authentication modules agent initiated user enrollment, 322, 386 deleting, 389 registering new ones, 389 accelerators, 269 authorityKeyIdentifier, 123, 464, 474 active logs default file location, 76 message categories, 79 backing up the Certificate System, 107 adding backups, 107 extensions...
  • Page 548 Index Certificate Manager, 15 certificate-based enrollment, 386 administrators forms for, 387 creating, 124, 394 what you need, 387 agents when to use, 387 creating, 124, 394 certificateIssuer, 480 as root CA, 7 certificatePolicies, 465 as subordinate CA, 7 certificates CA hierarchy, 7 and LDAP Directory, 504 CA signing certificate, 226 authentication using, 491...
  • Page 549 format, 68 deleting format for localizable values, 69 authentication modules, 389 guidelines for editing, 68 log modules, 87 name, 68 mapper modules, 363 when created, 68 privileged users, 400 Configuration tab, 61 publisher modules, 363 configuring for high availability, 451 deltaCRLIndicator, 475 deployment planning viewing content, 359...
  • Page 550 Index expired certificates removing from the directory, 440 hardware accelerators, 269 Extended Key Usage extension hardware tokens OIDs for encrypted file system, 297 See external tokens, 265, 265 extending directory-attribute support in CS, 129 high availability, 451 extensions, 123, 459 holdInstructionCode, 480 an example, 461 host name...
  • Page 551 where keys are stored, 175 managing key length, 113 certificate database, 254 key recovery, 177 mapper modules designated agents deleting, 363 See key recovery agents, 177 registering new ones, 363 how to set up, 179 mappers key recovery agents created during installation, 346, 367, 369 passwords, 177 mappers that use significance, 177...
  • Page 552 Index online certificate validation authority infrastructure, 503 defined, 12 management, 504 publisher modules deleting, 363 registering new ones, 363 password publishers using for authentication, 490 created during installation, 345, 365, 365, 366 password-based authentication, defined, 491, publishers that can publish to CA's entry in the directory, 365, 365, 366 password-quality checker, 66 files, 364...
  • Page 553 revoking certificates subsystem instance, 66 reasons, 324 storage key pair, 174 who can revoke certificates, 324 storing user's certificates, 252 roles subjectAltName, 471 agent, 392 subjectDirectoryAttributes, 471 key recovery agents, 177 subjectKeyIdentifier root CA, 7 subjectKeyIdentifier, 471 root versus subordinate CA, 25, 114 subordinate CA, 7 rotating log files archiving files, 82...
  • Page 554 Index users creating, 124, 161, 181, 220, 394 storing certificates, 252 why to revoke certificates, 324 wTLS CA signing certificate, 112 nickname, 112 X.509 certificates, 22...

Table of Contents