Certifier 5.2.3 ReferenceGuide

8/19/2019 Certifier 5.2.3 ReferenceGuide

http://slidepdf.com/reader/full/certifier-523-referenceguide 1/138

www.insta.fi

Insta Certifier 5.2.3

Reference Guide



Insta Certifier : Reference Guide

Version 5.2.3

Date 16 September 2013

© 2013 Insta DefSec Oy. This software is protected by international copyright laws. Allrights reserved.

All other names and marks are property of their respective owners.

No part of this publication may be reproduced, published, stored in an electronic data-base, 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 USEFUL-NESS OF THIS INFORMATION EXCEPT AS REQUIRED BY APPLICABLE LAW OREXPRESSLY AGREED IN WRITING.

Insta DefSec OySarankulmankatu 20P.O.Box 80FIN-33901 TampereFinland

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 This Document ................................................................................................................... 1

Administration Interface ............................................................................................................... 2

2.2 Database Search ............................................................................................................... 3

2.2.1 Database Search Options ...................................................................................... 4

2.2.2 Search Results....................................................................................................... 8

2.2.3 Viewing Log Entries ............................................................................................... 9

2.3 Processing Requests ....................................................................................................... 11

2.3.1 Certificate Profile .................................................................................................. 13 2.3.2 Entity .................................................................................................................... 14

2.3.3 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 ............................................................................................................................. 21

2.4.1 Adding Entities ..................................................................................................... 22

2.4.2 Editing Entities ..................................................................................................... 23

2.4.3 Adding and Modifying Pre-Shared Keys ............................................................... 24

2.4.4 Adding Policy Module Attributes ........................................................................... 26

2.4.5 Removing Entities ................................................................................................ 27

2.5 Viewing Certificates.......................................................................................................... 27

2.5.1 Viewing and Exporting Private Keys ..................................................................... 29

2.6 Certification Authority Settings ......................................................................................... 31

2.6.1 Creating a New 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

Insta Certifier : Reference Guide 1

Chapter 1

About This Document

Insta Certifier offers versatile configuration and customization options to suit theneeds of your PKI service.

This document describes the user interfaces, command-line tools, and other configu-ration 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 en-rollment GUI

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

instructions on using PKCS #11 compatible hardware security modules (HSM) forstoring CA/RA private keys

appendix with information on miscellaneous topics (such as configuration filesand database backup)

appendix that lists the Certifier syslog messages

To use the information in this document, you should have basic knowledge of public-key cryptography and X.509 certificates. You should also be familiar with the infor-mation presented in Insta Certifier Product Description and Insta Certifier Administra-tor’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



Chapter 2: Administration Interface


Chapter 2

Administration Interface

The administration interface of Insta Certifier is produced by the Administration Ser-vice. All administrative tasks including certificate request processing, certificate pub-lishing, CA policy configuring, and database searches can be performed by using theweb-based administration interface.

This chapter describes the different functions the operators can perform using theadministration interface. Detailed explanations on how to fill the configuration data andhow to use the various GUI features are given. The Help buttons in the administrationinterface itself are linked to these explanations.

In addition to the main admin UI, Insta Certifier is provided with a limited administra-tion interface. See Insta Certifier Administrator’s Guide for instructions.

For a description of the web enrollment interface, see Section 3.3 (Web EnrollmentService).

Insta Certifier offers also the possibility to customize a totally new GUI. Customizing orprogramming 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 dynami-

cally created from HTML templates. Each page is divided into two parts, the topmenu, the main menu on the left, and the actual settings page. The top menu andthe 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 admin-istration GUI. Some options may be hidden on the menu, depending on the adminis-trator settings.





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 userinterface, as in some cases they may cause the application to function erratically. In-

stead, use the Back , Cancel, and OK buttons provided on the UI page, or just selecta new option from the main menu.

2.2 Database Search

Almost all objects in the Database can be located with the generic search functionali-ty. 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 listonly the objects that are relevant for each particular situation.

Select the Search option from the main menu to open the Database Search page.





The Find Certificates, Find Requests, and Find Entities options will go to the

same Database Search page. The difference between these options is that somevalues 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 thesearch.

Figure 2-3 The Database Search page





Text Search

Using the Text search field is straightforward for anyone who has used a commonweb 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. Thismeans that only those objects that contain all of the searched words are shown in thesearch 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 precedingthem with a plus sign (+). In both modes a minus sign (-) can be used to restrict theresult 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 haveall 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 fol-lowed by the operand.

Object Status

By using the Object status switch, the search can be restricted to only those objectsthat have the specified status. The object status can be one of the following:

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 istype-specific.

Publish Status

Certificates can also be searched according to their publishing status. This allows theoperator 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 exam-

ple, in case of certificates issued through CMP that are specifically requested notto be published.





Ready: The certificate has been published correctly.

Error: Some of the required publishing methods have failed to publish the certifi-cate.

Object Type

The Object type option can be used to search for certain kinds of objects, for exam-ple, certification requests. The effects of later search parameters can also differ de-pending on the selected object type. Some parameters have an effect only when aspecific object type is selected.

The available object types are certificate request, certificate, entity, and logentry.

Select CA

The Select CA option can be used to restrict certificate searches to certificates whichare issued by a certain CA. Also certification requests can be selected by their CA, ifthey 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 drop-down list does not display all CAs. The names of the first level sub-CAs are displayedimmediately after their top-level CAs, and they are preceded by a plus sign (+). If asub 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 their numberis shown (in square brackets). The sub-CA list can be expanded by selecting a sub-

CA and clicking Refresh.

In the resulting list, only the sub-CAs are displayed and if they have sub-CAs of theirown, 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 requestsearches. In certificates the time period matches with the certificate’s validity period.





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 periodend 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 inclusivemode the validity period must be fully contained in the given time period. In exclusivemode a certificate will match if even a portion of its validity period matches with thegiven time period.

Certification requests do not have validity periods in the same sense as certificatesdo. In their case, this option is interpreted according to the time the request was re-ceived. Defining a time period allows the operator to search all requests that arrivedduring that period. Using strict time period matching does not affect certification re-quest searches.

Time period also affects log event searches, in which case only events that happenedduring the given period are shown.

Sort Order

The sort order of the result can be changed by selecting the options Sort by timevalues and Sort in reverse order.

All objects have some kind of a primary time stamp. With certificates, it is the timewhen the certificate was issued. With certification requests, it is the time the requestwas received. Entities are sorted according to the creation time, and log events aresorted according to their time stamp.

If the Sort by time values option is selected, objects are sorted with this primarytime 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 searchto 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





When you click the Search button, the page is updated and the text field is replacedwith a drop-down list showing the names of all entities that matched the given searchstring. Now all certificate and certification request searches are restricted to those objects 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. Selectthe type of identification and the format of the number from the drop-down lists andtype 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 de-

sired 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 thispage, 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 allmatching certificates (all certificates that matched the search criteria).

Select the boxes on the right side of the certificates and click Make It So to continuewith 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 thispage, multiple certificates can be published simultaneously.


Publish marked certificates, Publish not marked certificates, or Publish allmatching certificates (all certificates that matched the search criteria).

Select the boxes on the right side of the certificates and click Make It So to continuewith publication.





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. Fromthis page, multiple requests can be rejected simultaneously.


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 continuewith rejection.

A warning message listing the requests to be rejected is displayed. Click Proceed toreject 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 excep-

tion 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 resultsare displayed. Depending on the event and object type there may be additional linksbeside the log entry.





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 cur-rently viewed change set and previous CA revision is shown. When viewing revisionof system parameters, difference between viewed revision and previous revision isshown.





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 ex-ample, if shared secrets are not used in certificate enrollment), the operator has tomanually 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 ProcessRequests button on top of the main menu. This runs a database search on all pend-ing certification requests in the Database and displays the result to the operator, most

recently arrived requests first.





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





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 operatorcan manually verify all fields of the certificate and modify almost any other data asso-ciated with the certification request, prior to making the 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 restrictthe allowable fields in a request by removing all extensions that are not explicitly setby the profile. They can also change the names in a request and add extra extensionswith default values if they are not present in the request.

Note: The profiles are processed only if the relevant CA policy contains an ApplyProfile or Apply Request Profile policy module. See document Policy chain andmodules.

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 differentrequirements for the certificate extensions and fields, you need to be aware of whatkind of certificates a specific installation requires. Also, sometimes it makes sense tohave a certificate for multiple purposes. New certificate profiles can be easily createdfor environments where the following sample policies are not enough. Contact InstaCertifier 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 DataEncipherment 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 certificatetemplate. 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 tem-plate. Fails if it is not present.

If present, copies the Email subject alternative name from the request to thecertificate template.

Sets the Digital Signature, Key Encipherment, and Data Encipherment keyusage bits.

Windows 2000 logon with smart cards





A profile for Microsoft Windows smart card logon certificates. Note that this profilerequires a preconfigured entity with the UPN attribute.

Copies the UPN attribute of the entity to the UPN subject alternative name ofthe 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 assignsan entity mapping to the request.

The operator can manually change the entity mapping. This is done by entering theentity search string (such as the name of the entity) in the string input box and thenclicking 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 cer-tification 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 de-cisions made for the request and will also determine the resulting certificate’s futureuse to a great extent.

Creating self-signed certificates (certificates that do not have an issuing CA) is disal-

lowed in request processing, but can be done using the Create Certificate option

under the System Configuration main menu item. The operator must have super-user 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 fieldneeds to contain a local RA of the system. Instead of issuing the certificate, the RAsigns the certification request and sends it to the remote CA that is associated withthis 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 algorithmfor 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:





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 hasa randomly increasing serial number counter (unless sequential increase has beenconfigured from global configuration file), and the serial numbers are automaticallygenerated.

In some situations operator may want to use a specific serial number e.g. for self-signed root CA certificates or subordinate CA certificates. If the number is manually

given, it is verified to be a number in range 1 – 1040. Serial number is not accepted ifthe same issuer has already issued a certificate with the given number, or if there is aself-signed certificate with the given number.

2.3.5 Subject Name

The subject name should be checked and verified. The system automatically checksthat the given distinguished name is syntactically correct, and certain CA policies canbe used to check that the subject name matches a pattern. Errors in these checks aredisplayed 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 formatthat the operator must check manually. For example, a person’s name can be writtenin several different formats (first name first, last name first, without middle names, withmiddle initials, etc). Verifying that the name is in reasonable format for your organiza-tion’s needs can sometimes be hard to do automatically.

Note: All distinguished names, including the subject name mentioned here, are writtenin the same order that is used when the names are encoded in certificates. This is ex-actly the opposite order as the one used in LDAP applications. When dealing withLDAP, Insta Certifier will convert all distinguished names to the correct order automat-ically.

2.3.6 Validity Period

The validity period defines the time frame within which the certificate is valid. All cli-ents should disallow using certificates before or after their validity period.

Figure 2-11 The validity period options





The validity period is rarely set in the original request and it is usually reset by the CApolicy to some default value. CA policy allowing, the operator can check and modifythe validity period of the resulting certificate. The system automatically restricts validityperiods inside the validity period of their issuing CA certificate.

The used date and hour format depend on the operator-specific settings. See Section2.9.2 (Editing the Operator Information). The Not before and Not after times aregiven (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 drop-

down 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 certifi-cate. The field contains SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512. The de-fault value is SHA-1 when using RSA key type. For EC key type, the signature algo-rithm is automatically selected based on issuer key size. Selection is based on NISTrecommendations (2011).

2.3.8 Certificate Extension Fields

The Extension subsection shows all extension fields present in the certification re-quest. Existing fields can be modified like any other request data and additional ex-tensions can be added by selecting an extension from the drop-down list and clickingthe 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 momentthis 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 non-relative (for example, http://www.certificate.fi).

Domain Name (DNS)

DNS subject alternative name. Multiple values are allowed.

Registered ID (RID)





RID contains an OID as a value, for example, 2.5.223.67.32.568.64.23 is a validOID. Multiple values are allowed.

User Principal Name (UPN)

UPN subject alternative name. This extension is required, for example, for Win-dows 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, NokiaR&D extension for Symbian and Nokia R&D capabilities for Symbian.

Policy Info

This field contains information about the applicability of the certificate for varioususes 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 usethe 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 theextension.Click the Edit button to edit the policy information extension. The extension needsto have an object identifier (OID), which is registered for the certificate policy. Addi-tionally, the extension may contain a user notice and a certification practice state-ment (CPS) URI. The CPS URI field can give, for example, the location where thewritten certificate policy can be found with a web browser.The user notice is intended to be displayed to a client when the certificate is beingused. The textual statement needs to be written to the Explicit text field. The Or-ganization field can be given name of the organization giving the statement andReference List the number that identifies the statement. Click the Add User Noticeand 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 CAservices (other than CRLs). The authority access may contain either informationabout CAs that have issued certificates superior to the CA that issued the certifi-

cate containing this extension, or location of the OCSP service.The first drop-down menu is used to select which one of these is being used, caIs-suers 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 ofthe 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 cer-tificate. The path length constraint is optional and can be removed selecting unlim-

ited from the drop-down list. To remove the Basic Constraints extension, click theRemove button.





If the path length constraint is present, it indicates the maximum number of certifi-cates that can follow that particular CA certificate in the certification path. Thismeans that a CA with a path length of zero cannot issue any sub-CA certificates atall, and a CA with a path length of one can issue only CA certificates with a pathlength 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 purposesthan 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 certificatescan have this bit set.

CRL Sign

Set when the key is used to sign CRL information. Only CA certificates can havethis 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 keyagreement procedure.Note that not all bit combinations are valid. Such factors as if the certificate is a CAcertificate or the key type affect the possible combinations. The system automati-cally 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 dif-

ferent key usage constraints.

ekuServerAuth





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 the certifi-cate 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





ing its validity period, the certificate will stay in the CRL even after its validity periodhas ended. By default, this option is not selected.

If Publish certificate is selected, the certificate will be published (according to thepublishing 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 but-ton in the bottom of the page.

When the operator clicks either the Accept or the Reject button, the request’s statusis updated accordingly, the last search is refreshed and its results are displayed au-tomatically. 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 asa 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 methodused).

After the approval, the certificate is stored in the internal Database and published to adirectory server (if so configured). Also the approval operation, including the operatorlogin name, is stored in the Database to enable audit trail of the certificates. If a re-quest is denied, the same request cannot be approved later.

A Poll reference ID for the request is shown on the request processing page. ThisID needs to be given when polling for the approved certificate, for example, via theWeb Enrollment Service.

Clicking the Postpone button sets the request to postponed status. This means that itwill 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 theDatabase and effectively cancels all modifications done by the operator after the lastupdate.

The View Log option displays recent log events related to this request. CopyRequest 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. Anexample of an entity could be a user requesting a certificate for e-mail usage, or anetwork device requesting certificates for IPSec.

Entities are used to bind a set of attributes describing the entity and a set of requestsand certificates together. This makes it easier for operators to view what kind of certif-

icates are given to users.





Entities can also contain a set of shared secrets, in the form of a secret key ID and apre-shared key. These keys can be used to map incoming certification requests to acertain entity. Additionally, secrets can have a set of policy attributes that can alter theway they are handled in the automatic CA policy code. For example, the system canbe 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 ex-tension values without operator intervention.

Using entities is not strictly necessary, as Insta Certifier can also operate on certifica-tion requests without entity mapping. Using entities is recommended if the potentialend 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 optionfrom 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, se-lect a CA from the list. The list works as described in Section 2.2.1 (Database SearchOptions).

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 descriptivename 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, usergroup it belongs to, or perhaps its location. Exact information such as the IP addresscan have a separate attribute in the entity. This makes searching for them more accu-rate.





Entity Attributes

In addition to these fixed elements, an entity can have a selection of attributes. An at-

tribute 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 theattributes differ by their name and the size of text input box, but some have differentcontent types, such as drop-down lists giving a limited selection of choices, or Boole-an values represented as check boxes.

The Email address and Account Password attributes of the entity are used whenentity account management is enabled in the Web Enrollment Service. See Sections2.11.11 (Customizing the Web Enrollment Pages) and 3.3.4 (Managing User Certifi-cates) 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 acertificate, for example, as the values for LDAP attributes.

An attribute can be removed by clicking the Remove button on the right hand side ofthe 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 returnfrom 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 ontheir 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 en-tries have an associated entity which can be viewed. An entity associated with a certif-icate can be viewed from the certificate page.

The Entity page looks almost the same as the entity creation page. The only differ-ence is the addition of Pre-shared keys and some different buttons in the bottom of

the page.





Figure 2-13 The Entity page

Clicking the Commit Changes button will update the Database with the new name, status and at-tribute values that have been set by the operator. Changes in pre-shared keys are updated on theirown 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 pendingcertification 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 pagewith the current entity automatically bound.

The Copy Entity option makes a new copy of this entity. Only attributes, type andname 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 addsa new row to the table, displaying the newly created shared secret.





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 beenused successfully to enroll a certificate. (Certain policy functions and policy attributesrestrict multiple uses of the same key.)

The Reference Number is a unique identification number for this secret, assignedby the Insta Certifier Engine. This ID is required by the CMP protocol, which uses it toidentify the used secret.

The Key field contains the actual shared secret. This is a free-form text string thatwas 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 forsome reason wants to enroll another certificate with same key. However, the recom-mended way to do this is to generate a new shared secret and distribute it to the userin 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 allowthe use of passwords (passphrases) generated by external systems instead of ran-





dom character strings generated by Insta Certifier. These passwords should, howev-er, be of sufficient length.

All changes made on this page are committed to Database by clicking the CommitChanges 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 viewdirectly 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. Themodules can affect the way the incoming certification requests containing this key arehandled by the system. This is generally used to shorten the processing time by allow-ing a certificate to be automatically issued. They can also be used to identify the certi-fication request to the operator, thereby allowing faster manual identity verification.

Policy modules that are added to the entity affect all certification requests by the enti-ty. Policy modules added to a shared secret affect only the requests made with thatsecret.

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 NewPolicy 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 theentry 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 PolicyModule – 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





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 mod-ules.

2.4.5 Removing Entities

Sometimes an entity has to be removed from the system. Normally certificate revoca-tion and removal of the shared keys are enough, and basically provide the same out-come.

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 toconfirm the selection before the entity and all associated certificates and keys are re-moved from the system.

2.5 Viewing Certificates

To view a certificate, first search the certificate from the Database with the normalsearch 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.





Figure 2-16 The Certificate page

On the Certificate page, you can Revoke or Suspend the certificate by clicking theappropriate 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 thatcan be used to reactivate the certificate.

Suspension and reactivation take place immediately after you click the button (butthere will be a delay, depending on the CA settings, before the information will appear

in the CRL).





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. Thecomment 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 beused:

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 codescannot be used in mass revocations.

After suspension or revocation, the revocation information is included in the next pub-lished CRL (it is immediately available for OCSP). After that the certificate cannot beused any longer by the PKI client applications.

The only difference between suspension and revocation is that a revocation cannot bereversed. If a suspended certificate is reactivated, the suspension information will beremoved 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 buttonopens the request processing page with preset values from the certificate. See Sec-tion 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 Sec-tion 2.12.7 (Creating Certificates)) or if a CMP enrollment client has requested keybackup, the private key corresponding to the certificate is stored in the Certifier Data-base. 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-64-encoded PKCS#12 format. The PKCS#12 blob is encrypted with a random passwordthat is shown on the top of the page.





Figure 2-17 The View Encrypted Private Key page

To download the key (in binary PKCS#12), click the Download button. Your browserwill 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 withpassphrase field and click Refresh.





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 (in-

cludes 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 organiza-tion. CA management and creation can be easily handled via the administration inter-face 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 opera-tors. It should be easily distinguishable and unique as it will be displayed in drop-downlists in several different displays in the system. SCEP enrollment clients may some-times require this name to be formatted like a domain name.





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 can-not 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 morethoroughly later - the default options are provided on this page just to make the opera-tor’s life easier, since the publishing and policy editing do not need to be started fromscratch.

The Default policy list displays three basic policy options, Deny all, Manualrequest approval, and Automatic request approval. When Deny all is selected,the CA will not issue any certificates before the policy is specifically activated. By se-

lecting Manual request approval, the initial policy does not allow automatic issu-

ance at all, instead all requests will be pending operator approval. When Automaticrequest approval is being employed, the CA will automatically issue the certificate ifthe 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 policythat is automatically generated for the new CA. Note that if the generated set-validity-period policy module is removed from the policy, there will be no default time and thetime 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 be-ing 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 PublishingService defines the directory access including the server address and the directoryadministrator login name and password.

All of the above choices can be edited later, so setting them correctly is not critical atthis stage.

CA Certificate

If a CA certificate is already in the Database (added by an external utility, previouslycreated) 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. Notethat if a result list is too long, it will be truncated. Therefore it is advisable to use pre-cise search texts.

If previously created CA keys and a certification request exists in the database, a CAcertificate 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.





When the Proceed button is clicked, a certificate is created and the operator is re-turned 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, theuser should wait until the key generation process is complete and then restart the CAcreation. The new certificate in the Database can be found, for example, by searchingits 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 ashort 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.





Figure 2-19 The Certification Authority page

CA Certificate

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

revoke all certificates issued by that CA before the change!





Certificate Publish Methods

Certificate Publish Methods describe the current publishing methods for certifi-cates issued with the CA. The line shows the current protocol and server address, if

applicable. The configuration can be changed on the Edit Certificate PublishingMethod page by clicking the Edit Publish button. See Section 2.8 (Publishing Set-tings).

CA Auto Renew

CA keys (and certificate) can be automatically renewed. The Renewal period fieldshows how much in advance the keys are renewed prior to the current certificate expi-

ration. Time until next renew field shows how much time is left before the next re-

newal. 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, ThisUpdate 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 thatthe next CRL is still published according to the old update settings. The CRL Updateinformation 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 ViewCurrent CRL. The system generates the CRL with the validity period starting from thecurrent time and ending after a configurable amount of time. (This is configured withthe engine configuration file.)

Advance is the time marginal reserved for CRL generation. For example, if UpdatePeriod is 600 (10 minutes) and Advance is 120 (2 minutes), the system will every 8minutes publish a CRL with a lifetime of 10 minutes. This is to ensure some overlapperiod, 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 publica-

tion time of the CRL is 13:00, the thisUpdate field is set to 12:30. The option is use-ful to accomodate for PKI client clocks that are slightly off. PKI clients could, for ex-ample, 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 ex-

ample, if Update Period has been set to 3600 (1 hour) and Next Update Offset to7200 (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 isdown or unreachable.

The CRL Update Type can be either periodic update only, or update after each revo-

cation. 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 situa-tions, this option provides a useful substitute for OCSP. Note, however, that all clientsdo not necessarily get this new CRL if their old CRL is still valid (based on the update





period). In environments that require true real-time certificate status information, onlyOCSP should be used.

By clicking the Edit Publish button on the CRL Publish Methods row the distribu-tion 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, SHA-256, SHA-384 or SHA-512. SHA-1 is the default. Signature algorithm depends on keytype (RSA or ECDSA).

Other Settings

The Next serial number is a CA specific counter for serial numbers assigned forcertificates issued by the CA. It is normally increased by a random value after each is-

suance. This value can be used to set a starting point of a serial number space for theCA, 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 CommitChanges button.

The Edit Policy button will display the separate policy editing page where the policyof 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 alllog events related to this CA.

Restarting Publishing

Clicking the Restart publishing unpublished certificates button will search all ac-

tive certificates issued by this CA that have pending or error as their publishing sta-tus. One by one, it tries to republish them. This is useful if many certificates havefailed to publish correctly because of a network problem or misconfigured publishinginformation. The process is only started when this button is clicked and will continue inthe background until finished.

The Restart publishing all certificates button is similar, but will instead republishall 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 Da-tabase 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 thenext update marked into the current CRL.





Via the View log link you can see the log items related to the distribution point. ViewCRL link shows the current CRL in PEM format. The Generate CRL link can be usedto 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 self-signed certificate is issued for the key.

Also two additional certificates are issued: one for the old key signed with the new keyand one for the new key signed with the old key. These certificates can be used tomaintain trust relationship during the transition period when some of the clients areusing certificates from the new CA key and some are still using certificates from theold 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 forthe corresponding CA.

Renew marginal is the time how much CA certificate has validity time left before therenewal takes place. The value can be given as days, e.g. 30d.

Note: renewal marginal cannot be longer than ¼ of the certificate life time. Greatervalues 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.





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 displayedonly if CA certificate has been renewed.

Inactive CA renewal

Inactive renewal works the same way as normal renewal, except the resulting certifi-cates are not taken into use. This means that the certificates are active and linked tothe CA, but the CA still operates using the previous certificate and private key. Tomake certificates operational, the certificates must be activated.

Inactive certificates must always be manually activated by the operator . Theyare not automatically activated even if the current operational CA certificate ex-pires.

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 acti-

vated, the new certificates will overwrite the previous.

If the current operational certificate is expired, inactive renewal generates thenew CA certificate but not cross certificates.

Selecting Manual renewal will reset inactive renewal. Certificates generatedwith 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 insideInactive renewal data box. By selecting Activate the certificates are taken intouse. Note that this operation cannot be undone.





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 normalautomatic renewal. If inactive information exists, the automatic renewal interval is cal-culated using certificate created in inactive renewal. Otherwise interval is calculatedusing current operational CA certificate. SNMP notification “CA certificate expires” in-

cludes attribute which informs inactive mode state.

If a CA is issuer to sub CAs, Renew sub(s) with inactive? option selects if the subCA renewal will be issued using root CA's current operational certificate or certificatefrom inactive renewal. When enabled, the CA will issue sub CA certificates using itscertificate from inactive renewal. When disabled, the CA will issue sub CA certificatesusing its current operation certificate. The latter is the standard way. Option will havean effect to all sub CAs under the CA. If the CA is not an issuer to any sub CAs, thisoption has no effect. Option does not affect normal certificate enrollment. End entitycertificates are enrolled under the operation CA certificate until inactive certificate isactivated.

2.7 Registration Authority Settings

In Insta Certifier, an RA is in many ways similar to a CA. However, the RA creation isa bit different, since RA usually enrolls its certificate from a CA which is not running onthe same installation.

When using a remote CA (not running on the same installation) pre-requisities for RAcreation 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 canuse when performing the RA certificate enrollment. See Section 2.10.1 (Creatinga Delegated RA Entity).

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

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.





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 RAdoes not have any CRL settings. On the other hand, RAs need to have a connectionto a remote CA, so there are additional settings related to the RA-CA connection.





Figure 2-23 The Registration Authority page

The first field, CA name, is a short and descriptive name that operators can easilyidentify. 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 thename 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 CAwithin the same installation.





In case direct CMP connection is used, Connection Path is an HTTP URL ofthe CMP Service on the CA host.

If the CMP request is written to a file, Connection Path is the file name. This op-tion 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 exe-

cuted when communicating with the CA. The generated RA message is written toa 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 acceptedcertificates. 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 ProcessOffline CA Response page, where a PEM-encoded CMP message can be insertedto 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 certificatesissued through the RA. The line shows the current protocol and server address, if ap-

plicable. The configuration can be changed on the Edit Certificate PublishingMethod page by clicking the Edit Publish button. See Section 2.8 (Publishing Set-

tings).

RA Certificate

The RA certificate can be viewed by clicking the View Certificate button on the RAcertificate 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. Thiswill 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 RACertificate).

Other Options

Changes made to the RA data can be updated to Database by clicking the CommitChanges button.

The Edit Policy button will display the separate policy editing page where the policyof the RA can be viewed and modified. See document Policy chain and modules.

View Log shows all log events related to this RA.





Restarting Publishing

Clicking the Restart publishing unpublished certificates button will search all ac-

tive 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 havefailed to publish correctly because of a network problem or misconfigured publishinginformation. The process is only started when this button is clicked and will continue inthe background until finished.

The Restart publishing all certificates button is similar, but will instead republishall active certificates of this RA. This can be used, for example, if the LDAP server haschanged 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 Da-tabase 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 youhave given the CMP URL on the RA page, the CA address will already be filled. Oth-

erwise 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 nameof 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 KeyGeneration Parameters. This opens the Key Generation / Import page whereyou can edit the key attributes.





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 Certifi-cate. 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 thepending request.

2.7.4 Using a Local CA with RA

To use a local CA, select Local as Connection type. This setting affects the RAfunctionality in the following ways:

The new RA certificate request is processed as a request within the same Certifi-er instance where the RA is running. In other words, the RA’s own certificate isenrolled locally.

When a certification request is addressed to the RA, it forwards the request afterinitial 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’spolicy. If the module is not used, the target CA will be the same that issued theRA’s own certificate.

2.8 Publishing Settings

The CA needs a configuration that tells it how the CRLs and certificates are to be pub-lished. This is done with a generic publishing method configuration.

The publishing methods supported by Insta Certifier are Lightweight Directory AccessProtocol (LDAP) and HTTP. Also external methods can be plugged in the system andrevocation 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.





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 in-stance 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 iscorrectly configured and it has access to the LDAP directory.

Note that LDAPv3 is recommended over LDAPv2 for its better security and compati-bility between different implementations.

CRL Distribution

In LDAP publishing, the CRL distribution point can be included either as an LDAPURL 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.





Object Name Format

The object name format is the path name used when adding the object to the directo-ry. 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 arewritten as %{name}.

LDAP object name is a distinguished name and therefore must be structured as OIDand value pairs. Most commonly used OIDs can be written using their symbolicnames but they can also be given as numeric OID values. Very probably the certifi-cates and CRLs should be published to exactly the location implied by the subjectname of the certificate (or the issuing CA subject name in the CRL case). If this is notthe case, various PKI clients will not be able to automatically perform certificate pathconstruction 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 pieceby piece. For example, the following object name format string for certificate publish-ing would take the organization (O) from the subject name of the certificate issuer, thecommon name (CN) from the subject name of the certificate, and finally add the serialnumber 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 param-eter can be appended to specify a RDN within the subject name. If the subjectname is, for example, C=FI,O=Insta,CN=Test Person, the field %{subject-

name: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, %{ca-subject-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 val-ue is used even if the entity contains multiple attributes of the same type. For ex-

ample, %{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 publishmethod this is the same as ca-serial-number.





%{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 withfunction given as a parameter. This allows an extensible way to define objectnames. Same functions are also usable in LDAP attribute definitions.

Usually the subject name is a good choice for the certificate’s path name and the subject name of the CA certificate for certificate revocation lists. Note that the object pathgiven here is expected to be in the same order as all other distinguished names in In-sta 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 beconfigured 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 theLDAP attribute table.

The attribute table contains columns for attribute name, value, and type. AttributeName is a string that identifies the attribute in the LDAP system. How the Value fieldis 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) isstored to the attribute as binary data. This can be an end-user certificate or a sub-CA certificate, depending on the type of certificate that was issued. Alternatively,the serial number, validity period start or end, or Netscape comment extension ofthe certificate can be stored.

CA Certificate

The entire CA certificate (of the issuing CA) associated with the operation is storedto the attribute as binary data. Other values can also be stored as in the User Cer-

tificate case.CRL

The certificate revocation list (CRL) is generated and stored to the attribute as bi-nary 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 the user certificate is used.

IP Address Extension





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 RDNfrom 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 attrib-ute. If the entity has several attributes of the same type, only the first attribute or allattributes 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 thema 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 re-placed 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 LDAPdirectory. If the object does not exist, the system performs an add operation with thegiven path name and attribute. If the object already exists, the system performs thepublishing action selected for the attribute. The actions can be:

Update by replace: The system tries to perform a replace-type modify opera-tion. This means that previous values of the attribute are replaced with the newvalue(s), creating the attribute if it did not exist. If this fails, the publishing attemptfails and the engine can either mark the publishing attempt as failed or restart theoperation 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 attributevalues, creating the attribute if it did not exist. If this fails, the publishing attemptfails.





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 schemaand 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 objectclasses 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 todefault 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 structuralobject 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 andclicking 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 afull-scale LDAP deployment: The built-in HTTP server of the Web Enrollment Servicecan be used for CRL publishing.

If you have chosen the HTTP publishing method for CRLs, the only setting that needsto be defined is the Web Enrollment Service instance that is being used for CRL pub-

lishing. Remember to enable CRL publishing in the Web Enrollment Service configu-





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 us-ing the system. Operators marked as inactive are not allowed to log into the system. Ifthey are already logged in, they are not allowed to update anything.





Access Control

Every operator has to have at least one access control item, defining what types ofoperations 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 accesscontrol 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 custom-

ized. 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 to entity andcertificate management are shown.

If Simple Admin UI is selected, the operator will use a simplified user interface thatcontains only the functions for creating and editing entities and revoking and suspend-ing 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 Timeformat can be selected here. If autodetect is selected as the Timezone, Insta Cer-tifier uses the time zone information of the browser. The time values (e.g. certificatevalidity and issuing times) are displayed in the GUI according to the time zone setting.

When entering time values in text boxes, use the time format specified for the opera-

tor 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 ofattributes 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 toidentity and contact each other. If the operators require TLS client certificates, the en-

tity attributes can be included in the certificates if a suitable policy module is used inthe CA policy.

Pre-Shared Keys and Certificates

Operators may have pre-shared keys just like entities. Shared keys are used to au-thenticate operators when they are enrolling TLS client certificates for themselves.

These certificates can be used to authenticate operators when they log in to the Ad-ministration Service. Passwords are not necessarily needed when TLS with client au-thentication is used. TLS with client authentication has to be defined on the Admin-istration Service configuration page. See Section 2.11.2 (Editing the Administration

Service).





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 givethe key when enrolling a certificate through the Web Enrollment Service. The CA whois authorized to issue operator client certificates can be selected on the configurationpage of the Administrator Service. Instruct the operator to select this CA during theenrollment.

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 opera-

tor and the View Log button shows all log events that this operator has been involvedin. So if one operator changes another operator’s phone number, that can be dis-played by clicking the first button, but if this operator accepts a request, that can bedisplayed by clicking the second button.

Removing an Operator

Click the Remove Operator button to remove the operator from the system. Be care-ful 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 op-erations the operator is allowed to perform. These operations can be restricted for cer-tain kind of operations (read , entity write, write, write and key recovery , and super-user ) and/or for certain CAs and RAs in the system. This enables adding administra-tors that are allowed to configure only one specific logical CA or RA in the system. Al-so, by using access control levels, lower and higher privileged operators can be add-ed.

Insta Certifier supports the following access control levels:

Read access

Read access for certain CA in the system means that the administrator is author-ized to view any information related to the CA. However, this access control leveldoes not allow any modification such as certification request approval, entity modi-fications 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





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 phonenumbers or e-mail address. The operator can also revoke certificates belonging tothe 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 revokingand suspending valid certificates. This is an appropriate authorization level for op-erators 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 ad-dition the operator can access escrowed private keys.Note that this access level gives the operator access to sensitive information (userprivate keys), and should be given to operators only if they are required to do keyrecovery operations.

Super-user access

A super user is allowed to perform any operation related to specific CA. These op-erations include modifying CA settings such as certificate policy and publishingschemas. As a super user has full control over the policy of the CA and access to escrowedprivate keys, this access level should be used only when it is necessary.

Configuring servers and creating and updating other operators requires Super-user 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, Readand revocation access, Entity write access, Write access, Write and keyrecovery access, or Super-user access).





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 ac-cess all logical CAs in the system.

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

The fourth menu can be used to set additional Constraints that limit the operator’srights 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 constraintfrom the list and enter the pattern to be matched in the text box. Several constraintscan be added.

To remove a constraint, click Remove next to it.

Example: Email is selected as the Entity attribute constraint, and the pattern is thefollowing:

ˆ[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 theoperator edits a request or a certificate belonging to an entity.

Certificate constrains are verified only when the operator manages a request or a cer-tificate.

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).





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 spe-cific 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, RAdelegation typically has deeper implications to the PKI than just authorizing an endentity 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 existingdelegated 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 CreateNew 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 descrip-

tion can be specified in the RA Entity name and RA Entity description fields. Con-

firm the addition by clicking the Create button. The Cancel button can be used tocancel 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 click-

ing Add.

An attribute can be removed by clicking the Remove button on the right hand side ofthe attribute.

Click Create to create the entity. This opens the Delegated Registration Authority Entity page where the entity can be further edited.





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 au-

thentication. A new pre-shared key can be added by clicking Add next to the Pre-

shared keys box. The reference number and key need to be provided for the RAadministration who is performing the RA certificate enrollment.

After the RA has enrolled its RA certificate, it will be shown in the RA ClientCertificates field of the page.

A delegated RA entity should have access to a CA within the same Insta Certifier in-

stallation. The access control can be defined by editing the Access Control list. Bydefault, the RA entity can request certification from any CA. Approval is subject to theCA 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 ApprovedCertificates button. (Clicking these buttons initiates a database search with appro-priate search criteria.)





The third menu (Rule scope) can be used to decide whether also subordinate CAs ofthe 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 ofthis policy takes place when a request arrives from a remote RA to the CA (the RAhas 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 pol-

icy can be edited by clicking Edit Policy on the Delegated Registration AuthorityEntity page.

2.11 Certifier Servers and Services

The modular architecture of Insta Certifier provides a flexible way to centrally managethe various PKI frontend interfaces and optionally distribute them to different hosts.This allows scalability for large deployments, but on the other hand, more limited PKIdeployments can be easily implemented since only the required mandatory servicesneed to be taken into use.

In addition to the Certifier Engine, there needs to be at least one Certifier Server in-stance 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 instancesrunning 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 installationone Server instance is created to provide the Administration and Web Enrollment Ser-vices.

To add a new Server instance, click the Add New Server button. After this, you needto 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.





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 apre-shared key added to it.

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

See Insta Certifier Administrator’s Guide for more instructions.

After the new Certifier Server is installed and connected to the Certifier Engine itneeds to be configured by adding at least one Certifier Service. The currently sup-ported Certifier Services are:

Administration Service

CMP Service

External Enrollment Client Service

LDAP Authentication Service

OCSP Responder Service

Publishing Service

SCEP Service

Web Enrollment Service





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 Serv-er. You can just add the needed Service to some existing Server. This is a much eas-ier 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 parame-

ters. 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 tosecure the communication between the Server and Certifier Engine. In addition, someof the Services may have certificates. For example, the OCSP Responder Serviceneeds 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





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 bechanged, 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 auto-matically 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 CertifierSubordinate Servers. Normally a server needs only one pre-shared key and it can be





removed after the service is running. A server does not need a pre-shared key duringnormal operation and it can renew its certificate automatically.

However if a service installation has been erased or if it has not been used for sometime, 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 ViewLog 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 toprovide the web-based administration interface for the administrators. An Administra-tion 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 thenew service has been validated. This is a precaution, to avoid a situation where theadministrator has selected the security settings of the Administration Service, andcannot access the system any more since she has not enrolled an administrator certif-icate for herself. Also if there are problems in the administration configurations, similarproblems may arise.





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 ofuse.

The Service bind address is the address where the Administration Service listens toincoming HTTP and HTTPS connections. Remember to include the port number in theaddress. 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 beginwith 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 newtemplates have been customized by the customer, only one template set is available

( Administration Interface). The template sets are located in the Insta Certifier in-





stallation directory under admin-templates/ (the default set is in the admin-

templates/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 se-lected, the Service allows all operations.

Each operator has an access level as described in Section 2.9.3 (Operator AccessControl Levels). If the operator has lower access level than the Service, the operator’saccess 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 ProtectedHTTP connection, the server has a certificate that it uses for authentication. All con-nections are encrypted when using this option. However, the client (administrator) hasto 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 cer-tificate in order to connect to the server. If this mode is being used, administratorpasswords are not mandatory, since the client private key is used for the authentica-tion instead of password. You should also make sure there are no other Administra-

tion 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 TLSServer Certificate CA field. Insta Certifier Internal CA, which is created during theinstallation, can be used, unless a dedicated CA is wanted for this purpose. In the lat-ter case, the same CA that is used for a protected Web Enrollment Service can beused. See Section 2.11.10 (Editing the Web Enrollment Service).

When the TLS settings of the Administration Service are turned on, the service cre-

ates a private key and enrolls a TLS server certificate for itself. Validity periodlength and Key size can be selected in the TLS Server Certificate Settings. Thevalidity 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 certifi-cate 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 selectedCAs, 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 Ser-

vice, 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.3 Editing the CMP Service

Certificate Management Protocol (CMP) is an online certificate life-cycle managementprotocol that provides functions such as initial enrollment, certificate renewal, key up-date, and revocation request. Within Insta Certifier, CMP is used in the RA-CA com-munication. 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, thesystem needs to have a CMP Service for providing the server-side functionality of theCMP.





Figure 2-36 Editing the CMP Service configuration

Basic Settings






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

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 Servicedomain 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 pag-es. 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 re-sponse are placed into a caPubs field or extraCerts field of the message. If caPubsfield is chosen only the signing CA certificate is sent. If extraCerts is chosen the wholeCA chain from the signing CA to the root CA is sent.

Deliver CA dynamically enabled, CA delivery depends on the CMP request. If re-quest includes CA certificates in extraCerts field, CA certificates are delivered in ex-traCerts. If CA certificates are in caPubs, CA certificate is delivered in caPubs. Whenoption is disabled, delivery depends on Deliver CA in field option.

Deliver root certificate in extraCerts (KUP) enabled the root CA certificate is in-cluded in KUR extraCerts field. When option disabled, KUR extraCerts included all in-termediate CA certificates, but not the root. In short, when enabled, KUR extraCertswill not contain self-signed CA certificate.

Options

Protection hash algorithm selection can be used to specify which hash algorithm isused when calculating CMP message protection signature. The default auto optionchooses the algorithm automatically based on the signing key size, but some clientsoftware may not support all hash algorithms.

CA certificate delivery method in response

These settings specify which CMP response message field is used for delivering theCA certificate.

Allowed Operations

The Allowed operations check boxes can be used to select the CMP operationsthat 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 authenticationmethod.

Allow enrollment based on existing certificate (signature)

Allows a certificate holder to request another certificate using the signature (withthe key bound to the existing certificate) as the authentication method.





Allow revocation requests

Allows a certificate holder to request revocation of an certificate using the pre-shared 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 authen-tication 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 hasto authenticate itself using another key bound to the same entity. Key recovery re-quests 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




2.11.4 Editing the External Enrollment Client Service

An External Enrollment Client Service is needed when an RA requests certificationfrom a CA or when a CA requests a cross-certificate or a sub-CA certificate from anexternal 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








2.11.5 Editing the LDAP Authentication Service

The LDAP Authentication Service is used for LDAP-based authentication in web en-rollment 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



LDAP Settings

The LDAP Server Address and Port number specify the address of the directoryserver 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 inthe 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





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 (LDAPPublishing 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 correctLDAP Authentication Service.

Commiting Changes




2.11.6 Editing the OCSP Responder Service

The Online Certificate Status Protocol (OCSP) can be used to provide online certifi-cate status information for the end entities within the PKI. OCSP can be seen as a re-placement for CRL, and it may be a more appropriate method in environments wheresignatures of individual transactions need to be validated with up-to-date revocationinformation.

The OCSP Responder Service of Insta Certifier can be used to answer clients’ statusrequests concerning one or more of the Certifier CAs. Currently the OCSP respondercan provide status information only for those certificates that are issued by CAs thatare managed within the Certifier installation.





Figure 2-38 Editing the OCSP Responder Service configuration

Basic Settings



Service bind address is an HTTP URL, since OCSP uses HTTP as a transportmechanism.

Allowed Operations

If the check box under Allowed operations is selected, an OCSP client can requeststatus information without signing the request.

Certificate Settings

The OCSP responder needs to have a private key and a certificate, so that end enti-ties can validate the signed OCSP responses. Once the OCSP Responder Service iscreated, 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.





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 informationextension field of the issued end-entity certificates, if the extension is included in theCA policy. End entities will use this field to connect to the OCSP responder. This defi-

nition can be left empty, in which case the Service bind address field is used as adefault value. However, please note that this address must be accessible from all cli-ents 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




2.11.7 Editing the Validation Authority Service

The Validation Authority Service of Insta Certifier can be used to answer clients’ sta-tus requests concerning one or more of the Certifier CAs. Currently the Validation Au-thority service can provide similar information as the OCSP responder service. Thedifference is in the way that the certificate status information fetched and maintainedby the service.





Figure 2-39 Editing the Validation Authority Service configuration

Basic Settings


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

use.





Service bind address is an HTTP URL, since OCSP uses HTTP as a transportmechanism.

Allowed Operations

If the check box Requests without signature is selected, an OCSP client can re-quest status information without signing the request.

OCSP Response Generation Settings

Cache mode options are: Cache status only which means that certificate statuscache 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 thecache is filled with responses at startup.

In each case the status and/or responses are maintained based on the information inthe Certifier database.

Validation Authority Certificate Settings

The service needs to have a private key and a certificate, so that end entities can val-idate 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 informationextension field of the issued end-entity certificates, if the extension is included in theCA policy. End entities will use this field to connect to the OCSP responder. This defi-

nition can be left empty, in which case the Service bind address field is used as adefault value. However, please note that this address must be accessible from all cli-

ents 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 multipledifferent CAs. The accessible CAs may be selected. It should be noted however, thatthe responses are signed with a certificate from a single CA only.





Commiting Changes




2.11.8 Editing the Publishing Service

If LDAP or external commands are used to publish certificates, CRLs or other entitydata in the directory, then at least one Publishing Service needs to be added in thesystem. Publishing Service is not required when HTTP is used to publish CRLs.

Publishing Service represents a connection to a specific LDAP directory. PublishingService is also used for running external publishing commands. There may be morethan one Publishing Service in a single Certifier Server instance, if several CAs pub-

lish to different directories, or if single CAs publish to several directories.

Figure 2-40 Editing the Publishing Service configuration





Basic Settings



LDAP Settings

The LDAP Server Address and Port number specify the address of the directoryserver (for example, directory.certificate.fi and 389, the default LDAP

port).

LDAP Username and LDAP Password are normally also required for directory ac-cess. Permission to add and modify objects within the object hierarchy must be con-

figured 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, theremight be several network interfaces in the directory server, and the one that the Pub-lishing Service is using can be different than the one the end entities use when con-necting 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 bespecified 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 publish-ing data and send it to an external command for further processing. The commandline can be given in the text box.

Security Settings

LDAP publishing can be protected by TLS. The relevant settings are made under TLSSettings. 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 eliminatesthe need for an LDAP password. Select the client authentication CA from the list.





References

The References field shows the number of CAs that use this Publishing Service forpublishing CRLs. The field is intended to warn the operator that removing the Publish-

ing Service disables CRL publishing and may thus compromise the security of thePKI. 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 theremay be a valid reason to remove a Publishing Service used only for certificate pub-lishing, hence no warning is given.

Committing Changes




2.11.9 Editing the SCEP Service

Several VPN gateways and VPN clients support the Simple Certificate EnrollmentProtocol (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 Ser-vice can be used to provide this service in Insta Certifier.

Figure 2-41 Editing the SCEP Service configuration





Basic Settings



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 qualifieddomain name). If the field is left empty, the name is generated from the Service bindaddress.

Service domain name and Service description are shown on the web enrollment pag-es. 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 anentity to a request. If an LDAP Authentication Service has been defined, it can be se-

lected. Otherwise only Pre-Shared Key can be selected.

Commiting Changes




2.11.10 Editing the Web Enrollment Service

The Web Enrollment Service can be used to provide enrollment pages for browser-based PKI clients. Default enrollment pages of the Web Enrollment Service includepages (designed for both MS Internet Explorer and Netscape Navigator) that can beused to generate private keys and post certification requests to the Web EnrollmentService. A PKCS #10 enrollment page is also offered to enable submitting certificationrequests that are generated by other PKI clients. There are also some account man-agement functionality that browser users can use to manage their own certificates.





Figure 2-42 Editing the Web Enrollment Service configuration





Basic Settings



The Service bind address is the address where the Web Enrollment Service listensto incoming HTTP and HTTPS connections. Remember to include the port number inthe address. For example, http://0.0.0.0:8080/ is an address for a service running onthe local host listening to port 8080. Remember that the Service bind address has tobegin 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 HTTPas an operational protocol to fetch CRLs. To enable this function, select DistributeCRLs for all accessible CAs. If a CA has a publishing method, which uses the WebEnrollment 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 forCRL distribution points field. This should be an URL containing scheme, host andport parts, ending in a slash. Note that the given URL must be accessible from all cli-ents. For example http://enroll.big-corp.com:8080/ is a valid URL prefix. If the URLprefix 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 brows-

er and the server are plain text. By selecting TLS Protected HTTP connection, theserver has a certificate, which it uses for authentication. All connections are encryptedwhen 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 authen-tication has to be selected, if account management is going to be used. However, ifthis is the case, there should be another Web Enrollment Service running without TLSclient 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 TLSserver 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. Thesame CA that is used for a protected Administration Service can be used. See Section2.11.2 (Editing the Administration Service).

When the TLS settings of the Web Enrollment Service are turned on, the service cre-

ates a private key and enrolls a TLS server certificate for itself. Validity periodlength and Key size can be selected in the TLS Server Certificate Settings. Thevalidity 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 certifi-cate 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 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 selectedCAs, 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 Ser-

vice, 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 WebEnrollment Service. We might not want to have all CAs visible to every end user. Alsoit might be the case that CAs form certain groups that are dedicated to certain organi-zations. 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 Allexcept 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 UserInterface 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 UserInterface 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 tomap 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




2.11.11 Customizing the Web Enrollment Pages

When browser-based enrollment services are provided, the enrollment pages shouldbe 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 us-er. Basic customization can be done easily via the Administration Service.





Sometimes, it may also be desirable to match the layout and graphics of the pageswith the appearance of the site where the enrollment services are provided. While theadministration GUI is seen only by a couple of operators, the enrollment pages maybe visible to tens of thousands of end users. In this case, the actual HTML templateswith 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 customizingthe 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 andrenew them. Account Management can be disabled, allowed with TLS client au-





thentication, or allowed with TLS or password authentication. If account managementis 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 tem-plates have been customized by the customer, only one template set is available

(Web Enrollment Interface). The template sets are located in the Insta Certifier in-stallation directory under enroll-templates/ (the default set is in the enroll-

templates/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 in-

formation, Insta Certifier creates an entity and a pre-shared key for the user andsends the pre-shared key to the given e-mail address. This method is not crypto-graphically secure, but nevertheless may be useful in some cases. In addition to al-lowing registration on this page, the operator has to edit the lib/ssh-ca-notify-

email 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 bespecifically allowed or disallowed. If the option is disallowed, the users cannot sus-

pend their TLS client authentication certificate used for logging in to the Web Enroll-ment Service.

Revocation with PSK can be disabled or allowed. This option is independent of ac-count management settings. If the option is allowed, the users can suspend certifi-cates bound to a specific pre-shared key (PSK). The PSK use count is not affected bythis. Activating revocation with PSK requires that the Web Enrollment Service usesTLS protection.

Enrollment Methods

PKCS#10 enrollment and browser enrollment are available through the Web Enroll-ment Service. By selecting Hide PKCS-10 enrollment or Hide Netscape/IEenrollment under Enrollment Methods, links for PKCS#10 enrollment or browserenrollment, respectively, can be hidden. However, the enrollment pages are not disa-bled, and they can still be accessed by typing the page URL in the location bar of thebrowser.

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).





Advanced Request Editing

Advanced Request Editing can be allowed or disabled. It is also possible to allowonly advanced request editing.

Internet Explorer Options

Additional key options that are available on Microsoft Internet Explorer can be set un-

der MSIE Key Generation.

If a check box is selected, the corresponding option is shown on the MS IE enrollmentpages. 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 keysize is set to 1024, the user cannot select the key size when submitting the requestbut 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 canbe 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 textbox.

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 fromthe 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 modi-

fied. 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.





Figure 2-44 Customizing the Web Enrollment Service

For subject name components, a default value can be given. To allow editing the val-

ue, 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 boxprevents editing the requested key usages.





Click Continue to accept the settings and return to the Edit Configuration for WebEnrollment 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.





2.12.1 Editing System Parameters





Figure 2-45 The System Parameters page

Engine-Server TLS Settings

All communication between Certifier Engine and Certifier Server instances is securedwith TLS to provide authentication, integrity, and confidentiality for the communica-tions. This is especially important in largescale deployments where Insta Certifierfunctionality, 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 TLScertificates for Certifier Server instances. Also the Certifier Engine needs to have anown 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 EditSystem 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 thepreferred 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 forvalid server entity, as the Certifier Engine and Certifier Servers need to renew theircertificates in regular intervals to stay operational.

To view Certifier Engine’s TLS certificate, click View Certificate button. You can al-

so change it to another certificate by clicking the Change button, and then searchingfor 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 thereare enough active operator accounts in the system. This is because adding a new op-erator under multi approval requires approval from a specified number of operatorsbefore the new operator can be added. Insta Certifier contains only one operator afterthe initial setup.

When multi approval is in use, all add, modify, delete, and write operations except cer-tain HSM-related operations require dual/multiple operator approval.

To enable Multi Approval, select the corresponding check box. Enter the Numberof Approvals needed before a change set can be commited.

Select the Multi Approval Scope. If Multi approval required for system serviceconfiguration is selected, all system level operations (for example, new root CAcreation, server and service configuration) require multi approval process.





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 exceptselected 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 Sec-tion 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. Achange 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 thePending 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 nextto the listed change. The object is shown with a grayed ”page header” and ”footer”with additional info on the change set in the header.





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 com-

mited. Click Commit to make the change set active. After commiting, the changestake 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 becreated, crosscertification is involved. In the case of independent PKI domains, twoCAs may both issue CA certificates for each other. In the case of sub-CA creation, on-ly 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.





Figure 2-48 Searching for certificate requests

Type in some search criteria and click the Search button to see the list of certificaterequests 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 theCA certificate page. This operation will create a in the database a request that can beused 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 corre-sponding field. In the case of CMP, a list of available remote Certifier CAs can be que-

ried 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 ini-tiate 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 buttonto view the certificate request. When performing manual cross-certification, the re-quest needs to be copied and pasted to a file and then sent to the CA.





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 certification re-quest is sent to the CA, the issued cross-certificate has to be inserted in the Insta Cer-

tifier 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 but-

ton and select from the Associated Request field the request that corresponds tothe 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 thecontents of the issued cross-certificate.





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 certifi-

cate. Private key data can either be a software private key in PKCS#1, PKCS#8 orPKCS#12 format or information about private key stored in hardware token and ac-cessed through PKCS#11. In that case the import operation stored only access infor-mation to database, the key itself is not imported.

Note that when a key is imported, the old private key data stored to certificate is re-moved and this operation cannot be undone. Also note that this operation only affectsone certificate. Any other certificates with same private key data are unaffected. Keymust be imported to them separately (or their keys removed) if old key data needs tobe 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 andthen importing it to the hardware token. The key can then used in Certifier by import-ing it back.





Import Private Key option automatically recognizes if a matching PKCS#11 privatekey is present. Please configure and insert the right token before starting the importoperation. If no PKCS#11 key is detected, the user is given an option to import a soft-ware key instead.

Software key import needs an base-64-encoded (PEM-encoded) private key file whichis copied to Software private key input box. Private Key Format field can usuallybe 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 de-coding encrypted private key files like PKCS#8 or PKCS#12 and is not used other-wise.

2.12.7 Creating Certificates

The Create Certificate option allows creating a new certificate in the system. Click-

ing the button will open the Make New Certificate page, which is very similar to theregular 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.





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

Validity period defaults to the current time. At least Not after should be changed toa later value.

Key generation parameters can be adjusted by clicking Set Key GenerationParameters. This opens the Key Generation / Import page. On this page, KeyProvider Type, Key type, and Key size can be selected. If a hardware securitymodule (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.





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 toperform 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 acertificate from external CA in CMP init message. This behaviour is specified in RFC4210 E.7. In-Band Initialization Using External Identity Certificate.

The list of Trust Anchors show the TA certificate subject and issuer fields, status, seri-al number and validity times. By clicking the subject name link a Trust Anchor pageopens 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 requiredwhen 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 tovar/pki/trust_anchor_crls/failed.

Successfully added CRLs are stored into the Certifier database, thus the files in ok di-

rectory are not required and can be removed.

CRL date field shows the CRL issuing time. Note that CRLs do not have an expirationtime. Only the latest CRL added to the database will be used. CRLs that are issuedearlier 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 acertificate 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 ata time. The CRL is used as long as it is not removed or replaced with a new. Whenadding a CRL, the issuing date is checked and only a newer CRL will replace the oldone.

Path validation

If there exists a sub CA hierarchy between the Trust Anchor certificate and the endentity certificate used in signing the CMP initialization message, then the sub CA cer-tificates should be included in the extraCerts field of the CMP message to enable cer-

tificate path construction and validation. When sub CA certificates are received, theyare also stored along with the TA certificate. This means that the certificate path will





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

2.12.10 Changing the Master Password

All Certifier software private keys are stored in encrypted format in the internal data-base. Also the PIN codes of the hardware security modules, if being used, are en-crypted in the Database. Every Certifier installation has a master password, which isused to protect these objects. If the master password is lost, the whole PKI systemmay become inoperational, since the CA and RA software private keys (as well asother encrypted information) cannot be accessed any more. Therefore it is critical tobe extremely careful when changing this password!

After a new Insta Certifier installation, the password equals an empty string. Thismeans 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 newpassword. When checked the new password will be stored into the database in en-crypted 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. Masterpassword policy is defined in system parameters.





After the master password has been taken in use, it has to be given to Insta Certifierevery time the Engine is restarted - otherwise signature operations will not be possi-ble. 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 provid-ed in the Administration Service by an administrator. After operator login, the masterpassword 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 suchcases the master password is asked also at reboot (if not stored to database). How-ever, the interactive screen may not be visible by default and may lead to systemhang. To prevent this, the interactive screen should be made visible (e.g. by clickingesc-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 hardwaretokens that need PIN codes. These CAs aren’t available until their passphrase havebeen given through this page.

2.12.12 User-Defined Policy Modules

Custom policy modules can be created under User Defined Policy Modules. Thecustom 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 mod-ule 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 canadd 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).





conditional test

Test clauses (IF, ELSE IF) of the Conditional policy module. See document Policychain and modules.

2.12.13 Viewing System Configuration

Clicking Show System Configuration shows a plain-text summmary of the InstaCertifier 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 es-

timated restart time. Click Continue to proceed with the shutdown.



Chapter 3: Certificate Life-Cycle Management Services


Chapter 3

Certificate Life-Cycle Management Ser-vices

In Insta Certifier, all end-entity actions are performed via Enrollment Services runningon 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 andsoftware 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 re-quest is passed on to be handled by CA policies. The requests are checked to beformally and cryptographically correct, and in case of CMP, the CMP protection isverified either by using a pre-shared key or a certificate. If the request passes re-

quirements 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. TheCMP Service acts as a server for handling incoming CMP messages (including certifi-cation requests and revocation requests). The CMP Service can be configured to pro-vide either TCP or HTTP-based transport for the Certificate Management Protocol(CMP).

The CMP implementation of Insta Certifier is based on RFC documents RFC4210 andRFC4211 also known as CMPv2. The CMP messages currently supported in the CMPService 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





In CMP, an end entity needs to send an initial request when the first certificate is en-rolled from a given CA. Consequent certification requests can be signed with the validprivate key to facilitate automatic key renewal. Revocation requests can be used to in-form 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 theURL is http://host:8080/pkix/. These parameters can be modified by editing the CMPService via the Certifier Administration Service. See Section 2.11.3 (Editing the CMPService).

The communication between RAs and CAs of Insta Certifier uses CMP. Also InstaToken Master, whether used as an RA or end entity, uses CMP for requesting certifi-cates from the CA or RA.

Insta Certifier ships with a simple command-line utility that supports the client side ofthe corresponding server-side functionality of the CMP Service. It can be used to gen-erate 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 Proto-col (SCEP). The SCEP protocol is described in the Internet-Draft document draft-nourse-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 thushttp://host:8080/scep/. These parameters have to be configured in the enrollment cli-ent which is typically a VPN client or a VPN gateway.

A prerequisite for SCEP enrollment is that the end entity has to have the appropriateCA certificate, which must have been verified using some offline method (fingerprintcheck). The verifications should be done to prevent man-in-the-middle attacks, inwhich someone is impersonating the CA. The CA certificate can be retrieved from theSCEP Service by an HTTP GET operation. In addition to the enrollment URL the endentity needs to know the name of the CA that identifies it within the Insta Certifier in-stallation. This is needed since there may be several CAs providing SCEP within asingle Certifier installation. The name that is used to identify CAs in SCEP implemen-tation 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 notused for this).

The initial end-entity authentication in SCEP is achieved either manually or by usingshared secrets. When using a pre-shared secret scheme, the Insta Certifier adminis-trator generates a pre-shared key (a password string) for an entity. The key is distrib-uted to the entity in a secure way. When the certification request is generated, theshared secret is then used as a challenge password inside the request. The SCEPService forwards the encrypted certification request to the Certifier Engine, whichfinds the policy bound to the preshared key and processes the request according tothe policy.

When using manual authentication, the end entity calculates the MD5 fingerprint onthe generated PKCS #10 certification request. When the Certifier Engine receives therequest from the SCEP Service, it stores the request in the Database as a pending





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 contain-ing the keygen tag is posted, the browser will generate a key pair, wrap the public keyinside a request, and post the result. The key pair is stored in the encrypted key stor-age (PKCS#12 format).

The request is submitted to the Web Enrollment Service, which parses it and forwardsit to Certifier Engine. If the certificate approval is configured to be automatic, theWebEnrollment Service pushes the issued certificate to the browser to be installed. If therequest has to be manually approved, it can be downloaded later, using the requestidentifier issued by the Certifier Engine, and displayed to the end entity instead of thecertificate.

When using Internet Explorer, a Microsoft ActiveX control (xenroll.dll) can be

used to perform the client-side enrollment, including the key generation. The controlprovides 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 canthen 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-ns-

start.html and enroll-ie-start.html, respectively. The options available on

these forms depend on the customization settings of the Web Enrollment Service. SeeSection 2.11.11 (Customizing the Web Enrollment Pages). The default options are

described below.





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 tobe used in an environment where these are required.

The user may also request a key usage extension for the certificate. The extensioncan 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 ex-tended 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 boxshould be selected in the request form.

The Certification Authority from whom the certificate is requested has to be se-lected in the web form. Only those active CAs that are included in the Accessible

CAs list can be chosen.





If the Web Enrollment Service connection is TLS protected, also a pre-shared key canbe given in the enrolment form to enable automatic certificate issuing. This field is notshown in the web enrollment page without TLS, since pre-shared keys should not besent 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. Theuser can select the cryptographic provider (CSP) to use for key operations. The avail-able providers depend on the Windows version. If cryptographic tokens, such as Aladdin eToken, have been installed to the system, the token specific providers willalso be available. Selecting a token-based provider will generate the key pair securelyon the token.

With IE, the user can also select the certificate store type, either current user orlocal machine (for Windows IPSec and L2TP). As the names imply, the first store isused for storing personal certificates (for e-mail and TLS) and the latter for storingmachine-specific certificates.

With IE, the user can also select to use Private key protection. Selecting this checkbox 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 timethe key is used. This is a suitable setting if the key is used for non-repudiationsignatures, but may be cumbersome if the key is used for TLS or IPSec authenti-cation.

Medium security level (default if private key protection is selected) will ask forconfirmation 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 forTLS or IPSec.

Low security level (default if private key protection is not selected) will not requireconfirmation from the user when the key is used.

Advanced Request Editing

If allowed by the Web Enrollment Service settings, the Advanced Options button isshown on the browser enrollment page. Clicking this button immediately begins key

generation. After the key has been generated the advanced editing page opens. Thelayout of this page is similar to the certification request processing page.





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 edit-

ing the fields, the request can be sent by clicking Submit Request.

URL Options

Optionally the pre-shared key, key size, the cryptographic service provider (InternetExplorer only) and other parameters can be given in the URL when either theenroll-ie-start.html, enroll-ns-start.html or simple-enroll.html

page templates are used. Use the ’?’ character in between the template name and theparameters, and the ’&’ character between the individual parameters.





All options just set the default values in the form. The corresponding selections arestill 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 a part of it (for example

Microsoft%20Enhanced%20Crypto)

protect : Set to no to turn the USER_PROTECT flag in key generation off. Low-

ers 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

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

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

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 a part of it (for example

Microsoft%20Enhanced%20Crypto)

protect : Set to no to turn the USER_PROTECT flag in key generation off. Low-

ers security but can be useful in some cases.

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

Defaults to current-user.

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

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





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 set-

ting 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-ie-start.html?keysize=2048&psk=ssh&csp=Microsoft%20Enhanced%20Cryptographic%20Provider%20v1.0https://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 inthis 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 asPEM, 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 Windows.

View Certificate

The CA/RA certificate details can be viewed with the Insta Certifier’s web-basedCertificate Viewer by clicking this button. The certificate can be downloaded in bi-

nary 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 selectSave).

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 but-ton (some web browsers require user to click right button of the mouse and to se-lect Save).

Download CRL as PEM

The current CRL of the CA can be downloaded in base-64-encoded (PEM) formatby clicking this button (some web browsers require user to click right button of themouse and to select Save).





3.3.4 Managing User Certificates

The Web Enrollment Service can be configured to allow account management capa-bilities for end users including suspension of the user certificates. These services re-

quire TLS-protected web enrollment connections. Also, account management has tobe specifically enabled in the Web Enrollment Service configuration page. See Sec-tion 2.11.11 (Customizing the Web Enrollment Pages).

Password or TLS client authentication can be used for logging in to the account-management-enabled Web Enrollment Service.

If password authentication is used, the Email address and Account Password at-tributes 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 en-tity by a Certifier operator. See Section 2.4.3 (Adding and Modifying Pre-SharedKeys). 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 whenshared keys are used in the enrollment. In effect, using TLS client authentication re-quires setting up two Web Enrollment Services, one for requesting the TLS client cer-tificate and another for the actual account management. When the certificate is is-sued, it is associated to the entity and can be used to log in to the Web EnrollmentService.

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 in-

formation, Insta Certifier creates an entity and a pre-shared key for the user andsends 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 pass-word 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 forvalid 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 pol-icy module.

Your Account

The Your Account main menu item available when the user has logged in the WebEnrollment Service using an account. Clicking the menu item displays all pending re-quests and issued certificates of the user. All of the certificates may not be stored inthe certificate storages of the browser (such as PKCS#10 enrolled VPN certificates).





But also these certificates can be viewed if they are associated to the user entity withpre-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 the privatekey. If the certificate that is used for TLS client authentication is suspended, even theuser cannot log in any more.

Note that instead of revocation, the certificate is actually suspended. From the user’spoint of view, this is essentially the same as revocation. However, the backdoor hasbeen left for the Certifier operator to reactivate the certificate if the user suspended itmistakenly.

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 certifi-cates by using a pre-shared key. The Web Enrollment Service must use TLS protec-tion for this option to work. See Section 2.11.11 (Customizing the Web EnrollmentPages).

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 dis-played.

Clicking View Certificate will display the Revoke Your Certificate page where thecontents of the certificate are shown in detail. Clicking Revoke on this page will sus-

pend the certificate. Clicking Cancel will return to the previous page.

Note that instead of revocation, the certificate is actually suspended. From the user’spoint of view, this is essentially the same as revocation. However, the backdoor hasbeen left for the Certifier operator to reactivate the certificate if the user suspended itmistakenly.



Chapter 4: Using External CA/RA Private Keys


Chapter 4

Using External CA/RA Private Keys

Insta Certifier supports PKCS#11 for public-key cryptographic operations. PKCS#11 isa generic cryptographic interface, originally intended to be a cryptographic token inter-face standard. Nowadays PKCS#11 interface is also used for offloading cryptographicoperations to hardware.

Insta Certifier is able to use keys available in PKCS#11 modules. PKCS#11 module isa device and/or a piece of software which provides the PKCS#11 API. Insta Certifierhas been tested with the PKCS#11 implementation of nCipher Corporation andEracom Technologies.

nCipher HSMs

In this document, the term nCipher HSM (hardware security module) is used to re-fer to either nCipher nForce or nCipher nShield. nCipher is an UK based companyproviding hardware security modules for web (SSL/TLS) acceleration and for secu-rity applications such as CA key storage. nCipher HSMs support all the platformsInsta 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 producinghardware- 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 im-plementation:

The device has to support RSA.

All RSA key pairs in the device must have the CKA ID attribute. The correspond-ing public and private keys must have the same CKA ID value. The CKA ID at-tribute is only a recommendation in PKCS#11, but the attribute is required by In-sta Certifier. The Eracom and nCipher devices have been tested to work as rec-ommended.





4.1.2 Preparing an nCipher HSM for Use

There are three important nCipher-specific terms that you need to understand whensetting up a secure CA private key environment with nCipher hardware security mod-

ules:

Security world

The security world is the outermost layer of protection. The integrity and confiden-tiality of all other objects is guaranteed by encrypting everything with the privatekey embodied in the security world. Different HSMs with the same security worldcan use each other’s card sets.

Administrator Card Set

The Administrator Cards are not used in normal operation, but only in cases whenthe 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 Oper-ator Card must be inserted when Insta Certifier is started.

The following steps are required before taking nCipher HSMs in use. See nCipherUser Guide for more information.

Make sure the nCipher HSM is in correct operational mode. This can be checkedby 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 world has to be created. The security world is created using the

KeySafe key management tool of nCipher. Alternatively, the new-world com-

mand can be used. See the nCipher User Guide for instructions.

When the security world is initially created, it can be backed up and made recov-erable. We recommend that the security world is created as recoverable, be-cause if the HSM is damaged, the keys can be restored only if the security worldof the keys can be restored.We also recommend that the Administrator Card Set created within the securityworld creation consists of at least two cards. The Administrator Cards are notused 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 AdministratorCard. 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 todo the world restoration once before starting to use the HSM to ensure that therestoration works.

The Operator Cards are used to protect the created keys. KeySafe can be used tocreate Operator Card Sets. nCipher HSM can utilize n/m protection, but Insta Certifiersupports only 1/m protection at the moment. (However, Certifier Engine can be startedusing the with-nfast utility, which allows preloading of n/m keys, so the dual control

can be achieved that way.)





It is up to the Certification Practice Statement (CPS) of the CA to define whether theCA keys are recoverable. If so, the Operator Card sets should be made recoverableas 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 canbe used. If the card set is made recoverable, a new card set can be created if enoughcards from the old card set are available.

After the Operator Card Set has been created, the keys can be created either by us-ing the KeySafe tool of nCipher or by using the GUI as specified in Section 4.3 (CAPrivate Key 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 foundunder 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 acommented-out example in the default file indicates). On Unix, the following exampleadds an Eracom PKCS #11 module to the engine installation.

(provider (type "pkcs11")(library "/opt/ERACcpsdk/lib/linux-i386/libcryptoki.so")(info "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

Eracom: /opt/ERACcpsdk/lib/linux-i386/libcryptoki.so

Note: When the info parameter is set to "read-only(no)", keys can be created via thePKCS#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 tobe 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 CAPassphrase Status. The created PKCS#11 keys should be visible in the appearingkey list.

4.2 Checking the Key Backup

It is crucial that the key backup is properly implemented in the PKCS#11 module. ThePKCS#11 vendor should document the key backup procedure and the key backupshould be tested before the CA with a HSM key is made operational. It is recom-mended to test the key restoration in another host instead of the host where the keysare created to make the check as authentic as possible.





4.2.1 Key backup with nCipher HSMs

When the key or security world is generated, the encrypted version of the data isstored 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 secu-rity world is restored by restoring the contents of the kmdata directory and its subdi-

rectories from backup, and then using KeySafe or a command-line command (new-

world -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 thekmdata/local directory.

It is a good failsafe practice to have a nCipher HSM with the same security world in-stalled on a spare HSM in case the computer and the original HSM are damaged. Ifthe new HSM contains the same security world, the backed up keys are easier to takeinto use.

The security world is stored in the world file, encrypted with the Administrator CardSet. If you need to restore the security world, you need to have both the AdministratorCard and the world file available.

When you create the key, you can define whether the key can be restored (= Recov-ery feature in KeySafe). When you set this flag, the keys can be used with a replacedcard set. Without that flag, the keys can be only used with the card set that was usedto 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 pa-

rameters, (which include the used HSM), can be specified by clicking Set KeyGeneration Parameters.

To use an existing PKCS#11 key, select Use existing PKCS#11 key for the keyprovider, 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 the detected PKCS#11 tokensallowing 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 tomake it impossible to leak the CA key out programmatically. In some devices, likeEracom, clearing this flag makes it impossible to back up the key using the described





procedure. When this flag is set, the access to the CA private key is possible for aperson 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 togenerate keys and restore them. Some vendors (including Eracom) use proprietary

flags, which affect the key backup and restore procedures. In those cases, it is rec-ommended that the keys are generated/backed up and restored using the vendor’sown tools. See the vendor’s documentation for more information.

Depending on HSM vender, generating/using EC keys with HSM may require addi-tional licensing. Check your vendors manual for more information.





of this, CRL generation is always started before the actual update time. This varia-ble 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 withthis status after its validity period has ended. This status is used only as a methodof optimization, as it divides the certificate set in the database and enables moreefficient 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 thosecases it might occasionally be useful to see the ’current’ CRL. If the CRL updateperiod is set to zero (meaning that the CRL distribution point is disabled), request-ing the current CRL will generate a new CRL on the fly, with the validity periodstarting at the current time and ending after the value specified for dynamic-crl-validity-period, which is given in seconds.

heartbeat-interval

The interval (measured in minutes) of the heartbeats written in system log, whenthe Certifier Engine process is running.

keep-old-crls

When several CAs in the system publish CRLs frequently, the size of Certifier Da-tabase can increase significantly. By defining keep-old-crls as false, CRLs are notstored in the database. The default value is true. Please note that non-repudiationmay 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 networkconnections. Preferred cipher suites can be set separately for Certifier Engine,Certifier Server and services. The suite selection for the Server defines the algo-rithms suggested for the internal connection between the Server and the Engine.The selection for the Engine defines the algorithms accepted by the Engine. Thefirst 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 listmust always end with a colon (’:’). The first suite on the list is the most preferredone.The default configuration for all cipher suites is ”AES256-SHA:AES128-SHA:DESCBC3-SHA:RC4-SHA”. If the parameter is not set at all, then all suppor t-ed cipher suites are accepted.

Appendix 1 –2 Certifier Server Configuration File

The server.conf file contains both server and service specific parameters. Theserver-specific parameters are the following:





ca-engine

The address of the Certifier Engine, to which Certifier Server is connecting, and aflag 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, the second is tried and so on. This requiresthe Certifier Engines to be identical in terms of TLS settings and certificates. Thisfeature is mainly for HA cases where a secondary Engine host takes over in casethe primary fails.

pid-directory

The location of the PID files.

pki-directory

The location of the directory where the Certifier Server private key and certificatesare stored.

heartbeat-interval

Interval in minutes of the heartbeats written in system log, when the Certifier Serv-er process is running.In the server.conf configuration file you can also define parameters that are definedfor all Certifier Services of specific type running on that Certifier Server. These pa-rameters are mainly related to the web server data (such as the location of theHTML templates). Normally they are needed only for Administration Services andWeb Enrollment Services. The service-specific adjustable parameters of the serv-er.conf file are the following:

syslog-facility

The system log facility name for the log messages related to the Service can bespecified 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 thesession.

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





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 optionalpublic LDAP directory which is used for certificate and CRL publishing. Certifier En-gine is the only Certifier component that connects to the Database and performs da-tabase queries.

The Certifier Database is used to store all of the issued certificates, certification re-quests, CA policies, Server and Service configuration and all the other certificate andentity management related data. The operation log data and most of the configurationdefinitions 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 da-tabase file. In addition to this database file, it uses two files when it is running data-base, the transaction log and a temporary file.

The transaction log file contains a record of all the operations performed on the data-base. The temporary file is started during Certifier Engine start, and closed duringCertifier Engine stop. It is used to hold temporary data, that does not need to be keptbetween sessions.

Appendix 2 –1 Setting up Backup Procedure

A properly set up backup plan is needed to ensure data recovery in case of hardwaremalfunction. One method is to use hardware mirroring which will work on physical de-vice level. This requires no changes to Insta Certifier installation.

The other method is to use software mirroring in Sybase. To make the mirroring use-ful, two physically independent disks are needed. This way random hardware failuresare 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 databasefile 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 run-ning(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 theCertifier Database





Restore the Certifier database from the most recent backup and apply the currenttransaction 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. Toaccomplish 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, thenthe command should be:

./bin/ssh-ca-backup -restore-lossy [-bak-dir <path>]

This command will overwrite the old database without trying to apply the old transac-tion 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, anew certificate must be enrolled for that server before it can be used. This probablyrequires some operator activity to set up a pre-shared secret for the server. If thereare no functioning servers in the system, Insta Certifier must be started in insecureconfiguration mode first.

Appendix 2 –3 Remote Live Backup

In live backup, the dbbackup process has a continuous TCP connection to the data-

base 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 re-

mote 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 connec-tions. If a non-standard port is used (Sybase uses port 2638 by default), it must alsobe given in client connection parameters to dbbackup

(CommLinks=tcpip(Host=10.1.44.6;ServerPort=7075)).

WARNING: This will also mean that anyone able to connect to your database ma-chine and who also knows the password for a database user can change the data-base contents. Also, by default the password is transmitted as plain text in network, soanyone 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 usesome method to secure the connections (IPSec, Secure Shell tunnel, TLS tunnel or

such). In such cases dbbackup also needs DoBroadcast=NONE option which disa-

bles UDP-broadcast-based database auto-discovery.

To run the live backup, use the following command:

source ./bin/ssh-ca-runenvdbbackup -c "connection_string" -l transaction.log backup-directory





As the dbbackup needs specific libraries the ./bin/ssh-ca-runenv must be exe-

cuted first.

In addition to the normal database name, database engine name, user name, andpassword parts, the connection string must contain

links=tcpip(Host=serveraddress) in which serveraddress is the addressof the machine running the database. Additionally if database is running in non-

standard port, ServerPort=portnumber option must be given.

Live backup will only backup the transaction log, the database file itself is not backedup. All committed transactions are automatically flushed to the remote transaction logby the live backup process. This however is not transactional; when a transaction iscommitted to the database it is not ensured that it is already in the live backup trans-action log. In case of failure, a few transactions can be lost if the recovery is donefrom 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 suchcase, probably integraded into a monitoring solution which also either tries to restartthe current server machine or switches the Insta Certifier to a spare unit.

When implementing a normal backup process for Insta Certifier, it must be remem-bered that the live backup transaction log is truncated when normal transactions logsare (the -x option for dbbackup). Best way to ensure that no data is lost during back-

up is to make the full backups also remotely. Otherwise a failure right after a truncat-ing local backup might destroy both the database, transcation log, and the most re-cent 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/shif [ "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 ]; thenecho Unsupported OS; exit 2

fiif [ $# != "2" ]; thenecho "Usage: $0 backup-dest-dir server-address"; exit 1;

fiPREFIX=$1ADDR=$2

. $BASE/sybase/bin/asa_config.shSSH_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 ]; thenrm -f $PREFIX/live-transaction.log.oldmv -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





As a safety measure, the script will first move the possibly existing transaction log anddelete the older backup in the process. If wanted, this could also be changed to pre-serve 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 againstlocal, limited hardware failure, such as single malfunctioning hard disk, but alsoagainst total loss of the active database machine including its database.

Machine A: Machine B:Disk 1: <---------------> Live backup:certifier.db transaction.logtransaction.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 fullInsta 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 transac-tion 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 allthree transactions logs are also truncated. Machine B does not contain a running InstaCertifier installation, although it can contain a pre-installed system to help in the re-

covery 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 rela-tively 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

○ Just restart the database and it will automatically copy the maintransaction.log to mirror.log before starting.

Case 2: Disk 1 on machine A fails

1. Copy certifier.db from most recent backup to machine A.

2. Apply the mirror.log to certifier.db.

3. Restart the system.

Case 3: Machine A is totally destroyed (in a fire for example)

1. Copy certifier.db from the most recent backup to new machine A.

4. Apply the transaction.log from live backup to certifier.db.

5. Restart the system.

Note that in case 3 some committed transactions can be lost. In cases 1 and 2 the re-covery is always complete.





No special backup processes are needed on machine A. In machine B the full backupcan be arranged with either of backup scripts in Section Appendix 2 –1 (Setting upBackup Procedure) which can be run a cron jobs. Connection strings must be custom-ized 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, eitherdeliberately or by some real failure, the live backup process must be restarted. Oneway is to add another script which will monitor the live backup process and restart itautomatically. In such case, some additional care must be taken to ensure that the oldtransaction log is not overwritten.





Appendix 3 Migrating Certifier

Appendix 3 –1 Migration Steps

An already existing Certifier installation can be migrated from one host to another byperforming these steps.

Install the new Certifier

Install the installation package (rpm/pkg/depot) to the new host as described in In-

sta 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.) happen-ing during the migration process, you must first stop your old installation. However, inorder to avoid a break in certificate validation, you must ascertain that none of theCRLs are about to expire during the migration.

This is done with the administration interface 2.12.14 (System Shutdown) request inthe System Configuration Menu.

After shutting down the Certifier Engine with the System Shutdown request, the data-base and the server must be also stopped. Please run the ssh-ca-stop script (seeSection 4.1 (Starting and Stopping Certifier Manually)).

Disable database log mirroring

If you have enabled Sybase database log mirroring (either with ssh-ca-backupconf ormanually with the Sybase tools), you must disable mirroring before proceeding withmigration and enable it again on the target system after migration.

Database mirroring can be disabled with ssh-ca-backupconf, see Section A.3.1 (Set-ting up Backup Procedure).

Disable database live backup

If you have enabled Sybase database remote live backupping, you must disable thelive backup before proceeding and enable it again on the target system after migra-tion. If you need assistance with this step, please use your your official support e-mailaccount to contact us.

Backup the old installation

On Unix: Backup your installation with the ssh-ca-backup tool (see 4.2 (ssh-ca-backup)). Just run the following command (as the certifier user, not as root):

ssh-ca-backup

By default the backup is stored undervar/bak/ca-backup-current

under the

Certifier directory.





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 directoryspecified in the backup configuration.

Transfer the backup

On Unix: Transfer the fresh backup to the new host. The exact steps depend on yourhost/network setup. If the new host is accessible with a Secure Shell connection, thismight be achieved with the following commands:

cd /opt/certifier/var/baktar 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 migratedto the new host as well. Please consult your hardware crypto module documenta-

tion/support for details.

Setup the new Certifier

Run the ssh-ca-setup as described in Section Installing Certifier in the Administrator’sGuide. Note that the ssh-ca-backup must be run as certifier user, not as root.

./ssh-ca-setupbin/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, per-form 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 Administra-tor’s Guide.

Use the new PSKs when setting up the servers.

Checklist

After migration, please check at least the following details in the Certifier configura-tion.

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 thosefiles manually as appropriate.




Cleanup

Remove the var/migration directory from your new host.

Certifier 5.2.3 ReferenceGuide

Documents

Transcript of Certifier 5.2.3 ReferenceGuide