Certifier 5.2.3 ReferenceGuide

Insta Certifier 5.2.3

Reference Guide

www.insta.fi

Version

5.2.3

Date

16 September 2013

© 2013 Insta DefSec Oy. This software is protected by international copyright copyright laws. All rights reserved. All other names and marks are property property of their respective respective owners. owners. No part of this publication may be reproduced, published, stored in an electronic database, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, for any purpose, without the prior written permission of Insta DefSec Oy. THERE IS NO WARRANTY OF ANY KIND FOR THE ACCURACY OR USEFULNESS OF THIS INFORMATION EXCEPT AS REQUIRED BY APPLICABLE LAW OR EXPRESSLY AGREED IN WRITING.

Insta DefSec Oy Sarankulmankatu Sarankulmankatu 20 P.O.Box 80 FIN-33901 Tampere Finland http://www.insta.fi/ Tel: +358 600 97801 (Support HelpDesk) Tel: +358 20 771 7111 (Insta DefSec) Fax: +358 20 771 7122 (Insta DefSec)

Insta Certifier : Reference Guide

Version

5.2.3

Date

16 September 2013

© 2013 Insta DefSec Oy. This software is protected by international copyright copyright laws. All rights reserved. All other names and marks are property property of their respective respective owners. owners. No part of this publication may be reproduced, published, stored in an electronic database, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, for any purpose, without the prior written permission of Insta DefSec Oy. THERE IS NO WARRANTY OF ANY KIND FOR THE ACCURACY OR USEFULNESS OF THIS INFORMATION EXCEPT AS REQUIRED BY APPLICABLE LAW OR EXPRESSLY AGREED IN WRITING.

Insta DefSec Oy Sarankulmankatu Sarankulmankatu 20 P.O.Box 80 FIN-33901 Tampere Finland http://www.insta.fi/ Tel: +358 600 97801 (Support HelpDesk) Tel: +358 20 771 7111 (Insta DefSec) Fax: +358 20 771 7122 (Insta DefSec)


Table of Contents

Table of Content About About This Document Document .............................................. .............................................................. ................................. .................................. ................................. ................... ... 1 Administration Interface ............................................................................................................... 2 2.2 Database Search ............................................................................................................... 3 2.2.1 Database Search Options ...................................................................................... 4 2.2.2 Search Results................. Results.................................. ................................. ................................. .................................. .................................. ................... .. 8 2.2.3 Viewing Log Entries ............................................................................................... 9 2.3 Processing Requests ....................................................................................................... 11 2.3.1 Certificate Profile.................. ......... .................. ................... ................... ................... ................... .................. .................. ................... ............... ..... 13 2.3.2 Entity Entity.............................................. .............................................................. ................................. ................................. .................................. ..................... ... 14 2.3.3 Issuer Issuer ............................... ................................................ ................................. ................................. .................................. ................................. .................. 14 2.3.4 Serial Number ...................................................................................................... 15 2.3.5 Subject Name ...................................................................................................... 15 2.3.6 Validity Period ...................................................................................................... 15 2.3.7 Signature Algorithm.............................................................................................. 16 2.3.8 Certificate Extension Fields .................................................................................. 16 2.3.9 Additional Parameters .......................................................................................... 20 2.3.10 Updating a Changed Request ............................................................................ 21 2.4 Entities Entities ................................. ................................................. ................................. ................................. .................................. .................................. ......................... ......... 21 2.4.1 Adding Entities ..................................................................................................... 22 2.4.2 Editing Entities ..................................................................................................... 23 2.4.3 Adding and and Modifying Pre-Shared Pre-Shared Keys................... .......... .................. .................. ................... ................... ................ ....... 24 2.4.4 Adding Adding Policy Policy Module Attributes.................. ......... ................... ................... .................. ................... ................... .................. ........... 26 2.4.5 Removing Entities ................................................................................................ 27 2.5 Viewing Certificates.......................................................................................................... 27 2.5.1 Viewing Viewing and Exporting Exporting Private Keys................... ......... ................... .................. ................... ................... .................. ............. .... 29 2.6 Certification Authority Settings ......................................................................................... 31 2.6.1 Creating a New Certification Certification Authority................... ......... ................... .................. ................... ................... .................. ........... 31 2.6.2 Editing CA Settings .............................................................................................. 33 2.6.3 View CRL Distribution Points ............................................................................... 36 2.6.4 Editing CA Auto Renewal Settings ....................................................................... 37 2.7 Registration Authority Settings ......................................................................................... 39 2.7.1 Creating a New Registration Authority ................................................................. 39 2.7.2 Editing RA Settings .............................................................................................. 40 2.7.3 Enrolling an RA Certificate ................................................................................... 43 2.7.4 Using a Local CA with RA .................................................................................... 44 2.8 Publishing Settings .......................................................................................................... 44 2.8.1 LDAP Publishing Method ..................................................................................... 45 2.8.2 HTTP Publishing Method ..................................................................................... 49


Table of Contents

2.8.3 OCSP Publishing Method .................................................................................... 50 2.8.4 External Publishing Method.................................................................................. 50 2.9 Operators......................................................................................................................... 51 2.9.1 Adding Operators ................................................................................................. 51 2.9.2 Editing the Operator Information .......................................................................... 52 2.9.3 Operator Access Control Levels........................................................................... 55 2.10 Delegated RA Entities .................................................................................................... 58 2.10.1 Creating a Delegated RA Entity.......................................................................... 58 2.10.2 Editing a Delegated RA Entity ............................................................................ 59 2.10.3 Delegated RA Access Control Levels................................................................. 60 2.10.4 RA-CA Communication Policy............................................................................ 61 2.11 Certifier Servers and Services ........................................................................................ 61 2.11.1 Creating a New Server Entity ............................................................................. 62 2.11.2 Editing the Administration Service ...................................................................... 65 2.11.3 Editing the CMP Service .................................................................................... 68 2.11.4 Editing the External Enrollment Client Service ................................................... 71 2.11.5 Editing the LDAP Authentication Service............................................................ 72 2.11.6 Editing the OCSP Responder Service ................................................................ 73 2.11.7 Editing the Validation Authority Service.............................................................. 75 2.11.8 Editing the Publishing Service ............................................................................ 78 2.11.9 Editing the SCEP Service................................................................................... 80 2.11.10 Editing the Web Enrollment Service ................................................................. 81 2.11.11 Customizing the Web Enrollment Pages .......................................................... 84 2.12 System Configuration ..................................................................................................... 89 2.12.1 Editing System Parameters ................................................................................ 90 2.12.2 Viewing and Approving Pending Change Sets ................................................... 92 2.12.3 Cross-Certification.............................................................................................. 93 2.12.4 Importing a Certification Request ....................................................................... 95 2.12.5 Inserting a Certificate ......................................................................................... 95 2.12.6 Importing a Private Key ...................................................................................... 96 2.12.7 Creating Certificates........................................................................................... 97 2.12.8 Managing CRLs ................................................................................................. 99 2.12.9 Managing Trust Anchors .................................................................................. 100 2.12.10 Changing the Master Password ..................................................................... 101 2.12.11 CA Passphrase .............................................................................................. 102 2.12.12 User-Defined Policy Modules ......................................................................... 102 2.12.13 Viewing System Configuration........................................................................ 103 2.12.14 System Shutdown .......................................................................................... 103 Certificate Life-Cycle Management Services........................................................................... 104 3.1 CMP Service .................................................................................................................. 104 3.2 SCEP Service ................................................................................................................ 105 3.3 Web Enrollment Service ................................................................................................. 106 3.3.1 PKCS#10 Enrollment ......................................................................................... 106


Table of Contents

3.3.2 Browser-Based Enrollment................................................................................. 107 3.3.3 Downloading CA/RA Certificates and CRLs ....................................................... 113 3.3.4 Managing User Certificates ................................................................................ 114 Using External CA/RA Private Keys ......................................................................................... 116 4.1 Creating a CA with a PKCS#11 HSM ............................................................................. 116 4.1.1 Requirements for the PKCS#11 Modules ........................................................... 116 4.1.2 Preparing an nCipher HSM for Use .................................................................... 117 4.1.3 Adding PKCS #11 Modules to the Certifier Engine ............................................. 118 4.2 Checking the Key Backup .............................................................................................. 118 4.2.1 Key backup with nCipher HSMs ......................................................................... 119 4.3 CA Private Key Options ................................................................................................. 119 Appendix 1 Certifier Engine and Server Configuration Files ................................................. 121 Appendix 1 –1 Certifier Engine Configuration File ................................................................. 121 Appendix 1 –2 Certifier Server Configuration File ................................................................. 122 Appendix 2 Database ................................................................................................................ 125 Appendix 2 –1 Setting up Backup Procedure ........................................................................ 125 Appendix 2 –2 Recovery....................................................................................................... 126 Appendix 2 –3 Remote Live Backup ..................................................................................... 127 Appendix 2 –4 Sample Backup Plan ..................................................................................... 129 Appendix 3 Migrating Certifier ................................................................................................. 131 Appendix 3 –1 Migration Steps ............................................................................................. 131


Chapter 1: About This Document

Chapter 1

About This Document Insta Certifier offers versatile configuration and customization options to suit the needs of your PKI service. This document describes the user interfaces, command-line tools, and other configuration options of Insta Certifier. This document contains the following information:  

description of the administration GUI description of certificate life-cycle management services, including the web enrollment GUI



instructions on using the command-line tools included in the Insta Certifier package



instructions on using PKCS #11 compatible hardware security modules (HSM) for storing CA/RA private keys appendix with information on miscellaneous topics (such as configuration files and database backup)





appendix that lists the Certifier syslog messages

To use the information in this document, you should have basic knowledge of publickey cryptography and X.509 certificates. You should also be familiar with the information presented in Insta Certifier Product Description and Insta Certifier Administrator’s Guide. Styles and Conventions Convention

Usage

Example

Bold

GUI elements, variables, emphasis

Click System Configuration

Monospace

Filenames, commands, directories

Configuration file engine.conf

Italics

Terms and references

Certification Authority

Command lines and configuration file contents are shown as in this example: # chkconfig --list certifier


1

Chapter 2: Administration Interface

Chapter 2

Administration Interface The administration interface of Insta Certifier is produced by the Administration Service. All administrative tasks including certificate request processing, certificate publishing, CA policy configuring, and database searches can be performed by using the web-based administration interface. This chapter describes the different functions the operators can perform using the administration interface. Detailed explanations on how to f ill the configuration data and how to use the various GUI features are given. The Help buttons in the administration interface itself are linked to these explanations. In addition to the main admin UI, Insta Certifier is provided with a limited administration interface. See Insta Certifier Administrator’s Guide for instructions. For a description of the web enrollment interface, see Section 3.3 (Web Enrollment Service). Insta Certifier offers also the possibility to customize a totally new GUI. Customizing or programming a new GUI requires writing HTML code and/or embedded script code, Scheme. Contact Insta Certifier technical support for more information. Parts of the administration view After login, the administration interface opens. The administration pages are dynamically created from HTML templates. Each page is divided into two parts, the top menu, the main menu on the left, and the actual settings page. The top menu and the main menu are identical on all pages. The top menu (shown in Error! Reference source not found.) contains a link to the About and Logout links, and the quick Search button.

Figure 2-1 The top menu of the Administration GUI

The main menu (shown in Figure 2-2) contains links to the setting pages of the administration GUI. Some options may be hidden on the menu, depending on the administrator settings.


2


Figure 2-2 The main menu of the Administration GUI

Navigating the administration interface Do not use the Back or Forward buttons of the web browser to navigate in the user interface, as in some cases they may cause the application to function erratically. Instead, use the Back , Cancel, and OK buttons provided on the UI page, or just select a new option from the main menu.

2.2 Database Search Almost all objects in the Database can be located with the generic search functionality. Certificates, certification requests, and entities are all indexed for full-text retrieval. The search can be defined using several different options. This makes it easy to list only the objects that are relevant for each particular situation. Select the Search option from the main menu to open the Database Search page.


3


The Find Certificates, Find Requests, and Find Entities options will go to the same Database Search page. The difference between these options is that some values on the page are preset. The View Log Entries option will also go to a search page, but on that page the searched Log events can be restricted based on the event type. See Section 2.2.3 (Viewing Log Entries).

2.2.1 Database Search Options The Database Search page contains several options that can be used to define the search.

Figure 2-3 The Database Search page


4


Text Search Using the Text search field is straightforward for anyone who has used a common web search engine. However, there are some differences.

Figure 2-4 You can use the ’+’ and ’-’ operands to further define the search results

All white-space-separated words in the field are by default and’ed together. This means that only those objects that contain all of the searched words are shown in the search result. This behavior can be changed by setting the pop up menu on the right side of the text field from Match all to Match some. In the Match some mode all objects containing some of the searched for words are matched. Some individual words can be required to be in the result set by preceding them with a plus sign (+). In both modes a minus sign (-) can be used to restrict the result set by excluding any objects containing certain words. quick brown +fox -dog

For example, the above string in the Match all mode matches the objects which have all of the three words quick, brown, and fox, but not dog. In the Match some mode all of the objects containing the word fox but not the word dog are matched. If the result set is not sorted in time order, objects containing quick or brown would be shown before the other results. Note that both of the ’+’ and ’-’ operators must have a space before them and that they must be directly fo llowed by the operand. Object Status By using the Object status switch, the search can be restricted to only those objects that have the specified status. The object status can be one of the f ollowing: 

Certificate requests: pending, postponed, accepted, rejected or approved

Certificates: active, expired, revoked or hold

Entities: active or inactive

 

Note that this selection is used only if object type is also specified, because status is type-specific. Publish Status Certificates can also be searched according to their publishing status. This allows the operator to check if some certificates have failed to publish correctly. The following publishing statuses are used in Insta Certifier: 

Pending: The publishing is in progress. This status may also appear, for example, in case of certificates issued through CMP that are specifically requested not to be published.


5


 

Ready: The certificate has been published correctly. Error : Some of the required publishing methods have failed to publish the certificate.

Object Type The Object type option can be used to search for certain kinds of objects, for example, certification requests. The effects of later search parameters can also differ depending on the selected object type. Some parameters have an effect only when a specific object type is selected. The available object types are certificate request, certificate, entity, and log entry. Select CA The Select CA option can be used to restrict certificate searches to certificates which are issued by a certain CA. Also certification requests can be selected by their CA, if they have such associated.

Figure 2-5 The Select CA option specifies the CA name

If the CA hierarchy of the PKI contains more than two levels, the Select CA dropdown list does not display all CAs. The names of the first level sub-CAs are displayed immediately after their top-level CAs, and they are preceded by a plus sign (+). If a sub CA has further (level-2) sub-CAs, their names are preceded by two plus signs (++). If there are several level-2 sub-CAs under one level-1 sub-CA, only t heir number is shown (in square brackets). The sub-CA list can be expanded by selecting a subCA and clicking Refresh. In the resulting list, only the sub-CAs are displayed and if they have sub-CAs of their own, the names of the lower-level sub-CAs are preceded by plus signs. To return the list to the top level, click Reset. Time Period The Time period fields are used to restrict certificate and certification request searches. In certificates the time period matches with the certificate’s validity period.


6


Figure 2-6 The time period can be either strict or exclusive

The time format depends on the operator-specific settings. See Section 2.9.2 (Editing the Operator Information). Either the Time period start option or the Time period end option can be left out. In this case the search will be open ended in that direction. Certificates can use either strict (inclusive) period or exclusive periods. In inclusive mode the validity period must be fully contained in the given time period. In exclusive mode a certificate will match if even a portion of its validity period matches with the given time period. Certification requests do not have validity periods in the same sense as certificates do. In their case, this option is interpreted according to the time the request was received. Defining a time period allows the operator to search all requests that arrived during that period. Using strict time period matching does not affect certification request searches. Time period also affects log event searches, in which case only events that happened during the given period are shown. Sort Order The sort order of the result can be changed by selecting the options Sort by time values and Sort in reverse order. All objects have some kind of a primary time stamp. With certificates, it is the time when the certificate was issued. With certification requests, it is the time the request was received. Entities are sorted according to the creation time, and log events are sorted according to their time stamp. If the Sort by time values option is selected, objects are sorted with this primary time stamp. Otherwise they are generally sorted by their internal database ID number. When doing a free-text search with multiple words, however, the matches with most ’hits’ are shown first. Entity The search can also be restricted by entity. This can be done with the Bind search to entity text field. Write the entity search string (for example, the name of the entity) on the text field.

Figure 2-7 Selecting the entity


7


When you click the Search button, the page is updated and the text field is replaced with a drop-down list showing the names of all entities that matched the given search string. Now all certificate and certification request searches are restricted to those ob jects that belong to the selected entity. This restriction can be removed by clicking the Change button. Search with... You can also specify the Serial Number, Reference Number, Pre-Shared key, Request Poll ID, or Internal Object ID of the object you want to display. Select the type of identification and the format of the number from the drop-down lists and type the identification in the field. The identification can be specified in either decimal (DEC), hexadecimal (HEX), octal (OCT) or binary (BIN) format. Number of Results Shown To restrict the maximum number of displayed search results per page, type in the desired number in the Number of results shown field.

2.2.2 Search Results After you click the Proceed button, the search is started. After the search is complete, the results are displayed. The individual items can be viewed (and edited) by clicking View item below the name of the item. Revoking Certificates If certificates were searched, a list of matching certificates is displayed. From this page, multiple certificates can be revoked simultaneously. From the drop-down list on the bottom right corner of the page, you can select to Revoke marked certificates, Revoke not marked certificates, or Revoke all matching certificates (all certificates that matched the search criteria). Select the boxes on the right side of the certificates and click Make It So to continue with revocation. A warning message listing the certificates to be revoked is displayed. Click Proceed to revoke the certificates. Publishing Certificates If certificates were searched, a list of matching certificates is displayed. From this page, multiple certificates can be published simultaneously. From the drop-down list on the bottom right corner of the page, you can select to Publish marked certificates, Publish not marked certificates, or Publish all matching certificates (all certificates that matched the search criteria). Select the boxes on the right side of the certificates and click Make It So to continue with publication.


8


A confirmation message listing the certificates to be published is displayed. Click Proceed to publish the certificates. Rejecting Requests If certification requests were searched, a list of matching requests is displayed. From this page, multiple requests can be rejected simultaneously. From the drop-down list on the bottom right corner of the page, you can select to Reject marked requests, Reject not marked requests, or Reject all matching requests (all requests that matched the search criteria). Select the boxes on the right side of the requests and click Make It So to continue with rejection. A warning message listing the requests to be rejected is displayed. Click Proceed to reject the requests.

2.2.3 Viewing Log Entries Log events can be searched by clicking View Log Entries on the main menu. The search options are the same as on the main Database Search page, with the exception that the searched Log events can be restricted based on the event type. To start the search, click the Proceed button. After the search is complete, the results are displayed. Depending on the event and object type there may be additional links beside the log entry.


9


Figure 2-8 Searching for log entries

Some objects such as CAs and Certifier Servers allow detailed auditing of the made changes. Clicking the view original link shows the object in its original state before the logged change. Changes between revisions can be viewed by clicking the Prev and Next buttons. When viewing committed CA change sets, difference between currently viewed change set and previous CA revision is shown. When viewing revision of system parameters, difference between viewed revision and previous revision is shown.


10


Figure 2-9 Search results for log entries

2.3 Processing Requests When a CA policy does not allow the certificate to be automatically generated (for example, if shared secrets are not used in certificate enrollment), the operator has to manually approve the certification request. All received but not yet processed requests are marked with the pending status in the Database and can be easily found either by using the Process Requests option of the main menu or by a specific Database search with status set as pending. The easiest method to process a pending certification request is to click the Process Requests button on top of the main menu. This runs a database search on all pending certification requests in the Database and displays the result to the operator, most recently arrived requests first.


11


Figure 2-10 Operator’s view to a certification request


12


Also other, more specific searches can be used. From the Search Results page the View Request button will bring up the request in an editable form, and the operator can manually verify all fields of the certificate and modify almost any other data associated with the certification request, prior to making t he certificate. The different request fields are described in the following sections.

2.3.1 Certificate Profile A certification request can have an associated Profile in it. In general, profiles restrict the allowable fields in a request by removing all extensions that are not explicitly set by the profile. They can also change the names in a request and add extra extensions with default values if they are not present in the request. Note: The profiles are processed only if the relevant CA policy contains an Apply Profile or Apply Request Profile policy module. See document Policy chain and modules. The following certificate profiles are sample profiles that might not work in all cases. Because PKI-enabled applications, such as routers and e-mail clients, have different requirements for the certificate extensions and fields, you need to be aware of what kind of certificates a specific installation requires. Also, sometimes it makes sense to have a certificate for multiple purposes. New certificate profiles can be easily created for environments where the following sample policies are not enough. Contact Insta Certifier technical support if you need customized certificate profiles. Email A profile for e-mail (S/MIME) certificates. Copies the Email subject alternative name from the request to the certificate template. Fails if it is not present. Sets the Digital Signature, Non Repudiation, Key Encipherment, and Data Encipherment key usage bits. Sets the ekuEmailProtection extended key usage OID. 





TLS A profile for TLS certificates. Copies the Email subject alternative name from the request to the certificate template. Fails if it is not present. Sets the Digital Signature and Key Encipherment key usage bits. Sets the ekuServerAuth and ekuClientAuth extended key usage OIDs. 

 

IPSEC A profile for IPSec certificates. Copies the IP subject alternative name from the request to the certificate template. Fails if it is not present. If present, copies the Email subject alternative name from the request to the certificate template. Sets the Digital Signature, Key Encipherment, and Data Encipherment key usage bits. 





Windows 2000 logon with smart cards


13


A profile for Microsoft Windows smart card logon certificates. Note that this profile requires a preconfigured entity with the UPN attribute. Copies the UPN attribute of the entity to the UPN subject alternative name of the certificate template. Fails if it is not present. Sets the Digital Signature and Key Encipherment key usage bits. Sets the ekuSmartCardLogon and ekuClientAuth extended key usage OIDs. 

 

2.3.2 Entity If the request contains a known pre-shared key, the CA Engine automatically assigns an entity mapping to the request. The operator can manually change the entity mapping. This is done by entering the entity search string (such as the name of the entity) in the string input box and then clicking the Search button adjacent to the box. The first few dozen entities matching with the search parameters are then displayed in a drop-down list. The entity selection can be removed by clicking the Change button next to the menu. If the entity is already set, it can be cleared by clicking the Reset button.

2.3.3 Issuer Usually the enrollment process pre-selects one of the CAs in the system for each certification request, but requests without a CA mapping can also exist in the Database. The operator should check if the selected CA is correct for the certification request. The selected issuing CA is extremely important as it will radically affect the policy decisions made for the request and will also determine the resulting certificate’s future use to a great extent. Creating self-signed certificates (certificates that do not have an issuing CA) is disallowed in request processing, but can be done using the Create Certificate option under the System Configuration main menu item. The operator must have superuser privileges for this, as certificates made that way bypass all CA policy code. A request can also be approved by an RA, and if this is the case, the issuer field needs to contain a local RA of the system. Instead of issuing the certificate, the RA signs the certification request and sends it to the remote CA that is associated with this RA. The CA list works as described in Section 2.2.1 (Database Search Options). If CA policy chain doesn’t include specific module for setting the signature algorithm for enrolling certificate, engine automatically selects one based on issuer key size: When issuer key is RSA type: Issuer Key Size

Algorithm

<= 2048 bits

RSA with SHA-256

2049..3072 bits

RSA with SHA-384

> 3072 bits

RSA with SHA-512

When issuer key is EC type:


14


Issuer Key Size

Algorithm

<= 256 bits

ECDSA with SHA-256

257..384 bits

ECDSA with SHA-384

> 384 bits

ECDSA with SHA-512

2.3.4 Serial Number Serial number can be set manually, although it is not recommended. Each issuer has a randomly increasing serial number counter (unless sequential increase has been configured from global configuration file), and the serial numbers are automatically generated. In some situations operator may want to use a specific serial number e.g. for selfsigned root CA certificates or subordinate CA certificates. If the number is manually given, it is verified to be a number in range 1 – 10 40. Serial number is not accepted if the same issuer has already issued a certificate with the given number, or if there is a self-signed certificate with the given number.

2.3.5 Subject Name The subject name should be checked and verified. The system automatically checks that the given distinguished name is syntactically correct, and certain CA policies can be used to check that the subject name matches a pattern. Errors in these checks are displayed to the operator before the request is updated or issued, but operators should still be somewhat familiar with the distinguished name format. However, there can be other, finer policy considerations for the subject name format that the operator must check manually. For example, a person’s name can be wri tten in several different formats (first name first, last name first, without middle names, with middle initials, etc). Verifying that the name is in reasonable format for your organization’s needs can sometimes be hard to do automatically. Note: All distinguished names, including the subject name mentioned here, are written in the same order that is used when the names are encoded in certificates. This is e xactly the opposite order as the one used in LDAP applications. When dealing with LDAP, Insta Certifier will convert all distinguished names to the correct order automatically.

2.3.6 Validity Period The validity period defines the time frame within which the certificate is valid. All clients should disallow using certificates before or after their validity period.

Figure 2-11 The validity period options


15


The validity period is rarely set in the original request and it is usually reset by the CA policy to some default value. CA policy allowing, the operator can check and modify the validity period of the resulting certificate. The system automatically restricts validity periods inside the validity period of their issuing CA certificate. The used date and hour format depend on the operator-specific settings. See Section 2.9.2 (Editing the Operator Information). The Not before and Not after times are given (as are all other time values in Insta Certifier) in local time. Setting the Validity Period Instead of writing the exact validity period in the request form to the Not before and Not after fields, the period length can be chosen from the Set Validity Period dropdown list. Click the Set Validity Period button, and the Not before and Not after fields are automatically set with the correct dates.

2.3.7 Signature Algorithm The Signature Algorithm field defines the algorithm that CA uses to sign the certificate. The field contains SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512. The default value is SHA-1 when using RSA key type. For EC key type, the signature algorithm is automatically selected based on issuer key size. Selection is based on NIST recommendations (2011).

2.3.8 Certificate Extension Fields The Extension subsection shows all extension fields present in the certification request. Existing fields can be modified like any other request data and additional extensions can be added by selecting an extension from the drop-down list and clicking the Add button. An existing extension can be removed from the request by clicking Remove next to the extension field. The extensions recognized by Insta Certifier are described below. Email Email subject alternative name. Multiple values are allowed. IP Address (IP) IP address subject alternative name. Multiple values are allowed. At the moment this field can only contain IPv4 addresses in dotted octet format (for example, 134.23.54.102). Universal Resource Identifier (URI) URI subject alternative name. Multiple values are allowed. The URI must be nonrelative (for example, http://www.certificate.fi). Domain Name (DNS) DNS subject alternative name. Multiple values are allowed. Registered ID (RID)


16


RID contains an OID as a value, for example, 2.5.223.67.32.568.64.23 is a valid OID. Multiple values are allowed. User Principal Name (UPN) UPN subject alternative name. This extension is required, for example, for Windows 2000 smart card logon. Directory Name Another distinguished name in addition to the subject name can be stored here. Multiple directory names are allowed. Nokia specific extensions Nokia mobile phone specific extensions: Nokia R&D extension for Java, Nokia R&D extension for Symbian and Nokia R&D capabilities for Symbian. Policy Info This field contains information about the applicability of the certificate for various uses and certification practices of the issuing CA. If this extension is set as critical (from the drop-down list), the client application handling the certificate must not use the certificate unless it is familiar with the extension. If this extension is set as noncritical, a client application may use the certificate even if it does not recognize the extension. Click the Edit button to edit the policy information extension. The extension needs to have an object identifier (OID), which is registered for the certificate policy. Additionally, the extension may contain a user notice and a certification practice statement (CPS) URI. The CPS URI field can give, for example, the location where the written certificate policy can be found with a web browser. The user notice is intended to be displayed to a client when the certificate is being used. The textual statement needs to be written to the Explicit text field. The Organization field can be given name of the organization giving the statement and Reference List the number that identifies the statement. Click the Add User Notice and Add CPS URI buttons to add optional policy fields. Authority Access This extension can be used to indicate how to access the CA information and CA services (other than CRLs). The authority access may contain either information about CAs that have issued certificates superior to the CA that issued the certificate containing this extension, or location of t he OCSP service. The first drop-down menu is used to select which one of these is being used, caIssuers or ocsp. The second drop-down menu identifies the way how this information is provided, URI, DN or Email are the options. When authority access is being used to locate the OCSP responder, HTTP URL of the responder service should be given Authority Access field. Basic Constraints Present only in CA certificates. If the CA flag is set, it indicates that this is a CA certificate. The path length constraint is optional and can be removed selecting unlimited from the drop-down list. To remove the Basic Constraints extension, click the Remove button.


17


If the path length constraint is present, it indicates the maximum number of certificates that can follow that particular CA certificate in the certification path. This means that a CA with a path length of zero cannot issue any sub-CA certificates at all, and a CA with a path length of one can issue only CA certificates with a path length of zero, and so on. A CA certificate with no path length constraint allows a certification path of unrestricted length underneath it. Key Usage The key usage extension is a bit field with a number of named bit values. Digital Signature Set when the public key is used for digital signatures for other purposes than non-repudiation, certificate signing, or CRL signing. Non Repudiation Set when the public key is used to provide a non-repudiation service. Key Encipherment Set when the key is used for key transport/management. Data Encipherment Set when the key is used to encipher data not consisting of cryptographic keys. Key Agreement Set when the key is used in key agreement. Key Cert Sign Set when the key is used to verify signatures on certificates. Only CA certificates can have this bit set. CRL Sign Set when the key is used to sign CRL information. Only CA certificates can have this bit set. Encipher Only If the key agreement bit is set, the key can only be used to encipher data in key agreement procedure. Decipher Only If the key agreement bit is set, the key can only be used to decipher data in key agreement procedure. Note that not all bit combinations are valid. Such factors as if t he certificate is a CA certificate or the key type affect the possible combinations. The system automatically ensures that only certificates with valid key usage extensions are issued. Extended Key Usage Extended key usage, unlike the key usage above, is a list of OIDs representing different key usage constraints. ekuServerAuth


18


The certificate is used in TLS server authentication. ekuClientAuth The certificate is used in TLS client authentication. ekuCodeSigning Signing of downloadable executable code. ekuTimeStamping Used in time stamping services. ekuEmailProtection Used for protecting e-mail messages. ekuIkeIntermediate Used with IKE. ekuOCSPSigning The certficate is used for signing OCSP responses. ekuSmartCardLogon Used for Windows 2000 smart card logon. Custom Extended Key Usage OID A custom extended key usage, given as an OID in a text box. Netscape Comment Extension displayed by Netscape, given as a text string. Subject directory attribute The various subject directory attribute extensions contain information on t he certificate user. The information can be entered in a text field. title The user’s title (free text). dateOfBirth The user’s date of birth. The time format depends on the operator -specific settings. See Section 2.9.2 (Editing the Operator Information). placeOfBirth The user’s place of birth (free text). gender The user’s gender (M or F). countryOfCitizenship


19


The user’s citizenship. Should be given as an ISO 3166-1-Alpha-2 country code (for example, FI). countryOfResidence The user’s country of residence. Should be given as an ISO 3166 -1-Alpha-2 country code (for example, US). Qualified Certificate Statement Qualified Certificate (QC) statement as per RFC 3039. The extension can have one of five values that are set on Edit Qualified Certificate Statement page. Several QC extensions can be added, each with different value. PKIX QC Syntax v1 Indicates conformance with Qualified Certificate profile as specified in RFC 3039. The extension can either have No content, contain a Semantics Identifier OID, or contain information on Name registration authorities (an URI, a Directory Name, or an Email address). QC EU Compliance Indicates compliance with the EU directives on Qualified Certificates. Monetary Limit Imposes a limitation on the value of transaction for which the certificate can be used. The Currency code and the Amount need to be entered in text boxes. The currency code should be given as an ISO 4217 three-letter code (for example, USD). Retention Period Indicates a period (in years) after the expiry of the certificate for which information related to the certificate is archived. Custom Statement A custom QC statement extension consists of an OID and the extension (in DERencoded hexadecimal format). Custom Binary Extension A custom binary extension consists of an OID and the extension data (in hexadecimal format). If this extension is set as critical (from the drop-down list), the client application handling the certificate must not use the certificate unless it is familiar with the extension. If this extension is set as non-critical, a client application may use the certificate even if it does not recognize the extension.

2.3.9 Additional Parameters Two additional parameters related to the certificate can be set. These parameters are not included in the certificate itself but they are used internally by Insta Certifier. Normally a revoked certificate is removed from the CRL after its expiration. If Include in CRL after expiration is selected, and the certificate is revoked at some point dur-


20


ing its validity period, the certificate will stay in the CRL even after its validity period has ended. By default, this option is not selected. If Publish certificate is selected, the certificate will be published (according to the publishing settings of the CA). If the option is not selected, the certificate will not be published. By default, this option is selected and the certificate is published.

2.3.10 Updating a Changed Request All modifications to request data are automatically updated into Database when the request is accepted. Data can also be manually updated by clicking the Update button in the bottom of the page. When the operator clicks either the Accept or the Reject button, the request’s status is updated accordingly, the last search is refreshed and its results are displayed automatically. Note that now the just-processed request has different status and might be removed from the search results. Accepting the certification request will create a certificate with the modified request as a template. Subject and Authority key identifiers will be assigned during this process (the SHA-1 hash over the corresponding DER encoding of public keys is the method used). After the approval, the certificate is stored in the internal Database and published to a directory server (if so configured). Also the approval operation, including the operator login name, is stored in the Database to enable audit trail of the certificates. If a request is denied, the same request cannot be approved later. A Poll reference ID for the request is shown on the request processing page. This ID needs to be given when polling for the approved certificate, for example, via the Web Enrollment Service. Clicking the Postpone button sets the request to postponed status. This means that it will be removed from pending requests but can otherwise be manipulated normally. The Reset button at the bottom of the page resets the page to the values found in the Database and effectively cancels all modifications done by the operator after the last update. The View Log option displays recent log events related to this request. Copy Request adds a new request to the Database with identical information. This can also be done to already accepted or rejected requests.

2.4 Entities An entity is anything that can request and receive certificates from Insta Certifier. An example of an entity could be a user requesting a certificate for e-mail usage, or a network device requesting certificates for IPSec. Entities are used to bind a set of attributes describing the entity and a set of requests and certificates together. This makes it easier for operators to view what kind of certificates are given to users.


21


Entities can also contain a set of shared secrets, in the form of a secret key ID and a pre-shared key. These keys can be used to map incoming certification requests to a certain entity. Additionally, secrets can have a set of policy attributes that can alter the way they are handled in the automatic CA policy code. For example, the system can be set up so that when a certification request with a matching pre-shared key comes in, it is automatically accepted and issued with a pre-configured set of certificate extension values without operator intervention. Using entities is not strictly necessary, as Insta Certifier can also operate on certification requests without entity mapping. Using entities is recommended if the potential end user base is large. For CMP enrolment entities have to be used.

2.4.1 Adding Entities You can add new entities to the PKI system by clicking the Add New Entity option from the main menu. An entity can be bound to a specific CA. This means that the certification requests by this entity are directed to the selected CA. To create a CA binding for the entity, select a CA from the list. The list works as described in Section 2.2.1 (Database Search Options).

Figure 2-12 Creating a new entity

The Entity status drop-down list displays the entity’s current status. An entity is normally marked as Active. In some cases, an entity’s future use in the system might need to be restricted. In this case, set the entity status to Inactive. The Entity name field is reserved for a freeform, short and hopefully descriptive name for this entity. In case of a person, the first and last name are the usual choice. In case of routers or other equipment, advisable choices are the entity’s use , user group it belongs to, or perhaps its location. Exact information such as the IP address can have a separate attribute in the entity. This makes searching for them more acc urate.


22


Entity Attributes In addition to these fixed elements, an entity can have a selection of attributes. An attribute can be added to the entity by selecting an attribute from the Attributes list and clicking Add. The selected attribute is added to the entity display and can be changed. Most of the attributes differ by their name and the size of text input box, but some have different content types, such as drop-down lists giving a limited selection of choices, or Boolean values represented as check boxes. The Email address and Account Password attributes of the entity are used when entity account management is enabled in the Web Enrollment Service. See Sections 2.11.11 (Customizing the Web Enrollment Pages) and 3.3.4 (Managing User Certificates) for more information. Otherwise the system does not use the attributes in any way. However, if the CA is properly configured, the attributes defined in the entity can be used when publishing a certificate, for example, as the values for LDAP attributes. An attribute can be removed by clicking the Remove button on the right hand side of the attribute. The attribute is then removed and a refreshed page is shown. The actual entity is not created until you finish the creation process by clicking the Create button at the bottom of the page. The Cancel button can be used to return from the entity creation process without actually adding the entity to the Database. You can also switch to some other page by using the main menu.

2.4.2 Editing Entities The Entity page can be reached in many ways. You can search for entities based on their creation time or by some indexed words given in the entity attributes. To do the search, select the Find Entities option from the main menu. Searches can also be made from the certification request update page. Some log entries have an associated entity which can be viewed. An entity associated with a certificate can be viewed from the certificate page. The Entity page looks almost the same as the entity creation page. The only difference is the addition of Pre-shared keys and some different buttons in the bottom of the page.


23


Figure 2-13 The Entity page

Clicking the Commit Changes button will update the Database with the new name, status and attribute values that have been set by t he operator. Changes in pre-shared keys are updated on their own and are unaffected by this button. Clicking the View Log button fetches the recent log entries related to this entity and displays them. The View Requests button searches the Database for all pending certification requests that are marked to this entity either automatically by some policy mapping or manually by the operator. The View Certificates option shows all active certificates that belong to this entity. The Search button shows a generic find page with the current entity automatically bound. The Copy Entity option makes a new copy of this entity. Only attributes, type and name are copied as shared secrets are naturally entity-specific.

2.4.3 Adding and Modifying Pre-Shared Keys A new entity will automatically have one pre-shared key. You can add new pre-shared keys to an entity by clicking the Add button on the top row of the key table. This adds a new row to the table, displaying the newly created shared secret.


24


Figure 2-14 Pre-shared keys listed

The Type field shows the type of the key - but currently only psk (for pre-shared key) is defined. The Use Count option gives the number of times that this key has been used successfully to enroll a certificate. (Certain policy functions and policy attributes restrict multiple uses of the same key.) The Reference Number is a unique identification number for this secret, assigned by the Insta Certifier Engine. This ID is required by the CMP protocol, which uses it to identify the used secret. The Key field contains the actual shared secret. This is a free-form text string that was randomly generated when the secret was created. The key can be removed by clicking the Remove button on its table row. Clicking the Edit button displays more information about the key.

Figure 2-15 The Pre-Shared Key page

On this page you can change the key’s type and use count. Increasing the Use count can be useful in certain situations, if a well known end user has used the key, but for some reason wants to enroll another certificate with same key. However, the recommended way to do this is to generate a new shared secret and distribute it to the user in order to minimize the possibility of key misuse. The actual key can also be changed either manually (by typing a new value to the text field) or by clicking the Generate New Key button. By typing a key, you can allow the use of passwords (passphrases) generated by external systems instead of ran-


25


dom character strings generated by Insta Certifier. These passwords should, however, be of sufficient length. All changes made on this page are committed to Database by clicking the Commit Changes button on the bottom of the page. This will also return the view to the main entity page. Clicking the Cancel button will discard the changes and return the view directly to the main entity page.

2.4.4 Adding Policy Module Attributes You can add Policy modules to the entity or to a shared secret of the entity. The modules can affect the way the incoming certification requests containing this key are handled by the system. This is generally used to shorten the processing time by allowing a certificate to be automatically issued. They can also be used to identify the cert ification request to the operator, thereby allowing faster manual identity verification. Policy modules that are added to the entity affect all certification requests by the entity. Policy modules added to a shared secret affect only the requests made with that secret. For the policy modules of the entity or a shared secret to take effect, the CA policy must contain the Apply Policy Attributes module in the receive-request chain. See document Policy chain and modules. To add a policy module to an entity, select the desired module from the – Add New Policy Module – dropdown list on the Entity page and click Add. After you have added the desired policy modules click the Commit Changes button to update the entry in the Database. To add a policy module to a shared secret, click edit next to the secret to go to the Pre-Shared Secret page. Select the desired module from the – Add New Policy Module – drop-down list and click Add. After you have added the desired policy modules click the Commit Changes button to update the entry in the Database and return to the Entity page. The currently supported policy module attributes are the following: Accept All Access List Active Certificate Limit Add Policy Info Extension Add Qualified Certificate Statement Apply Profile Check Key Usage Check Request Protocol Drop Extensions Match Names


26


Match Subject Name Reject All Remove Basic Constraints Set Absolute Validity Period Set Certificate Template Set Extended Key Usage Set GUID Set Key Usage Set Max Validity Time Set Meta Info : CRL Sticky Set Meta Info : Publish Set Request Field From Entity Set Signature Algorithm Set Subject Name Set Validity Period See document Policy chain and modules for a detailed description of the policy modules.

2.4.5 Removing Entities Sometimes an entity has to be removed from the system. Normally certificate revocation and removal of the shared keys are enough, and basically provide the same outcome. However, if the entity is obsolete, you can remove it by clicking the Remove Entity button on the Entity page. The Warning page will be shown and you are asked to confirm the selection before the entity and all associated certificates and keys are removed from the system.

2.5 Viewing Certificates To view a certificate, first search the certificate from the Database with the normal search function. See Section 2.2.1 (Database Search Options). To view a CA certificate, click View Certificate on the CA Hierarchy or Certification Authority page.


27


Figure 2-16 The Certificate page

On the Certificate page, you can Revoke or Suspend the certificate by clicking the appropriate button at the bottom of the page. If the certificate is already suspended (it is in hold status) the Suspend button is replaced with the Reactivate button that can be used to reactivate the certificate. Suspension and reactivation take place immediately after you click the button (but there will be a delay, depending on the CA settings, before the information will appear in the CRL).


28


If you select to Revoke the certificate, you will be asked for confirmation. On the Revoke Certificate page, you can give a Reason Code for the revocation (as per RFC 3280), adjust the Invalidity Date, and add a Comment to the revocation. The comment is visible in Insta Certifier only. The revocation codes and the invalidity date (only if its value is changed) are stored in the CRL. The following reason codes can be used:    

  

No reason code Key compromise CA compromise Affiliation changed Superseded Cessation of operation Privilege withdrawn

It is also possible to revoke (but not suspend) several certificates at the same time. See Section 2.2.2 (Search Results) for more information. Revocation reason codes cannot be used in mass revocations. After suspension or revocation, the revocation information is included in the next published CRL (it is immediately available for OCSP). After that the certificate cannot be used any longer by the PKI client applications. The only difference between suspension and revocation is that a revocation cannot be reversed. If a suspended certificate is reactivated, the suspension information will be removed from the next published CRL. In addition to revocation, you can choose to Re-publish or reissue the certificate by clicking the appropriate button on this page. Clicking the Reissue Certificate button opens the request processing page with preset values from the certificate. See Section 2.3 (Processing Requests).

2.5.1 Viewing and Exporting Private Keys If the certificate has been created using the Make New Certificate option (see Section 2.12.7 (Creating Certificates)) or if a CMP enrollment client has requested key backup, the private key corresponding to the certificate is stored in the Certifier Database. An operator with sufficient access level can view the private key by clicking View Private Key on the Certificate page. See Section 2.9.2 (Editing the Operator Information). On the View Encrypted Private Key page, the key is by default shown in base-64encoded PKCS#12 format. The PKCS#12 blob is encrypted with a random password that is shown on the top of the page.


29


Figure 2-17 The View Encrypted Private Key page

To download the key (in binary PKCS#12), click the Download button. Your browser will ask whether you want to open the key file or save it to disk. To view the key with another password, enter the password in the Refetch with passphrase field and click Refresh.


30


To select another format for the key, select the Envelope format from the list and click Refresh. The key is shown with the given passphrase in the new format. Available formats are PKCS#12 (default), PKCS#12 with issuer certificate (includes the issuing CA certificate), PKCS#12 with issuer chain (includes the whole certification path up to the root CA), and PKCS#8. After refreshing, you can download the key in the new format by clicking the Download button. Notice that when multi approval is enabled, operators can’t export private keys.

2.6 Certification Authority Settings Insta Certifier can manage several virtual CAs with complex hierarchies. It may be necessary to create several CAs for distinct purposes even within the same organization. CA management and creation can be easily handled via the administration interface by an operator.

2.6.1 Creating a New Certification Authority New CAs can be created on the CA Hierarchy page. To start creating a new CA, click the Create New CA button on the bottom of the CA list.

Figure 2-18 Creating a new certification authority

The main attributes of a CA are its name, description, status, and the CA certificate. The CA name is a short internal name used mainly to identify the CA to the operators. It should be easily distinguishable and unique as it will be displayed in drop-down lists in several different displays in the system. SCEP enrollment clients may sometimes require this name to be formatted like a domain name.


31


Description should be a longer text that more precisely identifies the intended use of this CA. The CA Status is either Active or Inactive . CAs marked as Inactive cannot be used. Preliminary Policy Settings Preliminary decisions concerning the CA policy and publishing methods of the CA can also be done already on the Create New CA page. They can be configured more thoroughly later - the default options are provided on this page just to make the operator’s life easier, since the publishing and policy editing do not need to be started from scratch. The Default policy list displays three basic policy options, Deny all, Manual request approval, and Automatic request approval. When Deny all is selected, the CA will not issue any certificates before the policy is specifically activated. By selecting Manual request approval , the initial policy does not allow automatic issuance at all, instead all requests will be pending operator approval. When Automatic request approval is being employed, the CA will automatically issue the certificate if the request contains a valid shared key that can be associated to an entity. The Default validity period length is the validity time used in the default CA policy that is automatically generated for the new CA. Note that if the generated set-validityperiod policy module is removed from the policy, there will be no default time and the time specified in the incoming requests are always used. Preliminary Publishing Settings Preliminary publishing settings can also be chosen in the Create New Certification Authority page. Default publish setting defines the publishing schema that is being used. If an LDAP Publishing Service is already being added and configured, it can be selected in the LDAP Server Connection drop-down menu. LDAP Publishing Service defines the directory access including the server address and the directory administrator login name and password. All of the above choices can be edited later, so setting them correctly is not critical at this stage. CA Certificate If a CA certificate is already in the Database (added by an external utility, previously created) it can be searched for by writing a free-text search string in the text box and clicking the Search button. The search results are displayed in a drop-down list. Note that if a result list is too long, it will be truncated. Therefore it is advisable to use precise search texts. If previously created CA keys and a certification request exists in the database, a CA certificate that has been signed by an off-line CA can be imported by clicking the Import certificate button. If there is no ready-made certificate in the Database, one must be created by clicking the Create New CA Certificate button. This will open the Make New Certificate page. See Section 2.12.7 (Creating Certificates) for options available on this page.


32


When the Proceed button is clicked, a certificate is created and the operator is returned to the CA creation page. The CA certificate box is automatically updated with the newly created certificate. Note that if long key lengths are used, key generation can take a long time and the browser connection may time out, producing an error message. If this happens, the user should wait until the key generation process is complete and then restart the CA creation. The new certificate in the Database can be f ound, for example, by searching its subject name. The new CA is created by clicking the Proceed button.

2.6.2 Editing CA Settings To configure an existing CA, click the CA name on the CA List page. This will open the Certification Authority page. On the CA page several CA specific fields can be set. The first field, CA name, is a short and descriptive name that operators can easily identify. It does not have to match the subject name in the CA certificate. Description is a longer description viewed only by the operators. The CA Status is either Active or Inactive . CAs marked as Inactive cannot be used.


33


Figure 2-19 The Certification Authority page

CA Certificate The CA certificate can be viewed by clicking the View Certificate button on the CA certificate row. The certificate can also be changed with the Change button, but this should be done only after extreme consideration! As all certificates issued by this CA are signed with the old CA certificate’s key, all CRLs issued after the CA certificate change might be invalid for old certificates. Changing the CA certificate will in effect revoke all certificates issued by that CA before the change!


34


Certificate Publish Methods

Certificate Publish Methods describe the current publishing methods for certificates issued with the CA. The line shows the current protocol and server address, if applicable. The configuration can be changed on the Edit Certificate Publishing Section 2.8 (Publishing SetMethod page by clicking the Edit Publish button. See Section 2.8 tings). tings). CA Auto Renew CA keys (and certificate) can be automatically renewed. The Renewal period field shows how much in advance the keys are renewed prior to the current certificate expiration. Time until next renew field shows how much time is left before the next renewal. The renewal settings can be configured by clicking the Edit button. CRL Update and CRL Publish Methods CRLs are published to a CRL distribution point. The Update Period, Advance, This Update Offset, and Next Update Offset (given in seconds) can be changed. They are updated in the Database when the Commit Changes button is clicked. Note that the next CRL is still published according to the old update settings. The CRL Update information is given in seconds (for example 3600) or in minutes (50m) or in hours (15h) or in days (370d). By setting the Update Period value to zero, the operator can disable CRL updating. After that no new CRLs are automatically generated, but the operator can still request on-the-fly CRL generation by clicking View Distribution Points and then View Current CRL. The system generates the CRL with the validity period starting from the current time and ending after a configurable amount of time. (This is configured with the engine configuration file.)

Advance is the time marginal reserved for CRL generation. For example, if Update Period is 600 (10 minutes) and Advance is 120 (2 minutes), the system will every 8 minutes publish a CRL with a lifetime of 10 minutes. This is to ensure some overlap period, as there may be a delay before the CRL is generated and available for clients. This Update Offset is the time reduced from the thisUpdate field of the CRL. For example, if This Update Offset has been set to 1800 (30 minutes) and the publication time of the CRL is 13:00, the thisUpdate field is set to 12:30. The option is useful to accomodate for PKI client clocks that are slightly off. PKI clients could, for example, reject a CRL that is published in the future from the clients’ point of view. Next Update Offset is the time added to the nextUpdate field of the CRL. For example, if Update Period has been set to 3600 (1 hour) and Next Update Offset to 7200 (2 hours), the system will every hour publish a CRL with a lifetime of 3 hours. The option is useful to allow some overlap of CRL validity periods in case the CA is down or unreachable. The CRL Update Type can be either periodic update only, or update after each revocation. If Update after revocation is selected, a new CRL will be generated each time a certificate is revoked, thus the CRL will always be up-to-date. In some situations, this option provides a useful substitute for OCSP. Note, however, that all clients do not necessarily get this new CRL if their old CRL is still valid (based on the update


35


period). In environments that require true real-time certificate status information, only OCSP should be used. By clicking the Edit Publish button on the CRL Publish Methods row the distribution point specific publishing configuration can be changed. See Section 2.8 (Publishing Settings). The active CRL distribution points can be viewed by clicking View Distribution Points. The CRL Signature Algorithm can be selected to be either SHA-1, SHA-224, SHA256, SHA-384 or SHA-512. SHA-1 is the default. Signature algorithm depends on key type (RSA or ECDSA). Other Settings The Next serial number is a CA specific counter for serial numbers assigned for certificates issued by the CA. It is normally increased by a random value after each issuance. This value can be used to set a starting point of a serial number space for the CA, if such is specified e.g. in CA policy. Changes made to the CA data or to non-publishing related data in CRL distribution points (update period) can be updated to the Database by clicking the Commit Changes button. The Edit Policy button will display the separate policy editing page where the policy of the CA can be viewed and modified. See document Policy chain and modules.

View Current CRL displays the currently active CRL for this CA. View Log shows all log events related to this CA. Restarting Publishing Clicking the Restart publishing unpublished certificates button will search all active certificates issued by this CA that have pending or error as their publishing status. One by one, it tries to republish them. This is useful if many certificates have failed to publish correctly because of a network problem or misconfigured publishing information. The process is only started when this button is clicked and will continue in the background until finished. The Restart publishing all certificates button is similar, but will instead republish all active certificates of this CA. This can be used, for example, if the LDAP server has changed and all certificates need to be added again. Both of these two buttons should be used with care as they will generate a lot of Database and network traffic.

2.6.3 View CRL Distribution Points The View CRL Distribution Points page lists the distribution points. The Current Size shows the number of certificates whose status can be checked via the distribution point. Update Period shows the configured CRL update interval. Last Update shows the issuing time of the latest CRL and Next Update shows the time of the next update marked into the current CRL.


36


Via the View log link you can see the log items related to the distribution point. View CRL link shows the current CRL in PEM format. The Generate CRL link can be used to manually trigger a new CRL generation.

2.6.4 Editing CA Auto Renewal Settings Automatic CA renewal means that a new CA private key is generated and a new selfsigned certificate is issued for the key. Also two additional certificates are issued: one for the old key signed with the new key and one for the new key signed with the old key. These certificates can be used to maintain trust relationship during the transition period when some of the clients are using certificates from the new CA key and some are still using certificates from the old CA key. The automatic renewal is established by enabling it and defining a margin time.

Figure 2-20 The CA renewal configuration page

By checking the Renewal enabled checkbox the automatic renewal is enabled for the corresponding CA.

Renew marginal is the time how much CA certificate has validity time left before the renewal takes place. The value can be given as days, e.g. 30d. Note: renewal marginal cannot be longer than ¼ of the certificate life time. Greater values are automatically adjusted.

Old CA certificate is the previous CA certificate. New with old is the certificate for the new CA key signed with the old CA key.


37


Old with new is the certificate for the old CA key signed with the new CA key. These last three input fields need not to be filled by the user and they are displayed only if CA certificate has been renewed. Inactive CA renewal Inactive renewal works the same way as normal renewal, except the resulting certificates are not taken into use. This means that the certificates are active and linked to the CA, but the CA still operates using the previous certificate and private key. To make certificates operational, the certificates must be activated. 









Inactive certificates must always be manually activated by the operator . They are not automatically activated even if the current operational CA certificate expires. The certificates are not published after inactive renewal. Publishing is done only when the certificates are activated. If the inactive renewal is done before the previous inactive certificates are activated, the new certificates will overwrite the previous. If the current operational certificate is expired, inactive renewal generates the new CA certificate but not cross certificates. Selecting Manual renewal will reset inactive renewal. Certificates generated with inactive renewal still exist, but they cannot be activated.

Figure 2-21 CA Renewal configuration with inactive renewal data

Inactive renewal information is shown in Edit CA Auto Renewal page inside Inactive renewal data box. By selecting Activate the certificates are taken into use. Note that this operation cannot be undone.


38


Inactive renewal can be enabled in automatic renewal by checking Inactive mode? Inactive mode in automatic renewal will work with the same renew marginal as normal automatic renewal. If inactive information exists, the automatic renewal interval is calculated using certificate created in inactive renewal. Otherwise interval is calculated using current operational CA certificate. SNMP notification “CA certificate expires” includes attribute which informs inactive mode state. If a CA is issuer to sub CAs, Renew sub(s) with inactive? option selects if the sub CA renewal will be issued using root CA's current operational certificate or certificate from inactive renewal. When enabled, the CA will issue sub CA certificates using its certificate from inactive renewal. When disabled, the CA will issue sub CA certificates using its current operation certificate. The latter is the standard way. Option will have an effect to all sub CAs under the CA. If the CA is not an issuer to any sub CAs, this option has no effect. Option does not affect normal certificate enrollment. End entity certificates are enrolled under the operation CA certificate until inactive certificate is activated.

2.7 Registration Authority Settings In Insta Certifier, an RA is in many ways similar to a CA. However, the RA creation is a bit different, since RA usually enrolls its certificate from a CA which is not running on the same installation. When using a remote CA (not running on the same installation) pre-requisities for RA creation are that: 



There is an online CMP connection to the CA. If Insta Certifier is running the CA, a CMP Service needs to be running on the Certifier Server instance. The CA has to have an automatic issuing policy for valid RA entities.



The CA administrator has issued a reference number and a key that the RA can use when performing the RA certificate enrollment. See Section 2.10.1 (Creating a Delegated RA Entity).



There is an External Enrollment Client Service running on the same server with the RA. This service is needed for performing the RA side of the RA-CA communication.

2.7.1 Creating a New Registration Authority New RAs can be created on the RA List page. To start creating a new RA, click the Create New RA button on the bottom of the RA list.


39


Figure 2-22 Registration authority

The main attributes of an RA are its name, description, and status. The RA name is a short internal name used mainly to identify the RA to the operators. Description should be a longer text that more precisely identifies the intended use of this RA. The RA Status is either Active or Inactive. RAs marked as Inactive cannot be used. Preliminary decisions concerning the certificate policy and publishing methods of the RA can also be done already on the Create New Registration Authority page. The settings are the same as on the Create New Certification Authority page. See Section 2.6.1 (Creating a New Certification Authority). Click Proceed to create the new RA.

2.7.2 Editing RA Settings To configure an existing CA, click the RA name on the RA List page. This will open the Registration Authority page. Many RA configuration options are identical with CA configuration options. There are, however, some differences. RAs do not publish certificate revocation lists, so an RA does not have any CRL settings. On the other hand, RAs need to have a connection to a remote CA, so there are additional settings related to the RA-CA connection.


40


Figure 2-23 The Registration Authority page

The first field, CA name, is a short and descriptive name that operators can easily identify. It does not have to match the subject name in the RA certificate. Description is a longer description viewed only by the operators. The RA Status is either Active or Inactive . RAs marked as Inactive cannot be used. RA Connection Configuration The RA field contains settings of the RA-CA connection. Enroll Client Service is the name of the External Enrollment Client Service used by this RA.

Connection Type indicates the method the RA uses to connect to the CA. Possible connection types are Local, CMP over HTTP connection, Write CMP to file, External command line, and No automatic connection. Local means using a CA within the same installation.


41








In case direct CMP connection is used, Connection Path is an HTTP URL of the CMP Service on the CA host. If the CMP request is written to a file, Connection Path is the file name. This option can be used, for example, if the CA is normally offline and batch-processes the requests at certain intervals. If external command line is used, Connection Path is the command line executed when communicating with the CA. The generated RA message is written to a temporary file and the %file tag on command line is replaced with its name.

Polling Interval is the time interval in minutes that the RA polls the CA for accepted certificates. Polling can be disabled by setting the interval to zero. RA message can be sent manually with the Send RA Message button. It will use current connection type and path to send the message. View RA Message button can be used to view the message in browser. Clicking the Insert CA Reply button opens the Process Offline CA Response page, where a PEM-encoded CMP message can be inserted to the RA. Remote CA Certificate shows the certificate of the remote CA. The certificate can be viewed by clicking View Certificate. The certificate can be changed by clicking Change. This is normally done automatically when RA certificate is enrolled. Certificate Publishing

Certificate Publish Method describes the current publishing method for certificates issued through the RA. The line shows the current protocol and server address, if applicable. The configuration can be changed on the Edit Certificate Publishing Method page by clicking the Edit Publish button. See Section 2.8 (Publishing Settings). RA Certificate The RA certificate can be viewed by clicking the View Certificate button on the RA certificate row. If the RA does not yet have a certificate, a certificate can be searched by clicking the Search button. An existing certificate can be changed by clicking the Change button. A new certificate can be enrolled by clicking the Enroll New Certificate button. This will also set connection parameters and remote CA certificate in RA configuration and commit the changes. For a detailed description, see Section 2.7.3 (Enrolling an RA Certificate). Other Options Changes made to the RA data can be updated to Database by clicking the Commit Changes button. The Edit Policy button will display the separate policy editing page where the policy of the RA can be viewed and modified. See document Policy chain and modules.

View Log shows all log events related to this RA.


42


Restarting Publishing Clicking the Restart publishing unpublished certificates button will search all active certificates issued through this RA that have pending or error as their publishing status. One by one, it tries to republish them. This is useful if many certificates have failed to publish correctly because of a network problem or misconfigured publishing information. The process is only started when this button is clicked and will continue in the background until finished. The Restart publishing all certificates button is similar, but will instead republish all active certificates of this RA. This can be used, for example, if the LDAP server has changed and all certificates need to be added again. Both of these two buttons should be used with care as they will generate a lot of Database and network traffic.

2.7.3 Enrolling an RA Certificate To enroll a new RA certificate Click the Enroll New Certificate button. This opens the New RA Certificate Enrollment page. If you are using CMP over HTTP connection as the RA-CA connection type and you have given the CMP URL on the RA page, the CA address will already be filled. Otherwise select the Enroll Client Service to use and give the CA Connection Address. Click Refresh to update the CA list and select the relevant CA. Fill in the Reference number and the Key of the delegated RA entity. You can also fill in the subject name of the RA certificate request in the Subject name field.

Figure 2-24 Enrolling the RA certificate

By default, a 1024-bit RSA key is generated. To change this, click Set Key Generation Parameters. This opens the Key Generation / Import page where you can edit the key attributes.


43


Click Proceed to start the private key generation and certificate enrollment. If the CA is set to issue certificates automatically for valid (RA) entities the certificate should now be displayed on the Registration Authority page under RA Certificate. If the request needs to be manually approved or the connection to the CA is slow, there will be a Poll Request button under RA Certificate and a note about the pending request.

2.7.4 Using a Local CA with RA To use a local CA, select Local as Connection type. This setting affects the RA functionality in the following ways: 



The new RA certificate request is processed as a request within the same Certifier instance where the RA is running. In other words, the RA’s own certificate is enrolled locally. When a certification request is addressed to the RA, it forwards the request after initial policy processing to a CA, which processes it again against its own policy. The CA can be selected by using a policy module Set Issuing CA in the RA’s policy. If the module is not used, the target CA will be the same that issued the RA’s own certificate.

2.8 Publishing Settings The CA needs a configuration that tells it how the CRLs and certificates are to be published. This is done with a generic publishing method configuration. The publishing methods supported by Insta Certifier are Lightweight Directory Access Protocol (LDAP) and HTTP. Also external methods can be plugged in the system and revocation status can be published through the OCSP protocol as well. To edit certificate publishing methods, click Edit Publish on the Certification Authority page. To add a new publishing method, choose the publishing method from the Add new method drop-down list and click Add. For certificate publishing, LDAP and External methods are supported. For CRL publishing, LDAP, HTTP, OCSP, and External methods are supported.


44


Figure 2-25 The Edit Certificate Publishing Methods page

2.8.1 LDAP Publishing Method For the LDAP publishing method, you need to choose a LDAP Publishing Service instance that is being used to perform the directory publishing. It is selected from the LDAP Server Connection list. Make sure that this Publishing Service instance is correctly configured and it has access to the LDAP directory. Note that LDAPv3 is recommended over LDAPv2 for its better security and compatibility between different implementations. CRL Distribution In LDAP publishing, the CRL distribution point can be included either as an LDAP URL or as a directory name. To actually include the CRL distribution point information in the issued certificates, the CA policy has to contain the Set CRL Distribution Point module.


45


Object Name Format The object name format is the path name used when adding the object to the directory. The correct format is a string containing literal characters and symbolic fields that are to be replaced with data from their respective objects. The format field names are written as %{name}. LDAP object name is a distinguished name and therefore must be structured as OID and value pairs. Most commonly used OIDs can be written using their symbolic names but they can also be given as numeric OID values. Very probably the certificates and CRLs should be published to exactly the location implied by the subject name of the certificate (or the issuing CA subject name in the CRL case). If this is not the case, various PKI clients will not be able to automatically perform certificate path construction or fetch peer certificates from the directory. This recommended setup is accomplished by specifying

%{subject-name} as the object name format. For non-trivial PKI or directory setups the object path name can be constructed piece by piece. For example, the following object name format string for certificate publishing would take the organization (O) from the subject name of the certificate issuer, the common name (CN) from the subject name of the certificate, and finally add the serial number of the certificate with a fictional OID 1.2.3.4.5.6.

C=FI, O=%{ca-subject-name:O}, CN=%{subject-name:CN}, OID.1.2.3.4.5.6=${serial-number} The supported special fields are the following: %{subject-name}

Replaced with the subject name of the user certificate (if any). Optionally a parameter can be appended to specify a RDN within the subject name. If the subject name is, for example, C=FI,O=Insta,CN=Test Person, the field %{subjectname:CN} will be replaced with the string Test Person. %{ca-subject-name}

Replaced with the subject name of the CA certificate. Optionally a parameter can be appended to specify a RDN within the subject name. For example, %{casubject-name:OU} will be replaced with the value of the OU field from the sub ject name (without the OU= part). %{entity:attribute}

Replaced with an attribute from the associated entity, if any. Only one attribute value is used even if the entity contains multiple attributes of the same type. For example, %{entity:email} will be replaced with the Email attribute of the entity. Valid attributes are ip, email, uri, upn, description, address, and phone. %{serial-number}

Replaced with a serial number from the associated certificate. In CRL publish method this is the same as ca-serial-number.


46


%{ca-serial-number}

Replaced with a serial number from the associated CA certificate. %{callback:function}

Replaced with the result of a policy callback function defined in policy.scm with function given as a parameter. This allows an extensible way to define object names. Same functions are also usable in LDAP attribute definitions. Usually the subject name is a good choice for the ce rtificate’s path name and the sub ject name of the CA certificate for certificate revocation lists. Note that the object path given here is expected to be in the same order as all other distinguished names in Insta Certifier. This order is then reversed before the name is sent to the LDAP client. LDAP Attributes LDAP stores data as attribute/value pairs. To maximize flexibility, the attributes can be configured very freely. Attributes can be added by selecting an attribute from the LDAP Attributes list and clicking the Add button. This will add a new row to the LDAP attribute table. The attribute table contains columns for attribute name, value, and type. Attribute Name is a string that identifies the attribute in the LDAP system. How the Value field is used depends on the type of the attribute. String Literal The value field is stored to the attribute as is. User Certificate By default, the entire issued certificate associated with the operation (if any) is stored to the attribute as binary data. This can be an end-user certificate or a subCA certificate, depending on the type of certificate that was issued. Alternatively, the serial number, validity period start or end, or Netscape comment extension of the certificate can be stored. CA Certificate The entire CA certificate (of the issuing CA) associated with the operation is stored to the attribute as binary data. Other values can also be stored as in the User Certificate case. CRL The certificate revocation list (CRL) is generated and stored to the attribute as binary data. Email Extension The Email subject alternative name extension field of the user certificate is used. DNS Extension The DNS subject alternative name extension field of t he user certificate is used. IP Address Extension


47


The IP subject alternative name extension field of the user certificate is used. Serial Number The serial number of the user certificate is used. User Subject Name The subject name of the user certificate is copied to the attribute. If Single RDN from user subject name is selected, only the named RDN value from the subject name is copied (without the tag part). For example, if the subject name is C=AS, O=Policy Application Inc., S=Grant + G=Prachi and the value is O, then the attribute will have the value of Policy Application Inc.. CA Subject Name As User Subject Name above, but the CA subject name (or one of its components) is stored. Entity Data String The specified data field is copied the from the associated entity data. For example, selecting Email copies the Email attribute from the entity to the given LDAP attribute. If the entity has several attributes of the same type, only the f irst attribute or all attributes can be selected. Use Policy Callback The value is given as a parameter to the scheme policy callback function and its result is stored to the attribute. Example functions provided in policy.scm include make-user-name

Takes either the CN or the G and S fields from the subject name and makes them a single name string. current-time

Replaced with current time value in 2001-10-21 20:15:30 format. set-certificate

The value is replaced with a binary certificate. In addition, the attribute name is replaced with cACertificate if the CA flag of the certificate is set. When publishing an object, the system first tries to search the object from the LDAP directory. If the object does not exist, the system performs an add operation with the given path name and attribute. If the object already exists, the system performs the publishing action selected for the attribute. The actions can be: 



Update by replace: The system tries to perform a replace-type modify operation. This means that previous values of the attribute are replaced with the new value(s), creating the attribute if it did not exist. If this f ails, the publishing attempt fails and the engine can either mark the publishing attempt as failed or restart the operation after a delay.

Update by add: The system tries to perform an add-type modify operation. This means that the new attribute value is added to the list of existing attribute values, creating the attribute if it did not exist. If this fails, the publishing attempt fails.


48




Initial add only: If the attribute already exists, the publishing attempt fails.

Default Publishing Schemas The LDAP publishing schema can be reset to default values by selecting a schema and clicking the Set button in the Reset to default box. The available default schemas for certificate publishing are: 

LDAPv2 pkiUser schema

 

LDAPv3 pkiUser schema LDAPv2 strongAuthenticationUser schema



LDAPv3 strongAuthenticationUser schema

The available default schemas for CRL publishing are: 

LDAPv2 pkiCa shcema



LDAPv3 pkiCa shcema LDAPv2 certificationAuthority shcema

  

LDAPv3 certificationAuthority shcema ActiveDirectory schema

RFC 2587, Internet X.509 Public Key Infrastructure LDAPv2 Schema, defines object classes for certain PKI objects. For certificates the standard defines the object class pkiUser, which can be configured in Insta Certifier by selecting LDAPv2 pkiUser schema under Reset to default and clicking Set. For CRLs the RFC defines multiple object classes, one of which is pkiCa. It can be configured in Insta Certifier by selecting LDAPv2 pkiCa schema under Reset to default and clicking Set. Note that both the pkiUser and the pkiCA are auxiliary object classes meaning that you have to use a structural object class with them. There are also common structural object classes containing attributes for certificates and CRLs such as inetOrgPerson and eidCertificationAuthority. Also these can be used when the directory schema supports them. Other Options Clicking the Commit Changes button will update the data into the Database and clicking the Cancel button will ignore the changes.

2.8.2 HTTP Publishing Method Insta Certifier includes a convenient way of publishing CRLs without the need for a full-scale LDAP deployment: The built-in HTTP server of the Web Enrollment Service can be used for CRL publishing. If you have chosen the HTTP publishing method for CRLs, the only sett ing that needs to be defined is the Web Enrollment Service instance that is being used for CRL publishing. Remember to enable CRL publishing in the Web Enrollment Service configu-


49


rations in order to be able to select it from the Web enrollment service connection drop-down list. As the server address is not always sufficient for external PKI clients to connect to the Enrollment Service, the URL prefix for CRL distribution points in Enrollment Service configuration must also be set to contain correct address and port information. For example, http://enroll.big-corp.com:8080/ is a valid setting. See Section 2.11.10 (Editing the Web Enrollment Service). To include the CRL distribution point information in the issued certificates, the publishing method has to have the Include in Certificates check box selected and the CA policy has to contain the Set CRL Distribution Point module.

2.8.3 OCSP Publishing Method The OCSP publishing method contains only the OCSP Responder Service that is used. All information about its address is configured in the service. Note that the Authority Info Access extension is added to the issued certificates only if the CA policy contains the Set CRL Distribution Point module and the publishing method has the Include in Certificates check box selected.

2.8.4 External Publishing Method To allow maximal flexibility in CRL and certificate publishing, Insta Certifier also supports external publishing. This method can be used either to write the published object into a normal file or to execute an external script. All types of external publishing are run in the Web Enrollment Service. This is important to remember when considering path names in external scripts and f ile names. The external publishing method can also be used to add arbitrary URI CRL distribution point extensions to certificates. On the Edit CRL Publishing Methods page, select the Include in Certificates check box and write the URI to URL to add text box. Now all certificates issued will contain that URL provided that the CA policy has the Set CRL Distribution Point module added. The external publishing method contains three action types. First of them is Just add the CRL distribution point extension. This options is available in CRL publishing only and it can be used if just the distribution point extension is needed in certificates. The Write to file action simply writes the object to a named file. The current working directory is the Certifier installation directory so it is usually a good idea to give absolute pathname for the file. File format controls the format of the file. The Run command action executes an external command to handle the object. Also in this case it is advisable to provide an absolute path to the command. Apart for command name the line can also contain parameters to that command. These are usually given as special fields that represent files containing the data to be published. Publishing Service then writes the data to temporary files and executes the command line with special fields replaced with file names. Supported fields in the command line are as follows: %cert


50


The certificate to be published. Either in PEM or binary DER depending on the File format setting. Ignored in CRL publishing. %crl

The CRL to be published. Either in PEM or binary DER depending on the File format setting. Ignored in certificate publishing. %ca

The certificate of the issuing CA, both in CRL and certificate publishing. Either in PEM or binary DER depending on the File format setting. %crl-url

Full CRL distribution point URL. Ignored in certificate publishing. %msg

Complete publishing parameters encoded as an ASL; contains the published ob ject, CA certificate and other configuration data.

2.9 Operators All persons who are allowed to operate Insta Certifier must have an operator account created for them. Operators are identified with a short login name and a password (if TLS client authentication is not used). However, in most situations the most crucial identification method is the operator’s TLS certificate. This certificate can be stored on the operator’s personal workstation, or on a crypt ographic token such as a smart card. If software storage is used, the security and the integrity of the used operating system is very important. Normally browsers can be configured to protect the private keys with a password when the private key is generated during web enrollment. Using this security feature is highly recommended. Note also that if the certificates used for TLS client authentication are stored in the workstation, an operator can login only from the specific workstation that stores the key. The aforementioned problems can be avoided by creating the keys on a smart card.

2.9.1 Adding Operators Any operator with super-user privileges is authorized to add new operators and to set their privileges. This can be done on the Operator page, accessed by selecting the Operators main menu option. To create a new operator, click the Create New Operator button located at the bottom of the screen. On the following page the operator’s attributes can be set before the operator is act ually created. The Login Name field is the short and unique login name that is used in login and identifying different operators in log event displays. It is customary that such names


51


are written in lower case and without spaces. However, note that the name is casesensitive.

Figure 2-26 Creating a new operator

There are two Password fields that are used as verification. The same password must be entered into both boxes. Password policy (requirements) are configured in system parameters page. Passwords have operator specific history of 20 passwords. Operator can’t use the same password again (until 20 password changes). The longer Operator Name field is provided for the complete name of the operator. This field is mainly used as a help for the other operators. The basic access rights of the operator can also be set ( Read only, Normal, Super user). The access rights can (and should) be f urther modified on the Operator page. See Section 2.9.2 (Editing the Operator Information) for more information on the levels. After this information is correctly set, the operator can create the new operator account by clicking the Create New Operator button. This will open the Operator page, where further editing can be done.

2.9.2 Editing the Operator Information On the Operator page the operator information can be edited and the password changed. Login and password information is required if only server authentication (not client) is used in TLS. Also the privileges can be defined here by an operator with su fficient privileges. New and changed operator passwords must be at minimum 8 characters long and include uppercase, lowercase and numeric characters.


52


Figure 2-27 The Operator page, the phone number and email attributes have been added

Operator Status The operator also has a status field which is normally in the Active position. By changing this to Inactive that specific operator can effectively be disallowed from u sing the system. Operators marked as inactive are not allowed to log into the system. If they are already logged in, they are not allowed to update anything.


53


Access Control Every operator has to have at least one access control item, defining what types of operations she is authorized to perform. Only super-user operators are authorized to modify access control items of other operators in the system. To add a new access control item, click the Add button. To remove or edit an existing rule, click either the Remove or the Edit button. Configuration Insta Certifier allows the GUI view of each operator or operator group to be customized. The UI Level can be set to Show All Options, Hide Super User Options, or to Simple Admin UI Only. If hiding super-user options is selected, only the menu options that relate t o entity and certificate management are shown. If Simple Admin UI is selected, the operator will use a simplified user interface that contains only the functions for creating and editing entities and revoking and suspending certificates. The Simple Admin UI is described in Insta Certifier Administrator’s Guide. Also the Character set used in the operator’s browser, the Timezone, and Time format can be selected here. If autodetect is selected as the Timezone, Insta Certifier uses the time zone information of the browser. The time values (e.g. certificate validity and issuing times) are displayed in the G UI according to the time zone setting. When entering time values in text boxes, use the time format specified for the operator without the time zone code (for example, 2003-01-23 09:45:41). Operator Attributes As is the case with entities, also the operator can have a dynamically changed set of attributes with additional information. Attributes can be added by selecting an attribute from the drop-down list and clicking Add. The available attribute types include Description fields, Address fields, and Email addresses. By default this information is not used in any way, but it exists to help the operators to identity and contact each other. If the operators require TLS client certificates, the entity attributes can be included in the certificates if a suitable policy module is used in the CA policy. Pre-Shared Keys and Certificates Operators may have pre-shared keys just like entities. Shared keys are used to authenticate operators when they are enrolling TLS client certificates for themselves. These certificates can be used to authenticate operators when they log in to the Administration Service. Passwords are not necessarily needed when TLS with client authentication is used. TLS with client authentication has to be defined on the Administration Service configuration page. See Section 2.11.2 (Editing the Administration Service).


54


Click the Add button in the Pre-shared keys box to add a pre-shared key for the operator. Provide the value of the Key field to the operator. The operator must give the key when enrolling a certificate through the Web Enrollment Service. The CA who is authorized to issue operator client certificates can be selected on the configuration page of the Administrator Service. Instruct the operator to select this CA during the enrollment. When the TLS client certificate is issued for the operator, this certificate is shown in the Client certificates of the Operator page. Committing Changes The Commit Changes button updates all changed operator data into the Database. Operator Logs The View Operator Change Log button shows all log events relating to this operator and the View Log button shows all log events that this operator has been involved in. So if one operator changes another operator’s phone number, that can be di splayed by clicking the first button, but if this operator accepts a request, that can be displayed by clicking the second button. Removing an Operator Click the Remove Operator button to remove the operator from the system. Be careful with this option, since removing an operator means that all operator certificates are revoked and the shared keys belonging to the operator are deleted!

2.9.3 Operator Access Control Levels An Insta Certifier operator has a set of access control rights, defining what kind of operations the operator is allowed to perform. These operations can be restricted for certain kind of operations (read , entity write, write, write and key recovery , and superuser ) and/or for certain CAs and RAs in the system. This enables adding administrators that are allowed to configure only one specific logical CA or RA in the system. Also, by using access control levels, lower and higher privileged operators can be added. Insta Certifier supports the following access control levels: Read access Read access for certain CA in the system means that the administrator is authorized to view any information related to the CA. However, this access control level does not allow any modification such as certification request approval, entity modifications or configuring. Read and revocation access This is as read access above, but in addition the operator can suspend and revoke certificates. The operator cannot reactivate suspended certificates. Entity write access


55


With entity write access the operator is authorized to modify entities in the system. These operations include creating new entities and modifying entity information. This means that the operator can update entity contact information such as phone numbers or e-mail address. The operator can also revoke certificates belonging to the entities. However, an operator with entity write access is not allowed to create shared keys or accept certification requests. Write access Write access allows editing entities, processing requests manually, and revoking and suspending valid certificates. This is an appropriate authorization level for operators who run the everyday CA/RA operations, but do not configure the system. Write and key recovery access Write and key recovery access allows the same actions as write access, but in addition the operator can access escrowed private keys. Note that this access level gives the operator access to sensitive information (user private keys), and should be given to operators only if they are required to do key recovery operations. Super-user access A super user is allowed to perform any operation related to specific CA. These o perations include modifying CA settings such as certificate policy and publishing schemas. As a super user has full control over the policy of the CA and access to escrowed private keys, this access level should be used only when it is necessary. Configuring servers and creating and updating other operators requires Superuser access to ALL CAs . Editing Access Control Items There are four drop-down menus in the Edit Access Control Item page. The first one defines the Access level as described above ( No access, Read access, Read and revocation access , Entity write access , Write access, Write and key recovery access , or Super-user access).


56


Figure 2-28 Editing an access control item

The second menu ( Target CA) can be used to select to which CA the access control is applicable. If the – ALL CAs – option is selected, the operator is authorized to access all logical CAs in the system. The third menu ( Rule scope) can be used to decide whether also subordinate CAs of the selected CA are included in the authorization. The fourth menu can be used to set additional Constraints that limit the operator’s rights only to those certificates or entities that match the given criteria. Two types of constraints can be used. These are Certificate/request field match and Entity attribute match . Both constraint types contain an additional selection, for the Certificate field and Entity attribute, respectively. To add a constraint, select the type from the list and click Add. Select the constraint from the list and enter the pattern to be matched in the text box. Several constraints can be added. To remove a constraint, click Remove next to it. Example: Email is selected as the Entity attribute constraint, and the pattern is the following: ˆ[email protected]$

The entity must have the Email attribute [email protected] for the operator’s access control item to match. Entity constraints are verified when the operator manages an entity and also when the operator edits a request or a certificate belonging to an entity. Certificate constrains are verified only when the operator manages a request or a certificate. The constrains are regular expressions and they are not required to match the whole string. For example, the constraint ’ Insta’ would match the string ’[email protected]’. If you want to match the whole string the pattern must be enclosed between the ’ ˆ’ and ’$’ characters (as in the example above).


57


See document Policy chain and modules for more information.

2.10 Delegated RA Entities The CA can delegate user registration (among other PKI management tasks) to specific registration authorities. This delegation can be performed using the Insta Certifier administration interface by adding so called delegated RA entities. A delegated RA entity is very similar to a normal entity in Insta Certifier. However, RA delegation typically has deeper implications to the PKI than just authorizing an end entity for a certificate.

2.10.1 Creating a Delegated RA Entity Click Delegated RA Entities on the main menu of the admin GUI. List of existing delegated RA entities is shown. Properties of the existing RA entities can be edited by clicking their names. New delegated RA entity can be added by clicking the Create New RA Entity button. The Create New RA Entity page opens.

Figure 2-29 The Create New RA Entity page

The entity name, shown in the administration user interface, and a freeform description can be specified in the RA Entity name and RA Entity description fields. Confirm the addition by clicking the Create button. The Cancel button can be used to cancel the operation. A delegated RA entity can have similar attributes to the end entities. An attribute can be added to the RA entity by selecting an attribute from the Attributes list and clicking Add. An attribute can be removed by clicking the Remove button on the right hand side of the attribute. Click Create to create the entity. This opens the Delegated Registration Authority Entity page where the entity can be further edited.


58


2.10.2 Editing a Delegated RA Entity

Figure 2-30 The Delegated RA Entity page

When the RA enrolls its own certificate using CMP, it needs a pre-shared key for authentication. A new pre-shared key can be added by clicking Add next to the Preshared keys box. The reference number and key need to be provided for the RA administration who is performing the RA certificate enrollment. After the RA has enrolled its RA certificate, it will be shown in the RA Client Certificates field of the page. A delegated RA entity should have access to a CA within the same Insta Certifier installation. The access control can be defined by editing the Access Control list. By default, the RA entity can request certification from any CA. Approval is subject to the CA policy. To view requests directed to this RA, click the View Requests button on the bottom of the page. To view certificates approved through this CA, click the View Approved Certificates button. (Clicking these buttons initiates a database search with appropriate search criteria.)


59


Once the entity data has been edited, changes can be taken in use by clicking the Commit Changes button on the bottom of the page.

2.10.3 Delegated RA Access Control Levels An Insta Certifier delegated RA has a set of access control rights, defining what kind of operations the delegated RA is allowed to perform. These operations can be restricted for certain kind of operations (enrollment , revocation, and key recovery and/or for certain CAs and RAs in the system. This enables delegated RAs to operate in multi CA environment. Also, by using access control levels, lower and higher privileged RAs can be added. Insta Certifier supports the following access control levels: Revocation access Revocation access for certain CA in the system means t hat the RA is authorized to revoke certificates issued by that CA. Revocation and enrollment access This is as revocation access, but in addition the RA is authorized to request certificates from the CA. Revocation, enrollment and key recovery access This is as revocation and enrollment access, but in addition the RA is authorized to do key recovery for certificates issued by the CA. Editing Access Control Items There are three drop-down menus in the Edit Access Control Item page. The first one defines the Access level as described above ( No access, Revocation access, Revocation and enrollment access , or Revocation, enrollment and key recovery access ).

Figure 2-31 Editing an access control item

The second menu ( Target CA) can be used to select to which CA the access control is applicable. If the – ALL CAs — option is selected, the RA is authorized (or denied when using No access) to access all logical CAs in the system.


60


The third menu (Rule scope) can be used to decide whether also subordinate CAs of the selected CA are included in the authorization.

2.10.4 RA-CA Communication Policy Delegated RA entities can have a policy for RA-CA communication. The processing of this policy takes place when a request arrives from a remote RA to the CA (the RA has already accepted the request). However, the policy is run only if the CA policy contains the Apply Policy Attributes (from Entity) module in the receive-request chain. See document Policy chain and modules. The RA-CA communication policy contains only the receive-request chain. The policy can be edited by clicking Edit Policy on the Delegated Registration Authority Entity page.

2.11 Certifier Servers and Services The modular architecture of Insta Certifier provides a flexible way to centrally manage the various PKI frontend interfaces and optionally distribute them to different hosts. This allows scalability for large deployments, but on the other hand, more limited PKI deployments can be easily implemented since only the required mandatory services need to be taken into use. In addition to the Certifier Engine, there needs to be at least one Certifier Server instance having at least one Certifier Service. In a small-scale deployment there can be just one Certifier Server instance running on the same host machine than Certifier Engine. In a large-scale deployment there can be several Certifier Server instances running on different hosts, and Certifier Engine running on a dedicated host.

Figure 2-32 The Server List page

The Server List page lists the Server instances of the system. During the installation one Server instance is created to provide the Administration and Web Enrollment Services. To add a new Server instance, click the Add New Server button. After this, you need to install the Certifier Server software to the host (see Insta Certifier Administrator’s Guide for instructions). To configure an existing Certifier Server instance, click the View Server button.


61


2.11.1 Creating a New Server Entity Creating a new Certifier Server instance is done in two steps: 1.

A new server entity is added to Insta Certifier. This server also needs to have a pre-shared key added to it.

2.

The actual server software is installed to the target machine from the Certifier Subordinate Server package. During the installation process you are prompted for the Certifier Engine address and the pre-shared key you created for the server entity.

See

Insta Certifier Administrator’s Guide for

more instructions.

After the new Certifier Server is installed and connected to the Certifier Engine it needs to be configured by adding at least one Certifier Service. The currently supported Certifier Services are: Administration Service CMP Service External Enrollment Client Service LDAP Authentication Service OCSP Responder Service Publishing Service SCEP Service Web Enrollment Service


62


Figure 2-33 The Create New Server Entity page

Note that to add a service to the system you probably do not have to add a new Server. You can just add the needed Service to some existing Server. This is a much easier process as you will not have to install a new Certifier Subordinate Server. Each of these services has a configuration, that defines the service-specific parameters. To edit an existing Certifier Service, click the Edit button next to the service entry in the Edit Server Entity page. To remove an existing service, click the Remove button next to the service, and then click the Commit Changes button in the bottom of the page. All operations, including editing a Certifier Service, need to be confirmed by clicking the Commit Changes button. Every Server entity has a status field, a name field, and optionally a description field. These are given in the beginning of the Edit Server Entity page. Server status can be Active or Inactive. Inactive server is temporarily out of use. To give new attributes to a Server entity, click the attributes in the Entity Attribute box, fill the text field, and click Commit Changes button on the bottom of the page. These fields are mainly informational. Every Server entity has at least one certificate, which is the TLS certificate used to secure the communication between the Server and Certifier Engine. In addition, some of the Services may have certificates. For example, the OCSP Responder Service needs to have a certificate in order to be operational. All certificates related to the Server entity are listed under Client certificates. If the CA that is issuing certificates


63


does not allow automatic issuing, the pending certificate requests are listed under Pending client requests. Services enroll and renew their certificates automatically. If a certificate needs to be changed, for example, to give it a more suitable name, it can be done by viewing the certificate and then Reissuing it. Then the service must be restarted and it will automatically fetch and use the new certificate.

Figure 2-34 Edit server entity

A server can also have a shared secret which it uses when setting up new Certifier Subordinate Servers. Normally a server needs only one pre-shared key and it can be


64


removed after the service is running. A server does not need a pre-shared key during normal operation and it can renew its certificate automatically. However if a service installation has been erased or if it has not been used for some time, it might have lost its certificate or the certificate might have expired. In order to reinstall the server, a new shared secret must be added to server entity. To view the server entity log or server entity requests, click the corresponding View Log and View Requests buttons. Server entities with similar configurations can be created by clicking Copy Entity button. The server entity can be removed by clicking the Remove Entity button. This operation should be used with extreme care.

2.11.2 Editing the Administration Service The Administration Service is a mandatory service in Insta Certifier, since it is used to provide the web-based administration interface for the administrators. An Administration Service is created as a part of the Certifier installation. It is recommended that instead of configuring the one and only Administration Service, a new service is created. The old one could then be removed, after the function of the new service has been validated. This is a precaution, to avoid a situation where the administrator has selected the security settings of the Administration Service, and cannot access the system any more since she has not enrolled an administrator certificate for herself. Also if there are problems in the administration configurations, similar problems may arise.


65


Figure 2-35 Editing the Administration Service configuration

Basic Settings

Service description is a free-form description of the Service and its function. Service status can be either Active or Disabled. If the service is Disabled, it does not perform its function. This option can be used to take the service temporarily out of use. The Service bind address is the address where the Administration Service listens to incoming HTTP and HTTPS connections. Remember to include the port number in the address. For example, http://0.0.0.0:8083/ is an address for a service running on the local host listening to port 8083. Note that the Service bind address needs to begin with http instead of https even if TLS is being used. Template Set and Access Level The Template set is the set of HTML templates used by this service. Unless new templates have been customized by the customer, only one template set is available ( Administration Interface). The template sets are located in the Insta Certifier in-


66


stallation directory under admin-templates/ (the default set is in the admintemplates/admin-html/ sub-directory). The Access level is the maximum operator access level through this Administration Service. If Normal Operators Only is selected, the Service allows write operations (this corresponds to operator Write access level). If Full Super User Access is selected, the Service allows all operations. Each operator has an access level as described in Section 2.9.3 (Operator Access Control Levels). If the operator has lower access level than the Service, the operator’s access level sets the limits. If the operator has higher access level than the Service, the Server’s access level sets the limits. That is, operators with super-user access can log in to an Administration Service that allows Normal Operators Only, but they are limited to Write access while using that Service. Security Settings The Security Settings option defines whether the HTTP server is protected with TLS or not. If Unprotected HTTP connection is selected, all connections between an administrator’s browser and the server are in plain text. By selecting TLS Protected HTTP connection, the server has a certificate that it uses for authentication. All connections are encrypted when using this option. However, the client (administrator) has to use a login name and password to authenticate itself to the server. When TLS with client authentication is selected, also the client has to have a certificate in order to connect to the server. If this mode is being used, administrator passwords are not mandatory, since the client private key is used for the authentication instead of password. You should also make sure there are no other Administration Services in the system that would allow login without client authentication. The CA that is used for issuing TLS server certificates has to be selected in the TLS Server Certificate CA field. Insta Certifier Internal CA, which is created during the installation, can be used, unless a dedicated CA is wanted for this purpose. In the latter case, the same CA that is used for a protected Web Enrollment Service can be used. See Section 2.11.10 (Editing the Web Enrollment Service). When the TLS settings of the Administration Service are turned on, the service creates a private key and enrolls a TLS server certificate for itself. Validity period length and Key size can be selected in the TLS Server Certificate Settings. The validity period will be included in the certification request. You can later re-issue the TLS server certificate with new parameters, for example, if you want to edit the certificate fields further, which is typically the case. When TLS protection with client authentication is used, Client Authentication CAs must be set. These are the CAs that are accepted for issuing TLS client certificates for connecting to the Administration Service. If all CAs are trusted, click Trust all CAs. If only some CAs are trusted for this purpose, click Trust only selected CAs, select the CAs from the drop-down list, and click Add. Or click Trust all except selected CAs, select the CAs that are not trusted for this purpose, and click Add. If TLS is used, Certificate status shows the status of the TLS certificate of the Service, and the certificate can be viewed by clicking View Certificate.


67


Commiting Changes Click the Continue button to accept changes made to the Service settings, or click Cancel to discard them. After clicking Continue, remember to Commit Changes on the Edit Server Entity page.

2.11.3 Editing the CMP Service Certificate Management Protocol (CMP) is an online certificate life-cycle management protocol that provides functions such as initial enrollment, certificate renewal, key update, and revocation request. Within Insta Certifier, CMP is used in the RA-CA communication. Also some PKI client applications use CMP to communicate with the CA. If there are RAs that connect to the Insta Certifier system or clients that use CMP, the system needs to have a CMP Service for providing the server-side functionality of the CMP.


68


Figure 2-36 Editing the CMP Service configuration

Basic Settings

Service description is a free-form description of the Service and its function. Insta Certifier : Reference Guide

69


Service status can be either Active or Disabled. If the service is Disabled, it does not perform its function. This option can be used to take the service temporarily out of use.

Service bind address is a mandatory field. The address is either an HTTP URL or a TCP URL, since CMP supports both transport mechanisms. Optionally, also Service domain name can be given (a fully qualified domain name). If the field is left empty, the name is generated from the Service bind address. Service domain name and Service description are shown on the web enrollment pages. Service domain name is also shown on the entity print page.

Deliver CA in field controls whether CA certificates sent to the client in CMP response are placed into a caPubs field or extraCerts field of the message. If caPubs field is chosen only the signing CA certificate is sent. If extraCerts is chosen the whole CA chain from the signing CA to the root CA is sent. Deliver CA dynamically enabled, CA delivery depends on the CMP request. If request includes CA certificates in extraCerts field, CA certificates are delivered in extraCerts. If CA certificates are in caPubs, CA certificate is delivered in caPubs. When option is disabled, delivery depends on Deliver CA in field option. Deliver root certificate in extraCerts (KUP) enabled the root CA certificate is included in KUR extraCerts field. When option disabled, KUR extraCerts included all intermediate CA certificates, but not the root. In short, when enabled, KUR extraCerts will not contain self-signed CA certificate. Options Protection hash algorithm selection can be used to specify which hash algorithm is used when calculating CMP message protection signature. The default auto option chooses the algorithm automatically based on the signing key size, but some client software may not support all hash algorithms. CA certificate delivery method in response These settings specify which CMP response message field is used for delivering the CA certificate. Allowed Operations The Allowed operations check boxes can be used to select the CMP operations that are allowed via the service. The following operations can be selected: Allow enrollment based on pre-shared secrets Allows certificate enrollment using pre-shared keys as the initial authentication method. Allow enrollment based on existing certificate (signature) Allows a certificate holder to request another certificate using the signature (with the key bound to the existing certificate) as the authentication method.


70


Allow revocation requests Allows a certificate holder to request revocation of an certificate using the preshared key (PSK). The PSK use count is not affected by this. Allow key update requests Allows requesting a certificate for a new key. The old certificate is used for authe ntication and a similar certificate is requested for the new key. Allow key backup Allows backing up a private key. Allow key recovery requests Allows an end entity to request recovery of a backed-up private key. The entity has to authenticate itself using another key bound to the same entity. Key recovery requests by an RA are allowed irrespective of this setting. Accessible CAs

Accessible CAs is used to define the CAs of the system that can be accessed via the Service. If all CAs can be used with the Service, click All CAs. If only some CAs can be used, click Only selected CAs, select the CAs you want to use with the service from the drop-down list, and click Add. Or click All except selected CAs and select the CAs that cannot be used and click Add. Commiting Changes Click the Continue button to accept changes made to the Service settings, or click Cancel to discard them. After clicking Continue, remember to Commit Changes on the Edit Server Entity page.

2.11.4 Editing the External Enrollment Client Service An External Enrollment Client Service is needed when an RA requests certification from a CA or when a CA requests a cross-certificate or a sub-CA certificate from an external CA. Every Certifier system that has at least one RA has to have an External Enrollment Client Service running on a Certifier Server instance. Basic Settings The only settings that are needed with an External Enrollment Client Service are the Service description and the Status of the service ( Active or Disabled). Commiting Changes Click the Continue button to accept changes made to the Service settings, or click Cancel to discard them. After clicking Continue, remember to Commit Changes on the Edit Server Entity page.


71


2.11.5 Editing the LDAP Authentication Service The LDAP Authentication Service is used for LDAP-based authentication in web enrollment and SCEP enrollment. During enrollment, the service can authenticate users based on their LDAP credentials (username and password).

Figure 2-37 Editing the LDAP Authentication Service configuration

Basic Settings

Service description is a free-form description of the Service and its function. Service status can be either Active or Disabled. If the service is Disabled, it does not perform its function. This option can be used to take the service temporarily out of use. LDAP Settings The LDAP Server Address and Port number specify the address of the directory server where the user credentials are stored.

LDAP Version is the LDAP protocol version used by the LDAP server. If the LDAP query is done via a firewall with a Socks server, this server address can be given in the Socks URL field (socks://..). Name Formats The Name Formats setting is used to define mappings between the username (sub ject name) given by the enrolling user and the actual record in the LDAP server and in the entity stored in Insta Certifier. The LDAP username format field defines the mapping to the username on the LDAP server and the Entity name format field to


72


the subject name of the entity. The format for these strings is the same as the format for Object Name Format in certificate publishing methods. See Section 2.8.1 (LDAP Publishing Method). To use LDAP authentication with web enrollment and/or SCEP, the Entity Mapping in the Web Enrollment Service or SCEP Service settings should be set to the correct LDAP Authentication Service. Commiting Changes Click the Continue button to accept changes made to the Service settings, or click Cancel to discard them. After clicking Continue, remember to Commit Changes on the Edit Server Entity page.

2.11.6 Editing the OCSP Responder Service The Online Certificate Status Protocol (OCSP) can be used to provide online certificate status information for the end entities within the PKI. OCSP can be seen as a replacement for CRL, and it may be a more appropriate method in environments where signatures of individual transactions need to be validated with up-to-date revocation information. The OCSP Responder Service of Insta Certifier can be used to answer clients’ status requests concerning one or more of the Certifier CAs. Currently the OCSP responder can provide status information only for those certificates that are issued by CAs that are managed within the Certifier installation.


73


Figure 2-38 Editing the OCSP Responder Service configuration

Basic Settings

Service description is a free-form description of the Service and its function. Service status can be either Active or Disabled. If the service is Disabled, it does not perform its function. This option can be used to take t he service temporarily out of use.

Service bind address is an HTTP URL, since OCSP uses HTTP as a transport mechanism. Allowed Operations If the check box under Allowed operations is selected, an OCSP client can request status information without signing the request. Certificate Settings The OCSP responder needs to have a private key and a certificate, so that end entities can validate the signed OCSP responses. Once the OCSP Responder Service is created, the private key is generated and the responder certificate enrolled. Select the CA from which the OCSP responder certificate is enrolled using the Responder CA field.


74


The validity period included in the certification request can be selected using the Validity period length field. The length of the OCSP responder private key (measured in number of bits used) can be chosen with the Key size option. External URL

External URL address is the URL that will be included in the authority information extension field of the issued end-entity certificates, if the extension is included in the CA policy. End entities will use this field to connect to the OCSP responder. This definition can be left empty, in which case the Service bind address field is used as a default value. However, please note that this address must be accessible from all clients using OCSP, so a different address might be wanted here. Certificate Status Once the certificate for the Service has been enrolled, Certificate status shows its status, and the certificate can be viewed by clicking View Certificate. Commiting Changes Click the Continue button to accept changes made to the Service settings, or click Cancel to discard them. After clicking Continue, remember to Commit Changes on the Edit Server Entity page.

2.11.7 Editing the Validation Authority Service The Validation Authority Service of Insta Certifier can be used to answer clients’ status requests concerning one or more of the Certifier CAs. Currently the Validation Authority service can provide similar information as the OCSP responder service. The difference is in the way that the certificate status information fetched and maintained by the service.


75


Figure 2-39 Editing the Validation Authority Service configuration

Basic Settings

Service description is a free-form description of the Service and its function. Service status can be either Active or Disabled. If the service is Disabled, it does not perform its function. This option can be used to take the service temporarily out of use.


76


Service bind address is an HTTP URL, since OCSP uses HTTP as a transport mechanism. Allowed Operations If the check box Requests without signature is selected, an OCSP client can request status information without signing the request. OCSP Response Generation Settings

Cache mode options are: Cache status only which means that certificate status cache is maintained and OCSP responses are generated and signed when requested. This is recommended option since it supports nonce in the responses which make it less vulnerable for replay-attacks. Create pre-signed response on first request means that an OCSP response is created upon first request and the response is cached and re-used. Fill with pre-signed responses in advance means that the cache is filled with responses at startup. In each case the status and/or responses are maintained based on the information in the Certifier database. Validation Authority Certificate Settings The service needs to have a private key and a certificate, so that end entities can validate the signed OCSP responses. Once the Validation Authority Service is created, the private key is generated and the responder certificate enrolled. Select the CA from which the OCSP responder certificate is enrolled using the Validation CA field. The validity period included in the certification request can be selected using the Validity period length field. The length of the OCSP responder private key (measured in number of bits used) can be chosen with the Key size option.

External URL address is the URL that will be included in the authority information extension field of the issued end-entity certificates, if the extension is included in the CA policy. End entities will use this field to connect to the OCSP responder. This definition can be left empty, in which case the Service bind address field is used as a default value. However, please note that this address must be accessible from all clients using OCSP, so a different address might be wanted here. Once the certificate for the Service has been enrolled, Certificate status shows its status, and the certificate can be viewed by clicking View Certificate. Accessible CAs The same service can provide status information for certificates enrolled from multiple different CAs. The accessible CAs may be selected. It should be noted however, that the responses are signed with a certificate from a single CA only.


77


Commiting Changes Click the Continue button to accept changes made to the Service settings, or click Cancel to discard them. After clicking Continue, remember to Commit Changes on the Edit Server Entity page.

2.11.8 Editing the Publishing Service If LDAP or external commands are used to publish certificates, CRLs or other entity data in the directory, then at least one Publishing Service needs to be added in the system. Publishing Service is not required when HTTP is used to publish CRLs. Publishing Service represents a connection to a specific LDAP directory. Publishing Service is also used for running external publishing commands. There may be more than one Publishing Service in a single Certifier Server instance, if several CAs publish to different directories, or if single CAs publish to several directories.

Figure 2-40 Editing the Publishing Service configuration


78


Basic Settings

Service description is a free-form description of the Service and its function. Service status can be either Active or Disabled. If the service is Disabled, it does not perform its function. This option can be used to take the service temporarily out of use. LDAP Settings The LDAP Server Address and Port number specify the address of the directory server (for example, directory.certificate.fi and 389, the default LDAP port).

LDAP Username and LDAP Password are normally also required for directory access. Permission to add and modify objects within the object hierarchy must be configured in the LDAP server for this user. LDAP Version is the LDAP protocol version used by the LDAP server. If the Server address for URL generation field is left empty, the Server address field is used in the CRL distribution point URL in certificate extensions. However, there might be several network interfaces in the directory server, and the one that the Publishing Service is using can be different than the one the end entities use when connecting to the server. In this case, the address that the end entities are going to use should be filled in the Server address for URL generation field. If the LDAP publishing fails, the Publishing Service retries the operation a certain number of times after certain time intervals. The retry count and time interval can be specified in the Retry and times with fields. If the publishing is done via a firewall with a Socks server, this server address can be given in the Socks URL field (socks://..). External Client If External Client is selected, Insta Certifier will generate an LDIF file of the publishing data and send it to an external command for further processing. The command line can be given in the text box. Security Settings LDAP publishing can be protected by TLS. T he relevant settings are made under TLS Settings. Select Use TLS server authenticated LDAP connection to take TLS in use. To search a trusted TLS CA certificate from the database, click Search. To insert an external certificate to the database, click Insert Certificate. See Section 2.12.4 (Importing a Certification Request). It is also possible to Use TLS client authentication. Client authentication eliminates the need for an LDAP password. Select the client authentication CA from the list.


79


References The References field shows the number of CAs that use this Publishing Service for publishing CRLs. The field is intended to warn the operator that removing the Publishing Service disables CRL publishing and may thus compromise the security of the PKI. If the Publishing Service is used only for publishing certificates (and not CRLs), the field will show: This service isn’t referenced by any CA . Certificate publishing (unlike CRL publishing) is not a critical feature for a properly functioning CA, and there may be a valid reason to remove a Publishing Service used only for certificate publishing, hence no warning is given. Committing Changes Click the Continue button to accept changes made to the Service settings, or click Cancel to discard them. After clicking Continue, remember to Commit Changes on the Edit Server Entity page.

2.11.9 Editing the SCEP Service Several VPN gateways and VPN clients support the Simple Certificate Enrollment Protocol (SCEP) for enrolling certificates from the CA. It is a simple online protocol, which provides means of getting a certificate to a VPN box such as router. SCEP Se rvice can be used to provide this service in Insta Certifier.

Figure 2-41 Editing the SCEP Service configuration


80


Basic Settings

Service description is a free-form description of the Service and its function. Service status can be either Active or Disabled. If the service is Disabled, it does not perform its function. This option can be used to take the service temporarily out of use.

Service bind address is an HTTP URL, since SCEP uses HTTP as a transport mechanism. Optionally, also Service domain name can be given (a fully qualified domain name). If the field is left empty, the name is generated from the Service bind address. Service domain name and Service description are shown on the web enrollment pages. Service domain name is also shown on the entity print page. Accessible CAs

Accessible CAs is used to define the CAs of the system that can be accessed via the Service. If all CAs can be used with the Service, click All CAs. If only some CAs can be used, click Only selected CAs, select the CAs you want to use with the service from the drop-down list, and click Add. Or click All except selected CAs and select the CAs that cannot be used and click Add. Entity Mapping is used to select the method used by the SCEP Service to map an entity to a request. If an LDAP Authentication Service has been defined, it can be selected. Otherwise only Pre-Shared Key can be selected. Commiting Changes Click the Continue button to accept changes made to the Service settings, or click Cancel to discard them. After clicking Continue, remember to Commit Changes on the Edit Server Entity page.

2.11.10 Editing the Web Enrollment Service The Web Enrollment Service can be used to provide enrollment pages for browserbased PKI clients. Default enrollment pages of the Web Enrollment Service include pages (designed for both MS Internet Explorer and Netscape Navigator) that can be used to generate private keys and post certification requests to the Web Enrollment Service. A PKCS #10 enrollment page is also off ered to enable submitting certification requests that are generated by other PKI clients. There are also some account management functionality that browser users can use to manage their own certificates.


81


Figure 2-42 Editing the Web Enrollment Service configuration


82


Basic Settings

Service description is a free-form description of the Service and its function. Service status can be either Active or Disabled. If the service is Disabled, it does not perform its function. This option can be used to take the service temporarily out of use. The Service bind address is the address where the Web Enrollment Service listens to incoming HTTP and HTTPS connections. Remember to include the port number in the address. For example, http://0.0.0.0:8080/ is an address for a service running on the local host listening to port 8080. Remember that the Service bind address has to begin with http instead of https even if TLS is being used. CRL Distribution Web Enrollment Service can be used to publish CRLs for end entities that use HTTP as an operational protocol to fetch CRLs. To enable this function, select Distribute CRLs for all accessible CAs. If a CA has a publishing method, which uses the Web Enrollment Service for HTTP publishing, and sets CRL distribution point in the issued certificate, the prefix of the CRL distribution URL can be given in the URL prefix for CRL distribution points field. This should be an URL containing scheme, host and port parts, ending in a slash. Note that the given URL must be accessible from all clients. For example http://enroll.big-corp.com:8080/ is a valid URL prefix. If the URL prefix is left empty, the service address is used instead. Security Settings The Security Settings define whether HTTP server is protected with TLS or not. If Unprotected HTTP connection is selected, all the connections between the browser and the server are plain text. By selecting TLS Protected HTTP connection, the server has a certificate, which it uses for authentication. All connections are encrypted when using this option. However, the client has to use login name and password to authenticate itself to the server. When selecting TLS with client authentication, also the client has to have a certificate in order to connect to the server. Client authentication has to be selected, if account management is going to be used. However, if this is the case, there should be another Web Enrollment Service running without TLS client authentication. New users, who do not yet have a TLS client certificate, could use that service to enrol the first certificate. The CA that is used for issuing TLS server certificates has to be selected in the TLS server CA field. Insta Certifier Internal CA, which is created during the installation, can be used, but it is recommended to have a dedicated CA for this purpose. The same CA that is used for a protected Administration Service can be used. See Section 2.11.2 (Editing the Administration Service). When the TLS settings of the Web Enrollment Service are turned on, the service creates a private key and enrolls a TLS server certificate for itself. Validity period length and Key size can be selected in the TLS Server Certificate Settings. The validity period will be included in the certification request. You can later re-issue the TLS server certificate with new parameters, for example, if you want to edit the certificate fields further, which is typically the case.


83


When TLS protection with client authentication is used, Client Authentication CAs must be set. These are the CAs that are accepted for issuing TLS client certificates for connecting to the Web Enrollment Service. If all CAs are trusted, click Trust all CAs. If only some CAs are trusted for this purpose, click Trust only selected CAs , select the CAs from the drop-down list, and click Add. Or click Trust all except selected CAs, select the CAs that are not trusted for this purpose, and click Add. If TLS is used, Certificate status shows the status of the TLS certificate of the Service, and the certificate can be viewed by clicking View Certificate. Accessible CAs

Accessible CAs is used to define the CAs of the system that are visible in the Web Enrollment Service. We might not want to have all CAs visible to every end user. Also it might be the case that CAs form certain groups that are dedicated to certain organizations. All organizations could have an own dedicated Web Enrollment Service, which would show only their own CAs. If all CAs can be used with the Service, click All CAs. If only some CAs can be used, click Only selected CAs, select the CAs you want to use with the service from the drop-down list, and click Add. Or click All except selected CAs and select the CAs that cannot be used and click Add. User Interface Options The options available on the web enrollment pages can be selected under User Interface Options. Selecting Generic shows most options on the enrollment pages. Selecting Restricted user interface shows only a limited number of options. The web enrollment pages can be further customized by clicking the Customize User Interface button. See Section 2.11.11 (Customizing the Web Enrollment Pages) for details. If the pages have been customized, the User Interface Options will display Custom UI. Entity Mapping

Entity Mapping is used to select the method used by the Web Enrollment Service to map an entity to a request. If an LDAP Authentication Service has been defined, it can be selected. Otherwise None or Pre-Shared Key can be selected. Commiting Changes Click the Continue button to accept changes made to the Service settings, or click Cancel to discard them. After clicking Continue, remember to Commit Changes on the Edit Server Entity page.

2.11.11 Customizing the Web Enrollment Pages When browser-based enrollment services are provided, the enrollment pages should be customized to reflect the image the CA wants to impose. For example, only those request fields that are relevant to the particular application should be shown to the user. Basic customization can be done easily via the Administration Service.


84


Sometimes, it may also be desirable to match the layout and graphics of the pages with the appearance of the site where the enrollment services are provided. While the administration GUI is seen only by a couple of operators, the enrollment pages may be visible to tens of thousands of end users. In this case, the actual HTML templates with the enroll prefix can be customized. The templates are HTML descriptions with a Scheme-based script which is used for customizing the pages on the fly. The basic customization options are described below. For information on customizing the HTML templates, contact Insta Certifier technical support (http://www.certificate.fi/).

Figure 2-43 Customizing the Web Enrollment Service

Account Management If account management is enabled, entities can log in the Web Enrollment Service with their accounts. After having logged in, they can view their certificates, revoke and renew them. Account Management can be disabled, allowed with TLS client au-


85


thentication, or allowed with TLS or password authentication. If account management is enabled, the security level of the Web Enrollment Service has to be set to match. Template Set

Template Set is the set of HTML templates used by the service. Unless new templates have been customized by the customer, only one template set is available (Web Enrollment Interface ). The template sets are located in the Insta Certifier installation directory under enroll-templates/ (the default set is in the enrolltemplates/enroll-html/ sub-directory). Account Registration If New Account Registration is allowed, a user can send registration information (including an e-mail address) through the Web Enrollment Service. Based on this information, Insta Certifier creates an entity and a pre-shared key for the user and sends the pre-shared key to the given e-mail address. This method is not cryptographically secure, but nevertheless may be useful in some cases. In addition to allowing registration on this page, the operator has to edit the lib/ssh-ca-notifyemail script to customize the e-mail sending. Revocation Options Normally, when account management is enabled, the users can revoke (or actually, suspend) their own certificates. However, Client Certificate Revocation can be specifically allowed or disallowed. If the option is disallowed, the users cannot suspend their TLS client authentication certificate used for logging in to the Web Enrollment Service.

Revocation with PSK can be disabled or allowed. This option is independent of account management settings. If the option is allowed, the users can suspend certificates bound to a specific pre-shared key (PSK). The PSK use count is not affected by this. Activating revocation with PSK requires that the Web Enrollment Service uses TLS protection. Enrollment Methods PKCS#10 enrollment and browser enrollment are available through the Web Enrollment Service. By selecting Hide PKCS-10 enrollment or Hide Netscape/IE enrollment under Enrollment Methods, links for PKCS#10 enrollment or browser enrollment, respectively, can be hidden. However, the enrollment pages are not disabled, and they can still be accessed by typing the page URL in the location bar of the browser. Character Set The Character Set used by the browser can be autodetected, asked from the user, or forced (UTF-8, ISO-8859-1, or ISO-8859-15).


86


Advanced Request Editing

Advanced Request Editing can be allowed or disabled. It is also possible to allow only advanced request editing. Internet Explorer Options Additional key options that are available on Microsoft Internet Explorer can be set under MSIE Key Generation . If a check box is selected, the corresponding option is shown on the MS IE enrollment pages. If the check box is cleared, the option is not shown to the user. For example, if the Allow key size selection option is cleared, and the Default key size is set to 1024, the user cannot select the key size when submitting the request but the browser will generate only 1024-bit keys. The following options can be selected/cleared: Allow CSP selection Allows the user to select the CSP used for key generation. The Default CSP can be entered in the text box. Select key protection Allows the user to change the Private key protection setting. Set key protection by default Sets Private key protection on. Allow key size selection Allows the user to select the key size. Default key size can be entered in the text box. Allow key store selection Allows the user to select the key store. Allow key type (KeySpec) selection Allows the user to select the KeySpec. The Default KeySpec can be selected from the list. See Section 3.3.2 (Browser-Based Enrollment) for more information on these settings. Request Elements The Request Elements that are available on the enrollment pages can also be modified. To add a new request element, select an element form the list and click Refresh. The element is added to the bottom of the page. The display order of the elements can be organized by using the Up/Down buttons or by selecting a new place number from the drop-down list next to the element and clicking Refresh.


87


Figure 2-44 Customizing the Web Enrollment Service

For subject name components, a default value can be given. To allow editing the value, select the Allow Edit? check box. To make a component mandatory in a request, select the Required? check box. Key usages can be selected to be on by default. Clearing the Allow Edit? check box prevents editing the requested key usages.


88


Click Continue to accept the settings and return to the Edit Configuration for Web Enrollment Service page. To take the settings in use, click Continue and click Commit Changes on the Edit Server Entity page.

2.12 System Configuration Miscellaneous settings are grouped under the System Configuration Menu.


89


2.12.1 Editing System Parameters


90


Figure 2-45 The System Parameters page

Engine-Server TLS Settings All communication between Certifier Engine and Certifier Server instances is secured with TLS to provide authentication, integrity, and confidentiality for the communications. This is especially important in largescale deployments where Insta Certifier functionality, such as CA signing functions, enrollment services and administration, are distributed to several hosts. One CA of the system has to be used as the internal authority who issues the TLS certificates for Certifier Server instances. Also the Certifier Engine needs to have an own TLS certificate which it uses for authentication when it connects to the Certifier Server. These parameters can be configured on the System Parameters page. To access this page, click System Configuration on the menu, and click the Edit System Parameters option. Select the CA that is used to issue the TLS certificates for Certifier components, in the Server CA field. The Insta Certifier Internal CA created during the installation is the preferred default choice. To view the CA settings, click Refresh and then click View CA. Note: Whichever CA is used, its policy should be Automatically issue requests for valid server entity, as the Certifier Engine and Certifier Servers need to renew their certificates in regular intervals to stay operational. To view Certifier Engine’s TLS certificate, click View Certificate button. You can also change it to another certificate by clicking the Change button, and then searching for another certificate-private key pair in the database. To issue a new TLS certificate with a new validity period and possibly new fields, click the Reissue Certificate button. Click the Commit button to take changes into use. Multi Approval Settings Multi approval is part of the dual admin control feature of Insta Certifier. By default, multi approval is disabled. Before activating the feature, make sure there are enough active operator accounts in the system. This is because adding a new operator under multi approval requires approval from a specified number of operators before the new operator can be added. Insta Certifier contains only one operator after the initial setup. When multi approval is in use, all add, modify, delete, and write operations except certain HSM-related operations require dual/multiple operator approval. To enable Multi Approval, select the corresponding check box. Enter the Number of Approvals needed before a change set can be commited. Select the Multi Approval Scope. If Multi approval required for system service configuration is selected, all system level operations (for example, new root CA creation, server and service configuration) require multi approval process.


91


If all CAs require multi approval, click All CAs require multi approval. If only some CAs require multi approval, click Multi approval for only selected CAs , select the CAs from the drop-down list, and click Add. Or click Multi approval for all except selected CA, select the CAs that do not require multi approval, and click Add. Click the Commit button to take changes into use. For information on how to handle change sets when multi approval is in use, see Section 2.12.2 (Viewing and Approving Pending Change Sets) .

2.12.2 Viewing and Approving Pending Change Sets All changes that have been selected to require multi approval create change sets. A change set contains one or more add, modify, or delete operations. The change sets can be viewed on the Change Set List page. To access this page, click System Configuration on the menu and click the Pending Change Set List option. Viewing a Change Set Click View next to the change set you want to review. This opens the Change Set page.

Figure 2-46 The Change Set List page

When an operator makes changes requiring multi approval, an additional link for Current Change Set appears in the main menu. After the changes have been made, the operator must self approve them. Clicking the Current Change Set option takes the operator straight to the Change Set page of the current change set. A change set can also be made ”current”, by clicking the Open button on the Change Set page. The Current Change Set link appears on the main menu. A current change set can be closed by clicking Close on the Change Set page. On the Change Set page, you can enter a Description for the change set. Click Save to save the description. The added, changed, or deleted object can be reviewed by clicking the number next to the listed change. The object is shown with a grayed ”page header” and ”footer” with additional info on the change set in the header.


92


Figure 2-47 The Change Set page

Approving a Change Set To approve the change set, click the Approve button. Commiting the Change Set After the required number of operators have approved the change set, it can be commited. Click Commit to make the change set active. After commiting, the changes take effect and the change set is removed from the pending change sets list. Removing the Change Set The change set can be removed by clicking the Remove button on the Change Set page. Doing this immediately loses the change set and all changes contained in it.

2.12.3 Cross-Certification When two independent CA hierarchies need to be connected or a sub-CA needs to be created, crosscertification is involved. In the case of independent PKI domains, two CAs may both issue CA certificates for each other. In the case of sub-CA creation, only one certificate is issued. Sending Cross-Certificate Request Click the Cross-Certification option in the System Configuration menu to open the Send Cross-Certificate Request page.


93


Figure 2-48 Searching for certificate requests

Type in some search criteria and click the Search button to see the list of certificate requests generated with Insta Certifier. Choose the correct certification request from the drop-down menu and click the Commit button. A cross-certificate request can be generated by clicking the Re-issue button on the CA certificate page. This operation will create a in the database a request that can be used in cross-certification. If CMP is used for cross-certification, External Enrollment Client Service needs to be selected in the Enroll Client Service list and the enrollment URL given in the corresponding field. In the case of CMP, a list of available remote Certifier CAs can be queried by using Refresh button. Also the reference number and key need to be filled in. These should be provided by the issuing CA operator. Click the Proceed button to initiate the CMP cross-certification.

Figure 2-49 Sending the cross-certificate request

If you want to use manual cross-certification, click the View PKCS10 Request button to view the certificate request. When performing manual cross-certification, the request needs to be copied and pasted to a file and then sent t o the CA. Insta Certifier : Reference Guide

94


2.12.4 Importing a Certification Request A certification request can be imported in a form of PKCS#10 data. This is done by selecting Import Certification Request from the System Configuration menu. Paste the request data into the PEM Coded Data field and press Proceed.

Figure 2-50 Inserting a certification request

2.12.5 Inserting a Certificate If CMP is not used in the cross-certification, but instead the PKCS #10 certif ication request is sent to the CA, the issued cross-certificate has to be inserted in the I nsta Certifier database manually. This can be done by selecting the Insert Certificate option in the System Configuration menu. There are two fields in the Insert External Certificate page. Click the Search button and select from the Associated Request field the request that corresponds to the issued cross certificate. The issued cross-certificate needs to be copied and pasted in base-64-encoded (PEM) format in the large text input field. Click the View Certificate button to see the contents of the issued cross-certificate. Insta Certifier : Reference Guide

95


Figure 2-51 The certificate can be pasted in the text input field

2.12.6 Importing a Private Key The Import Private Key option is used to import private key data to existing certificate. Private key data can either be a software private key in PKCS#1, PKCS#8 or PKCS#12 format or information about private key stored in hardware token and accessed through PKCS#11. In that case the import operation stored only access information to database, the key itself is not imported. Note that when a key is imported, the old private key data stored to certificate is removed and this operation cannot be undone. Also note that this operation only affects one certificate. Any other certificates with same private key data are unaffected. Key must be imported to them separately (or their keys removed) if old key data needs to be removed from database. One possible use for this feature is moving existing software key to hardware token. This is done by first exporting the key in PKCS#8 file through View Private Key and then importing it to the hardware token. The key can then used in Certifier by importing it back.


96


Import Private Key option automatically recognizes if a matching PKCS#11 private key is present. Please configure and insert the right token before starting the import operation. If no PKCS#11 key is detected, the user is given an option to import a software key instead. Software key import needs an base-64-encoded (PEM-encoded) private key file which is copied to Software private key input box. Private Key Format field can usually be left to default autodetect option, but in case Certifier has problems in decoding the private key selecting the precise format might help. Passphrase is needed when decoding encrypted private key files like PKCS#8 or PKCS#12 and is not used otherwise.

2.12.7 Creating Certificates The Create Certificate option allows creating a new certificate in the system. Clicking the button will open the Make New Certificate page, which is very similar to the regular request editing page. The buttons at the bottom of the page are different, as only the Proceed and Cancel buttons are available. This option can be used to create CA certificates, for example. See Section 2.6.1 (Creating a New Certification Authority). Most fields on this page correspond to those on the Certification Request page. See 2.3 (Processing Requests). Fill in data as necessary.


97


Figure 2-52 The Make New Certificate page - CA certificate

Validity period defaults to the current time. At least Not after should be changed to a later value. Key generation parameters can be adjusted by clicking Set Key Generation Parameters . This opens the Key Generation / Import page. On this page, Key Provider Type, Key type , and Key size can be selected. If a hardware security module (HSM) is used, additional settings are available. See Section 4.3 (CA Private Key Options). Clicking Continue will return to the Make New Certificate page.


98


After this, the selected key type and length are shown in the Public key field on the Make New Certificate page. The Signature algorithm field contains SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 algorithms. Definition sets the signature algorithm the CA uses to sign the certificate. The default value is SHA-1 when using RSA key type. For EC key type, the signature algorithm is automatically selected based on issuer key size. Selection is based on NIST recommendations (2011). The CRL distribution point extension is usually added to the certificate in the policy processing stage by the issuing CA. However, certificate creation through the Create Certificate option bypasses all CA policies. Thus, the CRL distribution point needs to be explicitly added when creating the certificate. Selecting From Issuing CA Configuration adds the CRL distribution extension to the certificate. Selecting Static URI allows a URI to be entered in the text box. Clicking the Proceed button will start the key and certificate creation. Creating a CA Certificate When the page is accessed from CA creation, some of the certificate attributes are pre-filled with usable default values. Also, two extensions are selected by default.

Basic Constraints must be set on all CA certificates with the CA flag set. The path length can be used to control whether this CA can issue other CA certificates. Path length is the maximum number of CA certificates that can be located under this certificate in path validation. Setting this value to zero means that this CA can issue only end-user certificates. Key usage is also defined with a few default bits. CRL Sign and Key Cert Sign must be defined in the CA certificate because it must be able to sign the certificates and CRLs it issues. If the Make New Certificate page was accessed from CA creation, clicking Proceed will return the operator to the CA creation page. Note, however, that key generation may take some time depending on key size.

2.12.8 Managing CRLs In the CRL management page CRLs can be downloaded as CSV file or deleted. Super-user access rights are required for both operations. CRLs are selected by search options. Select CA specifies the issuer for the CRLs, Issued after and Issued before are used to specify the time period when the CRLs were issued. The Issued after field is inclusive while the Issued before is exclusive. The time period is compared only the the issuance time and not the CRL validity times. The search never matches the latest CRL for any distribution point, i.e. the CRL that can be viewed via distribution point’s View CRL link is not in the exported CSV and cannot be deleted. By pressing Download CSV the CRLs matching the search criteria will be sent to the browser as a CSV file.


99


By pressing Delete from database the CRLs matching the search criteria will be permanently deleted from the database. Confirm delete must be checked in order to perform the deletion.

2.12.9 Managing Trust Anchors In the Trust Anchor (TA) management page Trust Anchor certificates can be viewed, deleted and uploaded. Super-user access rights are required for these operations. These TA certificates are trusted roots in case a CMP client authenticates itself with a certificate from external CA in CMP init message. This behaviour is specified in RFC 4210 E.7. In-Band Initialization Using External Identity Certificate. The list of Trust Anchors show the TA certificate subject and issuer fields, status, serial number and validity times. By clicking the subject name link a Trust Anchor page opens that allows you to change TA related settings. Editing TA Settings The TA configuration has an option Require CRL. When set, a CRL check is required when using the TA certificate for validation. If the CRL is required but not available, certificate validation against the Trust Anchor will fail. To add a CRL, it must be copied as a binary or PEM file into the directory var/pki/trust_anchor_crls under the Certifier installation directory. Certifier polls this directory and reads the CRL files from it. All successfully read files will be moved to var/pki/trust_anchor_crls/ok directory, and if the reading or CRL adding fails for some reason, the CRL file is moved to var/pki/trust_anchor_crls/failed. Successfully added CRLs are stored into the Certifier database, thus the f iles in ok directory are not required and can be removed.

CRL date field shows the CRL issuing time. Note that CRLs do not have an expiration time. Only the latest CRL added to the database will be used. CRLs that are issued earlier than the current CRL in the database are imported from the file system. CRL can be removed by clicking the Remove CRL button. Note however, that if a certificate has been checked against the CRL and marked as revoked, removing the CRL does not change the revoked status of the certificate. Partial or delta CRLs are not supported and only one CRL per Trust Anchor is used at a time. The CRL is used as long as it is not removed or replaced with a new. When adding a CRL, the issuing date is checked and only a newer CRL will replace the old one. Path validation If there exists a sub CA hierarchy between the Trust Anchor certificate and the end entity certificate used in signing the CMP initialization message, then the sub CA certificates should be included in the extraCerts field of the CMP message to enable certificate path construction and validation. When sub CA certificates are received, they are also stored along with the TA certificate. This means that the certificate path will


100


be validated even if further CMP messages will not include the correct sub CA certificates. The end entity certificate is also stored with the received request. This allows signature validation of CMP poll messages even if the certificate is not included in the poll message.

2.12.10 Changing the Master Password All Certifier software private keys are stored in encrypted format in the internal database. Also the PIN codes of the hardware security modules, if being used, are encrypted in the Database. Every Certifier installation has a master password, which is used to protect these objects. If the master password is lost, the whole PKI system may become inoperational, since the CA and RA software private keys (as well as other encrypted information) cannot be accessed any more. Therefore it is critical to be extremely careful when changing this password! After a new Insta Certifier installation, the password equals an empty string. This means that if encryption needs to be taken into use, one of the first steps is to enter the master password on the Change Master Password page.

Figure 2-53 The Change Master Password page

When the password is given for the first time, the current password field can be left empty. The new password needs to be given in the Enter new password field and confirmed again in the Same again field. Check or uncheck the option Store new password. When checked the new password will be stored into the database in encrypted form. This way Certifier can start automatically without asking the password from the user at start-up. Click the Commit button to take the new password in use, or Cancel to abort the operation. Entered master password must apply with configured master password policy. Master password policy is defined in system parameters.


101


After the master password has been taken in use, it has to be given to Insta Certifier every time the Engine is restarted - otherwise signature operations will not be possible. However, if the password is stored into the database, it will not be asked. There are two ways to pass the master password to the Engine. The master password can be specified on the command line when the Engine is started, or it can be provided in the Administration Service by an administrator. After operator login, the master password field is prompted and the operator can type in the master password. Note: in some operating system versions the boot-up screen is interactive. In such cases the master password is asked also at reboot (if not stored to database). However, the interactive screen may not be visible by default and may lead to system hang. To prevent this, the interactive screen should be made visible (e.g. by clicking esc-key, or clicking “show details” depending on the OS).

2.12.11 CA Passphrase Clicking the Show CA Passphrase Status lists all CAs with keys stored in hardware tokens that need PIN codes. These CAs aren’t available until their passphrase have been given through this page.

2.12.12 User-Defined Policy Modules Custom policy modules can be created under User Defined Policy Modules. The custom modules are essentially macros that consist of other policy modules. To create a new custom policy module, click Add. Give a suitable name for the module and select the policy chains in which the module is allowed. The name cannot contain dot (’.’) or slash (’/’) characters. Click Edit to edit the custom module. You can add policy modules to the custom module as if you were editing a normal policy chain. The policy chains in which the custom modules are allowed are the following. receive-request The Receive Request chain. accept-request The Accept Request chain. view-request The View Request chain. update-request The Update Request chain. psk PSK-specific policy chains. See Section 2.4.4 (Adding Policy Module Attributes). entity Entity-specific policy chains. See Section 2.4.4 (Adding Policy Module Attributes).


102


conditional test Test clauses (IF, ELSE IF) of the Conditional policy module. See document Policy chain and modules.

2.12.13 Viewing System Configuration Clicking Show System Configuration shows a plain-text summmary of the Insta Certifier system configuration.

2.12.14 System Shutdown The Certifier Engine can be temporarily shut down, for example, during maintenance. To shut down the engine, click System Shutdown. You will be prompted for the estimated restart time. Click Continue to proceed with the shutdown.


103

Chapter 3: Certificate L ife-Cycle Management Services

Chapter 3

Certificate Life-Cycle Management Services In Insta Certifier, all end-entity actions are performed via Enrollment Services running on Certifier Server instance(s). These services perform the message-transport-related server-side functionality of certificate enrolment or certificate life-cycle management. There is a dedicated Certifier Service for each protocol: 

 

SCEP Service for enrollment services for VPN applications such as routers and software clients. CMP Service acting as a certificate life-cycle management server. Web Enrollment Service for a web-based enrollment interface.

Each of these services does a protocol level verification to the request before the request is passed on to be handled by CA policies. The requests are checked to be formally and cryptographically correct, and in case of CMP, the CMP protection is verified either by using a pre-shared key or a certificate. If the request passes requirements of the protocol, then it proceeds to CA policy checking.

3.1 CMP Service The CMP Service provides the PKI certificate life-cycle management capabilities. The CMP Service acts as a server for handling incoming CMP messages (including certification requests and revocation requests). The CMP Service can be configured to pr ovide either TCP or HTTP-based transport for the Certificate Management Protocol (CMP). The CMP implementation of Insta Certifier is based on RFC documents RFC4210 and RFC4211 also known as CMPv2. The CMP messages currently supported in the CMP Service are:        

Initial request Certification requests signed by an initialized end entity Key update request Revocation request (according to error message: hold or revoke) Key recovery request PKCS#10 request Polling request General message for fetching CA key update announcements


104


In CMP, an end entity needs to send an initial request when the first certificate is enrolled from a given CA. Consequent certification requests can be signed with the valid private key to facilitate automatic key renewal. Revocation requests can be used to i nform the CA about the need to revoke a certificate. The default port in the CMP Service for CMP on TCP is 829. For HTTP transport the URL is http://host:8080/pkix/. These parameters can be modified by editing the CMP Service via the Certifier Administration Service. See Section 2.11.3 (Editing the CMP Service). The communication between RAs and CAs of Insta Certifier uses CMP. Also Insta Token Master, whether used as an RA or end entity, uses CMP for requesting certificates from the CA or RA. Insta Certifier ships with a simple command-line utility that supports the client side of the corresponding server-side functionality of the CMP Service. It can be used to generate private keys and performing enrollment, key updates and revocation requests. For more information, see document Command Line Interface.

3.2 SCEP Service The SCEP Service handles the server side of the Simple Certificate Enrollment Protocol (SCEP). The SCEP protocol is described in the Internet-Draft document draftnourse-scep. SCEP uses HTTP as the transport protocol. By default, the SCEP Service listens to the incoming SCEP messages on port 8080. The port can be modified via the Certifier Administration Service. See Section 2.11.9 (Editing the SCEP Service). The default enrolment URL for SCEP client is thus http://host:8080/scep/. These parameters have to be configured in the enrollment client which is typically a VPN client or a VPN gateway. A prerequisite for SCEP enrollment is that the end entity has to have the appropriate CA certificate, which must have been verified using some offline method (fingerprint check). The verifications should be done to prevent man-in-the-middle attacks, in which someone is impersonating the CA. The CA certificate can be retrieved from the SCEP Service by an HTTP GET operation. In addition to the enrollment URL the end entity needs to know the name of the CA that identifies it within the Insta Certifier installation. This is needed since there may be several CAs providing SCEP within a single Certifier installation. The name that is used to identify CAs in SCEP implementation of Insta Certifier is the CA name given in the administration interface and is shown in the CA List page of the GUI (the subject name of the CA certificate is not used for this). The initial end-entity authentication in SCEP is achieved either manually or by using shared secrets. When using a pre-shared secret scheme, the Insta Certifier administrator generates a pre-shared key (a password string) for an entity. The key is distributed to the entity in a secure way. When the certification request is generated, the shared secret is then used as a challenge password inside the request. The SCEP Service forwards the encrypted certification request to the Certifier Engine, which finds the policy bound to the preshared key and processes the request according to the policy. When using manual authentication, the end entity calculates the MD5 fingerprint on the generated PKCS #10 certification request. When the Certifier Engine receives the request from the SCEP Service, it stores the request in the Database as a pending


105


certification request. Later the end entity has to manually authenticate itself to the Insta Certifier operator with this fingerprint. The operator then compares it to the one found in the Database. If they match, the operator manually approves the certification request. The client can poll the issued certificate from the SCEP Service after this. As the PKCS#7 request payload containing the PKCS#10 request is encrypted using the CA/RA’s public key, no one else but the end entity and the CA/RA can know the fingerprint, and thus we know that the request is legitimate. (The end entity as we now know, has access to the private key, whose public components are inside the PKCS#10). When the SCEP is performed between an end entity and an RA, the end entity needs also the RA certificate in addition to the CA certificate. So when the RA certificate is fetched by the end entity, also the CA certificate is sent in a PKCS#7 envelope to the end entity by the SCEP Service. This RA certificate can be used for both encryption and authentication in the enrollment.

3.3 Web Enrollment Service In Insta Certifier, web-based enrollment services for Internet browsers are provided by the Web Enrollment Service. The default HTML template files that are shipped with Insta Certifier provide web forms for posting certificate requests, scripts that enable browsers to perform the key generation, and a web page that can be used to download CA certificates and CRLs. TLS is also supported to provide additional confidentiality and optionally client authentication in the web enrollment. The following sections explain the different ways to do the certificate enrollment with a browser and the related services.

3.3.1 PKCS#10 Enrollment Web-form-based PKCS#10 enrollment is the simplest enrollment option supported by Insta Certifier. However, it requires more manual work than SCEP and CMP. Most of the VPN end-entity applications and devices support this method if they do not include an SCEP client. In this enrollment method an end entity generates a key pair and a base-64-encoded (PEM-encoded) PKCS#10 certification request in a file. The PKCS#10 request is then pasted in the web form and submitted to the Web Enrollment Service. The Enrollment Service then parses the request and forwards it to Certifier Engine, which performs the policy processing (ending in approval or denial). Shared secrets can be given in the web form to enable automatic user authentication, in that case, however, TLS has to be enabled to provide confidentiality. If the policy requires manual administrator approval, the user needs to download the certificate later after it has been approved. Insta Certifier offers a default HTML page enroll-form-start.html for PKCS#10 submitting.


106


Figure 3-1 PKCS#10 enrollment form

Several client applications generate a text file containing the PKCS#10 request after the key generation. The PKCS#10 request looks something like the following example: -----BEGIN CERTIFICATE REQUEST----MIIBwjCCASsCAQAwYjEQMA4GA1UEBhMHRmlubGFuZDEoMCYGA1UEChMfU1NIIENvbW11bmljYXR pb25zIFNlY3VyaXR5IEx0ZDENMAsGA1UECxMEVGVjaDEVMBMGA1UEAxMMMTkyLjE2OC4yLjQ2MI GdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKBgQC3RCZScukV5VacEv7t2dlbCNaFUI8c+WkqQZOBH l88eYPSjImxK4sF/6siNT5596X/LTSbImlLta56K3FbsYDmOuR6OFT6TVgi909z2jIcgn0c3JjR enn87thTu9ZXYJApt6+/ENSC0PtXcwwXvbNEn79D29o90Szgk8w+/dRZxQIBJaAiMCAGCSqGSIb 3DQEJDjETMBEwDwYDVR0RBAgwBocEwKgCLjANBgkqhkiG9w0BAQQFAAOBgQBsjd4qSie3Iycqff OI7uMHziZgHX0MMugVzJArlgtmM/Z7E8jeoB2v8ghLLEqFMvLLx+1vDkGgaJM52OZkC6VBT1YJg XRVOpeJEI8B21yATN/yI/2H6tEzodODQ1IZuFtkNvgI2I9JWKNAXUkpxAoi2ot4tPqzMOrPe4qu A1m7Nw== -----END CERTIFICATE REQUEST-----

When this string is pasted to the enrollment form and submitted, a request will be processed in Engine. If Engine cannot automatically issue the certificate, a polling ID is given to the end entity. This id can later be used for polling the issued certificate. The default polling page in the Web Enrollment Service is enroll-poll.html.

3.3.2 Browser-Based Enrollment Insta Certifier allows client-side enrollment to be performed using the most popular web browsers, Microsoft Internet Explorer, Firefox and Opera.


107


Firefox and Opera support the HTML tag keygen, which is used for generating key and certificate requests (using Netscape’s proprietary format). When a form contai ning the keygen tag is posted, the browser will generate a key pair, wrap the public key inside a request, and post the result. The key pair is stored in the encrypted key storage (PKCS#12 format). The request is submitted to the Web Enrollment Service, which parses it and forwards it to Certifier Engine. If the certificate approval is configured to be automatic, theWeb Enrollment Service pushes the issued certificate to the browser to be installed. If the request has to be manually approved, it can be downloaded later, using the request identifier issued by the Certifier Engine, and displayed to the end entity instead of the certificate. When using Internet Explorer, a Microsoft ActiveX control ( xenroll.dll) can be used to perform the client-side enrollment, including the key generation. The control provides a scriptable interface for this. The most relevant functions of the interface are CreatePKCS10 and acceptPKCS7. The CreatePKCS10 function creates a private key in the Windows registry and a base-64-encoded PKCS #10 request, which can then be posted to the Enrollment Service. When the Engine has issued the certificate, it can be installed to be used by Windows client applications such as IE and Outlook Express, by using the acceptPKCS7 function. Enrollment Forms The default forms for Firefox and MS IE enrollment in Insta Certifier are enroll-nsstart.html and enroll-ie-start.html, respectively. The options available on these forms depend on the customization settings of the Web Enrollment Service. See Section 2.11.11 (Customizing the Web Enrollment Pages). The default options are described below.


108


Figure 3-2 Default enrollment page for Internet Explorer in the Web Enrollment Service

The web forms request the user subject name components Common Name, Organization Unit, Organization , and Country . Common Name is mandatory, the other components are optional. Optionally the user may enter subject alternative names, such as an Email address, an IP address, or an URI, if the certificate is to be used in an environment where these are required. The user may also request a key usage extension for the certificate. The extension can include the Digital Signature, Key Encipherment, and Data Encipherment key usages. The Email Protection, IKE Intermediate, Client Authentication , Server Authentication, Code Signing, OCSP Signing, and Time Stamping extended key usages can also be selected. The necessary extensions depend on the intended use of the certificate. For example, when requesting a certificate for S/MIME use, the Email Protection check box should be selected in the request form. The Certification Authority from whom the certificate is requested has to be selected in the web form. Only those active CAs that are included in the Accessible CAs list can be chosen.


109


If the Web Enrollment Service connection is TLS protected, also a pre-shared key can be given in the enrolment form to enable automatic certificate issuing. This field is not shown in the web enrollment page without TLS, since pre-shared keys should not be sent as plain text. The Key size of the private key should also be selected. Additional Private Key Options (MS IE only) With Microsoft Internet Explorer, additional Private Key Options are available. The user can select the cryptographic provider (CSP) to use for key operations. The available providers depend on the Windows version. If cryptographic tokens, such as Aladdin eToken, have been installed to the system, the token specific providers will also be available. Selecting a token-based provider will generate the key pair securely on the token. With IE, the user can also select the certificate store type, either current user or local machine (for Windows IPSec and L2TP). As the names imply, the first store is used for storing personal certificates (for e-mail and TLS) and the latter for storing machine-specific certificates. With IE, the user can also select to use Private key protection. Selecting this check box will cause Windows to prompt for security level of the key. 





High security will protect the key with a password, which will be asked every time the key is used. This is a suitable setting if the key is used for non-repudiation signatures, but may be cumbersome if the key is used for TLS or IPSec authentication. Medium security level (default if private key protection is selected) will ask for confirmation every time the key is used. This setting is suitable for S/MIME use, for example, but again may slow the operation unacceptably if the key is used for TLS or IPSec. Low security level (default if private key protection is not selected) will not require confirmation from the user when the key is used.

Advanced Request Editing If allowed by the Web Enrollment Service settings, the Advanced Options button is shown on the browser enrollment page. Clicking this button immediately begins key generation. After the key has been generated the advanced editing page opens. The layout of this page is similar to the certification request processing page.


110


Figure 3-3 Advanced request editing

The following fields can be edited: 

Subject name Validity period



Extensions, see Section 2.3.8 (Certificate Extension Fields)



Pre-shared key



Note, however, that the processing of these fields is totally up to CA policy. After editing the fields, the request can be sent by clicking Submit Request. URL Options Optionally the pre-shared key, key size, the cryptographic service provider (Internet Explorer only) and other parameters can be given in the URL when either the enroll-ie-start.html, enroll-ns-start.html or simple-enroll.html page templates are used. Use the ’?’ character in between the template name and the parameters, and the ’&’ character between the individual parameters.


111


All options just set the default values in the form. The corresponding selections are still shown to the user and they can be manually edited. The supported parameters for enroll-ie-start.html are: 

psk : Sets the pre-shared key in the form.



ca : Default CA, given as object id (for example ca=12)



keysize : Default key size



csp : Default CSP name, or Microsoft%20Enhanced%20Crypto)



protect : Set to no to turn the USER_PROTECT flag in key generation off. Lowers security but can be useful in some cases.



c : C component in distinguished name (DN)



o : O component in DN



ou : OU component in DN



cn : CN component in DN



email : E-mail subject alternative name



dns : DNS subject alternative name



ip : IP subject alternative name

a

part

of

it

(for

example

The supported parameters for enroll-ns-start.html are: 




ca : Default CA, given as object id (for example ca=12)



c : C component in distinguished name (DN)



o : O component in DN



ou : OU component in DN



cn : CN component in DN



email : E-mail subject alternative name



dns : DNS subject alternative name



ip : IP subject alternative name

These are the same options as in enroll-ie-start.html, except that csp, protect, and keysize are not available. Key size cannot be set in URL because it is done in the keygen tag in Netscape. The supported parameters for simple-enroll.html are: 

keysize : Default key size



csp : Default CSP name, or Microsoft%20Enhanced%20Crypto)



protect : Set to no to turn the USER_PROTECT flag in key generation off. Lowers security but can be useful in some cases.



storetype : Sets the key store, either current-user or local-machine. Defaults to current-user.

a

part

of

it

(for

example

The supported parameters for simple-form-enroll.html are: 



112


The supported parameters for enroll-form-start.html are the same as in enroll-ns-start.html. In addition, the pkcs10 parameter is supported for setting the PKCS#10 request. The following URLs are examples where one or more of these parameters are given in the URL. https://pki.certificate.fi:8081/enroll-iestart.html?keysize=2048&psk=ssh&csp=Microsoft%20Enhanced%20Cryptographic%20Provi der%20v1.0 https://pki.certificate.fi:8081/enroll-ns-start.html?psk=1234

3.3.3 Downloading CA/RA Certificates and CRLs Both CA and RA certificates, and the CRLs can be downloaded from the Certification Authorities page (enroll-ca-list.html) by clicking CA List in the main menu of the Web Enrollment Services. All the CAs and RAs, whose statuses are not Private and are included in the Accessible CAs list in the Web Enrollment Service configuration, can be viewed in this page. The following buttons can be found under each CA/RA entry: View Certificate as PEM The CA/RA certificate can be viewed in base-64-encoded format (also known as PEM, privacy enhanced mail encoding). Certificate can be installed in the root CA storage of Windows by opening this file with Internet Explorer and choosing Install in the certificate viewer dialog of W indows. View Certificate The CA/RA certificate details can be viewed with the Insta Certifier’s web -based Certificate Viewer by clicking this button. The certificate can be downloaded in binary format by clicking Download Certificate in the bottom of this web page (some web browsers require user to click right button of the mouse and to select Save). Download Certificate With Netscape Navigator, the CA can be installed by using this option. Clicking this button will start the New Certificate Authority wizard of Netscape Navigator. Download CRL The current CRL of the CA can be downloaded in binary format by clicking this button (some web browsers require user to click right button of the mouse and to select Save). Download CRL as PEM The current CRL of the CA can be downloaded in base-64-encoded (PEM) format by clicking this button (some web browsers require user to click right button of the mouse and to select Save).


113


3.3.4 Managing User Certificates The Web Enrollment Service can be configured to allow account management capabilities for end users including suspension of the user certificates. These services require TLS-protected web enrollment connections. Also, account management has to be specifically enabled in the Web Enrollment Service configuration page. See Section 2.11.11 (Customizing the Web Enrollment Pages). Password or TLS client authentication can be used for logging in to the accountmanagement-enabled Web Enrollment Service. If password authentication is used, the Email address and Account Password attributes of the entity are used in authentication. See Section 2.4.1 (Adding Entities). If TLS client authentication is used, a pre-shared key needs to be generated for an entity by a Certifier operator. See Section 2.4.3 (Adding and Modifying Pre-Shared Keys). This key has to be distributed to the user and the user has to enter it in the web enrollment page. Remember that TLS protection is needed for confidentiality when shared keys are used in the enrollment. In effect, using TLS client authentication requires setting up two Web Enrollment Services, one for requesting the TLS client certificate and another for the actual account management. When the certificate is issued, it is associated to the entity and can be used to log in to the Web Enrollment Service. Registering a New Account If allowed by the Web Enrollment Service, a user can send registration information (including an e-mail address) through theWeb Enrollment Service. Based on this information, Insta Certifier creates an entity and a pre-shared key for the user and sends the pre-shared key to the given e-mail address. Clicking the Register menu item on the main page opens the Register New User Account page. On this page the user can give a name, e-mail address, and password for the user account. The information is sent to Insta Certifier when the user clicks the Submit button. Enrolling New Certificates for the Entity When a user has logged in using an account, he can make certification requests which can be approved automatically based on the valid user entity. Note, however, that if the CA policy has been set to issue certificates automatically for valid entities, the certificate is issued regardless of any PSK use count. If this needs to be limited, the correct option is to use the Automatically issue with valid PSK policy module. Your Account The Your Account main menu item available when the user has logged in the Web Enrollment Service using an account. Clicking the menu item displays all pending requests and issued certificates of the user. All of the certificates may not be stored in the certificate storages of the browser (such as PKCS#10 enrolled VPN certificates).


114


But also these certificates can be viewed if they are associated to the user entity with pre-shared keys. A certificate can be viewed in detail by clicking the View Certificate button. On the Certificate page, the certificate can be suspended by clicking the Revoke button. This should be done if the user suspects that someone may have a copy of t he private key. If the certificate that is used for TLS client authentication is suspended, even the user cannot log in any more. Note that instead of revocation, the certificate is actually suspended. From the user’s point of view, this is essentially the same as revocation. However, the backdoor has been left for the Certifier operator to reactivate the certificate if the user suspended it mistakenly. The user can log out from the account by clicking Close Session on the Main Page. Self-Revocation Using a PSK If allowed by the Web Enrollment Service settings, users can suspend their certificates by using a pre-shared key. The Web Enrollment Service must use TLS protection for this option to work. See Section 2.11.11 (Customizing the Web Enrollment Pages). Pages). If revocation is allowed, the Revoke Certificate option is shown on the enrollment pages. Clicking this option opens the Revoke Certificates With Pre-Shared Key page where the PSK can be given. When the pre-shared key is entered and the Show All Certificates button is clicked certificates enrolled with the PSK are displayed. Clicking View Certificate will display the Revoke Your Certificate page where the contents of the certificate are shown in detail. Clicking Revoke on this page will suspend the certificate. Clicking Cancel will return to the previous page. Note that instead of revocation, the certificate is actually suspended. From the user’s point of view, this is essentially the same as revocation. However, the backdoor has been left for the Certifier operator to reactivate the certificate if the user suspended it mistakenly.


115

Chapter 4: Using External CA/RA Private Keys

Chapter 4

Using External CA/RA Private Keys Insta Certifier supports PKCS#11 for f or public-key cryptographic operations. PKCS#11 is a generic cryptographic interface, originally originally intended to be a cryptographic token interface standard. Nowadays PKCS#11 interface is also used for offloading cryptographic operations to hardware. Insta Certifier is able to t o use keys available in PKCS#11 modules. PKCS#11 module is a device and/or a piece of software which provides the PKCS#11 API. Insta Certifier has been tested with the PKCS#11 implementation of nCipher Corporation and Eracom Technologies. Technologies. nCipher HSMs In this document, the term nCipher HSM (hardware security module) is used to refer to either nCipher nForce or nCipher nShield. nCipher is an UK based company providing hardware hardware security modules for web (SSL/TLS) acceleration and for security applications such as CA key storage. nCipher HSMs support all the platforms Insta Certifier supports. Eracom HSMs Insta Certifier supports the Eracom ProtectServer Orange (CSA 8000) HSM. Eracom Technologies is an Australian company with a long history of producing hardware- and software-based security solutions.

4.1 Creating a CA with a PKCS#11 HSM 4.1.1 Requirements for the PKCS#11 Modules The use of PKCS#11 with Insta Certifier requires the following from a PKCS#11 implementation: 

The device has to support RSA.



All RSA key pairs in the device must have have the CKA CKA ID attribute. attribute. The corresponding public and private keys must have the same CKA ID value. The CKA ID attribute is only a recommendation in PKCS#11, but the attribute is required by Insta Certifier. The Eracom and nCipher devices have been tested to work as recommended.


116


4.1.2 Preparing an nCipher HSM for Use There are three important nCipher-specific terms that you need to understand when setting up a secure CA private key environment with nCipher hardware security modules: Security world The security world is the outermost layer of protection. The integrity and confidentiality of all other objects is guaranteed by encrypting everything with the private key embodied in the security world. Different HSMs with the same security world can use each other’s card sets. Administrator Card Set The Administrator Cards are not used in normal operation, but only in cases when the security world is set up or restored, or when Operator Cards are recovered. Operator Card Set The Operator Cards are used to protect the created CA/RA private keys. An Operator Card must be inserted when Insta Certifier is started. The following steps are required before taking nCipher HSMs in use. See nCipher User Guide for more information. 

Make sure the nCipher HSM is in correct operational operational mode. mode. This can be checked by running the command enquiry provided by nCipher Corporation (in /opt/nfast/bin). The mode should be pre-initialization when the security world is being created, and the mode should be operational when the module is used with Insta Certifier.



Next, the security security world has to be created. The security security world is created created using the KeySafe key management tool of nCipher. Alternatively, the new-world command can be used. See the nCipher User Guide for instructions. When the security security world is initially initially created, itit can be backed backed up up and and made made recoverable. We recommend that the security world is created as recoverable, because if the HSM is damaged, the keys can be restored only if the security world of the keys can be restored. We also recommend that the Administrator Card Set created within the security world creation consists of at least two cards. The Administrator Cards are not used in normal operation, but only in cases when the security world is set up or restored, or when Operator Cards are recovered. The security world information is stored in a file kmdata/local/world. This file is not securitysensitive, since it it is encrypted with the key in the Administrator Card. The copy of the file is needed when recovering the security world. So, again we recommend that you back up the world file. It is also a good practice to do the world restoration once before starting to use the HSM to ensure that the restoration works.



The Operator Cards are used to protect the created keys. KeySafe can be used to create Operator Card Sets. nCipher HSM can utilize n/m protection, but Insta Certifier supports only 1/m protection at the t he moment. (However, Certifier Engine can be started using the with-nfast utility, which allows preloading of n/m keys, so the dual control can be achieved that way.)


117


It is up to the Certification Practice Statement (CPS) of the CA to define whether the CA keys are recoverable. If so, the Operator Card sets should be made recoverable as well. It is worth noticing that a single card set may protect multiple keys. Again, we recommend that the Operator Cards are created so that there are more than one spare cards available. When an Operator Card is lost, the spare cards can be used. If the card set is made recoverable, a new card set can be created if enough cards from the old card set are available. After the Operator Card Set has been created, the keys can be created either by using the KeySafe tool of nCipher or by using the GUI as specified in Section 4.3 (CA Private Key Options). Options).

4.1.3 Adding PKCS #11 Modules to the Certifier Engine PKCS#11 modules are added to Insta Certifier by editing the configuration file of the Insta Certifier engine. The configuration file is named engine.conf and it can be found under the Insta Certifier installation directory in the conf sub-directory (for example, /usr/local/certifier/conf/engine.conf). The PKCS#11 module configuration is in the top level of the ca-engine block (as a commented-out example in the default file indicates). On Unix, the following example adds an Eracom PKCS #11 module to the engine installation. (provider (type "pkcs11") (library "/opt/ERACcpsdk/lib/linux-i386/l "/opt/ERACcpsdk/lib/linux-i386/libcryptoki.so") ibcryptoki.so") (info "read-only(no)")) "read-only(no)"))) )

The information which needs to be changed is the path to the dynamically loaded PKCS#11 shared object. The defaults are:  

nCipher: /opt/nfast/gcc/lib/libcknfast.so /opt/nfast/gcc/lib/libcknfast.so Eracom: /opt/ERACcpsdk/lib/linux-i386 /opt/ERACcpsdk/lib/linux-i386/libcryptoki.so /libcryptoki.so

Note: When the info parameter is set to "read-only(no)", keys can be created via the PKCS#11 interface. If the read-only option is missing, or it is set to "read-only(yes), only existing keys can be used via the PKCS#11 interface. In addition, "threads(no)" has to be added under info when an nCipher module is used on Linux platforms. Once the PKCS#11 modules are added to Insta Certifier Engine, the Engine needs to be restarted. To check whether the Engine has detected the installed PKCS#11 keys, log in to the Administration Service, and click System Configuration. Click Show CA Passphrase Status. The created PKCS#11 keys should be visible in the appearing key list.

4.2 Checking the Key Backup It is crucial that the key backup is properly implemented in the PKCS#11 module. The PKCS#11 vendor should document the key backup procedure and the key backup should be tested before the CA with a HSM key is made operational. It is recommended to test the key restoration in another host instead of the host where the keys are created to make the check as authentic as possible.


118


4.2.1 Key backup with nCipher HSMs When the key or security world is generated, the encrypted version of the data is stored to the kmdata directory ( /opt/nfast/kmdata/) and its subfolders, which should be included in the backup regime. If the entire nCipher device was rendered unusable or/and the security world was lost, the prerequise for the keys to be used is that the security world is restored. The security world is restored by restoring the contents of the kmdata directory and its subdirectories from backup, and then using KeySafe or a command-line command ( newworld -l). If the same security world is available for the keys, and the operator card is available, the key can be ”restored” just by copying the key files from the backup to the kmdata/local directory. It is a good failsafe practice to have a nCipher HSM with the same security world installed on a spare HSM in case the computer and the original HSM are damaged. If the new HSM contains the same security world, the backed up keys are easier to take into use. The security world is stored in the world file, encrypted with the Administrator Card Set. If you need to restore the security world, you need to have both the Administrator Card and the world file available. When you create the key, you can define whether the key can be restored (= Recovery feature in KeySafe). When you set this flag, the keys can be used with a replaced card set. Without that flag, the keys can be only used with the card set that was used to create the key. Having listed all the precautions the change of a CA key is such a drastic operation, that all the precautions should be used to avoid it.

4.3 CA Private Key Options When creating a certificate in Make New Certificate page, the key generation parameters, (which include the used HSM), can be specified by clicking Set Key Generation Parameters. To use an existing PKCS#11 key, select Use existing PKCS#11 key for the key provider, and click refresh. Certifier will then show all the detected PKCS#11 keys. You should be able to see the keys created with the key management utilities. For Insta Certifier to be able to use your key, you must enter the passphrase to it by clicking CA Passphrase Status in System configuration. To create a new PKCS#11 key, select Create PKCS#11 key from the drop-down list and click Refresh. Insta Certifier will then show you all t he detected PKCS#11 tokens allowing you to select the token you wish to generate the key with. You can specify some of the PKCS#11 attributes, though the default attributes are sensitive. In some cases you might want to clear the Exportable flag in order to make it impossible to leak the CA key out programmatically. In some devices, like Eracom, clearing this flag makes it impossible to back up the key using the described


119


procedure. When this flag is set, the access to the CA private key is possible for a person who can run arbitraty commands on the host running the Certifier Engine. Note, that in most cases the HSM vendor provides the tools which can be used to generate keys and restore them. Some vendors (including Eracom) use proprietary flags, which affect the key backup and restore procedures. In those cases, it is recommended that the keys are generated/backed up and restored using the vendor’s own tools. See the vendor’s documentation for more information. Depending on HSM vender, generating/using EC keys with HSM may require additional licensing. Check your vendors manual f or more information.


120


Appendix 1 Certifier Engine and Server Configuration Files Most of the Insta Certifier configuration tasks can be done via the administration user interface of the Administration Service. However, there are some parameters that are not stored in the database or edited via Administration Service. They need to be given in configuration files to the ssh-ca-engine and ssh-ca-server commands. The default configuration files ( engine.conf and server.conf) can be found in the certifier/conf/ directory. When Engine is started up without TLS protection in insecure mode, engine-insecure.conf can be used as an configuration file.

Appendix 1 –1 Certifier Engine Configuration File The adjustable parameters of the engine.conf are the following: data-source-name The ODBC data source name of the database connection. When used outside the embedded Certifier Database, the value of this parameter needs to be the DSN of the appropriate database. service-address The address and the port that Certifier Engine listens to. tls This parameter defines whether TLS is being used between Certifier Servers and Certifier Engine. For insecure configuration this is set to false. pid-directory The location of the PID files. syslog-facility The system log facility name can be given in here. max-unfinished-publications The maximum number of concurrent publishing attempts. If this limit is reached, the publication status of the oldest unpublished certificate is set as failed and the certificate publication will not be automatically tried again. This limit does not concern CRL publishing. max-crl-publication-safety-limit CRL generation is usually quite fast (typically a couple of seconds), but with extremely large databases or overloaded systems it may require more time. Because


121


of this, CRL generation is always started before the actual update time. This variable specifies the maximum advance time. The value is defined in seconds. expired-timeout-period One of the certificate statuses in the system is expired. A certificate is marked with this status after its validity period has ended. This status is used only as a method of optimization, as it divides the certificate set in the database and enables more efficient searches for valid certificates. This status cannot feasibly be updated in real time, but is done in batches instead. This variable controls the period between the times that these batches are run. Usually the value is set to one hour or less. The shorter the period, the more accurate the expired status becomes. dynamic-crl-validity-period In some cases the actual CRL generation may be unnecessary. But even in those cases it might occasionally be useful to see the ’current’ CRL. If the CRL update period is set to zero (meaning that the CRL distribution point is disabled), requesting the current CRL will generate a new CRL on the fly, with the validity period starting at the current time and ending after the value specified for dynamic-crlvalidity-period, which is given in seconds. heartbeat-interval The interval (measured in minutes) of the heartbeats written in system log, when the Certifier Engine process is running. keep-old-crls When several CAs in the system publish CRLs frequently, the size of Certifier Database can increase significantly. By defining keep-old-crls as false, CRLs are not stored in the database. The default value is true. Please note that non-repudiation may require storing CRLs in order to enable later verification of a signature. tls-cipher-suites This feature controls the used and accepted algorithms in TLS protected network connections. Preferred cipher suites can be set separately for Certifier Engine, Certifier Server and services. The suite selection for the Server defines the algorithms suggested for the internal connection between the Server and the Engine. The selection for the Engine defines the algorithms accepted by the Engine. The first common suite in these configurations is selected in the TLS negotiation. If no common suite is found, the connection fails. The value is a list of cipher suites separated with a colon (’:’). Note that the list must always end with a colon (’:’). The first suite on the list is the most preferred one. The default configuration for all cipher suites is ”AES256-SHA:AES128SHA:DESCBC3-SHA:RC4-SHA”. If the parameter is not set at all, then all suppor ted cipher suites are accepted.

Appendix 1 –2 Certifier Server Configuration File The server.conf file contains both server and service specific parameters. The server-specific parameters are the following:


122


ca-engine The address of the Certifier Engine, to which Certifier Server is connecting, and a flag to specify whether TLS is being used for protection. Multiple addresses can be configured by separating them with a semicolon (;). If the connection to the first address fails, t he second is tried and so on. This requires the Certifier Engines to be identical in terms of TLS settings and certificates. This feature is mainly for HA cases where a secondary Engine host takes over in case the primary fails. pid-directory The location of the PID files. pki-directory The location of the directory where the Certifier Server private key and certificates are stored. heartbeat-interval Interval in minutes of the heartbeats written in system log, when the Certifier Server process is running. In the server.conf configuration file you can also define parameters that are defined for all Certifier Services of specific type running on that Certifier Server. These parameters are mainly related to the web server data (such as the location of the HTML templates). Normally they are needed only for Administration Services and Web Enrollment Services. The service-specific adjustable parameters of the server.conf file are the following: syslog-facility The system log facility name for the log messages related to the Service can be specified here. dos Parameters for the denial of service avoidance mechanism. host-rate-limit Maximum number of requests from one client host during a ten second period. max-packet-size Maximum request packet size. session-idle-ttl How many seconds the web sessions may be idle before the Web server drops the session. initial Session may be idle this many seconds after the first request. normal Session may be idle this many seconds after subsequent requests. path-mime-types


123


The location of the file that describes the mappings from filename extensions to MIME types. mime-paths Describes mapping between mime-type and the directory containing files of this type. The default configuration can include the following entries: text The location of the HTML templates used in the GUI. Several directories can be specified. image The location of the images (GIF, JPEG etc.) used by the GUI. Several directories can be specified. tls-cipher-suites This feature controls the used and accepted algorithms in TLS protected network connections. Preferred cipher suites can be set separately for Certifier Engine, Certifier Server and services. The suite selection for the Server defines the algorithms suggested for the internal connection between the Server and the Engine. The selection for the Engine defines the algorithms accepted by the Engine. The first common suite in these configurations is selected in the TLS negotiation. If no common suite is found, the connection fails. For services, the suite selection is only applicable for services that support TLS. These are the Administration service and the Web Enrollment service. The preferred cipher suite determines what algorithms are used between the Certifier service and a web browser. The value is a list of cipher suites separated with a colon (’:’). Note that the list must always end with a colon (’:’). The first suite on the list is the most preferred one. The default configuration for all cipher suites is ”AES256-SHA:AES128SHA:DESCBC3-SHA:RC4-SHA”. If the parameter is not set at all, then all suppor ted cipher suites are accepted. library-path The location of the Scheme code libraries used in the GUI.


124


Appendix 2 Database Insta Certifier uses an embedded database for internal data storage, Adaptive Server Anywhere from Sybase Inc. This database should not be confused with the optional public LDAP directory which is used for certificate and CRL publishing. Certifier Engine is the only Certifier component that connects to the Database and performs database queries. The Certifier Database is used to store all of the issued certificates, certification requests, CA policies, Server and Service configuration and all the other certificate and entity management related data. The operation log data and most of the configuration definitions are also stored in the Database. All the software CA/RA private keys are stored in the database encrypted with the master password. All the information in an Adaptive Server Anywhere database is stored in a single database file. In addition to this database file, it uses two files when it is running database, the transaction log and a temporary file. The transaction log file contains a record of all the operations performed on the database. The temporary file is started during Certifier Engine start, and closed during Certifier Engine stop. It is used to hold temporary data, that does not need to be kept between sessions.

Appendix 2 –1 Setting up Backup Procedure A properly set up backup plan is needed to ensure data recovery in case of hardware malfunction. One method is to use hardware mirroring which will work on physical device level. This requires no changes to Insta Certifier installation. The other method is to use software mirroring in Sybase. To make the mirroring useful, two physically independent disks are needed. This way random hardware failures are very unlikely to affect both disks at the same time. Establishing Backup Policy For successful data recovery, the current backup of the database file (or the database file itself) and one of the two transaction log files must be available. To guarantee total recovery, establish a regular backup policy using cron or something similar. On Unix software mirroring and automated database backups are set up by running(preferably as root) the command: ./bin/ssh-ca-backupconf

This script will prompt you for: 

Directory (on your file system) where the Certifier Database transaction logs will be mirrored. This directory must be located on a different physical disk from the Certifier Database


125






Directory (on your file system) where the Certifier Database backups will be copied to. This directory should also be located on a different physical disk from the Certifier Database. If this is not he case, even if you arrange automated copying of the backups to a removable media or to a remote host you are exposed to a catastrophic disk failure during the time window between the end of the backup and the end of the copy operation. The backup schedule (daily/weekly/monthly). Please note that this schedule affects the amount of lost information only in the case of a catastrophe destroying both your disks at the same time. If either one of the disks survives, you will be able recover the database completely.

The script will: 

Enable/disable software mirroring for the Database



Enable/disable up a daily/weekly/monthly cron job for automated full database backups. ○

The cron job will be run as the certifier user. The backup is done with the script bin/ssh-ca-backup.

○

The backups will include the database, configuration files, internal PKI data in the var/pki directory.

○

Each new backup will be saved in a separate subdirectory and the older backups will not be erased. Also the nCipher HSM security world files are automatically backed up if they are located in the default directory.

○ 



Modify the cron.allow file if that is/was required for enabling the cron job. Modify bin/ssh-ca-runenv to reflect the new backup policy.

Data Integrity Check Backup as such is worthless if the data itself is corrupted. Checking the database thoroughly is a somewhat long process it is not normally done at startup. However after (or before) each backup it is recommended to run a special validation utility: dbvalid -c "connection_string" -f

To check the backup (as opposed to the running system), the backup database must be run under an additional database engine in read-only mode (-r option in dbeng7) to prevent modifications to the backup. Checking the backup database can be useful for performance reasons as the validity check can be performed on a separate, spare machine. The ssh-ca-backup script by default performs dbvalid before proceeding with the backup.

Appendix 2 –2 Recovery To recover a backup run the command: ./bin/ssh-ca-backup -restore

This command will:


126




Restore the Certifier database from the most recent backup and apply the current transaction log (or its mirror) to it.



Restore the configuration files in the conf/ subdirectory. Restore the var/pki subdirectory



This command will not automatically restore the nCipher HSM security world files. To accomplish this, run the following command instead: ./bin/ssh-ca-backup -restore -with-nfast

In case the backup files should be restored into a new installation as in migration, then the command should be: ./bin/ssh-ca-backup -restore-lossy [-bak-dir ]

This command will overwrite the old database without trying to apply the old transaction log. For a full description of the ssh-ca-backup script options, please see document Command Line Interface. If private keys used by one of the Insta Certifier server installations have been lost, a new certificate must be enrolled for that server before it can be used. This probably requires some operator activity to set up a pre-shared secret for the server. If there are no functioning servers in the system, Insta Certifier must be started in insecure configuration mode first.

Appendix 2 –3 Remote Live Backup In live backup, the dbbackup process has a continuous TCP connection to the database server running in an Insta Certifier installation. To enable this the dbeng12 in the bin/ssh-ca-runenv script must be replaced with dbsrv12, which accepts remote connections. Further connection parameters can be given to dbsrv12 with the -x option. For example, -x "tcpip(MyIP=10.1.44.6;ServerPort=7075)" would specify the interface and port the database server uses for incoming connections. If a non-standard port is used (Sybase uses port 2638 by default), it must also dbbackup be given in client connection parameters to (CommLinks=tcpip(Host=10.1.44.6;ServerPort=7075)). WARNING: This will also mean that anyone able to connect to your database machine and who also knows the password for a database user can change the database contents. Also, by default the password is transmitted as plain text in network, so anyone with access to your network can also get access to your database. The best way is either to run the whole setup in a physically trusted network or use some method to secure the connections (IPSec, Secure Shell tunnel, TLS tunnel or such). In such cases dbbackup also needs DoBroadcast=NONE option which disables UDP-broadcast-based database auto-discovery. To run the live backup, use the following command: source ./bin/ssh-ca-runenv dbbackup -c "connection_string" -l transaction.log backup-directory


127


As the dbbackup needs specific libraries the ./bin/ssh-ca-runenv must be executed first. In addition to the normal database name, database engine name, user name, and password parts, the connection string must contain links=tcpip(Host=serveraddress) in which serveraddress is the address of the machine running the database. Additionally if database is running in nonstandard port, ServerPort=portnumber option must be given. Live backup will only backup the transaction log, the database file itself is not backed up. All committed transactions are automatically flushed to the remote transaction log by the live backup process. This however is not transactional; when a transaction is committed to the database it is not ensured that it is already in the live backup transaction log. In case of failure, a few transactions can be lost if the recovery is done from the live backup. The dbbackup process exits when the database connection is lost. This means that it must be encapsulated into a script that automatically restarts the process in such case, probably integraded into a monitoring solution which also either tries to restart the current server machine or switches the Insta Certifier to a spare unit. When implementing a normal backup process for Insta Certifier, it must be remembered that the live backup transaction log is truncated when normal transactions logs are (the -x option for dbbackup). Best way to ensure that no data is lost during backup is to make the full backups also remotely. Otherwise a failure right after a truncating local backup might destroy both the database, transcation log, and the most recent backup at the same time. Example Here is a simple example script to use for live backups. It does not offer any restart functionality for dbbackup or Insta Certifier itself. #!/bin/sh if [ "X‘uname‘" = XLinux ] ; then BASE=/usr/local/certifier ; fi if [ "X‘uname‘" = XSunOS ] ; then BASE="‘pkginfo -r certifier\* | tail -1‘/certifier" ; fi

if [ -z $BASE ]; then echo Unsupported OS; exit 2 fi if [ $# != "2" ]; then echo "Usage: $0 backup-dest-dir server-address"; exit 1; fi PREFIX=$1 ADDR=$2 . $BASE/sybase/bin/asa_config.sh SSH_CA_DBCONN=${SSH_CA_DBCONN:-"eng=certdbeng;dbn=certifier;uid=DBA;pwd=SQL"} SSH_CA_DBCONN="$SSH_CA_DBCONN;CommLinks=tcpip(Host=$ADDR;DoBroadcast=NONE)" if [ -f $PREFIX/live-transaction.log ]; then rm -f $PREFIX/live-transaction.log.old mv -f $PREFIX/live-transaction.log $PREFIX/live-transaction.log.old fi nohup dbbackup -c $SSH_CA_DBCONN -l $PREFIX/live-transaction.log $PREFIX > $PREFIX/live-backup.out 2>&1 < /dev/null & echo $! > $PREFIX/live-backup.pid


128


As a safety measure, the script will first move the possibly existing transaction log and delete the older backup in the process. If wanted, this could also be changed to preserve all log files. Then the script will start the dbbackup process in the background using nohup. Stdout and stderr are redirected to the file live-backup.out for debug purposes. Finally the pid of the dbbackup process is stored in live-backup.pid and can be used by other scripts to check its status or kill it.

Appendix 2 –4 Sample Backup Plan In this example, we examine a situation where the system is secured not only against local, limited hardware failure, such as single malfunctioning hard disk, but also against total loss of the active database machine including its database. Machine A: Machine B: Disk 1: <---------------> Live backup: certifier.db transaction.log transaction.log Disk 2: <---------------> Full backup: mirror.log certifier.db

On the main, active machine (A) we have the database server running as a part of full Insta Certifier installation. It has two separate disks (1 and 2) and it uses transaction log mirror. Spare machine (B) continuously runs live backup process which maintains almost up-to-date transaction log copy on that machine. Machine B also runs remote full backups periodically in which the database file ( certifier.db) is copied to the remote machine and all three transactions logs are also truncated. Machine B does not contain a running Insta Certifier installation, although it can contain a pre-installed system to help in the recovery process. Only thing it requires is a working dbbackup application for the backup process. Full backup frequency mainly affects transaction log sizes. In an installation with relatively low usage a full backup once per week (or even once per month) is enough. However if transactions logs grow too large a more frequent backups are necessary. In this configuration the following failure cases are handled: 

Case 1: Disk 2 on machine A fails ○



Case 2: Disk 1 on machine A fails 1. 2.



Just restart the database and it will automatically copy the main transaction.log to mirror.log before starting. Copy certifier.db from most recent backup to machine A. Apply the mirror.log to certifier.db.

3. Restart the system. Case 3: Machine A is totally destroyed (in a fire for example) 1. 4. 5.

Copy certifier.db from the most recent backup to new machine A. Apply the transaction.log from live backup to certifier.db. Restart the system.

Note that in case 3 some committed transactions can be lost. In cases 1 and 2 the recovery is always complete. Insta Certifier : Reference Guide

129


No special backup processes are needed on machine A. In machine B the f ull backup can be arranged with either of backup scripts in Section Appendix 2 –1 (Setting up Backup Procedure) which can be run a cron jobs. Connection strings must be customized to include the address of the database server as is done in live backup script. Live backup can be started with script in Section Appendix 2 –3 (Remote Live Backup) but some care must be taken to ensure that if the database is ever shut down, either deliberately or by some real failure, the live backup process must be restarted. One way is to add another script which will monitor the live backup process and restart it automatically. In such case, some additional care must be taken to ensure that the old transaction log is not overwritten.


130


Appendix 3 Migrating Certifier Appendix 3 –1 Migration Steps An already existing Certifier installation can be migrated from one host to another by performing these steps. Install the new Certifier Install the installation package ( rpm/pkg/depot) to the new host as described in Insta Certifier Administrator’s Guide , but do not run the ssh-ca-setup script yet. Shutdown the old installation As you definitely do not want to lose any events (revocations, issuances etc.) happening during the migration process, you must first stop your old installation. However, in order to avoid a break in certificate validation, you must ascertain that none of the CRLs are about to expire during the migration. This is done with the administration interface 2.12.14 (System Shutdown) request in the System Configuration Menu. After shutting down the Certifier Engine with the System Shutdown request, the database and the server must be also stopped. Please run the ssh-ca-stop script (see Section 4.1 (Starting and Stopping Certifier Manually)). Disable database log mirroring If you have enabled Sybase database log mirroring (either with ssh-ca-backupconf or manually with the Sybase tools), you must disable mirroring before proceeding with migration and enable it again on the target system after migration. Database mirroring can be disabled with ssh-ca-backupconf, see Section A.3.1 (Setting up Backup Procedure). Disable database live backup If you have enabled Sybase database remote live backupping, you must disable the live backup before proceeding and enable it again on the target system after migration. If you need assistance with this step, please use your your official support e-mail account to contact us. Backup the old installation On Unix: Backup your installation with the ssh-ca-backup tool (see 4.2 (ssh-cabackup)). Just run the following command (as the certifier user, not as root): ssh-ca-backup

By default the backup is stored under var/bak/ca-backup-current under the Certifier directory.


131


Note: if you have set up a regular backup routine with ssh-ca-backupconf (see Section A.3.1 (Setting up Backup Procedure)), the result gets stored to the directory specified in the backup configuration. Transfer the backup On Unix: Transfer the fresh backup to the new host. The exact steps depend on your host/network setup. If the new host is accessible with a Secure Shell connection, this might be achieved with the following commands: cd /opt/certifier/var/bak tar cf - ca-bak-current | ssh root@your-new-host \ "mkdir /opt/certifier/var/migration ; cd /opt/certifier/var/migration; tar xf -"

Transfer your hardware crypto modules If your Certifier installation includes crypto hardware modules, they must be migrated to the new host as well. Please consult your hardware crypto module documentation/support for details. Setup the new Certifier Run the ssh-ca-setup as described in Section Installing Certifier in the Administrator’s Guide. Note that the ssh-ca-backup must be run as certifier user, not as root. ./ssh-ca-setup bin/ssh-ca-backup -restore-lossy -bak-dir var/migration

Subordinate Servers Subordinate server installations are not migrated, as their configurations live in the main installation database. When migrating old subordinate servers to new hosts, perform the following steps: 





Create a new PSK for each of the old subordinate servers with the admin GUI. See Section 2.11.1 (Server Entity). Install the subordinate server packages as instructed in Insta Certifier Administrator’s Guide . Use the new PSKs when setting up the servers.

Checklist After migration, please check at least the following details in the Certifier configuration. 

Hostnames in the service configurations CN in certificates of TLS enabled web services



Engine address in subserver configuration file conf/server.conf



Your database setup is in desired state with respect to: ○ Automated backup routine



○ ○

Database log mirroring Database live backup

Please note that the Certifier syslog files ( certifier/var/log/engine.log and certifier/var/log/server.log in a default installation) are not transferred from the old host to the new host with this procedure. You should copy or archive those files manually as appropriate.


132

Certifier 5.2.3 ReferenceGuide

Recommend Documents