1. Manuals
  2. Brands
  3. Red Hat Manuals
  4. Software
  5. CERTIFICATE SYSTEM 7.2 - MIGRATION GUIDE
  6. Administration manual

Red Hat CERTIFICATE SYSTEM 7.2 - ADMINISTRATION Administration Manual

Hide thumbs Also See for CERTIFICATE SYSTEM 7.2 - 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
Table of Contents

Advertisement

Quick Links

Download this manual See also: Reference Manual, Manual
Red Hat Certificate
System 7.2
Administration Guide
Publication date: November 6, 2006, and updated on August 25, 2009

Advertisement

Table of Contents
loading
Need help?

Need help?

Do you have a question about the CERTIFICATE SYSTEM 7.2 - ADMINISTRATION and is the answer not in the manual?

Questions and answers

Related Manuals for Red Hat CERTIFICATE SYSTEM 7.2 - ADMINISTRATION

Summary of Contents for Red Hat CERTIFICATE SYSTEM 7.2 - ADMINISTRATION

  • Page 1 Red Hat Certificate System 7.2 Administration Guide Publication date: November 6, 2006, and updated on August 25, 2009...
  • Page 2 Administration Guide Red Hat Certificate System 7.2 Administration Guide Copyright © 2008 Red Hat, Inc. Copyright © 2008 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 1. Who Should Read This Guide ..................xv 2. Recommended Knowledge ..................... xv 3. What Is in This Guide ....................xv 4. Examples and Formatting ..................... xvii 5. Additional Reading ...................... xviii 6. Giving Feedback ......................xviii 7.
  • Page 4 Administration Guide 1.5. CS SDK ........................21 1.6. Support for Open Standards ..................21 1.6.1. Certificate Management Formats and Protocols ..........21 1.6.2. Security and Directory Protocols ............... 22 2. Installation and Configuration 2.1. Deployment Considerations ..................23 2.1.1. Security Domains .................... 24 2.1.2.
  • Page 5 3.3. System Passwords ..................... 62 3.3.1. Protecting the password.conf File ..............62 3.3.2. Password-Quality Checker ................64 3.4. Starting, Stopping, and Restarting Certificate System Subsystems ......... 64 3.4.1. Starting a Server Instance ................64 3.4.2. Stopping a Server Instance ................64 3.4.3.
  • Page 6 Administration Guide 4.2.3. SSL Server Key Pair and Certificate ............... 104 4.2.4. Certificate Considerations ................104 4.2.5. Cross-Pair Certificates ..................105 4.3. CA Hierarchy ......................105 4.3.1. Subordination to a Public CA ................106 4.3.2. Subordination to a Certificate System CA ............106 4.4.
  • Page 7 6.4. Overview of Archiving Keys ..................143 6.4.1. Reasons to Archive Keys ................143 6.4.2. Where the Keys Are Stored ................143 6.4.3. How Key Archival Works ................143 6.5. Overview of Key Recovery ..................145 6.5.1. Key Recovery Agents and Their Passwords ............ 145 6.5.2.
  • Page 8 Administration Guide 10.2.3. Retrieving Certificates from the End-Entities Page .......... 216 10.3. Managing User Certificates ..................218 10.3.1. Managing Certificate System User and Agent Certificates ....... 219 10.3.2. Importing Certificates into Mozilla Firefox ............220 10.4. Managing the Certificate Database ................221 10.4.1.
  • Page 9 12.7.2. Authority Key Identifier Extension Default ............259 12.7.3. Basic Constraints Extension Default .............. 260 12.7.4. CRL Distribution Points Extension Default ............. 261 12.7.5. Extended Key Usage Extension Default ............263 12.7.6. Freshest CRL Extension Default ..............264 12.7.7. Issuer Alternative Name Extension Default ............ 266 12.7.8.
  • Page 10 Administration Guide 13.4. Issuing CRLs ......................292 13.4.1. Configuring Issuing Points ................294 13.4.2. Configuring CRLs for Each Issuing Point ............295 13.4.3. Setting CRL Extensions ................299 13.5. Setting Full and Delta CRL Schedules ..............300 13.5.1. Configuring Extended Updated Intervals for CRLs in the Console ....301 13.5.2.
  • Page 11 15.4. Setting up CMC Enrollment ..................350 15.4.1. Setting up the Server for Multiple Requests in a Full CMC Request ....351 15.4.2. Testing CMCEnroll ..................352 15.5. Certificate-Based Enrollment ................... 352 15.5.1. Setting up Certificate-Based Enrollment ............353 15.6. Testing Enrollment ....................354 15.7.
  • Page 12 Administration Guide 16.7.26. certServer.ee.facetofaceenrollment .............. 383 16.7.27. certServer.ee.request.enrollment ..............383 16.7.28. certServer.ee.request.facetofaceenrollment ..........383 16.7.29. certServer.ee.request.ocsp ................384 16.7.30. certServer.ee.request.revocation ..............384 16.7.31. certServer.ee.requestStatus ................ 384 16.7.32. certServer.general.configuration ..............385 16.7.33. certServer.job.configuration ................. 385 16.7.34. certServer.kra.certificate.transport ..............386 16.7.35. certServer.kra.configuration ................. 386 16.7.36.
  • Page 13 18.3.3. Configuration Parameters of requestInQueueNotifier ........410 18.3.4. Configuration Parameters of publishCerts ............411 18.3.5. Configuration Parameters of unpublishExpiredCerts ........412 18.3.6. Frequency Settings for Automated Jobs ............413 18.4. Managing Job Plug-ins .................... 414 18.4.1. Registering or Deleting a Job Module ............414 19.
  • Page 14 Administration Guide B.1. Internet Security Issues .................... 449 B.2. Encryption and Decryption ..................450 B.2.1. Symmetric-Key Encryption ................450 B.2.2. Public-Key Encryption ..................451 B.2.3. Key Length and Encryption Strength ............... 452 B.3. Digital Signatures ..................... 452 B.4. Certificates and Authentication .................. 453 B.4.1.

  • Page 15: 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. 1.
  • Page 16 About This Guide Chapter 4, Certificate Manager • provides information and instructions for configuring the Certificate Manager and an overview of the configuration options. Chapter 5, Online Certificate Status Protocol Responder • provides information and instructions for configuring an Online Certificate Status Manager. Chapter 6, Data Recovery Manager •...

  • Page 17: Examples And Formatting

    Examples and Formatting 4. Examples and Formatting All of the examples for Red Hat Certificate System commands, file locations, and other usage are given for Red Hat Enterprise Linux 5 systems. Be certain to use the appropriate commands and files for your platform.

  • Page 18: Additional Reading

    HTTP interfaces, javadocs, samples, and tutorials related to Certificate System. A downloadable zip file of this material is available for user interaction with the tutorials. For the latest information about Red Hat Certificate System, including current release notes, complete http://www.redhat.com/docs/ product documentation, technical notes, and deployment information, see manuals/cert-system/.

  • Page 19: Document History

    Document History 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: • Select the Red Hat Certificate System product. • Set the component to Doc - administration-guide. • Set the version number to 7.2.
  • Page 20 Edited to token management sections per Bugzilla 455345. Revision 7.2.2 July 3, 2008 Ella Deon Lackey dlackey@redhat.com Added information for configuring client authentication, per Bugzilla 236253. Added information that there can be CRLs can be updated at multiple preset times, per Bugzilla 439547.

  • Page 21: 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 22: 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 23: Self-Tests

    Self-Tests sign and encrypt the logs. Audit logging is configured to specify the events that are logged. See Section 3.9.13, “Signed Audit Log” for details. 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.

  • Page 24: Authentication

    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 7, Token Processing System.

  • Page 25: Crls

    CRLs 1.1.11. CRLs The Certificate System can create certificate revocation lists (CRLs) from a configurable framework which allows user-defined issuing points so a CRL can be created for each issuing point. Delta CRLs can also be created for any issuing point that is defined. CRLs can be issued for each type of certificate or for a specific subset of a type of certificate.

  • Page 26: Support For Open Standards

    Chapter 1. Overview 1.1.17. Support for Open Standards The Certificate System supports open standards and protocols so that its subsystems can communicate across a heterogeneous computing environment. Some of the standards and areas which the Certificate System supports include the following: •...

  • Page 27: 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 28 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 29: 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 30 Chapter 1. Overview certificate content. The default certificate profiles can be modified and new custom modules created. Chapter 12, 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 31: 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 32: 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 33: 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 34: 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 35: 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 36 Chapter 1. Overview Figure 1.4. Certificate System Architecture...

  • Page 37: 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 38: 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 39: 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 40: 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 41: Cs Sdk

    CS SDK three times as long as the key for standard DES. Because the key size is so large, there are approximately 3.7 * 10 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 possible keys.

  • Page 42: Security And Directory Protocols

    Chapter 1. Overview certificates with Diffie-Hellman public-keys. A standard from the IETF PKIX working group. CMC incorporates CRMF and CMMF. • Cryptographic Message Syntax (CS). A superset of PKCS #7 syntax used for digital signatures and encryption. A proposed standard from the IETF PKIX working group. •...

  • Page 43: 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 44: 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 45: 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 46: Required Programs And Dependencies

    Chapter 2. Installation and Configuration 2.2.2. Required Programs and Dependencies The following must be installed before installing the Certificate System: • Java™ 1.5.0 Java Runtime Environment (JRE). Certificate System does not support earlier versions of the JRE. This JRE is required for running Tomcat, among other applications for the Certificate System.
  • Page 47 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 48: Packages Installed

    Chapter 2. Installation and Configuration • kernel-smp (package) • e2fsprogs (package) • firefox (package) • On 64-bit Red Hat Enterprise Linux platforms, be certain that the 64-bit (x86_64) compat-libstdc ++ libraries are installed, and not only the 32-bit (i386) libraries. To confirm this, run the following as root: rpm -qa --queryformat 'compat-libstdc++-%{VERSION}-%{RELEASE}.%{ARCH}.rpm\n' | grep x86_64 Numerous libraries should be displayed.
  • Page 49 Packages Installed RPMs for Tomcat Web Services 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 jpackage-utils xerces-j2 jakarta-commons-collections ldapjdk xml-commons jakarta-commons-daemon log4j xml-commons-apis jakarta-commons-dbcp mx4j xml-commons-resolver jakarta-commons-digester oldjdom xmlbeans Table 2.3.
  • Page 50 Chapter 2. Installation and Configuration RPMs for Java™ java-1.5.0-ibm java-1.5.0-ibm-devel Table 2.8. 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 51 Packages Installed Packages for Tomcat Web Services 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 Table 2.10. Packages for Fortitude Web Services RHATfortitude-webx RHATmod-nssx RHATmod-revocatorx Table 2.11. Packages for Apache Web Services RHATapr-utilx RHATmod-perlx...

  • Page 52: Configuration Preparation

    Chapter 2. Installation and Configuration Packages for Java™ SUNWj5rt (32-bit JRE) SUNWj5rtx (64-bit JRE) Table 2.15. 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 53: Default Settings

    Default Settings • Certificate and key recovery files. 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.16, “Default Subsystem Instance Ports and File Locations” The ports and file directories in show the default installation and configuration information.

  • Page 54: 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 55: 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 56: 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 57: 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 58: 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 59: 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 60: 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 61: 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 62: 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 63: 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 64: 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 65: 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 66: 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 67 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 68: 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 69 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 70: 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 71: Configuring A Tps

    Configuring a TPS 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 72: Creating Additional Subsystem Instances

    Chapter 2. Installation and Configuration 12. Give the information for the new subsystem administrator. 13. Click Next through the remaining panels to import the agent certificate into the browser and complete the configuration. 14. When the configuration is complete, restart the subsystem. /etc/init.d/rhpki-tps restart 2.7.

  • Page 73: Cloning A Subsystem

    Cloning a Subsystem Section 2.6, 3. Open the new instance URL, and go through the configuration wizard as described in “Configuring the Default Subsystem Instances”. Supply the security domain, CA, instance ID, internal LDAP database, and agent information. 4. When the configuration is complete, restart the subsystem. /etc/init.d/instance_ID restart 2.7.1.

  • Page 74: Silent Installation

    Chapter 2. Installation and Configuration Figure 2.17. Supplying the Key and Certificate Information NOTE When cloning a CA, the master and clone instances have the same CA signing key. 6. The subsystem information is automatically supplied from the master instance to the clone instance once the keys are successfully restored.
  • Page 75 -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 76: Updating Certificate System Packages

    Chapter 2. Installation and Configuration 2.9. Updating Certificate System Packages Section 2.2.3.1, “Red Hat Enterprise Linux RPMs” There are many packages, listed in Section 2.2.3.2, “Solaris Packages”, installed with Certificate System for related applications and dependencies, not just the subsystem packages. For all supported platforms, individual Certificate System packages may be updated through the native package utilities, rpm on Red Hat Enterprise Linux systems and pkgrm and pkgadd on Solaris 9.

  • Page 77: Updating Certificate System On Solaris

    Updating Certificate System on Solaris 3. Run up2date for the package. For example: up2date rhpki-java-tools-7.2.0-4.noarch 4. Restart the Certificate System instances. /etc/init.d/instance_ID start 2.9.2. Updating Certificate System on Solaris 1. Stop all Certificate System instances. /etc/init.d/instance_ID stop 2. Log in as root. 3.

  • Page 78: Removing Certificate System Subsystems

    Chapter 2. Installation and Configuration -pki_instance_name=pki_instance_ID The pki_instance_root is the directory path of the instance, such as /var/lib. The pki_instance_name is the instance name, such as rhpki-ca. force automatically answers yes to all uninstallation questions without prompting the user. pkiremove -pki_instance_root=/var/lib -pki_instance_name=rhpki-ca1 PKI instance Deletion Utility ...

  • Page 79: 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 80: 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 81 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 82: System Passwords

    Chapter 3. Administrative Basics If the procedure is successful, the command prints the following: pk12util: PKCS12 IMPORT SUCCESSFUL 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 83 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 84: 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 85: 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 86: Configuration Files

    Chapter 3. Administrative Basics 3.6. Configuration Files The runtime properties of a Certificate System subsystem are governed by a set of configuration parameters. These parameters are stored in a file that is read by the server during startup. An ASCII file, named CS.cfg, is created and populated with the appropriate configuration parameters when a subsystem is first installed.
  • Page 87 Guidelines for Editing the Configuration File • The format for parameters is as follows: #comment [parameter]=value • 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 88: Duplicating Configuration From One Instance To Another

    Chapter 3. Administrative Basics • All job-specific information, such as registered job modules and configured instances, appears in the job scheduler section of the configuration file. • Each registered job module is identified by its implementation name and the corresponding Java™...
  • Page 89 Other File Locations Directory Location Contents Security libraries shared by the CA, DRM, /usr/lib/dirsec OCSP, and TKS subsystems. For 32-bit Red Hat Enterprise Linux AS and ES i386 machines only. JNI Java™ archive files shared by the CA, DRM, /usr/lib/java OCSP, and TKS subsystems.

  • Page 90: Default Server Instance Locations

    Chapter 3. Administrative Basics Directory Location Contents For TPS subsystems only. Apache modules /usr/lib/httpd/modules shared by TPS subsystems. For 32-bit Red Hat Enterprise Linux AS and ES i386 machines only. 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.
  • Page 91 Default Server Instance Locations Default Location Type of Object Description File A file containing the active /var/run/rhpki-ca.pid process ID of the running CA instance. Table 3.2. CA Default Instance Location 3.6.6.2. DRM Default Instance Location Default Location Type of Object Description File The script used to start, stop, or...

  • Page 92: Using Security-Enhanced Linux

    Chapter 3. Administrative Basics 3.6.6.4. TKS Default Instance Location Default Location Type of Object Description File The script used to start, stop, or /etc/init.d/rhpki-tks restart the TKS instance. Directory Contains the configuration file /etc/rhpki-tks for the TKS instance. Directory Contains the user-specific /var/lib/rhpki-tks default and customized forms and data for the TKS instance.

  • Page 93: Using Java Servlets

    Using Java Servlets SELinux is configured through the config configuration file in the /etc/selinux/ directory. The typical SELinux configuration is as follows: ########################################### # SELINUX= can take one of these three values: enforcing - SELinux security policy is enforced. permissive - SELinux prints warnings instead of enforcing. disabled - SELinux is fully disabled.

  • Page 94: About Logs

    Chapter 3. Administrative Basics Section 3.9.5, “Log File Rotation” • Section 3.9.6, “Configuring Logs in the Console” • Section 3.9.7, “Configuring Logs in the CS.cfg File” • Section 3.9.8, “Configuring TPS Logs” • Section 3.9.9, “Monitoring Logs” • Section 3.9.10, “Signing Log Files” •...
  • Page 95 About Logs The general types of services which are recorded to the debug log are briefly discussed in Section 3.9.2, “Services That Are Logged”. These services include authorization requests, processing certificate requests, certificate status checks, and archiving and recovering keys, and access to web services.
  • Page 96 Chapter 3. Administrative Basics 7gxLzB+XwQ/VsWEoObGldg6WwJPOcBdvLiKKfC605wFdynbEgKs0fChVk9HYDhmJ^M 8hX6+PaquiHJSVNhsv5tOshZkCfMBbyxwrKd8yZ5G5I+2gE9PUznxJaMHTmlOqm4^M HwFxzy0RRQIDAQABo4HFMIHCMB8GA1UdIwQYMBaAFG8gWeOJIMt+aO8VuQTMzPBU^M 78k8MEoGCCsGAQUFBwEBBD4wPDA6BggrBgEFBQcwAYYuaHR0cDovL3Rlc3Q0LnJl^M ZGJ1ZGNvbXB1dGVyLmxvY2FsOjkwODAvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBeAw^M HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMCQGA1UdEQQdMBuBGSRyZXF1^M ZXN0LnJlcXVlc3Rvcl9lbWFpbCQ= Likewise, the OCSP shows OCSP request information: [07/Jul/2008:06:25:40][http-11080-Processor25]: OCSPServlet: OCSP Request: [07/Jul/2008:06:25:40][http-11080-Processor25]: OCSPServlet: MEUwQwIBADA+MDwwOjAJBgUrDgMCGgUABBSEWjCarLE6/BiSiENSsV9kHjqB3QQU 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 97: Services That Are Logged

    Services That Are Logged Apache (TPS) Tomcat (CA, DRM, OCSP, TKS) host-manager.timestamp localhost.timestamp localhost_access_log.timestamp manager.timestamp Table 3.7. Logs Created by Apache and Tomcat These logs are not available or configurable within the Certificate System; they are only configurable within Apache or Tomcat. See the Apache documentation for information about configuring these logs. 3.9.2.

  • Page 98: Log Levels (Message Categories)

    Chapter 3. Administrative Basics Service Description Request Queue Logs events related to the request queue activity. User and Group Logs events related to users and groups of the instance. Table 3.8. Services Logged 3.9.3. Log Levels (Message Categories) The different events logged by Certificate System services are deteremined by the log levels, which makes identifying and filtering events more simple.
  • Page 99 Log Levels (Message Categories) Log level Message category Description the server from operating normally, including failures to perform a certificate service operation (User authentication failed or Certificate revoked) and unexpected situations that can cause irrevocable errors (The server cannot send back the request it processed for a client through the same channel the request came from...

  • Page 100: Buffered Versus Unbuffered Logging

    Chapter 3. Administrative Basics Log levels can be used to filter log entries based on the severity of an event. By default, log level 3 (Failure) is set for all services. The log level is successive; specifying a value of 3 causes levels 4, 5, and 6 to be logged. Log data can be extensive, especially at lower (more verbose) logging levels.

  • Page 101: Configuring Logs In The Console

    Configuring Logs in the Console NOTE The Certificate System does not provide any tool or utility for archiving log files. The Certificate System provides a command-line utility, signtool, that signs log files before archiving Section 3.9.10, “Signing Log Files”. them as a means of tamper detection. For details, see Signing log files is an alternative to the signed audit logs feature.

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

    Chapter 3. Administrative Basics • bufferSize . The buffer size in kilobytes (KB) for the log. The default size is 512 KB. For more Section 3.9.4, “Buffered Versus Unbuffered Logging”. Once the buffer reaches information, see this size, the contents of the buffer are flushed out and copied to the log file. •...

  • Page 103: Configuring Tps Logs

    Configuring TPS Logs • fileName . Specify the full path, including the filename, to the file to write messages. The server should have read/write permission to the file. • flushInterval . Specify the interval, in seconds, to flush the buffer to the file. The default interval is 5 seconds.

  • Page 104: Monitoring Logs

    Chapter 3. Administrative Basics • Buffered logging For each log generated by a TPS instance, there are three parameters which can be configured: • enable , which sets whether the log is generated. • filename , which sets the name and location of the log. •...

  • Page 105: Signing Log Files

    Signing Log Files • Filename . Select the log file to view. Choose Current to view the currently active system log file. 5. Click Refresh. The table displays the system log entries. The entries are in reverse chronological order, with the most current entry placed at the top.

  • Page 106: Registering A Log Module

    Chapter 3. Administrative Basics 3.9.11. Registering a Log Module It is possible to create new log modules using the CS SDK. New log modules must be registered before they are available for use. 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 107 Signed Audit Log 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 108 Chapter 3. Administrative Basics 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 109 Signed Audit Log 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. INTER_BOUNDARY Records stat transfer between different subsystems.

  • Page 110: Self-Tests

    Chapter 3. Administrative Basics 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 16.2, “Creating Users” for details about setting up auditors.

  • Page 111: Self-Test Logging

    Self-Test Logging The self-tests that are configured for the subsystem will run. If any critical self-tests fail, the server will stop. 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 112: Ports

    Chapter 3. Administrative Basics • maxFileSize . Specify the file size in kilobytes (KB) for the error log. The default size is 100 KB. The maxFileSize determines how large a log file can become before it is rotated. Once 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”.
  • Page 113 About Ports 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 114: Changing A Port Number

    Chapter 3. Administrative Basics 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, DRM, OCSP, and TKS subsystem services, and the Apache web server is used for the TPS subsystem services. 3.11.1.3.

  • Page 115: The Internal Ldap Database

    The Internal LDAP Database 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" maxHttpHeaderSize="8192" ==== # Define a SSL HTTP/1.1 Connector on port 8443<Connector port="9443"...

  • Page 116: Changing The Internal Database Configuration

    Chapter 3. Administrative Basics • Storing ACLs • Storing privileged user and role information • Storing and retrieving end users' encryption private key records 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;...

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

    Enabling SSL Client Authentication with the Internal Database The hostname can be changed to something other than localhost if the visibility of the internal database can be limited to a local subnet. For example, if the Certificate System and Directory Server are installed on separate machines for load balancing, specify the hostname of the machine in which the Directory Server is installed.

  • Page 118: Restricting Access To The Internal Database

    Chapter 3. Administrative Basics Check all the rights in the Rights tab. Click This Entry in the Targets tab. 11. Click OK. 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.
  • Page 119 Backing up and Restoring Certificate System • Internal database. The Directory Server provides its own back up scripts and procedures; see the Directory Server documentation for more information on backing up the LDAP database. • Security databases. The security databases store the certificate and key material. If these are stored on an HSM, then consult the HSM vendor documentation for information on how to back up the data.
  • Page 120 Chapter 3. Administrative Basics 3. Copy the archived files to the directory. For example, restore the alias directory: cp -r /export/archives/ca/alias /var/lib/rhpki-ca/alias 4. Restart the subsystem instance. /etc/init.d/instance_ID start NOTE Stop the subsystem instance before restoring the instance or the security databases.

  • Page 121: 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 122: 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 17, Automated Notifications Chapter 18, agents on a preconfigured schedule.

  • Page 123: 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 124: 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 125: 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 126: 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 127: 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 128: 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 129: 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 130: 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 131 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 132: Ca Certificate Reissuance

    Chapter 4. Certificate Manager Configuration Section Chapter 19, 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 133 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 134: Setting Restrictions On Ca Certificates Through Certificate Extensions

    Chapter 4. Certificate Manager The signing algorithm specified in the certificate profile configuration overrides the algorithm set here. 4. Click Save. 4.8. Setting Restrictions on CA Certificates through Certificate Extensions When a subordinate CA is created, the root CA can generate a CA signing certificate with restrictions on the types of certificates that the subordinate CA can sign with that signing certificate.
  • Page 135 Setting Restrictions on CA Certificates through Certificate Extensions to the trusted root. For certificate chaining to work properly the certificates should have the following properties: • CA certificates must have either the Basic Constraints extension, a Key Usage or Extended Key Usage extension set to issue SSL or email certificates, or both.

  • Page 136: Creating Certificate Manager Agents And Administrators

    Chapter 4. Certificate Manager Section 12.3, “Setting up Certificate For more information on modifying certificate profiles, see Profiles” and the Certificate System Agent's Guide. 4.9. Creating Certificate Manager Agents and Administrators When the subsystem is configured, there is a default user created with both administrator and agent privileges.

  • Page 137: 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 138 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 139: 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 140: 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 141: 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 142 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 143 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 145: Online Certificate Status Protocol Responder

    Chapter 5. 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 146: Ocsp Responses

    Chapter 5. 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 5.3, For more information about the certificates associated with the OCSP Manager, see “Online Certificate Status Manager Certificates”.

  • Page 147: 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 148: Recognizing Online Certificate Status Manager Certificates

    Chapter 5. 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 10.5, “Configuring the Server Certificate Use Preferences”.

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

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

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

    Chapter 5. Online Certificate Status Protocol Responder Figure 5.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 151: 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 152: Identifying The Ca To The Ocsp Responder

    Chapter 5. 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 5.6, “Configuring the Certificate Manager's Internal OCSP Service” for more information.

  • Page 153: 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 154: Testing The Ocsp Service Setup

    Chapter 5. 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 155: 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 156 Chapter 5. 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 157: 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 5.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.2 than the location in Certificate System 7.1, which was simply / ocsp/.
  • Page 158 Chapter 5. 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 159 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 161: Data Recovery Manager

    Chapter 6. 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 162: Transport Key Pair And Certificate

    Chapter 6. Data Recovery Manager Section 6.2.1, “Transport Key Pair and Certificate” • Section 6.2.2, “Storage Key Pair” • Section 6.2.3, “SSL Server Certificate” • 6.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 163: Overview Of Archiving Keys

    Overview of Archiving Keys Initiating the key recovery process also requires its own HTML form. By default, the DRM agent services page provides the forms needed for initiating the process and retrieving keys. 6.4. Overview of Archiving Keys The DRM automatically archives private encryption keys if archiving is configured. For instructions on Section 6.6, “Configuring Key Archival and setting up a key archival and recovery infrastructure, see Recovery...
  • Page 164 Chapter 6. Data Recovery Manager • A transport key pair and corresponding certificate. • A storage key pair. Figure 6.1, “How the Key Archival Process Works” illustrates how the key archival process occurs when an end entity requests a certificate. Figure 6.1.

  • Page 165: Overview Of Key Recovery

    Overview of Key Recovery 4. Once the private encryption key has been successfully stored, the DRM uses the private key of its transport key pair to sign a token confirming that the key has been successfully stored; the DRM then sends the token to the Certificate Manager. 5.

  • Page 166: Key Recovery Agent Scheme

    Chapter 6. Data Recovery Manager In key recovery authorization, one of the key recovery agents informs all required recovery agents about an impending key recovery. All recovery agents access the DRM key recovery page. One of the agents initiates the key recovery process. The DRM returns a notification to the agent includes a recovery authorization reference number identifying the particular key recovery request that the agent is required to authorize.

  • Page 167: Setting Up Key Archival

    Setting up Key Archival 6.6.1. Setting up Key Archival To set up key archival, do the following: 1. Connect the Certificate Manager and the DRM. 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.

  • Page 168: Testing The Key Archival And Recovery Setup

    Chapter 6. Data Recovery Manager This is the default key agent scheme, which requires a single agent from the Data Recovery Manager Agents group to be in charge of authorizing key recovery. 2. Customize the appearance key recovery form. 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.

  • Page 169: Creating Data Recovery Manager Agents And Administrators

    Creating Data Recovery Manager Agents and Administrators d. The next screen returns a key recovery authorization number and a link to verify the status of this key recovery initiation request. This page keeps refreshing until all agents have completed authorizing the recovery request. It is important not to close this browser window. Depending on the agent scheme, a specified number of agents must authorize this key recovery.
  • Page 170 Chapter 6. Data Recovery Manager Figure 6.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 171: Token Processing System

    Chapter 7. 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 172: Configuring Failover Support

    Chapter 7. 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 7.1.2, enrollments for regular tokens are sent to a different CA.
  • Page 173 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 174: Formatting Smart Cards

    Chapter 7. Token Processing System Table 7.7, “Mapping and Filters”. The mapping and filter parameters are listed in 7.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 175: 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 176: Enabling Ssl In Tps

    Chapter 7. Token Processing System Section 7.5.1, “Enabling SSL in TPS” • Section 7.5.2, “Server-Side Key Generation and Archival of Encryption Keys” • Section 7.5.3, “Smart Card Certificate Enrollment Profiles” • Section 7.5.4, “Automating Encryption Key Recovery” • Section 7.5.5, “Configuring Symmetric Key Changeover” •...

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

    Server-Side Key Generation and Archival of Encryption Keys </VirtualHost> 3. Restart the TPS instance. /etc/init.d/rhpki-tps restart 4. Open the Enterprise Security Client, and reset the TPS information so that it connects to the TPS over SSL. BROWSER_URL=https://server.example.com:7890/cgi-bin/esc.cgi?action=settingspage TPS_HOST_PORT=7890 TPS_HOST_USES_SSL=yes 7.5.2. Server-Side Key Generation and Archival of Encryption Keys NOTE There is the option when the TPS instance is configured to set up a DRM to perform server-side key generation and key archival and recovery.
  • Page 178 Chapter 7. Token Processing System b. Import the transport certificate into the TKS security databases in the /var/ lib/instance_ID/alias/ directory. In the TKS Console, click Subsystem Keys and Certificates in the left navigation panel. In the Local Certificates tab, click Add, and paste in the certificate information.

  • Page 179: Smart Card Certificate Enrollment Profiles

    Smart Card Certificate Enrollment Profiles is encryption. Set the following parameters to enable server-side key generation and to archive keys: op.enroll.userKey.keyGen.encryption.serverKeygen.enable=true op.enroll.userKey.keyGen.encryption.serverKeygen.drm.conn=drm1 op.enroll.userKey.keyGen.encryption.serverKeygen.archive=true op.enroll.userKey.keyGen.encryption.serverKeygen.encryptPrivKey=true d. Restart the TPS subsystem. /etc/init.d/instance_ID start 7.5.3. Smart Card Certificate Enrollment Profiles The CA subsystem has four default smart card enrollment profiles which the TPS is configured, by default, to use: •...
  • Page 180 Chapter 7. Token Processing System When a user loses a token, the user must first get a replacement token. If a new enrollment is attempted with this new token, the TPS blocks the enrollment since the user already has an active token.

  • Page 181: Configuring Symmetric Key Changeover

    Configuring Symmetric Key Changeover op.enroll.userKey.keyGen.encryption.revokeCert=true 7.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 182 Chapter 7. Token Processing System 2. On the TKS instance, generate new keys to use for token-client communications. a. Open the TKS instance alias/ directory. 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 8.2, “Using Master Generating a new master key on the TKS is described in more detail in Keys”.

  • Page 183: Setting Token Types For Specified Smart Cards

    Setting Token Types for Specified Smart Cards 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 184 Chapter 7. Token Processing System ########################################################################## # Create two mappings ########################################################################## op.format.mapping.0.filter.tokenCUID.start=1000000000000000 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...

  • Page 185: Configuring Ldap Authentication

    Configuring LDAP Authentication auth.instance.1.hostport=ldap-qa.example.com:2222 auth.instance.1.SSLOn=false auth.instance.1.retries=1 auth.instance.1.retryConnect=3 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. •...

  • Page 186: Token Database

    Chapter 7. Token Processing System 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 7.5, “LDAP Authentication”. Server hostname and port, are listed in 7.7.
  • Page 187 TPS Configuration Parameters 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 • 0 - No logging. •...
  • Page 188 Chapter 7. Token Processing System 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 189 TPS Configuration Parameters 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 190 Chapter 7. Token Processing System 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 191 TPS Configuration Parameters 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 192 Chapter 7. Token Processing System 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 193 TPS Configuration Parameters 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 194 Chapter 7. Token Processing System 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 195 TPS Configuration Parameters 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 196 Chapter 7. Token Processing System 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 •...
  • Page 197 TPS Configuration Parameters 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 198 Chapter 7. Token Processing System 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.
  • Page 199 TPS Configuration Parameters 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 7.8. Enrollment Operation Preferences Parameter Description op.pinReset.tokenType.update.applet.emptyToken.enable...
  • Page 200 Chapter 7. Token Processing System Parameter Description 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. The valid values are true| false. When enabled, TPS checks to see the key version sent by the token matches symmetricKeys.requiredVersion.
  • Page 201 TPS Configuration Parameters Parameter Description tokendb.baseDN The LDAP suffix where the token entries should be added and modified by the TPS. The default value is ou=Tokens,baseDN. tokendb.activityBaseDN The LDAP suffix where the token-based activities should be recorded by the TPS. The default value is ou=Activities,baseDN.

  • Page 202: Tks Configuration File Parameters

    Chapter 7. Token Processing System Parameter Description • 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 7.11. Token Database Preferences 7.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 7.12, “TKS Configuration server-side key generation and for key updates.

  • Page 203: Token Key Service

    Chapter 8. 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 204: Configuring The Tks To Associate The Master Key With Its Version

    Chapter 8. Token Key Service tksTool -W -d . -n new_master -t transport -o file Enter Password or Pin for "NSS Certificate DB": Retrieving the transport key (for wrapping) from the specified token . . . Generating and storing the master key on the specified token . . . Naming the master key "wrapped_master"...

  • Page 205: Using Hsm For Generating Keys

    Using HSM for Generating Keys NOTE Stop the TKS instance before editing the configuration file. To reference the security database, set the tokenname to internal. All numeric key identifiers in mapping configurations must be suffixed with #01. #02 represents the master key version. NOTE Smart cards from the Axalto Web Store come with a default developer key set where all keys are set to 404142434445464748494a4b4c4d4e4f.

  • Page 206: Creating Token Key Service Agents And Administrators

    Chapter 8. Token Key Service 4. Restart the TKS instance. /etc/init.d/rhpki-tks restart 5. Update the CS.cfg for every Token Processing System (TPS) which uses the edited TKS instance. Set the requiredVersion parameter and enable key upgrade in all profiles with the parameters update.symmetricKeys.enable and update.symmetricKeys.requiredVersion in the parameter name.
  • Page 207 Creating Token Key Service Agents and Administrators Figure 8.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 209: Enterprise Security Client

    Chapter 9. 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 211: Managing Certificates

    Chapter 10. 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 212 Chapter 10. 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 213: Determining Which Certificates To Install

    Determining Which Certificates to Install 10.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 214 Chapter 10. 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 215: Certificate Data Formats

    Certificate Data Formats 10.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. 10.1.3.1. Binary The following binary formats are recognized: • DER-encoded certificate. This is a single binary DER-encoded certificate. •...

  • Page 216: Requesting And Receiving Certificates

    Chapter 10. Managing Certificates • Request and install new certificates for the subsystem certificates installed in a Certificate System instance; issuing or requesting a new certificate means getting a certificate based on a new public and private key pair. • Install CA certificates in the certificate or trust database of a Certificate System instance. •...

  • Page 217: Requesting Certificates

    Requesting Certificates The authentication process is determined by the certificate profiles that are associated with the enrollment forms used. This can be done automatically by the server applying preset criteria or by manual approval from an agent. Once the request is approved, it is available through the CA's end- entities page for the entity to retrieve.
  • Page 218 Chapter 10. Managing Certificates • Directory-Authenticated User Dual-Use Certificate Enrollment (if directory authentication has been configured) NOTE It is important that the agent or user generate and submit the client request from the computer that will be used later to access the subsystem because part of the request process generates a private key on the local machine.
  • Page 219 Requesting Certificates 5. The key pairs for the user certificate are generated, and the certificate request is sent to the agent queue. Alternatively, if automatic enrollment is configured, the certificate is approved (or rejected) by the server, and the new certificate is displayed in the web browser window. 10.2.1.2.
  • Page 220 Chapter 10. Managing Certificates Figure 10.2. Certificate Request Wizard 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: •...
  • Page 221 Requesting Certificates • Other certificate NOTE If selecting to create an "other" certificate, the Certificate Type field becomes active. Fill in the type of certificate to create, either caCrlSigning for the CRL signing certificate or client for an SSL client certificate.
  • Page 222 Chapter 10. Managing Certificates Figure 10.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 223 Requesting Certificates 8. Set the key-pair information. Figure 10.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 224 Chapter 10. Managing Certificates Figure 10.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 225 Requesting Certificates Figure 10.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 226 Chapter 10. Managing Certificates Figure 10.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 227 Requesting Certificates Figure 10.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 228 Chapter 10. Managing 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.
  • Page 229 Requesting Certificates Figure 10.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 230 Chapter 10. Managing 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 Table 10.2, “Files Created for type of certificate requested.
  • Page 231 Requesting 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 232: Submitting Certificate Requests

    Chapter 10. Managing Certificates 10.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 233 Submitting Certificate Requests Figure 10.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 234 Chapter 10. Managing Certificates 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 10.4.1.1, “Installing Certificates through the Console”.
  • Page 235 Submitting Certificate Requests Figure 10.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 236: Retrieving Certificates From The End-Entities Page

    Chapter 10. Managing Certificates When the CA issues the certificate, save the certificate to a file, and install it following the instructions Section 10.4.1.1, “Installing Certificates through the Console”. 10.2.2.3. Submitting a Certificate Request to a Third-Party CA An external CA is any public or third-party CA. Before sending a certificate request to a public CA, make sure that the CA can issue the type of certificate that is being requested.
  • Page 237 Retrieving Certificates from the End-Entities Page Figure 10.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 238: Managing User Certificates

    Chapter 10. Managing Certificates Figure 10.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 239: Managing Certificate System User And Agent Certificates

    Managing Certificate System User and Agent Certificates Section 10.4.1, For information on importing subsystem certificates into the security databases, see “Installing Certificates in the Certificate System Database”. 10.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 240: Importing Certificates Into Mozilla Firefox

    Chapter 10. Managing Certificates 10.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 241: Managing The Certificate Database

    Managing the Certificate Database 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 242 Chapter 10. Managing Certificates 10.4.1.1. Installing Certificates through the Console WARNING Installing certificates through the Certificate Setup Wizard is not supported in Certificate System 7.2. Use the certutil tool to manage certificates instead. The Certificate Setup Wizard can install or import the following certificates into either an internal or external token used by the Certificate System instance: •...
  • Page 243 Installing Certificates in the Certificate System Database b. Select the type of certificate to install. The options for the drop-down menu are the same options available for creating a certificate, depending on the type of subsystem, with the additional option to install a cross-pair certificate. c.
  • Page 244 Chapter 10. Managing Certificates certutil -A -n cert-name -t trustargs -d . -a -i certificate_file 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"...

  • Page 245: Viewing Database Content

    Viewing Database Content page which has been customized to enroll for cross-pair certificates by providing the hidden value certType==fbca. Section 14.6.1, “Publishing Cross-Pair For information on publishing cross-pair certificates, Certificates”. 10.4.2. Viewing Database Content The certificates stored in the subsystem certificates database, cert8.db, can be viewed through the subsystem administrative console.
  • Page 246 Chapter 10. Managing Certificates Figure 10.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 247: Deleting Certificates From The Database

    Deleting Certificates from the Database 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 248: Changing The Trust Settings Of A Ca Certificate

    Chapter 10. Managing Certificates 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 249: Configuring The Server Certificate Use Preferences

    Configuring the Server Certificate Use Preferences 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.
  • Page 250 Chapter 10. Managing Certificates • 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 251: Managing Tokens

    Chapter 11. 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 252: Using Hardware Security Modules With Subsystems

    Chapter 11. 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 253: Chrysalis Lunasa Hsm

    Chrysalis LunaSA HSM hardware-lunasa2-ca=caPassword 11.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; } 11.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 254: Managing Tokens Used By The Subsystems

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

  • Page 255: 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. 11.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 257: Certificate Profiles

    Chapter 12. 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 258: How Certificate Profiles Work

    Chapter 12. Certificate Profiles Policy sets are sets of constraints and default extensions attached to every certificate processed through the profile. The extensions define certificate content such as validity periods and subject name requirements. A profile handles one certificate request, but a single request can contain information for multiple certificates.

  • Page 259: Setting Up Certificate Profiles

    Setting up Certificate Profiles 12.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 260 Chapter 12. Certificate Profiles Figure 12.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 12.2.
  • Page 261 Modifying Certificate Profiles through the CA Console Figure 12.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 262 Chapter 12. 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 263 Modifying Certificate Profiles through the CA Console Figure 12.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 264 Chapter 12. Certificate Profiles Figure 12.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 12.7, “Defaults Reference”...
  • Page 265 Modifying Certificate Profiles through the CA Console Figure 12.7. Certificate Profile Inputs b. Choose the input from the list, and click OK. See Section 12.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 266 Chapter 12. Certificate Profiles Figure 12.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 267 Modifying Certificate Profiles through the CA Console Figure 12.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 268: Modifying Certificate Profiles Through The Command Line

    Chapter 12. 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 269 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 270 Chapter 12. 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 271: 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 272 Chapter 12. 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 273 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 12.2, “Tokens Used to Populate Certificates”. in the policy set.

  • Page 274: Customizing The Enrollment Form

    Chapter 12. Certificate Profiles Policy Set Token Description $request.profileSetId$ This inserts the name of the policy set which processed the certificate request. Table 12.2. Tokens Used to Populate Certificates 12.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 275: Input Reference

    Input Reference • caTransportCert. For a transport signing certificate, used by the DRM. • caUserCert. For enrolling end user certificates. 12.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 276: Image Input

    Chapter 12. Certificate Profiles • Text Being Signed. This gives the filename. 12.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. 12.5.6.

  • Page 277: 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 278: Defaults Reference

    Chapter 12. Certificate Profiles 12.7. Defaults Reference Defaults are used to define the contents of a certificate. This section lists and defines the predefined defaults. 12.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 279: Authority Key Identifier Extension Default

    Authority Key Identifier Extension Default Parameter Location_n Enable_n Table 12.3. Authority Info Access Extension Default Configuration Parameters 12.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 280: Basic Constraints Extension Default

    Chapter 12. Certificate Profiles 12.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 281: Crl Distribution Points Extension Default

    CRL Distribution Points Extension Default Parameter Table 12.4. Basic Constraints Extension Default Configuration Parameters 12.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 282 Chapter 12. Certificate Profiles Parameter IssuerName_n IssuerType_n...

  • Page 283: Extended Key Usage Extension Default

    Extended Key Usage Extension Default Parameter Table 12.5. CRL Distribution Points Extension Configuration Parameters 12.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 284: Freshest Crl Extension Default

    Chapter 12. 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 285 Freshest CRL Extension Default Parameter PointName_n PointIssuerName_n...

  • Page 286: Issuer Alternative Name Extension Default

    Chapter 12. Certificate Profiles Parameter PointType_n Table 12.8. Freshest CRL Extension Default Configuration Parameters 12.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 12.8.3, “Extension Constraint”.

  • Page 287: Key Usage Extension Default

    Key Usage Extension Default Parameter issuerAltExtPattern Table 12.9. Issuer Alternative Name Extension Default Configuration Parameters 12.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 288: Name Constraints Extension Default

    Chapter 12. Certificate Profiles Parameter keyEncipherment dataEncipherment keyAgreement keyCertsign cRLSign encipherOnly decipherOnly Table 12.10. Key Usage Extension Default Configuration Parameters 12.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 289 Name Constraints Extension Default Parameter PermittedSubtreesmax_n PermittedSubtreeNameChoice_n PermittedSubtreeNameValue_n...
  • Page 290 Chapter 12. Certificate Profiles Parameter PermittedSubtreeEnable_n ExcludedSubtreesn.min ExcludedSubtreeMax_n ExcludedSubtreeNameChoice_n...
  • Page 291 Name Constraints Extension Default Parameter ExcludedSubtreeNameValue_n ExcludedSubtreeEnable_n Table 12.11. Name Constraints Extension Default Configuration Parameters...

  • Page 292: Netscape Certificate Type Extension Default

    Chapter 12. Certificate Profiles 12.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 293: Policy Constraints Extension Default

    Policy Constraints Extension Default The following constraints can be defined with this default: Section 12.8.3, “Extension Constraint”. • Extension Constraint; see Section 12.8.6, “No Constraint”. • No Constraints; see Parameter critical Table 12.13. OCSP No Check Extension Default Configuration Parameters 12.7.14.

  • Page 294: Policy Mappers Extension Default

    Chapter 12. Certificate Profiles Parameter Table 12.14. Policy Constraints Extension Default Configuration Parameters 12.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 295: Subject Alternative Name Extension Default

    Subject Alternative Name Extension Default The following constraints can be defined with this default: Section 12.8.8, “Signing Algorithm Constraint”. • Signing Algorithm Constraint; see Section 12.8.6, “No Constraint”. • No Constraints; see Parameter signingAlgsAllowed signingAlg Table 12.16. Signing Algorithm Default Configuration Parameters 12.7.17.
  • Page 296 Chapter 12. 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 12.1. Default Subject Alternative Name Extension Configuration The Subject Alternative Name extension default checks the certificate request for the profile 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 297: Subject Directory Attributes Extension Default

    Subject Directory Attributes Extension Default Parameter Table 12.17. Subject Alternative Name Extension Default Configuration Parameters 12.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 12.8.3, “Extension Constraint”.

  • Page 298: Subject Key Identifier Extension Default

    Chapter 12. Certificate Profiles Parameter Enable Table 12.18. Subject Directory Attributes Extension Default Configuration Parameters 12.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 299: Token Supplied Subject Name Default

    Token Supplied Subject Name Default 12.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 300: User Supplied Key Default

    Chapter 12. 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 301: User Signing Algorithm Default

    User Signing Algorithm Default 12.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 302: Constraints Reference

    Chapter 12. Certificate Profiles Parameter range Table 12.20. Validity Default Configuration Parameters 12.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. 12.8.1.

  • Page 303: Extended Key Usage Extension Constraint

    Extended Key Usage Extension Constraint Parameter Table 12.21. Basic Constraints Extension Constraint Configuration Parameters 12.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 304 Chapter 12. Certificate Profiles Parameter keyEncipherment dataEncipherment keyAgreement keyCertsign cRLSign encipherOnly decipherOnly Table 12.24. Key Usage Extension Constraint Configuration Parameters...

  • Page 305: No Constraint

    No Constraint 12.8.6. No Constraint This constraint implements no constraint. When chosen along with a default, there are not constraints placed on that default. 12.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 306: Unique Subject Name Constraint

    Chapter 12. 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 307: Revocation And Crls

    Chapter 13. 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. 13.1.

  • Page 308: Cmc Revocation

    Chapter 13. 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. 13.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 309: Testing Cmc Revoke

    Testing CMC Revoke NOTE Surround values that include spaces in quotation marks. 13.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 310: Reasons For Revoking A Certificate

    Chapter 13. 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 311: Publishing Crls

    Publishing CRLs 13.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 14, Publishing. For information about setting up CRL publishing, see 13.3.3.

  • Page 312: Issuing Crls

    Chapter 13. 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 313 Issuing CRLs Figure 13.1. Default CRL Issuing Point Section 13.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 314: Configuring Issuing Points

    Chapter 13. Revocation and CRLs 13.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 315: 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. 13.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 316 Chapter 13. 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 317 Configuring CRLs for Each Issuing Point Figure 13.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 13.3.5, “How CRLs Work”.
  • Page 318 Chapter 13. Revocation and CRLs Figure 13.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 13.4.3, “Setting point.

  • Page 319: Setting Crl Extensions

    Setting CRL Extensions 7. Click Save. Section 13.4.3, “Setting 8. Extensions are allowed for this issuing point and can be configured. See CRL Extensions” for details. 13.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 320: Setting Full And Delta Crl Schedules

    Chapter 13. Revocation and CRLs Figure 13.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 321: 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 322: Configuring Extended Updated Intervals For Crls In Cs.cfg

    Chapter 13. Revocation and CRLs 5. Save the changes. 13.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 323: Publishing

    Chapter 14. 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 324: About Rules

    Chapter 14. Publishing 14.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 325: Ocsp Publishing

    OCSP Publishing 14.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 326: Setting Up Publishing

    Chapter 14. 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 327: Publishers

    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 328 Chapter 14. Publishing Figure 14.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 14.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 329: Configuring Publishers For Publishing To Ocsp

    Configuring Publishers for Publishing to OCSP Figure 14.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 330 Chapter 14. 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 14.4. Publishers Management Tab 3.

  • Page 331: 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 14.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 332: Mappers

    Chapter 14. 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 14.1. LDAP Publishers The publishers are enabled and configured using the X.500 standard attributes for storing certificates and CRLs.
  • Page 333 Configuring Mappers 2. In the Configuration tab, select Certificate Manager from the navigation tree on the left. Select Publishing, and then Mappers. The Mappers Management tab, which lists configured mappers, opens on the right. Figure 14.7. Mappers Management Tab 3. In the mapper list, select a mapper to modify. 4.
  • Page 334 Chapter 14. Publishing Figure 14.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 14.12.2, “Mapper Plug-in Modules ”.
  • Page 335 Configuring Mappers Figure 14.9. Selecting a New Mapper Type 6. Edit the mapper instance, and click OK.

  • Page 336: Rules

    Chapter 14. Publishing Figure 14.10. Creating a New Mapper Section 14.12.2, “Mapper Plug-in Modules ” for detailed information about each mapper. 14.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 337: Modifying Publishing Rules For Certificates And Crls

    Modifying Publishing Rules for Certificates and CRLs 14.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 338 Chapter 14. Publishing Figure 14.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 339 Modifying Publishing Rules for Certificates and CRLs Figure 14.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 340 Chapter 14. Publishing Figure 14.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 341: Enabling Publishing

    Enabling Publishing 14.5.1.1. Predicates Used in Publishing Rules Table 14.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 && isDeltaCRl==[true|false] To publish only the master CRL, set isDeltaCRl==false.
  • Page 342 Chapter 14. Publishing Figure 14.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 343: Publishing Cross-Pair Certificates

    Publishing Cross-Pair Certificates If the Directory Server is configured for SSL communication with client authentication, select SSL client authentication and the Use SSL communication option, and identify the certificate that the Certificate Manager must use for SSL client authentication to the directory. The server attempts to connect to the Directory Server.
  • Page 344 Chapter 14. Publishing Open the directory to which the binary blob of the certificate is supposed to be published. The certificate file should be named cert-serial_number.der. 5. Convert the DER-encoded certificate to its base 64-encoded format using the Binary to ASCII tool. For more information on this tool, refer to the Certificate System Command-Line Tools Guide.

  • Page 345: Viewing Certificates And Crls Published To File

    Viewing Certificates and CRLs Published to File PrettyPrintCrl input_file [output_file] 13. Compare the output. 14.8. Viewing Certificates and CRLs Published to File Certificates and CRLs can be published to two types of files: base-64 encoded or DER-encoded. The content of these files can be viewed by converting the files to pretty-print format using the dumpasn1 tool or the PrettyPrintCert or PrettyPrintCRL tool.

  • Page 346: Entry For The Ca

    Chapter 14. Publishing 14.9.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. This attribute is multi-valued; each value is a DER-encoded binary X.509 certificate. The LDAP object class named inetOrgPerson allows this attribute.

  • Page 347: Bind Dn

    Bind DN 14.9.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 348: Manually Updating Certificates In The Directory

    Chapter 14. 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 349: Manually Updating The Crl In The Directory

    Manually Updating the CRL in the Directory 14.10.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 350: Module Reference

    Chapter 14. Publishing 14.12. Module Reference The following sections list and describe the publisher, mapper, and rule modules that are contained by default with the Certificate Manager. Custom modules can be created using the CS SDK. Section 14.12.1, “Publisher Plug-in Modules” •...
  • Page 351 Publisher Plug-in Modules 14.12.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 352 Chapter 14. Publishing 14.12.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 353: 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 14.10. OCSPPublisher Parameters 14.12.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 354 Chapter 14. Publishing Section 14.12.2.1.1, “LdapCaCertMap”). • LdapCaCertMap for CA certificates (see 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 355 Mapper Plug-in Modules 14.12.2.1.1. LdapCaCertMap The LdapCaCertMap mapper is an instance of the LdapCaSimpleMap module. The Certificate Manager automatically creates this mapper during installation. This mapper creates an entry for the CA in the directory and maps the CA certificate to the CA's entry in the directory.
  • Page 356 Chapter 14. Publishing 14.12.2.3.1. Configuration Parameters of LdapSimpleMap The simple mapper requires one parameter, dnPattern. The value of dnPattern can be a list of AVAs separated by commas. An AVA can be a variable, such as uid=$subj.UID, or a constant, such as o=Example Corporation.
  • Page 357 Mapper Plug-in Modules • End-entity entries in the directory for publishing end-entity certificates. The mapper takes DN components to build the search DN. The mapper also takes an optional root search DN. The server uses the DN components to form an LDAP entry to begin a subtree search and the filter components to form a search filter for the subtree.
  • Page 358 Chapter 14. Publishing cn=Jane Doe, o=Example Corporation, c=US 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.

  • Page 359: Rule Instances

    Rule Instances Parameter Description For example, if dnComps uses the o and c attributes of the DN, the server starts the search from the o=org, c=country entry in the directory, 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...
  • Page 360 Chapter 14. Publishing Parameter Value Description Specifies the type of certificate type cacert that will be published. Specifies a predicate for the predicate publisher. Enables the rule. enable Specifies the mapper mapper LdapCaCertMap used with the rule. See Section 14.12.2.1.1, “LdapCaCertMap”...
  • Page 361 Rule Instances Parameter Value Description Specifies a predicate for the predicate publisher. Enables the rule. enable Specifies the mapper used with mapper LdapUserCertMap Section 14.12.2.3, the rule. See “LdapSimpleMap” for details on the mapper. Specifies the publisher publisher LdapUserCertPublisher used with the rule. Section 14.12.1.3, “LdapUserCertPublisher”...

  • Page 363: Authentication For Enrolling Certificates

    Chapter 15. 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. 15.1.

  • Page 364: Agent-Approved Enrollment

    Chapter 15. Authentication for Enrolling Certificates If the authentication method is automated, the end entity submits the request along with required information to authenticate the user, such as an LDAP username and password. When the user is 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.

  • Page 365: Setting Up Directory-Based Authentication

    Setting up Directory-Based Authentication • CMCAuth. Clients are created and sent agent-signed requests. Those requests are then processed, Section 15.4, “Setting up CMC Enrollment”. and the certificate issued. See • AgentCertAuth. Agents who are successfully issued server certificates through an automated process are automatically authenticated when they present the agent certificate.

  • Page 366: Setting Up Pin-Based Enrollment

    Chapter 15. Authentication for Enrolling Certificates • ldapStringAttributes. Specifies the list of LDAP string attributes that should be considered authentic for the end entity. If specified, the values corresponding to these attributes are copied from the authentication directory into the authentication token and used by the certificate profile to generate the subject name.
  • Page 367 Setting up PIN-based Enrollment directory using their user ID and password and against the PIN in their LDAP entry. When the user successfully authenticates, the request is automatically processed, and a new certificate is issued. The Certificate System provides a tool, setpin, that adds the necessary schema for PINs to the Directory Server and generates the PINs for each user.
  • Page 368 Chapter 15. Authentication for Enrolling Certificates setpin host=yourhost port=9446 length=11 input=infile output=outfile write "binddn=cn=pinmanager,o=example.com" bindpw="password" basedn=o=example.com "filter=(uid=u*)" 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.
  • Page 369 Setting up PIN-based Enrollment 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. Entering values for this parameter is optional. • ldap.ldapconn.host. Specifies the fully-qualified DNS host name of the authentication directory.

  • Page 370: Setting Up Cmc Enrollment

    Chapter 15. Authentication for Enrolling Certificates • ldap.minConns. Specifies the minimum number of connections permitted to the authentication directory. The permissible values are 1 to 3. • ldap.maxConns. Specifies the maximum number of connections permitted to the authentication directory. The permissible values are 3 to 10. Click OK.

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

    Setting up the Server for Multiple Requests in a Full CMC Request Click OK. The authentication instance is now set up and enabled. 3. Use the CMCEnroll utility to sign certificate requests with the agent certificate. This utility has the following syntax: CMCEnroll -d /certificate/directory -h password -n cert_nickname -r certrequest.file -p certDB_passwd [-c] Parameter...

  • Page 372: Testing Cmcenroll

    Chapter 15. Authentication for Enrolling Certificates /etc/init.d/rhpki-ca restart 15.4.2. Testing CMCEnroll 1. Enable CMCEnroll. 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 373: Setting Up Certificate-Based Enrollment

    Setting up Certificate-Based Enrollment Certificate-based enrollment is useful in two common deployment scenarios: • A client is deployed that can generate dual key pairs. Dual certificates, one for signing and one for encrypting data, need to issued to the users. Additionally, users should be able to put their key materials only on hardware tokens.

  • Page 374: Testing Enrollment

    Chapter 15. Authentication for Enrolling Certificates CertBasedEncryptionEnroll.html or CertBasedSingleEnroll.html, associate the Certificate link to the form or add more links to the index.html file. NOTE All three enrollment forms work by default with the directory-based authentication Section 15.3.1, “Setting up Directory-Based module, UidPwdDirAuth, explained in Authentication”.

  • Page 375: Managing Authentication Plug-Ins

    Managing Authentication Plug-ins Do not interrupt the key-generation process. Upon completion of the key generation, the request is submitted to the server to issue the certificate. The server subjects the request to the certificate profile and issues the certificate only if the request meets all the requirements. When the certificate is issued, install the certificate in the browser.

  • Page 377: User And Group Authorization

    Chapter 16. User and Group Authorization This chapter explains how to set up authorization for access to the administrative, agent services, and end-entities pages. 16.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 378 Chapter 16. 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 379 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 380: Creating Users

    Chapter 16. 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 381: Setting Up A Trusted Manager

    Setting up a Trusted Manager Figure 16.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 382 Chapter 16. 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 383 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 384: Modifying Certificate System User Entries

    Chapter 16. User and Group Authorization Figure 16.4. Setting Connector Information 16.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. 16.4.1. Changing a Certificate System User's Login Information Change a Certificate System user's login information by doing the following: 1.

  • Page 385: 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. 16.4.2. Changing a Certificate System User's Certificate To change a user's certificate, do the following: 1.

  • Page 386: Creating A New Group

    Chapter 16. 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 387: Authorization For Certificate System Users

    Authorization for Certificate System Users 16.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. 16.6.1.
  • Page 388 Chapter 16. 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 389 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. 16.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 390: Editing Acls

    Chapter 16. User and Group Authorization 16.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 16.6.
  • Page 391 Editing ACLs Figure 16.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 392: Acl Reference

    Chapter 16. User and Group Authorization Figure 16.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 16.6.4.1, “Allow and Deny”.

  • Page 393: Certserver.admin.certificate

    certServer.admin.certificate 16.7.1.1. Operations Operations read modify 16.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 394: Certserver.auth.configuration

    Chapter 16. User and Group Authorization Operations execute 16.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. 16.7.4. certServer.auth.configuration Controls operations on the authentication configuration. 16.7.4.1.

  • Page 395: Certserver.ca.certificates

    certServer.ca.certificates Operations unrevoke revoke read 16.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. 16.7.6. certServer.ca.certificates Controls revoke or list operations for certificates in the agent services interface. 16.7.6.1. Operations Operations revoke list...

  • Page 396: Certserver.ca.connector

    Chapter 16. User and Group Authorization Operations 16.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 397: Certserver.ca.crl

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

  • Page 398: Certserver.ca.ocsp

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

  • Page 399: Certserver.ca.requests

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

  • Page 400: Certserver.ca.request.profile

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

  • Page 401: 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. 16.7.20.2. Default ACIs allow (revoke,read,import) user="anybody" Anyone can request a revocation and import and read a certificate. 16.7.21.

  • Page 402: Certserver.ee.crl

    Chapter 16. User and Group Authorization 16.7.23. certServer.ee.crl Controls read and add operations for CRLs in the end-entities page. 16.7.23.1. Operations Operations read 16.7.23.2. Default ACIs allow (read,add) user="anybody" Anyone can add or read a CRL. 16.7.24. certServer.ee.profile Controls submit and read operations for certificate profiles in the end-entities page. 16.7.24.1.

  • Page 403: Certserver.ee.facetofaceenrollment

    certServer.ee.facetofaceenrollment Anyone can list certificate profiles. 16.7.26. certServer.ee.facetofaceenrollment Controls list operations for certificate profiles to read face-to-face enrollment pages. 16.7.26.1. Operations Operations read 16.7.26.2. Default ACIs allow (read) user="anybody" Anyone can read the face-to-face enrollment page. 16.7.27. certServer.ee.request.enrollment Controls submit operations for certificate enrollment in the end-entities page. 16.7.27.1.

  • Page 404: Certserver.ee.request.ocsp

    Chapter 16. User and Group Authorization Anyone can submit face-to-face enrollment. 16.7.29. certServer.ee.request.ocsp Controls submitting OCSP requests. 16.7.29.1. Operations Operations submit 16.7.29.2. Default ACIs allow (submit) user="anybody" Any clients can submit OCSP requests. 16.7.30. certServer.ee.request.revocation Controls submit operations for certificate revocation requests in the end-entities page. 16.7.30.1.

  • Page 405: Certserver.general.configuration

    certServer.general.configuration allow (read) user="anybody" Anyone can read a request status. 16.7.32. certServer.general.configuration Controls operations on the general configuration of the subsystem. 16.7.32.1. Operations Operations read modify 16.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 406: Certserver.kra.certificate.transport

    Chapter 16. User and Group Authorization 16.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 407: 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. 16.7.36. certServer.kra.connector Controls request submissions.

  • Page 408: Certserver.kra.request

    Chapter 16. User and Group Authorization 16.7.38.1. Operations Operations list 16.7.38.2. Default ACIs allow (list) group="Data Recovery Manager Agents" Only DRM agents can list keys. 16.7.39. certServer.kra.request Controls read operation for a DRM request. 16.7.39.1. Operations Operations read 16.7.39.2. Default ACIs allow (read) group="Data Recovery Manager Agents"...

  • Page 409: Certserver.kra.systemstatus

    certServer.kra.systemstatus 16.7.41.1. Operations Operations read 16.7.41.2. Default ACIs allow (read) group="Data Recovery Manager Agents" Only DRM agents can get the status of key archival requests. 16.7.42. certServer.kra.systemstatus Controls read operations to display the system status of a DRM. 16.7.42.1. Operations Operations read 16.7.42.2.

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

    Chapter 16. 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. 16.7.44. certServer.log.configuration.SignedAudit.expirationTime Controls operations on the expirationTime parameter of a log instance. 16.7.44.1.

  • Page 411: 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. 16.7.46. certServer.log.content.SignedAudit Controls read operations to the signed audit log. 16.7.46.1. Operations Operations read 16.7.46.2. Default ACIs deny (read) group="Administrators"...

  • Page 412: Certserver.ocsp.ca

    Chapter 16. User and Group Authorization 16.7.48. certServer.ocsp.ca Controls add operations for adding a CA to an Online Certificate Status Manager. 16.7.48.1. Operations Operations 16.7.48.2. Default ACIs allow (add) group="Online Certificate Status Manager Agents" Only Online Certificate Status Manager agents can add CAs. 16.7.49.

  • Page 413: Certserver.ocsp.configuration

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

  • Page 414: Certserver.publisher.configuration

    Chapter 16. User and Group Authorization 16.7.53.1. Operations Operations read modify 16.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 415: 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. 16.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 416 Chapter 16. 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 417: Automated Notifications

    Chapter 17. 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 418: Setting Up Automated Notifications

    Chapter 17. Automated Notifications be found, the notification is sent to the email address specified in the Sender's Email Address field of the Notification panel. The email resolver is customized through the ReqCertSANameEmailResolver.java class included as a sample with the CS SDK. 17.2.

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

    Configuring Specific Notifications by Editing the Configuration File • Subject . Type the subject title for the notification. • Content template path . Type the path, including the filename, to the directory that contains the template to use to construct the message content. 5.

  • Page 420: Testing Configuration

    Chapter 17. Automated Notifications /etc/init.d/rhpki-ca stop 2. Open the CS.cfg file for that instance. This file is in the instance's conf/ directory. 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...

  • Page 421: Customizing Notification Messages

    Customizing Notification Messages When the request gets queued for agent approval, a request-in-queue email notification should be sent. Check the message to see if it contains the configured information. 3. Log into the agent interface, and approve the request. When the server issues a certificate, the user receive a certificate-issued email notification to the address listed in the request.

  • Page 422: Notification Message Templates

    Chapter 17. Automated Notifications 17.3.1. Notification Message Templates Notification message templates are located in the CA_instance_ID/emails directory. 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;...

  • Page 423: Token Definitions

    Token Definitions Filename Description Template for the report or table that summarizes publishCerts the certificates to be published to the directory. Uses the publishCertsItem.html template to format the items in the table. Template for formatting the items included in the publishCertsItem.html summary table.
  • Page 424 Chapter 17. Automated Notifications Token Description Gives the type of request that was made. $RequestType 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.

  • Page 425: Automated Jobs

    Chapter 18. 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. 18.1. About Automated Jobs The Certificate Manager Console includes a Job Scheduler option that can execute specific jobs at specified times.

  • Page 426: Setting Up The Job Scheduler

    Chapter 18. Automated Jobs 18.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 427: Setting Up Specific Jobs

    Setting up Specific Jobs Figure 18.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 428: Configuring Specific Jobs Using The Certificate Manager Console

    Chapter 18. Automated Jobs 18.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 18.2, “Setting up the Job Scheduler” 2.
  • Page 429 Configuring Specific Jobs Using the Certificate Manager Console Figure 18.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 18.3.3, “Configuration Parameters of • For requestInQueueNotifier, see requestInQueueNotifier”.

  • Page 430: Configuring Jobs By Editing The Configuration File

    Chapter 18. 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 431: 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 432: Configuration Parameters Of Unpublishexpiredcerts

    Chapter 18. Automated Jobs Parameter Description Section 18.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 433: 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 434: Managing Job Plug-Ins

    Chapter 18. 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 435 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 437: Configuring The Certificate System For High Availability

    Chapter 19. 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 438: Load Balancing

    Chapter 19. Configuring the Certificate System for High Availability Figure 19.1. Certificate System Example Section 19.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. 19.1.2.

  • Page 439: 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 440: Clone-Master Conversion

    Chapter 19. 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 441: 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 442: Converting A Cloned Ca Into A Master Ca

    Chapter 19. 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 19.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 443: 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 19.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 444 Chapter 19. Configuring the Certificate System for High Availability 4. Start the new master OCSP responder server. /etc/init.d/instance_ID start...

  • Page 445: 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 446: Structure Of Certificate Extensions

    Appendix A. Certificate and CRL Extensions 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. The extensions defined for X.509 v3 certificates enable additional attributes to be associated with users or public keys and manage the certification hierarchy.

  • Page 447: Sample Certificate Extensions

    Sample Certificate Extensions 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 448: Note On Object Identifiers

    Appendix A. Certificate and CRL Extensions 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 Public Key Modulus: (1024 bits) : E4:71:2A:CE:E4:24:DC:C4:AB:DF:A3:2E:80:42:0B:D9: CF:90:BE:88:4A:5C:C5:B3:73:BF:49:4D:77:31:8A:88:...

  • Page 449: Standard X.509 V3 Certificate Extensions

    Standard X.509 v3 Certificate Extensions The PKIX standard recommends that all objects, such as extensions and policy statements, that are used in certificates be included in the form of an OID. This promotes interoperability between organizations on a shared network. If certificates will be issued that will be used on shared networks, register the OID prefixes with the appropriate registration authority.

  • Page 450: The Authoritykeyidentifier

    Appendix A. Certificate and CRL Extensions 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 451: Basicconstraints

    basicConstraints issuer's certificate against the authortiyCertIssuer and authorityCertSerialNumber in the Authority Key Identifier extension of the subject certificate. A.3.3. basicConstraints A.3.3.1. OID 2.5.29.19 A.3.3.2. Criticality PKIX Part 1 requires that this extension be marked critical. This extension is evaluated regardless of its criticality.

  • Page 452: Extkeyusage

    Appendix A. Certificate and CRL Extensions 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 453: Issueraltname Extension

    issuerAltName Extension Code signing Email Timestamping OCSP Signing OCSP Signing is not defined in PKIX Part 1, but in RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. Table A.1. PKIX Extended Key Usage Extension Uses Certificate trust list signing Microsoft Server Gated Crypto (SGC) Microsoft Encrypted File System...
  • Page 454 Appendix A. Certificate and CRL Extensions If this extension is included at all, set the bits as follows: • digitalSignature (0) for SSL client certificates, S/MIME signing certificates, and object-signing certificates. • nonRepudiation (1) for some S/MIME signing certificates and object-signing certificates. WARNING Use of this bit is controversial.

  • Page 455: Nameconstraints

    nameConstraints A.3.9. nameConstraints A.3.9.1. OID 2.5.29.30 A.3.9.2. Criticality PKIX Part 1 requires that this extension be marked critical. A.3.9.3. Discussion This extension, which can used in CA certificates only, defines a name space within which all subject names in subsequent certificates in a certification path must be located. A.3.10.

  • Page 456: Policymappings

    Appendix A. Certificate and CRL Extensions 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 457: Subjectdirectoryattributes

    subjectDirectoryAttributes 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 458: Introduction To Crl Extensions

    Appendix A. Certificate and CRL Extensions used in conjunction with the Authority Key Identifier extension for CA certificates. If the CA certificate has a Subject Key Identifier extension, the key identifier in the Authority Key Identifier extension of the certificate being verified should match the key identifier of the CA's Subject Key Identifier extension. It is not necessary for the verifier to recompute the key identifier in this case.

  • Page 459: Sample Crl And Crl Entry Extensions

    Sample CRL and CRL Entry Extensions The application receiving the CRL checks the extension ID to determine if it can recognize the ID. If it can, it uses the extension ID to determine the type of value used. A.4.2. Sample CRL and CRL Entry Extensions The following is an example of the section of a CRL containing X.509 v2 extensions.

  • Page 460: Extensions For Crls

    Appendix A. Certificate and CRL Extensions Section A.5.1, “Extensions for CRLs” • Section A.5.2, “CRL Entry Extensions” • A.5.1. Extensions for CRLs The following CRL descriptions are defined as part of the Internet X.509 v3 Public Key Infrastructure proposed standard. Section A.5.1.1, “authorityKeyIdentifier”...
  • Page 461 Extensions for CRLs 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 462 Appendix A. Certificate and CRL Extensions 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. A.5.1.4.4.
  • Page 463 Extensions for CRLs 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. For details, see the discussion under certificate Section A.3.7, “issuerAltName Extension”.
  • Page 464 Appendix A. Certificate and CRL Extensions Parameter Table A.8. IssuerAlternativeName Configuration Parameters 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.
  • Page 465 Extensions for CRLs 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. The rule can be modified to support any name form by making the appropriate changes to the sample code provided;...

  • Page 466: 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 467 CRL Entry Extensions Parameter 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 Table A.11.

  • Page 468: Netscape-Defined Certificate Extensions

    Appendix A. Certificate and CRL Extensions 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. All Netscape extensions should be tagged as noncritical, so that their presence in a certificate does not make that certificate incompatible with other clients.

  • Page 469: 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 470: 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 471: 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 472: 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 473: 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 474: 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 475 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 476 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 477: 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 478 Appendix B. Introduction to Public-Key Cryptography Certificate Type Example Client SSL certificates Used for client authentication A bank gives a customer an to servers over SSL. Typically, SSL client certificate that allows the identity of the client is the bank's servers to identify assumed to be the same that customer and authorize as the identity of a person,...

  • Page 479: Single Sign-On

    Single Sign-on Certificate Type Example the CA certificates stored in each user's copy of Firefox. Table B.1. Common Certificates B.4.3.2. SSL The Secure Sockets Layer (SSL) protocol governs server authentication, client authentication, and encrypted communication between servers and clients. SSL is widely used on the Internet, especially for interactions that involve exchanging confidential information such as credit card numbers.

  • Page 480: Contents Of A Certificate

    Appendix B. Introduction to Public-Key Cryptography related to the fact that passwords are sent over the network routinely and frequently, both of which make using multiple passwords problematic. The solution to this problem is single sign-on, which allows a user to log in once with a single password and get authenticated access to all network resources that user is authorized to use, without sending any passwords over the network.
  • Page 481 Contents of a Certificate • The certificate's serial number. Every certificate issued by a CA has a serial number that is unique among the certificates issued by that CA. • Information about the user's public key, including the algorithm used and a representation of the key itself.

  • Page 482: How Ca Certificates Establish Trust

    Appendix B. Introduction to Public-Key Cryptography Critical: no Key Identifier: f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36: 26:c9 Signature: Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06: 30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb: f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc: 2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5: b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5: 4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8: d:c4 Here is the same certificate in the base-64 encoded format: -----BEGIN CERTIFICATE----- MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzER MA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEw MTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQK...
  • Page 483 How CA Certificates Establish Trust organizational units may have different profile requirements; or a CA may need to be physically located in the same geographic area as the people to whom it is issuing certificates. These certificate-issuing responsibilities can be divided among subordinate CAs. The X.509 standard Figure B.6, “Example of a Hierarchy of includes a model for setting up a hierarchy of CAs, shown in Certificate...
  • Page 484 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 485 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 486 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 487: 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 488: 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 489: 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 491: 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 492 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 493 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 494 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 495 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 496 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 497 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 498 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 499 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 500 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 501 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 502 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 503 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 505: Index

    Index See also server authentication, 455 authentication modules agent initiated user enrollment, 288, 352 deleting, 355 registering new ones, 355 accelerators, 235 authorityKeyIdentifier, 115, 430, 440 active logs default file location, 74 message categories, 77 backing up the Certificate System, 99 adding backups, 99 extensions...
  • Page 506 Index Certificate Manager, 15 certificate-based enrollment, 353 administrators forms for, 353 creating, 116, 360 what you need, 353 agents when to use, 353 creating, 116, 360 certificateIssuer, 446 as root CA, 7 certificatePolicies, 431 as subordinate CA, 7 certificates CA hierarchy, 7 and LDAP Directory, 468 CA signing certificate, 192 authentication using, 455...
  • Page 507 format, 67 key archival, 147 format for localizable values, 67 key recovery, 147 guidelines for editing, 67 deleting name, 66 authentication modules, 355 when created, 66 log modules, 86 Configuration tab, 59 mapper modules, 329 configuring for high availability, 417 privileged users, 366 publisher modules, 329 viewing content, 325...
  • Page 508 Index Enterprise Security Client, 189, 189 Error log groups defined, 76 changing members, 365 expired certificates removing from the directory, 406 Extended Key Usage extension hardware accelerators, 235 OIDs for encrypted file system, 263 hardware tokens extending directory-attribute support in CS, 121 See external tokens, 231, 231 extensions, 115, 425 high availability, 417...
  • Page 509 how it works, 144 services that are logged, 77 how keys are stored, 143 types of logs, 74 how to set up, 147 Audit, 74 PKI setup required, 141 Error, 76 reasons to archive, 143 where keys are stored, 143 key length, 105 mail server used for notifications, 65 key recovery, 145...
  • Page 510 Index creating, 129, 360 agents, 358 agents public key creating, 129, 360 cryptography, 449 introduced, 12 defined, 451 key pairs and certificates infrastructure, 467 signing certificate, 127 management, 468 SSL server certificate, 127 publisher modules online certificate validation authority deleting, 329 defined, 12 registering new ones, 329 publishers...
  • Page 511 restore, 99 starting restoring the Certificate System, 99 subsystem instance, 64 revocation-status checking for agent certificates, Status tab, 60 stopping revoking certificates subsystem instance, 64 reasons, 290 storage key pair, 142 who can revoke certificates, 290 storing user's certificates, 219 roles subjectAltName, 436 agent, 358...
  • Page 512 Index unbuffered logging, 80 user certificate, 193 requesting, 197 users creating, 116, 129, 149, 186, 360 storing certificates, 219 why to revoke certificates, 290 wTLS CA signing certificate, 104 nickname, 104 X.509 certificates, 22...

Table of Contents