Certifier 7.3 ReferenceGuide

Insta Certifier 7.
Reference Guide
www.insta.fi
Version 7.3
Date 21 December 2016
© 2015 Insta DefSec Oy. This software is protected by international copyright laws. All
rights 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 OR
EXPRESSLY AGREED IN WRITING.
Insta DefSec Oy
Sarankulmankatu 20
P.O.Box 80
FIN-33901 Tampere
Finland
http://www.insta.fi/
Tel: +358 600 97801 (Support HelpDesk)
Tel: +358 20 771 7111 (Insta DefSec)
Fax: +358 20 771 7122 (Insta DefSec)
Insta Certifier : Reference Guide

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....................................................................................................... 9
2.3 Syslog Search .................................................................................................................. 10
2.4 Processing Requests ....................................................................................................... 12
2.4.1 Certificate Profile .................................................................................................. 14
2.4.2 Entity.................................................................................................................... 15
2.4.3 Issuer ................................................................................................................... 15
2.4.4 Serial Number ...................................................................................................... 16
2.4.5 Subject Name ...................................................................................................... 16
2.4.6 Validity Period ...................................................................................................... 16
2.4.7 Signature Algorithm.............................................................................................. 17
2.4.8 Certificate Extension Fields .................................................................................. 17
2.4.9 Additional Parameters .......................................................................................... 22
2.4.10 Updating a Changed Request ............................................................................ 23
2.5 Entities ............................................................................................................................. 23
2.5.1 Adding Entities ..................................................................................................... 24
2.5.2 Editing Entities ..................................................................................................... 25
2.5.3 Adding and Modifying Pre-Shared Keys ............................................................... 26
2.5.4 Adding Policy Module Attributes ........................................................................... 28
2.5.5 Removing Entities ................................................................................................ 29
2.6 Viewing Certificates.......................................................................................................... 29
2.6.1 Viewing and Exporting Private Keys ..................................................................... 31
2.6.2 Exporting certificates without private key.............................................................. 33
2.7 Certification Authority Settings ......................................................................................... 34
2.7.1 Creating a New Certification Authority .................................................................. 34
2.7.2 Editing CA Settings .............................................................................................. 36
2.7.3 View CRL Distribution Points ............................................................................... 40
2.7.4 Editing CA Auto Renewal Settings ....................................................................... 40
2.7.5 Editing CA SNMP Configuration ........................................................................... 43
2.7.6 Statistical charts ................................................................................................... 44
2.7.7 Removing CA ....................................................................................................... 44
2.8 Registration Authority Settings ......................................................................................... 44
2.8.1 Creating a New Registration Authority ................................................................. 45
2.8.2 Editing RA Settings .............................................................................................. 45
2.8.3 Enrolling an RA Certificate ................................................................................... 48

Table of Contents
2.8.4 Using a Local CA with RA .................................................................................... 49

2.9 Publishing Settings .......................................................................................................... 49
2.9.1 LDAP Publishing Method ..................................................................................... 50
2.9.2 HTTP Publishing Method ..................................................................................... 54
2.9.3 OCSP Publishing Method .................................................................................... 55
2.9.4 External Publishing Method.................................................................................. 55
2.10 Operators ....................................................................................................................... 56
2.10.1 Adding Operators ............................................................................................... 56
2.10.2 Editing the Operator Information ........................................................................ 58
2.10.3 Operator Access Control Levels ......................................................................... 60
2.10.4 Configuration Signature ..................................................................................... 62
2.11 Delegated RA Entities .................................................................................................... 64
2.11.1 Creating a Delegated RA Entity.......................................................................... 64
2.11.2 Editing a Delegated RA Entity ............................................................................ 66
2.11.3 Delegated RA Access Control Levels ................................................................. 67
2.11.4 RA-CA Communication Policy ............................................................................ 68
2.12 Certifier Servers and Services ........................................................................................ 68
2.12.1 Creating a New Server Entity ............................................................................. 69
2.12.2 Editing the Administration Service ...................................................................... 72
2.12.3 Editing the CMP Service .................................................................................... 75
2.12.4 Editing the External Enrollment Client Service ................................................... 78
2.12.5 Editing the LDAP Authentication Service............................................................ 79
2.12.6 Editing the OCSP Responder Service ................................................................ 82
2.12.7 Editing the Publishing Service ............................................................................ 83
2.12.8 Editing the SCEP Service................................................................................... 86
2.12.9 Editing the Web Enrollment Service ................................................................... 87
2.12.10 Customizing the Web Enrollment Pages .......................................................... 90
2.13 System Configuration ..................................................................................................... 96
2.13.1 Editing System Parameters ................................................................................ 97
2.13.2 Viewing and Approving Pending Change Sets ................................................... 99
2.13.3 Cross-Certification............................................................................................ 101
2.13.4 Importing a Certification Request ..................................................................... 102
2.13.5 Inserting a Certificate ....................................................................................... 103
2.13.6 Importing a Private Key .................................................................................... 104
2.13.7 Creating Certificates......................................................................................... 105
2.13.8 Configuring Certificate Transparency ............................................................... 107
2.13.9 Managing CRLs ............................................................................................... 108
2.13.10 Managing Trust Anchors ................................................................................ 108
2.13.11 Changing the Master Password ..................................................................... 109
2.13.12 CA Passphrase .............................................................................................. 110
2.13.13 User-Defined Policy Modules ......................................................................... 111
2.13.14 Viewing System Configuration........................................................................ 111
2.13.15 System Shutdown .......................................................................................... 112
2.14 Revocation Interface .................................................................................................... 112

Table of Contents
2.15 Statistics ...................................................................................................................... 112
Certificate Life-Cycle Management Services........................................................................... 115

3.1 CMP Service .................................................................................................................. 115
3.2 SCEP Service ................................................................................................................ 116
3.3 Web Enrollment Service ................................................................................................. 117
3.3.1 PKCS#10 Enrollment ......................................................................................... 117
3.3.2 Browser-Based Enrollment................................................................................. 119
3.3.3 Downloading CA/RA Certificates and CRLs ....................................................... 124
3.3.4 Managing User Certificates ................................................................................ 125
Using External CA/RA Private Keys ......................................................................................... 127

4.1 Creating a CA with a PKCS#11 HSM ............................................................................. 127
4.1.1 Requirements for the PKCS#11 Modules ........................................................... 127
4.1.2 Preparing an Thales HSM for Use...................................................................... 127
4.1.3 Adding PKCS #11 Modules to the Certifier Engine ............................................. 129
4.2 Checking the Key Backup .............................................................................................. 130
4.2.1 Key backup with Thales HSMs ........................................................................... 131
4.3 CA Private Key Options ................................................................................................. 131
Appendix 1 Certifier Engine and Server Configuration Files ................................................. 133

Appendix 1–1 Certifier Engine Configuration File ................................................................. 133
Appendix 1–2 Certifier Server Configuration File ................................................................. 136
Appendix 2 Database ................................................................................................................ 140

Appendix 2–1 Setting up Backup Procedure ........................................................................ 140
Appendix 2–2 Recovery ....................................................................................................... 141
Appendix 2–3 Remote Live Backup ..................................................................................... 142
Appendix 2–4 Sample Backup Plan ..................................................................................... 144
Appendix 2–5 Configuration parameters .............................................................................. 145
Appendix 3 Migrating Certifier ................................................................................................. 146

Appendix 3–1 Migration Steps ............................................................................................. 146
Appendix 4 IPv6 ........................................................................................................................ 149

Appendix 4–1 Syntax ........................................................................................................... 149
Appendix 4–1–1 Service address................................................................................ 149
Appendix 4–1–2 Cluster .............................................................................................. 149
Appendix 4–1–3 PostgreSQL...................................................................................... 149

Chapter 1: About This Document
Chapter 1
About This Document

Insta Certifier offers versatile configuration and customization options to suit the
needs of your PKI service.
This document describes the user interfaces, command-line tools, and other 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) for
storing CA/RA private keys
 appendix with information on miscellaneous topics (such as configuration files
and database backup)
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
Insta Certifier : Reference Guide 1

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 the
web-based administration interface.
This chapter describes the different functions the operators can perform using the
administration interface. Detailed explanations on how to fill the configuration data and
how to use the various GUI features are given. The Help buttons in the administration
interface itself are linked to these explanations.
In addition to the main admin UI, Insta Certifier is provided with a limited administra-
tion interface. See Insta Certifier Administrator’s Guide for instructions.
For a description of the web enrollment interface, see Section 3.3 (Web Enrollment
Service).
Insta Certifier offers also the possibility to customize a totally new GUI. Customizing or
programming a new GUI requires writing HTML code and/or embedded script code,
Scheme. Contact Insta Certifier technical support for more information.
Parts of the administration view
After login, the administration interface opens. The administration pages are dynami-
cally created from HTML templates. Each page is divided into two parts, the top
menu, the main menu on the left, and the actual settings page. The top menu and
the main menu are identical on all pages.
The top menu (shown in Figure 2-1) 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 user
interface, 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 select
a new option from the main menu.
2.2 Database Search
Almost all objects in the Database can be located with the generic search 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 list
only the objects that are relevant for each particular situation.
Select the Search option from the main menu to open the Database Search page.
The Find Certificates, Find Requests, and Find Entities options will go to the
same Database Search page. The difference between these options is that some
values on the page are preset.

The View Log Entries option will also go to a search page, but on that page the
searched Log events can be restricted based on the event type. See Section Error!
eference source not found. (Error! Reference source not found.).
2.2.1 Database Search Options
The Database Search page contains several options that can be used to define the
search.

Figure 2-3 The Database Search page
Text Search
Using the Text search field is straightforward for anyone who has used a common
web search engine. However, there are some differences.

Figure 2-4 You can use the ’+’ and ’-’ operands to further define the search results
All white-space-separated words in the field are by default and’ed together. This
means that only those objects that contain all of the searched words are shown in the
search result. This behavior can be changed by setting the pop up menu on the right
side of the text field from Match all to Match some.
In the Match some mode all objects containing some of the searched for words are
matched. Some individual words can be required to be in the result set by preceding
them with a plus sign (+). In both modes a minus sign (-) can be used to restrict the
result set by excluding any objects containing certain words.
quick brown +fox -dog
For example, the above string in the Match all mode matches the objects which have
all of the three words quick, brown, and fox, but not dog.
In the Match some mode all of the objects containing the word fox but not the word
dog are matched. If the result set is not sorted in time order, objects containing
quick or brown would be shown before the other results. Note that both of the ’+’
and ’-’ operators must have a space before them and that they must be directly fol-
lowed by the operand.
Object Status
By using the Object status switch, the search can be restricted to only those objects
that have the specified status. The object status can be one of the 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 is
type-specific.
Publish Status
Certificates can also be searched according to their publishing status. This allows the
operator to check if some certificates have failed to publish correctly.
The following publishing statuses are used in Insta Certifier:
 Pending: The publishing is in progress. This status may also appear, for exam-
ple, in case of certificates issued through CMP that are specifically requested not
to 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 a
specific object type is selected.
The available object types are certificate request, certificate, entity, and log
entry.
Select CA
The Select CA option can be used to restrict certificate searches to certificates which
are issued by a certain CA. Also certification requests can be selected by their CA, if
they have such associated.
Figure 2-5 The Select CA option specifies the CA name
If the CA hierarchy of the PKI contains more than two levels, the Select CA drop-
down list does not display all CAs. The names of the first level sub-CAs are displayed
immediately after their top-level CAs, and they are preceded by a plus sign (+). If a
sub CA has further (level-2) sub-CAs, their names are preceded by two plus signs
(++). If there are several level-2 sub-CAs under one level-1 sub-CA, only their number
is 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 their
own, the names of the lower-level sub-CAs are preceded by plus signs. To return the
list to the top level, click Reset.
Time Period
The Time period fields are used to restrict certificate and certification request
searches. In certificates the time period matches with the certificate’s validity period.
Figure 2-6 The time period can be either strict or exclusive

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

Search with...
You can also specify the Serial Number, Reference Number, Pre-Shared key,
Request Poll ID, Card ID, Profile ID or Internal Object ID of the object you want
to display. Select the type of identification and the format of the number from the drop-
down lists and type the identification in the field. The identification can be specified in
either decimal (DEC), hexadecimal (HEX), octal (OCT) or binary (BIN) format. With
card ID and profile ID, search is always expected to be in decimal format.
Email
To search with email, write the exact email to this field. When searching for email, the
text search and status fields are ignored.
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.
Certificate operations
Certificate search results a list of matching certificates. From this page multiple certifi-
cates can be revoked, suspended or reactivated or published simultaneously.
From the drop-down list on the bottom left corner of the page you can select one of
the operations:
 Revoke marked certificates
 Revoke not marked certificates
 Revoke all matching certificates (all certificates that matched the search crite-
ria)
 Suspend marked certificates
 Suspend not marked certificates
 Suspend all matching certificates (all certificates that matched the search crite-
ria)
 Reactivate marked certificates
 Reactivate not marked certificates
 Reactivate all matching certificates (all certificates that matched the search
criteria)
 Publish marked certificates
 Publish not marked certificates

 Publish all matching certificates (all certificates that matched the search crite-
ria)
Mark the certificates and click Make It So to continue with the selected operation.
List of affected certificates is displayed. Click Proceed to commit the operation.
Request operations
Certification request search results a list of matching requests. From this page multi-
ple requests can be approved or rejected simultaneously.
From the drop-down list on the bottom left corner of the page you can select one of
the operations:
 Approve marked requests
 Approve not marked requests
 Approve all matching requests (all requests that matched the search criteria)
 Reject marked requests
 Reject not marked requests
 Reject all matching requests (all requests that matched the search criteria)
Mark the requests and click Make It So to continue with the selected operation.
List of affected requests is displayed. Click Proceed to commit the operation.

Request that cannot be approved (e.g. request is missing subject name field) are
shown red in results page. These requests must be manually modified and approved.
2.3 Syslog Search
Engine syslog messages are viewable from View Syslog Messages page. Search is
done to local engine syslog file (certifier.log). Operator access control restricts
searchable data; i.e. only CAs that are under operator access can be searched.

Figure 2-8 Syslog Search page
Time period start and Time period end depends on syslog timestamp configuration.
By default syslog uses local machine timestamp. Certifier does not change this. Time
values have validation checks.
Select CA is used to specify which CA rows are searched. If CA is not specified, all
CAs that are under operator access control are searched. For unrestricted super us-
ers, all CAs are searched (no filtering applied).
Message type specified which types of rows are searched. Possible options are All,
Events and Certificate Enrollments (CMP and SCEP). All searched all rows and
only applied CA filtering, Events searched “event” type messages and Certificate
Enrollments (CMP and SCEP) searched messages that are produced by CMP and
SCEP enrolment processes. Notice that certificate enrolment produces both event
and enrolment type messages. Message type Certificate Enrollments (CMP and
SCEP) requires Select CA to be enabled. Select CA applies to all message types.
Log events are used to specify which events are searched when selected message
type is Events. All events are searched when no specific events are selected. This
selection has no effect if message type is other than Events.

Search Results shows the search results. CA, request and certificate are hyper-
linked. Clicking the ID will open CA, request or certificate page.
2.4 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 to
manually approve the certification request.
All received but not yet processed requests are marked with the pending status in
the Database and can be easily found either by using the Process Requests option
of the main menu or by a specific Database search with status set as pending.
The easiest method to process a pending certification request is to click the Process
Requests button on top of the main menu. This runs a database search on all pend-
ing certification requests in the Database and displays the result to the operator, most
recently arrived requests first.

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

Windows 2000 logon with smart cards

A profile for Microsoft Windows smart card logon certificates. Note that this profile
requires a preconfigured entity with the UPN attribute.
 Copies the UPN attribute of the entity to the UPN subject alternative name of
the certificate template. Fails if it is not present.
 Sets the Digital Signature and Key Encipherment key usage bits.
 Sets the ekuSmartCardLogon and ekuClientAuth extended key usage OIDs.
2.4.2 Entity
If the request contains a known pre-shared key, the CA Engine automatically assigns
an entity mapping to the request.
The operator can manually change the entity mapping. This is done by entering the
entity search string (such as the name of the entity) in the string input box and then
clicking the Search button adjacent to the box. The first few dozen entities matching
with the search parameters are then displayed in a drop-down list.
The entity selection can be removed by clicking the Change button next to the menu.
If the entity is already set, it can be cleared by clicking the Reset button.
2.4.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 future
use 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 field
needs to contain a local RA of the system. Instead of issuing the certificate, the RA
signs the certification request and sends it to the remote CA that is associated with
this RA.
The CA list works as described in Section 2.2.1 (Database Search Options).
If CA policy chain doesn’t include specific module for setting the signature algorithm
for enrolling certificate, engine automatically selects one based on issuer key size:
When issuer key is RSA type:
Issuer Key Size Algorithm
<= 2048 bits RSA with SHA-256
2049..3072 bits RSA with SHA-384
> 3072 bits RSA with SHA-512

When issuer key is EC type:

Issuer Key Size Algorithm
<= 256 bits ECDSA with SHA-256
257..384 bits ECDSA with SHA-384
> 384 bits ECDSA with SHA-512
2.4.4 Serial Number
Serial number can be set manually, although it is not recommended. Each issuer has
a randomly increasing serial number counter (unless sequential increase has been
configured from global configuration file), and the serial numbers are automatically
generated.
In some situations operator may want to use a specific serial number e.g. for 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 if
the same issuer has already issued a certificate with the given number, or if there is a
self-signed certificate with the given number.
2.4.5 Subject Name
The subject name should be checked and verified. The system automatically checks
that the given distinguished name is syntactically correct, and certain CA policies can
be used to check that the subject name matches a pattern. Errors in these checks are
displayed to the operator before the request is updated or issued, but operators
should still be somewhat familiar with the distinguished name format.
However, there can be other, finer policy considerations for the subject name format
that the operator must check manually. For example, a person’s name can be written
in several different formats (first name first, last name first, without middle names, with
middle initials, etc.). Verifying that the name is in reasonable format for your organiza-
tion’s needs can sometimes be hard to do automatically.
Note: All distinguished names, including the subject name mentioned here, are written
in the same order that is used when the names are encoded in certificates. This is ex-
actly the opposite order as the one used in LDAP applications. When dealing with
LDAP, Insta Certifier will convert all distinguished names to the correct order automat-
ically.
2.4.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-10 The validity period options

The validity period is rarely set in the original request and it is usually reset by the CA
policy to some default value. CA policy allowing, the operator can check and modify
the validity period of the resulting certificate. The system automatically restricts validity
periods inside the validity period of their issuing CA certificate.
The used date and hour format depend on the operator-specific settings. See Section
2.10.2 (Editing the Operator Information). The Not before and Not after times are
given (as are all other time values in Insta Certifier) in local time.
Setting the Validity Period
Instead of writing the exact validity period in the request form to the Not before and
Not after fields, the period length can be chosen from the Set Validity Period 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.4.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 NIST
recommendations (2011).
2.4.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 clicking
the Add button. An existing extension can be removed from the request by clicking
Remove next to the extension field.
The extensions recognized by Insta Certifier are described below.
Email
Email subject alternative name. Multiple values are allowed.
IP Address (IP)
IP address subject alternative name. Multiple values are allowed. At the moment
this field can only contain IPv4 addresses in dotted octet format (for example,
134.23.54.102).
Universal Resource Identifier (URI)
URI subject alternative name. Multiple values are allowed. The URI must be 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 valid
OID. 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.
Globally Unique Identifier (GUID)
Microsoft specific globally unique identifier (GUID) of a domain controller. The
GUID is a 16 Byte long number which identify the object of the domain controller in
the directory (ADS).
Issuer alternative names
The following issuer alternative names are supported. The format is the same as
for the subject alternative names described above:
○ Email
○ IP Address (IP)
○ Universal Resource Identifier (URI)
○ Domain Name (DNS)
○ Registered ID (RID)
○ User Principal Name (UPN)
○ Directory Name
Nokia specific extensions
Nokia mobile phone specific extensions: Nokia R&D extension for Java, Nokia
R&D extension for Symbian and Nokia R&D capabilities for Symbian.
Policy Info
This field contains information about the applicability of the certificate for various
uses and certification practices of the issuing CA. If this extension is set as critical
(from the drop-down list), the client application handling the certificate must not use
the certificate unless it is familiar with the extension. If this extension is set as non-
critical, a client application may use the certificate even if it does not recognize the
extension.
Click the Edit button to edit the policy information extension. The extension needs
to have an object identifier (OID), which is registered for the certificate policy. 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 the
written certificate policy can be found with a web browser.
The user notice is intended to be displayed to a client when the certificate is being
used. The textual statement needs to be written to the Explicit text field. The Or-
ganization field can be given name of the organization giving the statement and

Reference List the number that identifies the statement. Click the Add User Notice
and Add CPS URI buttons to add optional policy fields.
Authority Access
This extension can be used to indicate how to access the CA information and CA
services (other than CRLs). The authority access may contain either information
about CAs that have issued certificates superior to the CA that issued the 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 of
the responder service should be given Authority Access field.
Basic Constraints
Present only in CA certificates. If the CA flag is set, it indicates that this is a CA 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 the
Remove 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. This
means that a CA with a path length of zero cannot issue any sub-CA certificates at
all, and a CA with a path length of one can issue only CA certificates with a path
length of zero, and so on. A CA certificate with no path length constraint allows a
certification path of unrestricted length underneath it.
Key Usage
The key usage extension is a bit field with a number of named bit values.
Digital Signature
Set when the public key is used for digital signatures for other purposes
than non-repudiation, certificate signing, or CRL signing.
Non Repudiation
Set when the public key is used to provide a non-repudiation service.
Key Encipherment
Set when the key is used for key transport/management.
Data Encipherment
Set when the key is used to encipher data not consisting of cryptographic keys.
Key Agreement
Set when the key is used in key agreement.
Key Cert Sign
Set when the key is used to verify signatures on certificates. Only CA certificates
can have this bit set.

CRL Sign
Set when the key is used to sign CRL information. Only CA certificates can have
this bit set.
Encipher Only
If the key agreement bit is set, the key can only be used to encipher data in key
agreement procedure.
Decipher Only
If the key agreement bit is set, the key can only be used to decipher data in key
agreement procedure.
Note that not all bit combinations are valid. Such factors as if the certificate is a CA
certificate 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
The user’s citizenship. Should be given as an ISO 3166-1-Alpha-2 country code
(for example, FI).
countryOfResidence
The user’s country of residence. Should be given as an ISO 3166-1-Alpha-2 coun-
try code (for example, US).
Qualified Certificate Statement
Qualified Certificate (QC) statement as per RFC 3739. The extension can have
one of six values that are set on Edit Qualified Certificate Statement page. Several
QC extensions can be added, each with different value.
PKIX QC Syntax v1 or PKIX QC Syntax v2
Indicates conformance with Qualified Certificate profile as specified in RFC 3039
(v1) or in RFC 3739 (v2). The extension can have No content, contain a Semantics
Identifier OID, or contain information on Name registration authorities (an URI, a
Directory Name, or an Email address).
QC EU Compliance
Indicates compliance with the EU directives on Qualified Certificates.
Monetary Limit
Imposes a limitation on the value of transaction for which the certificate can be
used. The Currency code and the Amount need to be entered in text boxes. The
currency code should be given as an ISO 4217 three-letter code (for example,
USD).
Retention Period
Indicates a period (in years) after the expiry of the certificate for which information
related to the certificate is archived.

EU Qualified Signature/Seal Creation Device

QCStatement claiming that the private key related to the certified public key re-
sides in a QSCD.
EU QC Type
QCStatement claiming that the certificate is a EU qualified certificate of a particular
type. Possible types: esign, eseal, web.
PKI Disclosure Statement
QCStatement regarding location of PKI Disclosure Statements (PDS). Consists of
location URI and two letter PDS language code (default ‘en’).
Custom Statement
A custom QC statement extension consists of an OID and the extension (in DER-
encoded hexadecimal format).
Custom Binary Extension
A custom binary extension consists of an OID and the extension data (in hexadec-
imal format). If this extension is set as critical (from the drop-down list), the client
application handling the certificate must not use the certificate unless it is familiar
with the extension. If this extension is set as non-critical, a client application may
use the certificate even if it does not recognize the extension.
Private Key Usage Period
Time period for private key usage validity, which may be different from certificate
validity period. See RFC 5280 for details. Note that this extension is stated as ob-
solete by the RFC and not recommended for use.
Not before
Validity start time.
Not after
Validity end time.
2.4.9 Additional Parameters
Two additional parameters related to the certificate can be set. These parameters are
not included in the certificate itself but they are used internally by Insta Certifier.
Normally a revoked certificate is removed from the CRL after its expiration. If Include
in CRL after expiration is selected, and the certificate is revoked at some point dur-
ing its validity period, the certificate will stay in the CRL even after its validity period
has ended. By default, this option is not selected.
If Publish certificate is selected, the certificate will be published (according to the

publishing settings of the CA). If the option is not selected, the certificate will not be
published. By default, this option is selected and the certificate is published.

2.4.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 status
is 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 as
a template. Subject and Authority key identifiers will be assigned during this process
(the SHA-1 hash over the corresponding DER encoding of public keys is the method
used).
After the approval, the certificate is stored in the internal Database and published to a
directory server (if so configured). Also the approval operation, including the operator
login name, is stored in the Database to enable audit trail of the certificates. If a 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. This
ID needs to be given when polling for the approved certificate, for example, via the
Web Enrollment Service.
Clicking the Postpone button sets the request to postponed status. This means that it
will be removed from pending requests but can otherwise be manipulated normally.
The Reset button at the bottom of the page resets the page to the values found in the
Database and effectively cancels all modifications done by the operator after the last
update.
The View Log option displays recent log events related to this request. Copy
Request adds a new request to the Database with identical information. This can also
be done to already accepted or rejected requests.
2.5 Entities
An entity is anything that can request and receive certificates from Insta Certifier. An
example of an entity could be a user requesting a certificate for e-mail usage, or a
network device requesting certificates for IPSec.
Entities are used to bind a set of attributes describing the entity and a set of requests
and certificates together. This makes it easier for operators to view what kind of certif-
icates are given to users.
Entities can also contain a set of shared secrets, in the form of a secret key ID and a
pre-shared key. These keys can be used to map incoming certification requests to a
certain entity. Additionally, secrets can have a set of policy attributes that can alter the
way they are handled in the automatic CA policy code. For example, the system can
be set up so that when a certification request with a matching pre-shared key comes
in, it is automatically accepted and issued with a pre-configured set of certificate 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 potential
end user base is large. For CMP enrolment entities have to be used.
2.5.1 Adding Entities
You can add new entities to the PKI system by clicking the Add New Entity option
from the main menu.
An entity can be bound to a specific CA. This means that the certification requests by
this entity are directed to the selected CA. To create a CA binding for the entity, se-
lect a CA from the list. The list works as described in Section 2.2.1 (Database Search
Options).
Figure 2-11 Creating a new entity
The Entity status drop-down list displays the entity’s current status. An entity is
normally marked as Active.
In some cases, an entity’s future use in the system might need to be restricted. In this
case, set the entity status to Inactive.
The Entity name field is reserved for a freeform, short and hopefully descriptive
name for this entity. In case of a person, the first and last name are the usual choice.
In case of routers or other equipment, advisable choices are the entity’s use, user
group it belongs to, or perhaps its location. Exact information such as the IP address
can have a separate attribute in the entity. This makes searching for them more 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 the
attributes differ by their name and the size of text input box, but some have different

content types, such as drop-down lists giving a limited selection of choices, or Boole-
an values represented as check boxes.
The Email address and Account Password attributes of the entity are used when
entity account management is enabled in the Web Enrollment Service. See Sections
2.11.11 (Customizing the Web Enrollment Pages) and 3.3.4 (Managing User 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 a
certificate, for example, as the values for LDAP attributes.
An attribute can be removed by clicking the Remove button on the right hand side of
the attribute. The attribute is then removed and a refreshed page is shown.
The actual entity is not created until you finish the creation process by clicking the
Create button at the bottom of the page. The Cancel button can be used to return
from the entity creation process without actually adding the entity to the Database.
You can also switch to some other page by using the main menu.
2.5.2 Editing Entities
The Entity page can be reached in many ways. You can search for entities based on
their creation time or by some indexed words given in the entity attributes. To do the
search, select the Find Entities option from the main menu.
Searches can also be made from the certification request update page. Some log 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-12 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 their
own and are unaffected by this button.
Clicking the View Log button fetches the recent log entries related to this entity and
displays them. The View Requests button searches the Database for all pending
certification requests that are marked to this entity either automatically by some policy
mapping or manually by the operator. The View Certificates option shows all active
certificates that belong to this entity. The Search button shows a generic find page
with the current entity automatically bound.
The Copy Entity option makes a new copy of this entity. Only attributes, type and
name are copied as shared secrets are naturally entity-specific.
2.5.3 Adding and Modifying Pre-Shared Keys
A new entity will automatically have one pre-shared key. You can add new pre-shared
keys to an entity by clicking the Add button on the top row of the key table. This adds
a new row to the table, displaying the newly created shared secret.

Figure 2-13 Pre-shared keys listed
The Type field shows the type of the key - but currently only psk (for pre-shared key)
is defined. The Use Count option gives the number of times that this key has been
used successfully to enroll a certificate. (Certain policy functions and policy attributes
restrict multiple uses of the same key.)
The Reference Number is a unique identification number for this secret, assigned
by the Insta Certifier Engine. This ID is required by the CMP protocol, which uses it to
identify the used secret.
The Key field contains the actual shared secret. This is a free-form text string that
was randomly generated when the secret was created.
The key can be removed by clicking the Remove button on its table row.
Clicking the Edit button displays more information about the key.
Figure 2-14 The Pre-Shared Key page
On this page you can change the key’s type and use count. Increasing the Use count
can be useful in certain situations, if a well known end user has used the key, but for
some reason wants to enroll another certificate with same key. However, the recom-
mended way to do this is to generate a new shared secret and distribute it to the user
in order to minimize the possibility of key misuse.
The actual key can also be changed either manually (by typing a new value to the text
field) or by clicking the Generate New Key button. By typing a key, you can allow
the use of passwords (passphrases) generated by external systems instead of ran-

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 Commit
Changes button on the bottom of the page. This will also return the view to the main
entity page. Clicking the Cancel button will discard the changes and return the view
directly to the main entity page.
2.5.4 Adding Policy Module Attributes
You can add Policy modules to the entity or to a shared secret of the entity. The
modules can affect the way the incoming certification requests containing this key are
handled by the system. This is generally used to shorten the processing time by 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 that
secret.
For the policy modules of the entity or a shared secret to take effect, the CA policy
must contain the Apply Policy Attributes module in the receive-request chain.
See document Policy chain and modules.
To add a policy module to an entity, select the desired module from the – Add New
Policy Module – dropdown list on the Entity page and click Add. After you have
added the desired policy modules click the Commit Changes button to update the
entry in the Database.
To add a policy module to a shared secret, click edit next to the secret to go to the
Pre-Shared Secret page. Select the desired module from the – Add New Policy
Module – drop-down list and click Add. After you have added the desired policy
modules click the Commit Changes button to update the entry in the Database and
return to the Entity page.
The currently supported policy module attributes are the following:
Accept All
Access List
Active Certificate Limit
Add Policy Info Extension
Add Qualified Certificate Statement
Apply Profile
Check Key Usage
Check Request Protocol
Drop Extensions
Match Names

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.5.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 to
confirm the selection before the entity and all associated certificates and keys are re-
moved from the system.
2.6 Viewing Certificates
To view a certificate, first search the certificate from the Database with the normal
search function. See Section 2.2.1 (Database Search Options).
To view a CA certificate, click View Certificate on the CA Hierarchy or

Certification Authority page.

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

If you select to Revoke the certificate, you will be asked for confirmation. On the
Revoke Certificate page, you can give a Reason Code for the revocation (as per
RFC 3280), adjust the Invalidity Date, and add a Comment to the revocation. The
comment is visible in Insta Certifier only. The revocation codes and the invalidity date
(only if its value is changed) are stored in the CRL. The following reason codes can be
used:
 No reason code
 Key compromise
 CA compromise
 Affiliation changed
 Superseded
 Cessation of operation
 Privilege withdrawn
It is also possible to revoke (but not suspend) several certificates at the same time.
See Section 2.2.2 (Search Results) for more information. Revocation reason codes
cannot be used in mass revocations.
After suspension or revocation, the revocation information is included in the next pub-
lished CRL (it is immediately available for OCSP). After that the certificate cannot be
used any longer by the PKI client applications.
The only difference between suspension and revocation is that a revocation cannot be
reversed. If a suspended certificate is reactivated, the suspension information will be
removed from the next published CRL.
In addition to revocation, you can choose to Re-publish or reissue the certificate by

clicking the appropriate button on this page. Clicking the Reissue Certificate button
opens the request processing page with preset values from the certificate. See Sec-
tion 2.4 (Processing Requests).
2.6.1 Viewing and Exporting Private Keys
If the certificate has been created using the Make New Certificate option (see Sec-
tion 2.13.7 (Creating Certificates)) or if a CMP enrollment client has requested key
backup, the private key corresponding to the certificate is stored in the Certifier 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.10.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 password
that is shown on the top of the page.

Figure 2-16 The View Encrypted Private Key page
To download the key (in binary PKCS#12), click the Download button. Your browser
will ask whether you want to open the key file or save it to disk.
To view the key with another password, enter the password in the Refetch with
passphrase field and click Refresh.
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.2 Exporting certificates without private key
Certificates that do not have private key in database can be exported to PKCS#12 file.
File includes certificate and full issuer chain.
By default file does not include mac verification passphrase (as private key is not in-
cluded). Passphrase can be included if required.
Click Export Certificate button on certificate page. This opens certificate export page.
Download the p12 file by clicking Download Certificate. If passphrase is required, set
Refetch with passphrase (or use existing pre generated passphrase) and click Re-
fresh. If passphrase is set, Passphrase used appears on the top of the page show-
ing the passphrase.
PKCS#12 file can be opened e.g. with ssh-certview (comes with Certifier) or with
OpenSSL. When using OpenSSL, use –nomacver parameter if PKCS#12 file does
not include passphrase.

2.7 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.7.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-17 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-down
lists in several different displays in the system. SCEP enrolment 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 more
thoroughly 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 from
scratch.
The Default policy list displays three basic policy options, Deny all, Manual
request approval, and Automatic request approval. When Deny all is selected,

the CA will not issue any certificates before the policy is specifically activated. By 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 Automatic
request approval is being employed, the CA will automatically issue the certificate if
the request contains a valid shared key that can be associated to an entity.
The Default validity period length is the validity time used in the default CA policy
that is automatically generated for the new CA. Note that if the generated set-validity-
period policy module is removed from the policy, there will be no default time and the
time specified in the incoming requests are always used.
Preliminary Publishing Settings
Preliminary publishing settings can also be chosen in the Create New Certification
Authority page. Default publish setting defines the publishing schema that is 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 Publishing
Service defines the directory access including the server address and the directory
administrator login name and password.
All of the above choices can be edited later, so setting them correctly is not critical at
this stage.
CA Certificate
If a CA certificate is already in the Database (added by an external utility, previously

created) it can be searched for by writing a free-text search string in the text box and
clicking the Search button. The search results are displayed in a drop-down list. Note
that if a result list is too long, it will be truncated. Therefore it is advisable to use pre-
cise search texts.
If previously created CA keys and a certification request exists in the database, a CA
certificate that has been signed by an off-line CA can be imported by clicking the
Import certificate button.
If there is no ready-made certificate in the Database, one must be created by clicking
the Create New CA Certificate button. This will open the Make New Certificate
page. See Section 2.13.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, the
user should wait until the key generation process is complete and then restart the CA
creation. The new certificate in the Database can be found, for example, by searching
its subject name.
The new CA is created by clicking the Proceed button.

2.7.2 Editing CA Settings
To configure an existing CA, click the CA name on the CA List page. This will open
the Certification Authority page.
On the CA page several CA specific fields can be set. The first field, CA name, is a
short and descriptive name that operators can easily identify. It does not have to
match the subject name in the CA certificate. Description is a longer description
viewed only by the operators. The CA Status is either Active or Inactive. CAs
marked as Inactive cannot be used. Internal object ID shows the identifier that
engine uses internally to reference CAs and RAs. Internal ID is used in log messages
(caId and raId values).


Figure 2-18 The Certification Authority page
CA Certificate
The CA certificate can be viewed by clicking the View Certificate button on the CA
certificate row. The certificate can also be changed with the Change button, but this
should be done only after extreme consideration! As all certificates issued by this CA
are signed with the old CA certificate’s key, all CRLs issued after the CA certificate
change might be invalid for old certificates. Changing the CA certificate will in effect
revoke all certificates issued by that CA before the change!
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 Publishing
Method page by clicking the Edit Publish button. See Section 2.9 (Publishing Set-
tings).
CA Auto Renew
CA keys (and certificate) can be automatically renewed. The Renewal period field
shows how much in advance the keys are renewed prior to the current certificate 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.
SNMP configuration
CA related traps can be send to specific SNMP target. By default, all traps are send to
global SNMP target (specified in engine.conf file). When CA CNMP configuration is
set, general SNMP traps are send to global SNMP target (e.g. engine start/stop) and
CA specific traps to CA SNMP target (e.g. request rejected).
CRL Update and CRL Publish Methods
CRLs are published to a CRL distribution point. The Update Period, Advance, This
Update Offset, and Next Update Offset (given in seconds) can be changed. They
are updated in the Database when the Commit Changes button is clicked. Note that
the next CRL is still published according to the old update settings. The CRL Update
information is given in seconds (for example 3600) or in minutes (50m) or in hours
(15h) or in days (370d).
By setting the Update Period value to zero, the operator can disable CRL updating.
After that no new CRLs are automatically generated, but the operator can still request
on-the-fly CRL generation by clicking View Distribution Points and then View
Current CRL. The system generates the CRL with the validity period starting from the
current time and ending after a configurable amount of time. (This is configured with
the engine configuration file.)
Advance is the time marginal reserved for CRL generation. For example, if Update
Period is 600 (10 minutes) and Advance is 120 (2 minutes), the system will every 8

minutes publish a CRL with a lifetime of 10 minutes. This is to ensure some overlap
period, as there may be a delay before the CRL is generated and available for clients.
This Update Offset is the time reduced from the thisUpdate field of the CRL. For
example, if This Update Offset has been set to 1800 (30 minutes) and the publica-
tion time of the CRL is 13:00, the thisUpdate field is set to 12:30. The option is use-
ful to accommodate 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 to
7200 (2 hours), the system will every hour publish a CRL with a lifetime of 3 hours.
The option is useful to allow some overlap of CRL validity periods in case the CA is
down or unreachable.
The CRL Update Type can be either periodic update only, or update after each 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 clients
do 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, only
OCSP 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.9
(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 key
type (RSA or ECDSA).
Other Settings
The Next serial number is a CA specific counter for serial numbers assigned for
certificates issued by the CA. It is normally increased by a random value after each is-
suance. This value can be used to set a starting point of a serial number space for the
CA, if such is specified e.g. in CA policy.
Changes made to the CA data or to non-publishing related data in CRL distribution
points (update period) can be updated to the Database by clicking the Commit
Changes button.
The Edit Policy button will display the separate policy editing page where the policy
of the CA can be viewed and modified. See document Policy chain and modules.
View Current CRL displays the currently active CRL for this CA. View Log shows all
log events related to this CA.
Restarting Publishing
Clicking the Restart publishing unpublished certificates button will search all 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 have

failed to publish correctly because of a network problem or misconfigured publishing

information. The process is only started when this button is clicked and will continue in
the background until finished.
The Restart publishing all certificates button is similar, but will instead republish
all active certificates of this CA. This can be used, for example, if the LDAP server has
changed and all certificates need to be added again.
Both of these two buttons should be used with care as they will generate a lot of Da-
tabase and network traffic.
2.7.3 View CRL Distribution Points
The View CRL Distribution Points page lists the distribution points. The Current Size
shows the number of certificates whose status can be checked via the distribution
point. Update Period shows the configured CRL update interval. Last Update
shows the issuing time of the latest CRL and Next Update shows the time of the
next update marked into the current CRL.
Via the View log link you can see the log items related to the distribution point. View
CRL link shows the current CRL in PEM format. The Generate CRL link can be used
to manually trigger a new CRL generation.
2.7.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 key
and one for the new key signed with the old key. These certificates can be used to
maintain trust relationship during the transition period when some of the clients are
using certificates from the new CA key and some are still using certificates from the
old CA key.
The automatic renewal is established by enabling it and defining a margin time.

Figure 2-19 The CA renewal configuration page
By checking the Renewal enabled checkbox the automatic renewal is enabled for
the corresponding CA.
Renew marginal is the time how much CA certificate has validity time left before the
renewal takes place. The value can be given as days, e.g. 30d.
Note: renewal marginal cannot be longer than ¼ of the certificate life time. Greater
values are automatically adjusted.
Old CA certificate is the previous CA certificate.
New with old is the certificate for the new CA key signed with the old CA key.
Old with new is the certificate for the old CA key signed with the new CA key.
These last three input fields need not to be filled by the user and they are displayed
only if CA certificate has been renewed.
Inactive CA renewal
Inactive renewal works the same way as normal renewal, except the resulting certifi-
cates are not taken into use. This means that the certificates are active and linked to
the CA, but the CA still operates using the previous certificate and private key. To
make certificates operational, the certificates must be activated.
 Inactive certificates must always be manually activated by the operator. They
are not automatically activated even if the current operational CA certificate 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 the
new CA certificate but not cross certificates.
 Selecting Manual renewal will reset inactive renewal. Certificates generated
with inactive renewal still exist, but they cannot be activated.
Figure 2-20 CA Renewal configuration with inactive renewal data
Inactive renewal information is shown in Edit CA Auto Renewal page inside

Inactive renewal data box. By selecting Activate the certificates are taken into
use. Note that this operation cannot be undone.
Inactive renewal can be enabled in automatic renewal by checking Inactive mode?

Inactive mode in automatic renewal will work with the same renew marginal as normal
automatic renewal. If inactive information exists, the automatic renewal interval is cal-
culated using certificate created in inactive renewal. Otherwise interval is calculated
using 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 sub
CA renewal will be issued using root CA's current operational certificate or certificate
from inactive renewal. When enabled, the CA will issue sub CA certificates using its
certificate from inactive renewal. When disabled, the CA will issue sub CA certificates
using its current operation certificate. The latter is the standard way. Option will have
an effect to all sub CAs under the CA. If the CA is not an issuer to any sub CAs, this
option has no effect. Option does not affect normal certificate enrollment. End entity
certificates are enrolled under the operation CA certificate until inactive certificate is
activated.

2.7.5 Editing CA SNMP Configuration
By default Certifier engine and CAs use global SNMP configuration defined in en-
gine.conf configuration file (defined initially on Certifier setup).
CA can also be configured to use specific CA specific SNMP configuration. When CA
SNMP configuration is set, CA related traps are send using CA SNMP target and
global traps are send using global SNMP target. Notice that configuration is CA spe-
cific.
Figure 2-21 CA specific SNMP configuration
Configuration parameters are same as in engine.conf. Difference is “Send traps to

global session”. When option is enabled, CA related traps are send to CA specific
SNMP target and to global SNMP target.
CA related traps are:
 Request rejected
 Request rejected by policy
 CA certificate expires
 EE certificate expires
 Active certificate limit
 CRL publish fail

 CRL published
 CRL generation fail
 SCEP request handling failure (depends if failure is before/after parsing the

CA information)
 CMP request handling failure (depends if failure is before/after parsing the CA

information)
 Configuration change/update (when change/update is CA related)

Notice that SCEP/CMP and configuration traps may be send to global SNMP session
if CA (issuer) is not known. For example, if CMP handling failure occurs before we can
parse issuer information, trap is send to global SNMP and not to CA specific SNMP
target.
2.7.6 Statistical charts
Statistical charts page shows the summary of certificate requests and certificates is-
sued by the CA.
2.7.7 Removing CA
CA can be removed by clicking Remove CA button. All configuration data related to

the CA is deleted, the CA certificate is revoked, and all certificates issued by the CA
are revoked including any Sub CA certificates.
Note: If the CA is listed in any service’s accessible CAs or trusted CAs or the CA is
used to issue TLS certificates for the services, those functionalities will fail after the
removal. It is strongly recommended to remove any relation between the CA and ser-
vices before removing the CA.
2.8 Registration Authority Settings
In Insta Certifier, an RA is in many ways similar to a CA. However, the RA creation is

a bit different, since RA usually enrolls its certificate from a CA which is not running on
the same installation.
When using a remote CA (not running on the same installation) pre-requisities for RA
creation are that:
 There is an online CMP connection to the CA. If Insta Certifier is running the CA,
a CMP Service needs to be running on the Certifier Server instance.
 The CA has to have an automatic issuing policy for valid RA entities.
 The CA administrator has issued a reference number and a key that the RA can
use when performing the RA certificate enrollment. See Section 2.11.1 (Creating
a Delegated RA Entity).
 There is an External Enrollment Client Service running on the same server with
the RA. This service is needed for performing the RA side of the RA-CA commu-
nication.

2.8.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.7.1 (Creating a New Certification Authority).
Click Proceed to create the new RA.
2.8.2 Editing RA Settings
To configure an existing CA, click the RA name on the RA List page. This will open
the Registration Authority page.
Many RA configuration options are identical with CA configuration options. There are,
however, some differences. RAs do not publish certificate revocation lists, so an RA
does not have any CRL settings. On the other hand, RAs need to have a connection
to a remote CA, so there are additional settings related to the RA-CA connection.

Figure 2-23 The Registration Authority page
The first field, CA name, is a short and descriptive name that operators can easily
identify. It does not have to match the subject name in the RA certificate. Description
is a longer description viewed only by the operators. The RA Status is either Active
or Inactive. RAs marked as Inactive cannot be used.
RA Connection Configuration
The RA field contains settings of the RA-CA connection. Enroll Client Service is the
name of the External Enrollment Client Service used by this RA.
Connection Type indicates the method the RA uses to connect to the CA. Possible
connection types are Local, CMP over HTTP connection, Write CMP to file,
External command line, and No automatic connection. Local means using a CA
within the same installation.
 In case direct CMP connection is used, Connection Path is an HTTP URL of
the CMP Service on the CA host.
 If the CMP request is written to a file, Connection Path is the file name. This 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 to
a temporary file and the %file tag on command line is replaced with its name.
Polling Interval is the time interval in minutes that the RA polls the CA for accepted
certificates. Polling can be disabled by setting the interval to zero. RA message can
be sent manually with the Send RA Message button. It will use current connection
type and path to send the message. View RA Message button can be used to view
the message in browser. Clicking the Insert CA Reply button opens the Process
Offline CA Response page, where a PEM-encoded CMP message can be inserted
to the RA.
Remote CA Certificate shows the certificate of the remote CA. The certificate can
be viewed by clicking View Certificate. The certificate can be changed by clicking
Change. This is normally done automatically when RA certificate is enrolled.
Certificate Publishing
Certificate Publish Method describes the current publishing method for certificates
issued through the RA. The line shows the current protocol and server address, if ap-
plicable. The configuration can be changed on the Edit Certificate Publishing
Method page by clicking the Edit Publish button. See Section 2.9 (Publishing Set-
tings).
RA Certificate
The RA certificate can be viewed by clicking the View Certificate button on the RA
certificate row. If the RA does not yet have a certificate, a certificate can be
searched by clicking the Search button. An existing certificate can be changed by
clicking the Change button.
A new certificate can be enrolled by clicking the Enroll New Certificate button. This
will also set connection parameters and remote CA certificate in RA configuration and
commit the changes. For a detailed description, see Section 2.8.3 (Enrolling an RA
Certificate).
Other Options
Changes made to the RA data can be updated to Database by clicking the Commit
Changes button.
The Edit Policy button will display the separate policy editing page where the policy
of the RA can be viewed and modified. See document Policy chain and modules.
View Log shows all log events related to this RA.
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 have
failed to publish correctly because of a network problem or misconfigured publishing

information. The process is only started when this button is clicked and will continue in
the background until finished.
The Restart publishing all certificates button is similar, but will instead republish
all active certificates of this RA. This can be used, for example, if the LDAP server has
changed and all certificates need to be added again.
Both of these two buttons should be used with care as they will generate a lot of Da-
tabase and network traffic.
2.8.3 Enrolling an RA Certificate
To enroll a new RA certificate Click the Enroll New Certificate button. This opens
the New RA Certificate Enrollment page.
If you are using CMP over HTTP connection as the RA-CA connection type and you
have given the CMP URL on the RA page, the CA address will already be filled. 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 name
of the RA certificate request in the Subject name field.
Figure 2-24 Enrolling the RA certificate
By default, a 1024-bit RSA key is generated. To change this, click Set Key
Generation Parameters. This opens the Key Generation / Import page where
you can edit the key attributes.
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 the
pending request.
2.8.4 Using a Local CA with RA
To use a local CA, select Local as Connection type. This setting affects the RA
functionality in the following ways:
 The new RA certificate request is processed as a request within the same Certifi-
er instance where the RA is running. In other words, the RA’s own certificate is
enrolled locally.
 When a certification request is addressed to the RA, it forwards the request after
initial policy processing to a CA, which processes it again against its own policy.
The CA can be selected by using a policy module Set Issuing CA in the RA’s
policy. If the module is not used, the target CA will be the same that issued the
RA’s own certificate.
2.9 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 Access
Protocol (LDAP) and HTTP. Also external methods can be plugged in the system and
revocation status can be published through the OCSP protocol as well.
To edit certificate publishing methods, click Edit Publish on the Certification

Authority page. To add a new publishing method, choose the publishing method
from the Add new method drop-down list and click Add. For certificate publishing,
LDAP and External methods are supported. For CRL publishing, LDAP, HTTP,
OCSP, and External methods are supported.

Figure 2-25 The Edit Certificate Publishing Methods page
2.9.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 is
correctly 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 LDAP
URL or as a directory name.
To actually include the CRL distribution point information in the issued certificates, the
CA policy has to contain the Set CRL Distribution Point module.

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 are
written as %{name}.
LDAP object name is a distinguished name and therefore must be structured as OID
and value pairs. Most commonly used OIDs can be written using their symbolic
names but they can also be given as numeric OID values. Very probably the certifi-
cates and CRLs should be published to exactly the location implied by the subject
name of the certificate (or the issuing CA subject name in the CRL case). If this is not
the case, various PKI clients will not be able to automatically perform certificate path
construction or fetch peer certificates from the directory.
This recommended setup is accomplished by specifying
%{subject-name}
as the object name format.

For non-trivial PKI or directory setups the object path name can be constructed piece
by piece. For example, the following object name format string for certificate publish-
ing would take the organization (O) from the subject name of the certificate issuer, the
common name (CN) from the subject name of the certificate, and finally add the serial
number of the certificate with a fictional OID 1.2.3.4.5.6.
C=FI, O=%{ca-subject-name:O}, CN=%{subject-name:CN},
OID.1.2.3.4.5.6=${serial-number}
The supported special fields are the following:

%{subject-name}
Replaced with the subject name of the user certificate (if any). Optionally a param-
eter can be appended to specify a RDN within the subject name. If the subject
name is, for example, C=FI,O=Insta,CN=Test Person, the field %{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 publish
method 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 with
function given as a parameter. This allows an extensible way to define object
names. Same functions are also usable in LDAP attribute definitions.
Usually the subject name is a good choice for the certificate’s path name and the sub-
ject name of the CA certificate for certificate revocation lists. Note that the object path
given here is expected to be in the same order as all other distinguished names in 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 be
configured very freely. Attributes can be added by selecting an attribute from the
LDAP Attributes list and clicking the Add button. This will add a new row to the
LDAP attribute table.
The attribute table contains columns for attribute name, value, and type. Attribute
Name is a string that identifies the attribute in the LDAP system. How the Value field
is used depends on the type of the attribute.
String Literal
The value field is stored to the attribute as is.
User Certificate
By default, the entire issued certificate associated with the operation (if any) is
stored to the attribute as binary data. This can be an end-user certificate or a 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 of
the certificate can be stored.
CA Certificate
The entire CA certificate (of the issuing CA) associated with the operation is stored
to the attribute as binary data. Other values can also be stored as in the User 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 RDN
from user subject name is selected, only the named RDN value from the subject
name is copied (without the tag part). For example, if the subject name is C=AS,
O=Policy Application Inc., S=Grant + G=Prachi and the value is O,
then the attribute will have the value of Policy Application Inc..
CA Subject Name
As User Subject Name above, but the CA subject name (or one of its components)
is stored.
Entity Data String
The specified data field is copied the from the associated entity data. For example,
selecting Email copies the Email attribute from the entity to the given LDAP attrib-
ute. If the entity has several attributes of the same type, only the first attribute or all
attributes can be selected.
Use Policy Callback
The value is given as a parameter to the scheme policy callback function and its
result is stored to the attribute. Example functions provided in policy.scm include
make-user-name
Takes either the CN or the G and S fields from the subject name and makes them
a single name string.
current-time
Replaced with current time value in 2001-10-21 20:15:30 format.

set-certificate
The value is replaced with a binary certificate. In addition, the attribute name is 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 LDAP
directory. If the object does not exist, the system performs an add operation with the
given path name and attribute. If the object already exists, the system performs the
publishing action selected for the attribute. The actions can be:
 Update by replace: The system tries to perform a replace-type modify opera-
tion. This means that previous values of the attribute are replaced with the new
value(s), creating the attribute if it did not exist. If this fails, the publishing attempt
fails and the engine can either mark the publishing attempt as failed or restart the
operation after a delay.
 Update by add: The system tries to perform an add-type modify operation.
This means that the new attribute value is added to the list of existing attribute

values, creating the attribute if it did not exist. If this fails, the publishing attempt
fails.
 Initial add only: If the attribute already exists, the publishing attempt fails.
Default Publishing Schemas
The LDAP publishing schema can be reset to default values by selecting a schema
and clicking the Set button in the Reset to default box.
The available default schemas for certificate publishing are:
 LDAPv2 pkiUser schema
 LDAPv3 pkiUser schema
 LDAPv2 strongAuthenticationUser schema
 LDAPv3 strongAuthenticationUser schema
The available default schemas for CRL publishing are:
 LDAPv2 pkiCa shcema
 LDAPv3 pkiCa shcema
 LDAPv2 certificationAuthority shcema
 LDAPv3 certificationAuthority shcema
 ActiveDirectory schema
RFC 2587, Internet X.509 Public Key Infrastructure LDAPv2 Schema, defines object
classes for certain PKI objects. For certificates the standard defines the object class
pkiUser, which can be configured in Insta Certifier by selecting LDAPv2 pkiUser
schema under Reset to default and clicking Set.
For CRLs the RFC defines multiple object classes, one of which is pkiCa. It can be
configured in Insta Certifier by selecting LDAPv2 pkiCa schema under Reset to
default and clicking Set.
Note that both the pkiUser and the pkiCA are auxiliary object classes meaning that
you have to use a structural object class with them. There are also common structural
object classes containing attributes for certificates and CRLs such as
inetOrgPerson and eidCertificationAuthority. Also these can be used
when the directory schema supports them.
Other Options
Clicking the Commit Changes button will update the data into the Database and
clicking the Cancel button will ignore the changes.
2.9.2 HTTP Publishing Method
Insta Certifier includes a convenient way of publishing CRLs without the need for a
full-scale LDAP deployment: The built-in HTTP server of the Web Enrollment Service
can be used for CRL publishing.
If you have chosen the HTTP publishing method for CRLs, the only setting that needs
to 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-
rations in order to be able to select it from the Web enrollment service connection
drop-down list.
As the server address is not always sufficient for external PKI clients to connect to the
Enrollment Service, the URL prefix for CRL distribution points in Enrollment Ser-
vice configuration must also be set to contain correct address and port information.
For example, http://enroll.big-corp.com:8080/ is a valid setting. See Section 2.12.9
(Editing the Web Enrollment Service).
There is also an option in the HTTP publishing method to use a shortcut URL. For
example "my-crl" makes the CRL path as "http://1.2.3.4/my-crl". Valid values are
ASCII letters and numbers. All invalid characters will be escaped, for example
"my#url" will be changed to "my%23url" (23 is the hex value of '#').
To include the CRL distribution point information in the issued certificates, the publish-
ing method has to have the Include in Certificates check box selected and the CA
policy has to contain the Set CRL Distribution Point module.
2.9.3 OCSP Publishing Method
The OCSP publishing method contains only the OCSP Responder Service that is
used. All information about its address is configured in the service. Note that the
Authority Info Access extension is added to the issued certificates only if the CA
policy contains the Set CRL Distribution Point module and the publishing method
has the Include in Certificates check box selected.
2.9.4 External Publishing Method
To allow maximal flexibility in CRL and certificate publishing, Insta Certifier also sup-
ports external publishing. This method can be used either to write the published object
into a normal file or to execute an external script.
All types of external publishing are run in the Web Enrollment Service. This is im-
portant to remember when considering path names in external scripts and file names.
The external publishing method can also be used to add arbitrary URI CRL distribu-
tion point extensions to certificates. On the Edit CRL Publishing Methods page, se-
lect the Include in Certificates check box and write the URI to URL to add text
box. Now all certificates issued will contain that URL provided that the CA policy has
the Set CRL Distribution Point module added.
The external publishing method contains three action types. First of them is Just add
the CRL distribution point extension. This options is available in CRL publishing
only and it can be used if just the distribution point extension is needed in certificates.
The Write to file action simply writes the object to a named file. The current working
directory is the Certifier installation directory so it is usually a good idea to give abso-
lute pathname for the file. File format controls the format of the file.
The Run command action executes an external command to handle the object. Also
in this case it is advisable to provide an absolute path to the command. Apart for
command name the line can also contain parameters to that command. These are

usually given as special fields that represent files containing the data to be published.
Publishing Service then writes the data to temporary files and executes the command
line with special fields replaced with file names. Supported fields in the command line
are as follows:
%cert
The certificate to be published. Either in PEM or binary DER depending on the File
format setting. Ignored in CRL publishing.
%crl
The CRL to be published. Either in PEM or binary DER depending on the File for-
mat setting. Ignored in certificate publishing.
%ca
The certificate of the issuing CA, both in CRL and certificate publishing. Either in
PEM or binary DER depending on the File format setting.
%crl-url
Full CRL distribution point URL. Ignored in certificate publishing.

%msg
Complete publishing parameters encoded as an ASL; contains the published ob-

ject, CA certificate and other configuration data.
2.10 Operators
All persons who are allowed to operate Insta Certifier must have an operator account
created for them. Operators are identified with a short login name and a password (if
TLS client authentication is not used). However, in most situations the most crucial
identification method is the operator’s TLS certificate.
This certificate can be stored on the operator’s personal workstation, or on a crypto-
graphic token such as a smart card.
If software storage is used, the security and the integrity of the used operating system
is very important. Normally browsers can be configured to protect the private keys
with a password when the private key is generated during web enrollment. Using this
security feature is highly recommended.
Note also that if the certificates used for TLS client authentication are stored in the
workstation, an operator can login only from the specific workstation that stores the
key.
The aforementioned problems can be avoided by creating the keys on a smart card.
2.10.1 Adding Operators
Any operator with super-user privileges is authorized to add new operators and to set
their privileges. This can be done on the Operator page, accessed by selecting the

Operators main menu option. To create a new operator, click the Create New
Operator button located at the bottom of the screen.
On the following page the operator’s attributes can be set before the operator is actu-
ally created.
The Login Name field is the short and unique login name that is used in login and
identifying different operators in log event displays. It is customary that such names
are written in lower case and without spaces. However, note that the name is case-
sensitive.
Figure 2-26 Creating a new operator
There are two Password fields that are used as verification. The same password
must be entered into both boxes. Password policies (requirements) are configured in
system parameters page. Passwords have operator specific history of 20 passwords.
Operator can’t use the same password again (until 20 password changes).
The longer Operator Name field is provided for the complete name of the operator.
This field is mainly used as a help for the other operators.
If operator is based on LDAP user, select Use external authentication. In these cas-
es, operator is authenticated from LDAP server (see LDAP authentication service).
Password is not stored to Certifier. Login Name must be LDAP user’s name. Depend-
ing on LDAP authentication service configuration, name can be either just the last part
of the LDAP username (e.g. the cn part) or full path (e.g. dc=…, dc=… cn=…) or vari-
ation of full LDAP path. LDAP is only used to authenticate user. Access control is still
locally stored in Certifier.
The basic access rights of the operator can also be set (Read only, Normal, Super
user). The access rights can (and should) be further modified on the Operator page.
See Section 2.10.2 (Editing the Operator Information) for more information on the lev-
els. Notice that Read only and Normal level operators cannot create certificates with
basic constraints extension CA and critical set to true. This means that these levels
cannot create CA certificates. Use Super user level for CA certificates.
After this information is correctly set, the operator can create the new operator ac-
count by clicking the Create New Operator button. This will open the Operator
page, where further editing can be done.

2.10.2 Editing the Operator Information
On the Operator page the operator information can be edited and the password
changed. Login and password information is required if only server authentication (not
client) is used in TLS. Also the privileges can be defined here by an operator with suf-
ficient privileges.
Operator password requirements depend on Certifier password settings (see System
Configuration). Settings define password length and use of lower- and uppercase
characters, numeric and special characters (e.g. ‘#’).
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. If
they 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 of
operations he is authorized to perform. Only super-user operators are authorized to
modify access control items of other operators in the system. To add a new access
control item, click the Add button. To remove or edit an existing rule, click either the
Remove or the Edit button.
Notice that operators can’t add/edit/remove their own access rights. This applies to all
levels of operators including super-user.
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 and
certificate management are shown.
If Simple Admin UI is selected, the operator will use a simplified user interface that
contains only the functions for creating and editing entities and revoking and 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 Time
format 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. certificate
validity 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 of
attributes with additional information. Attributes can be added by selecting an attribute
from the drop-down list and clicking Add. The available attribute types include
Description fields, Address fields, and Email addresses.
By default this information is not used in any way, but it exists to help the operators to
identity and contact each other. If the operators require TLS client certificates, the en-
tity attributes can be included in the certificates if a suitable policy module is used in
the CA policy.

Pre-Shared Keys and Certificates
Operators may have pre-shared keys just like entities. Shared keys are used to 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.12.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 give
the key when enrolling a certificate through the Web Enrollment Service. The CA who
is authorized to issue operator client certificates can be selected on the configuration
page of the Administrator Service. Instruct the operator to select this CA during the
enrollment.
When the TLS client certificate is issued for the operator, this certificate is shown in
the Client certificates of the Operator page.
Committing Changes
The Commit Changes button updates all changed operator data into the Database.
Operator Logs
The View Operator Change Log button shows all log events relating to this opera-
tor and the View Log button shows all log events that this operator has been involved
in. So if one operator changes another operator’s phone number, that can be dis-
played by clicking the first button, but if this operator accepts a request, that can be
displayed by clicking the second button.
Removing an Operator
Click the Remove Operator button to remove the operator from the system. Be 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.10.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 and/or for certain CAs and RAs in the system. This enables
adding administrators that are allowed to configure only one specific logical CA or RA
in the system. Also, by using access control levels, lower and higher privileged opera-
tors can be added.
Operators cannot add/edit/remove their own access control rights.
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 level
does not allow any modification such as certification request approval, entity modi-
fications or configuring.
Read and suspend access
This is as read access above, but in addition the operator can suspend certificates.
The operator cannot reactivate suspended certificates.
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 phone
numbers or e-mail address. The operator can also revoke certificates belonging to
the entities. However, an operator with entity write access is not allowed to create
shared keys or accept certification requests.
Write access
Write access allows editing entities, processing requests manually, and revoking
and suspending valid certificates. Also enrollment services (Web Enrollment, CMP
and SCEP) can be created and configured within the limits of access to CAs. This
is an appropriate authorization level for operators who run the everyday CA/RA
operations, but do not configure the system.
Write and key recovery access
Write and key recovery access allows the same actions as write access, but in ad-
dition the operator can access escrowed private keys.
Note that this access level gives the operator access to sensitive information (user
private keys), and should be given to operators only if they are required to do key
recovery operations.
Super-user access
A super user is allowed to perform any operation related to specific CA. These op-
erations include modifying CA settings such as certificate policy and publishing
schemas.
As a super user has full control over the policy of the CA and access to escrowed
private keys, this access level should be used only when it is necessary.
Configuring servers and creating and updating other operators requires Super-
user access to ALL CAs. This access control, however, does not provide full ac-
cess to all CAs without additional Include subordinate CAs flag.
Editing Access Control Items
There are four drop-down menus in the Edit Access Control Item page. The first
one defines the Access level as described above (No access, Read access, Read

and suspend access, Read and revocation access, Entity write access, Write
access, Write and key recovery 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 option Include subordinate CAs can be used to decide whether also subordi-
nate CAs of the selected CA are included in the authorization.
2.10.4 Configuration Signature
Operator can sign configurations with smart card certificate service provider (CSP)
which supports signature creation service (SCS). Possible configurations are CA,
server and full system configuration.
Operator needs smart card with operator private key and certificate. Certificate must
be imported to Certifier for signature verification. Import certificate from System Con-
figuration Insert Certificate.
After certificate import, add the verification certificate to operator. Open Operators
page, select operator from list and under Configuration signature verification,
search for the imported certificate. When correct certificate is selected, click Commit
certificate.
After verification certificate is set, configuration signature buttons on CA, server and
system configuration page are visible. Operator can only have one signature per enti-
ty. This means that e.g. operator ‘A’ can only have one configuration signature for
‘CA-1’. If operator ‘A’ signs ‘CA-1’ configuration again, older signature is overwritten.
To sign CA configuration, open CA Hierarchy and select the CA. At the end of the
page, click Configuration signature button. This opens a configuration signature
page.

Click sign configuration and select the key to use for signing (this depends on CSP).
If signing is successful, signature appears in Signature text area. Click Save Signa-
ture to save it to database. Notice that signature algorithm is always RSAWith-
Sha256.

To verify signature, open Operators page and select the operator. At the end of the
page, operator has list of Configuration Signatures. Entity type shows the type of
entity (CA, Server of system configuration. Entity name is the name of the entity (e.g.
CA name). View certificate opens the verification certificate. Click Verify signatures.
Signature is verified against current running configuration. Each signature is verified
when Verify signature is clicked. If verification is success, configuration is not
changed; otherwise configuration differs from configuration that was signed. Verifica-
tion also fails if entity is removed from the system (e.g. CA is deleted), or verification
certificate is deleted.
2.11 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, RA
delegation typically has deeper implications to the PKI than just authorizing an end
entity for a certificate.
2.11.1 Creating a Delegated RA Entity
Click Delegated RA Entities on the main menu of the admin GUI. List of existing
delegated RA entities is shown. Properties of the existing RA entities can be edited by
clicking their names. New delegated RA entity can be added by clicking the Create
New RA Entity button. The Create New RA Entity page opens.

Figure 2-29 The Create New RA Entity page
The entity name, shown in the administration user interface, and a freeform 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 to
cancel the operation.
A delegated RA entity can have similar attributes to the end entities. An attribute can
be added to the RA entity by selecting an attribute from the Attributes list and click-
ing Add.
An attribute can be removed by clicking the Remove button on the right hand side of
the attribute.
Click Create to create the entity. This opens the Delegated Registration
Authority Entity page where the entity can be further edited.

2.11.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 RA
administration who is performing the RA certificate enrollment.
After the RA has enrolled its RA certificate, it will be shown in the RA Client
Certificates field of the page.
A delegated RA entity should have access to a CA within the same Insta Certifier in-
stallation. The access control can be defined by editing the Access Control list. By
default, the RA entity can request certification from any CA. Approval is subject to the
CA policy.
To view requests directed to this RA, click the View Requests button on the bottom
of the page. To view certificates approved through this CA, click the View Approved
Certificates button. (Clicking these buttons initiates a database search with appro-
priate search criteria.)

Once the entity data has been edited, changes can be taken in use by clicking the
Commit Changes button on the bottom of the page.
2.11.3 Delegated RA Access Control Levels
An Insta Certifier delegated RA has a set of access control rights, defining what kind
of operations the delegated RA is allowed to perform. These operations can be re-
stricted for certain kind of operations (enrollment, revocation, and key recovery and/or
for certain CAs and RAs in the system. This enables delegated RAs to operate in mul-
ti CA environment. Also, by using access control levels, lower and higher privileged
RAs can be added.
Insta Certifier supports the following access control levels:
Revocation access
Revocation access for certain CA in the system means that the RA is authorized to
revoke certificates issued by that CA.
Revocation and enrollment access
This is as revocation access, but in addition the RA is authorized to request certifi-
cates from the CA.
Revocation, enrollment and key recovery access
This is as revocation and enrollment access, but in addition the RA is authorized to
do key recovery for certificates issued by the CA.
Editing Access Control Items
There are three drop-down menus in the Edit Access Control Item page. The first
one defines the Access level as described above (No access, Revocation access,
Revocation and enrollment access, or Revocation, enrollment and key
recovery access).
Figure 2-31 Editing an access control item
The second menu (Target CA) can be used to select to which CA the access control
is applicable. If the – ALL CAs — option is selected, the RA is authorized (or denied
when using No access) to access all logical CAs in the system.

The third menu (Rule scope) can be used to decide whether also subordinate CAs of
the selected CA are included in the authorization.
2.11.4 RA-CA Communication Policy
Delegated RA entities can have a policy for RA-CA communication. The processing of
this policy takes place when a request arrives from a remote RA to the CA (the RA
has already accepted the request). However, the policy is run only if the CA policy
contains the Apply Policy Attributes (from Entity) module in the receive-request
chain. See document Policy chain and modules.
The RA-CA communication policy contains only the receive-request chain. The pol-
icy can be edited by clicking Edit Policy on the Delegated Registration Authority
Entity page.
2.12 Certifier Servers and Services
The modular architecture of Insta Certifier provides a flexible way to centrally manage
the various PKI frontend interfaces and optionally distribute them to different hosts.
This allows scalability for large deployments, but on the other hand, more limited PKI
deployments can be easily implemented since only the required mandatory services
need to be taken into use.
In addition to the Certifier Engine, there needs to be at least one Certifier Server 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 instances
running on different hosts, and Certifier Engine running on a dedicated host.
Figure 2-32 The Server List page
The Server List page lists the Server instances of the system. During the installation
one Server instance is created to provide the Administration and Web Enrollment Ser-
vices.
To add a new Server instance, click the Add New Server button. After this, you need
to install the Certifier Server software to the host (see Insta Certifier Administrator’s
Guide for instructions).
To configure an existing Certifier Server instance, click the View Server button.

2.12.1 Creating a New Server Entity
Creating a new Certifier Server instance is done in two steps:

1. A new server entity is added to Insta Certifier. This server also needs to have a
pre-shared key added to it.
2. The actual server software is installed to the target machine from the Certifier
Subordinate Server package. During the installation process you are prompted
for the Certifier Engine address and the pre-shared key you created for the server
entity.
See Insta Certifier Administrator’s Guide for more instructions.
After the new Certifier Server is installed and connected to the Certifier Engine it
needs to be configured by adding at least one Certifier Service. The currently 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 to
secure the communication between the Server and Certifier Engine. In addition, some
of the Services may have certificates. For example, the OCSP Responder Service
needs to have a certificate in order to be operational. All certificates related to the
Server entity are listed under Client certificates. If the CA that is issuing certificates

does not allow automatic issuing, the pending certificate requests are listed under
Pending client requests.
Services enroll and renew their certificates automatically. If a certificate needs to be
changed, for example, to give it a more suitable name, it can be done by viewing the
certificate and then Reissuing it. Then the service must be restarted and it will 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 Certifier
Subordinate 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 during
normal operation and it can renew its certificate automatically.
However if a service installation has been erased or if it has not been used for some
time, it might have lost its certificate or the certificate might have expired. In order to
reinstall the server, a new shared secret must be added to server entity.
To view the server entity log or server entity requests, click the corresponding View
Log and View Requests buttons. Server entities with similar configurations can be
created by clicking Copy Entity button. The server entity can be removed by clicking
the Remove Entity button. This operation should be used with extreme care.
You can’t add services with same bind address. Services that have bind address are:
administration, web enrolment, CMP, SCEP and older version of OCSP responder.
2.12.2 Editing the Administration Service
The Administration Service is a mandatory service in Insta Certifier, since it is used to

provide the web-based administration interface for the administrators. An 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 the
new service has been validated. This is a precaution, to avoid a situation where the
administrator has selected the security settings of the Administration Service, and
cannot access the system any more since she has not enrolled an administrator certif-
icate for herself. Also if there are problems in the administration configurations, similar
problems 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 of
use.
The Service bind address is the address where the Administration Service listens to
incoming HTTP and HTTPS connections. Remember to include the port number in the
address. For example, http://0.0.0.0:8083/ is an address for a service running on the
local host listening to port 8083. Note that the Service bind address needs to begin
with http instead of https even if TLS is being used.
Idle timeout specifies timeout in seconds before idle session to the administration
service is closed. Note that there are two global options in server.conf configuration
file for the same purpose: session-idle-ttl (initial) and session-idle-ttl (normal). The lat-
ter is used after operator has logged in. The Idle timeout setting overrides the ses-
sion-idle-ttl (normal). If it is set to zero (0) or left empty, the global option in server.conf
is used. Values less than 30 are rounded up to 30.
Template Set and Access Level
The Template set is the set of HTML templates used by this service. There are two
template sets available: Administration Interface and Revocation Interface.
The template sets are located in the Insta Certifier installation directory under admin-
templates/. The Administration Interface is the normal template set for administra-
tion tasks of the Certifier. The Revocation Interface is a limited set for operators that
only need to search user certificates and revoke, suspend and re-activate them. When
the Revocation Interface template set is used, there should be a separate Administra-
tion Service configured for this purpose. There must always be at least one Admin-
istration Service with the Administration Interface template set.
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.10.3 (Operator Access
Control Levels). If the operator has lower access level than the Service, the operator’s
access level sets the limits. If the operator has higher access level than the Service,
the Server’s access level sets the limits. That is, operators with super-user access can
log in to an Administration Service that allows Normal Operators Only, but they are
limited to Write access while using that Service.
Security Settings
The Security Settings option defines whether the HTTP server is protected with TLS
or not. If Unprotected HTTP connection is selected, all connections between an
administrator’s browser and the server are in plain text. By selecting TLS Protected
HTTP connection, the server has a certificate that it uses for authentication. All con-
nections are encrypted when using this option. However, the client (administrator) has
to use a login name and password to authenticate itself to the server.

When TLS with client authentication is selected, also the client has to have a cer-
tificate in order to connect to the server. If this mode is being used, administrator
passwords are not mandatory, since the client private key is used for the 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 TLS
Server Certificate CA field. Insta Certifier Internal CA, which is created during the
installation, can be used, unless a dedicated CA is wanted for this purpose. In the lat-
ter case, the same CA that is used for a protected Web Enrollment Service can be
used. See Section 2.12.9 (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 period
length and Key size can be selected in the TLS Server Certificate Settings. The
validity period will be included in the certification request. You can later re-issue the
TLS server certificate with new parameters, for example, if you want to edit the 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. Select the CAs from the drop-down list, 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.
If system has LDAP based operator authentication, enable Enable LDAP authentica-
tion and select LDAP authentication service from the drop down list. When ena-
bled, login page shows Authentication selection with values Certifier and LDAP.
When operator is Certifier based user (credentials checked in Certifier), select Certifi-
er. If operator is based on LDAP user, select LDAP. When LDAP is selected, user
credentials are verified from LDAP server. Username must be LDAP username and
Password is LDAP password. Operator can only be authenticated locally or from
LDAP.
Committing Changes
Click the Continue button to accept changes made to the Service settings, or click
Cancel to discard them. After clicking Continue, remember to Commit Changes on
the Edit Server Entity page.
2.12.3 Editing the CMP Service
Certificate Management Protocol (CMP) is an online certificate life-cycle management

protocol that provides functions such as initial enrollment, certificate renewal, key 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, the
system needs to have a CMP Service for providing the server-side functionality of the
CMP.

Figure 2-36 Editing the CMP Service configuration
Basic Settings

use.
Service bind address is a mandatory field. The address is either an HTTP URL or a
TCP URL, since CMP supports both transport mechanisms. Optionally, also Service
domain name can be given (a fully qualified domain name). If the field is left empty,
the name is generated from the Service bind address.
Service domain name and Service description are shown on the web enrollment 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 caPubs
field is chosen only the signing CA certificate is sent. If extraCerts is chosen the whole
CA chain from the signing CA to the root CA is sent. Used in IP and KIP responses.
Notice that pollResp response does not include caPubs field. Option extraCerts is en-
abled by default.
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. When
option is disabled, delivery depends on Deliver CA in field option. Notice that
pollResp response does not include caPubs field.
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 extraCerts
will not contain self-signed CA certificate. Notice that pollResp response does not in-
clude caPubs field.
Require PoP in KUR messages enabled, key update (KUR) messages are required
to always include valid proof of possession. Requirement affects even if request has
other means of authentication. When disabled, proof of possession field is not re-
quired. If field is included in the request, it will be ignored (not verified). Other means
of authentication is then required.
Options
Protection hash algorithm selection can be used to specify which hash algorithm is
used when calculating CMP message protection signature. The default auto option
chooses the algorithm automatically based on the signing key size, but some client
software may not support all hash algorithms.
CA certificate delivery method in response
These settings specify which CMP response message field is used for delivering the
CA certificate.
Allowed Operations
The Allowed operations check boxes can be used to select the CMP operations
that are allowed via the service.

The following operations can be selected:

Allow enrollment based on pre-shared secrets
Allows certificate enrollment using pre-shared keys as the initial authentication
method.
Allow enrollment based on existing certificate (signature)
Allows a certificate holder to request another certificate using the signature (with
the key bound to the existing certificate) as the authentication method.
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 has
to 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. Select the CAs you want to use with the service from the drop-down list, and
click Add.
Committing Changes
2.12.4 Editing the External Enrollment Client Service
An External Enrollment Client Service is needed when an RA requests certification

from a CA or when a CA requests a cross-certificate or a sub-CA certificate from an
external CA. Every Certifier system that has at least one RA has to have an External
Enrollment Client Service running on a Certifier Server instance.
Basic Settings
The only settings that are needed with an External Enrollment Client Service are the
Service description and the Status of the service (Active or Disabled).

Committing Changes
2.12.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

use.
LDAP Settings
The LDAP Server Address and Port number specify the address of the directory
server where the user credentials are stored.
LDAP Version is the LDAP protocol version used by the LDAP server.
If the LDAP query is done via a firewall with a Socks server, this server address can
be given in the Socks URL field (socks://..).
Name Formats
The Name Formats setting is used to define mappings between the username (sub-
ject name) given by the enrolling user and the actual record in the LDAP server and in
the entity stored in Insta Certifier. The LDAP username format field defines the
mapping to the username on the LDAP server and the Entity name format field to
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.9.1 (LDAP
Publishing Method).
The supported special fields are the following:
%{subject-name}
This is replaced with the login name.

%{operator-name}
This is replaced with the value stripped from the login name by ignoring the domain
part. If no @-mark is found the subject name and the operator name are the same.
To use LDAP authentication with web enrollment, SCEP or operator login authentica-
tion, the Entity Mapping in the service settings should be set to the correct LDAP
Authentication Service.
For example, if LDAP directory path to user data is:
dc=fi,dc=myorg,dc=ss,dc=certifier,ou=People
LDAP username format could be defined as:
dc=fi,dc=myorg,dc=ss,dc=certifier,ou=People,%{subject-name}
Subject name then comes from web enrollment Common Name field. If common
name is defined as “cn=myname”, LDAP authentication request would then be:
dc=fi,dc=myorg,dc=ss,dc=certifier,ou=People,cn=myname
To map this to entity, add new entity with Entity name as cn=myname. Update CA
policy chain to issue requests automatically when request is from valid entity.

When LDAP authentication service is used in operator login authentication,

%{subject-name} definition means login username. For example, if LDAP
username format is defined as:
dc=fi,dc=myorg,dc=ss,dc=certifier,ou=People,cn=%{subject-name}
LDAP authentication message path to LDAP server is then (e.g when username input
is “admin”):
dc=fi,dc=myorg,dc=ss,dc=certifier,ou=People,cn=admin
If LDAP username format is defined and LDAP authentication is used:

dc=fi,dc=myorg,dc=ss,dc=certifier,ou=People,%{subject-name}
Operator must input username as cn=admin.
In case of Active Directory, userPrincipalName (UPN) and Display Name can be

used as a login name. LDAP user name format should be defined as simple as:
%{subject-name}
To allow users to login with UPN and the Display Name, check the property Ignore
the domain part and create the operators using the name part of the UPN.
Security Settings
The LDAP Authentication Service is can be protected by TLS. The relevant settings
are made under TLS Settings. Select Use TLS server authenticated LDAP
connection to take TLS in use. To search a trusted TLS CA certificate from the data-
base, click Search. To insert an external certificate to the database, click Insert
Certificate. See Section 2.13.4 (Importing a Certification Request).
To ease TLS settings, following options are available:
Opportunistic TLS: plain connection to LDAP server is used if TLS connection can-
not be established. Recommended, that this option is set to false (disabled).
LDAP server certificate name match: checks that the LDAP server ‘hostname’
matches either LDAP server certificate’s DNS subject altname or common name rnd
in the subject name or IPaddr subject altname.
LDAP server certificate validation: validate LDAP server certificate root.
References
Table of administration services that bind to this LDAP authentication service. Table
shows service’s internal ID, description and server that the service is running. You can
remove LDAP authentication service even when it’s bind to administration service.
Committing Changes

2.12.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 where
signatures of individual transactions need to be validated with up-to-date revocation
information.
The OCSP Responder Service of Insta Certifier can be used to answer clients’ status
requests concerning one or more of the Certifier CAs. Currently the OCSP responder
can provide status information only for those certificates that are issued by CAs that
are managed within the Certifier installation.
Figure 2-38 Editing the OCSP Responder Service configuration
Basic Settings
use.
Service bind address is an HTTP URL, since OCSP uses HTTP as a transport
mechanism.

Allowed Operations
If the check box under Allowed operations is selected, an OCSP client can request
status information without signing the request.
Certificate Settings
The OCSP responder needs to have a private key and a certificate, so that end enti-
ties can validate the signed OCSP responses. Once the OCSP Responder Service is
created, the private key is generated and the responder certificate enrolled. Select the
CA from which the OCSP responder certificate is enrolled using the Responder CA
field.
The validity period included in the certification request can be selected using the
Validity period length field.
The length of the OCSP responder private key (measured in number of bits used) can
be chosen with the Key size option.
External URL
External URL address is the URL that will be included in the authority information
extension field of the issued end-entity certificates, if the extension is included in the
CA policy. End entities will use this field to connect to the OCSP responder. This defi-
nition can be left empty, in which case the Service bind address field is used as a
default value. However, please note that this address must be accessible from all 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.
Committing Changes
2.12.7 Editing the Publishing Service
If LDAP or external commands are used to publish certificates, CRLs or other entity
data in the directory, then at least one Publishing Service needs to be added in the
system. Publishing Service is not required when HTTP is used to publish CRLs.
Publishing Service represents a connection to a specific LDAP directory. Publishing
Service is also used for running external publishing commands. There may be more
than one Publishing Service in a single Certifier Server instance, if several CAs pub-
lish to different directories, or if single CAs publish to several directories.

Figure 2-39 Editing the Publishing Service configuration
Basic Settings
use.

LDAP Settings
The LDAP Server Address and Port number specify the address of the directory
server (for example, directory.certificate.fi and 389, the default LDAP
port).
LDAP Username and LDAP Password are normally also required for directory 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, there
might 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 be
specified in the Retry and times with fields.
If the publishing is done via a firewall with a Socks server, this server address can be
given in the Socks URL field (socks://..).
External Client
If External Client is selected, Insta Certifier will generate an LDIF file of the publish-
ing data and send it to an external command for further processing. The command
line can be given in the text box.
Security Settings
LDAP publishing can be protected by TLS. The relevant settings are made under TLS
Settings. Select Use TLS server authenticated LDAP connection to take TLS in
use. To search a trusted TLS CA certificate from the database, click Search. To insert
an external certificate to the database, click Insert Certificate. See Section 2.13.4
(Importing a Certification Request).
It is also possible to Use TLS client authentication. Client authentication eliminates

the need for an LDAP password. Select the client authentication CA from the list.
To ease TLS settings, following options are available:
Opportunistic TLS: plain connection to LDAP server is used if TLS connection can-
not be established. Recommended, that this option is set to false (disabled).
LDAP server certificate name match: checks that the LDAP server ‘hostname’
matches either LDAP server certificate’s DNS subject altname or common name rnd
in the subject name or IPaddr subject altname.
LDAP server certificate validation: validate LDAP server certificate root.

References
The References field shows the number of CAs that use this Publishing Service for
publishing CRLs. The field is intended to warn the operator that removing the Publish-
ing Service disables CRL publishing and may thus compromise the security of the
PKI. If the Publishing Service is used only for publishing certificates (and not CRLs),
the field will show: This service isn’t referenced by any CA. Certificate publishing
(unlike CRL publishing) is not a critical feature for a properly functioning CA, and there
may be a valid reason to remove a Publishing Service used only for certificate pub-
lishing, hence no warning is given.
Committing Changes
2.12.8 Editing the SCEP Service
Several VPN gateways and VPN clients support the Simple Certificate Enrollment
Protocol (SCEP) for enrolling certificates from the CA. It is a simple online protocol,
which provides means of getting a certificate to a VPN box such as router. SCEP Ser-
vice can be used to provide this service in Insta Certifier.
Figure 2-40 Editing the SCEP Service configuration

Basic Settings
use.
Service bind address is an HTTP URL, since SCEP uses HTTP as a transport
mechanism. Optionally, also Service domain name can be given (a fully qualified
domain name). If the field is left empty, the name is generated from the Service bind
address.
Service domain name and Service description are shown on the web enrollment 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. Select the CAs you want to use with the service from the drop-down list, and
click Add.
Entity Mapping is used to select the method used by the SCEP Service to map an
entity to a request. If an LDAP Authentication Service has been defined, it can be se-
lected. Otherwise only Pre-Shared Key can be selected.
Committing Changes
2.12.9 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 include
pages (designed for both MS Internet Explorer and Netscape Navigator) that can be
used to generate private keys and post certification requests to the Web Enrollment
Service. A PKCS #10 enrollment page is also offered to enable submitting certification
requests 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-41 Editing the Web Enrollment Service configuration

Basic Settings
use.
The Service bind address is the address where the Web Enrollment Service listens
to incoming HTTP and HTTPS connections. Remember to include the port number in
the address. For example, http://0.0.0.0:8080/ is an address for a service running on
the local host listening to port 8080. Remember that the Service bind address has to
begin with http instead of https even if TLS is being used.
CRL Distribution
Web Enrollment Service can be used to publish CRLs for end entities that use HTTP
as an operational protocol to fetch CRLs. To enable this function, select Distribute
CRLs for all accessible CAs. If a CA has a publishing method, which uses the Web
Enrollment Service for HTTP publishing, and sets CRL distribution point in the issued
certificate, the prefix of the CRL distribution URL can be given in the URL prefix for
CRL distribution points field. This should be an URL containing scheme, host and
port parts, ending in a slash. Note that the given URL must be accessible from all cli-
ents. For example http://enroll.big-corp.com:8080/ is a valid URL prefix. If the URL
prefix is left empty, the service address is used instead.
Security Settings
The Security Settings define whether HTTP server is protected with TLS or not. If
Unprotected HTTP connection is selected, all the connections between the brows-
er and the server are plain text. By selecting TLS Protected HTTP connection, the
server has a certificate, which it uses for authentication. All connections are encrypted
when using this option. However, the client has to use login name and password to
authenticate itself to the server. When selecting TLS with client authentication,
also the client has to have a certificate in order to connect to the server. Client authen-
tication has to be selected, if account management is going to be used. However, if
this is the case, there should be another Web Enrollment Service running without TLS
client authentication. New users, who do not yet have a TLS client certificate, could
use that service to enrol the first certificate.
The CA that is used for issuing TLS server certificates has to be selected in the TLS
server CA field. Insta Certifier Internal CA, which is created during the installation,
can be used, but it is recommended to have a dedicated CA for this purpose. The
same CA that is used for a protected Administration Service can be used. See Section
2.12.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 period
length and Key size can be selected in the TLS Server Certificate Settings. The
validity period will be included in the certification request. You can later re-issue the
TLS server certificate with new parameters, for example, if you want to edit the 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. Select the CAs from the drop-down list,
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 Web
Enrollment Service. We might not want to have all CAs visible to every end user. Also
it might be the case that CAs form certain groups that are dedicated to certain organi-
zations. All organizations could have an own dedicated Web Enrollment Service,
which would show only their own CAs. Select the CAs you want to use with the ser-
vice from the drop-down list, and click Add.
User Interface Options
The options available on the web enrollment pages can be selected under User
Interface Options. Selecting Generic shows most options on the enrollment pages.
Selecting Restricted user interface shows only a limited number of options. The
web enrollment pages can be further customized by clicking the Customize User
Interface button. See Section 2.12.10 (Customizing the Web Enrollment Pages) for
details. If the pages have been customized, the User Interface Options will display
Custom UI.
Entity Mapping
Entity Mapping is used to select the method used by the Web Enrollment Service to
map an entity to a request. If an LDAP Authentication Service has been defined, it can
be selected. Otherwise None or Pre-Shared Key can be selected.
Committing Changes
2.12.10 Customizing the Web Enrollment Pages
When browser-based enrollment services are provided, the enrollment pages should
be customized to reflect the image the CA wants to impose. For example, only those
request fields that are relevant to the particular application should be shown to the 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 pages
with the appearance of the site where the enrollment services are provided. While the
administration GUI is seen only by a couple of operators, the enrollment pages may
be visible to tens of thousands of end users. In this case, the actual HTML templates

with the enroll prefix can be customized. The templates are HTML descriptions with a
Scheme-based script which is used for customizing the pages on the fly.
The basic customization options are described below. For information on customizing
the HTML templates, contact Insta Certifier technical support
(http://www.certificate.fi/).
Figure 2-42 Customizing the Web Enrollment Service
Account Management
If account management is enabled, entities can log in the Web Enrollment Service
with their accounts. After having logged in, they can view their certificates, revoke and
renew them. Account Management can be disabled, allowed with TLS client au-

thentication, or allowed with TLS or password authentication. If account management

is enabled, the security level of the Web Enrollment Service has to be set to match.
Template Set
Template Set is the set of HTML templates used by the service. Unless new 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).
Anonymous login
This property controls the possibility to do the enrollment anonymously. If

Anonymous login is disabled, the Web Enrollment Interface cannot be used
without authentication. If the anonymous login is disabled and Account management
is not enabled, the service is unusable.
To enable anonymous web enrolment login:
1. Administration UI: Go to Servers  administration server  Web En-
rollment service  Connection mode set to TLS Protected HTTP
connection
2. Administration UI: Web enrolment configuration: Go to Customize Us-
er Interface  Account management set to Allow with TLS or
password authentication and Anonymous login to Disable anony-
mous login.
3. Commit changes
4. Create an entity for the Web enrolment user: Add New Entity: set En-
tity name and add attributes Account Password and Email. These
attributes are used when web enrolment user does a login.
5. Change web enrolment redirection value to enrolment page: edit
/usr/local/certifier/conf/server.conf file and set under
enroll-web configuration a line (session-entry (default
“enroll.html”)). Restart Certifier. Example of server.conf after
edit:
(enroll-web
(configuration
(operator-name "admin")
(session-entry (default "enroll.html"))
(syslog-facility "local1")
(template-set-path "./enroll-templates")
(path-mime-types "./lib/mime.types")
(dos (host-rate-limit 30))
(session-idle-ttl (initial 300) ;; 5 minutes
(normal 10800)) ;; 3 hours
(tls-session-cache "#t")
;; Preferred TLS cipher suites
(tls-cipher-suites "AES256-SHA:AES128-SHA:DES-CBC3-SHA:RC4-SHA:")
(mime-paths
(image "./enroll-html")
(application "./enroll-html")
(multipart "./enroll-html")

(text "./enroll-html"))
(scheme
(library-path "./lib"))))
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 and
sends 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 be
specifically 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 by
this. Activating revocation with PSK requires that the Web Enrollment Service uses
TLS protection.
Enrollment Methods
PKCS#10 enrollment and browser enrollment are available through the Web Enroll-
ment Service. By selecting Hide PKCS-10 enrollment or Hide Netscape/IE
enrollment under Enrollment Methods, links for PKCS#10 enrollment or browser
enrollment, respectively, can be hidden. However, the enrollment pages are not disa-
bled, and they can still be accessed by typing the page URL in the location bar of the
browser.
Character Set
The Character Set used by the browser can be autodetected, asked from the user,
or forced (UTF-8, ISO-8859-1, or ISO-8859-15).
Advanced Request Editing
Advanced Request Editing can be allowed or disabled. It is also possible to allow

only advanced request editing.

Internet Explorer Options
Additional key options that are available on Microsoft Internet Explorer can be set un-
der MSIE Key Generation.
If a check box is selected, the corresponding option is shown on the MS IE enrollment
pages. If the check box is cleared, the option is not shown to the user.
For example, if the Allow key size selection option is cleared, and the Default key
size is set to 1024, the user cannot select the key size when submitting the request
but the browser will generate only 1024-bit keys.
The following options can be selected/cleared:
Allow CSP selection
Allows the user to select the CSP used for key generation. The Default CSP can
be entered in the text box.
Select key protection
Allows the user to change the Private key protection setting.
Set key protection by default
Sets Private key protection on.
Allow key size selection
Allows the user to select the key size. Default key size can be entered in the text
box.
Allow key store selection
Allows the user to select the key store.
Allow key type (KeySpec) selection
Allows the user to select the KeySpec. The Default KeySpec can be selected from
the list.
See Section 3.3.2 (Browser-Based Enrollment) for more information on these settings.
Request Elements
The Request Elements that are available on the enrollment pages can also be 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-43 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 box
prevents editing the requested key usages.

Click Continue to accept the settings and return to the Edit Configuration for Web
Enrollment Service page. To take the settings in use, click Continue and click
Commit Changes on the Edit Server Entity page.
2.13 System Configuration
Miscellaneous settings are grouped under the System Configuration Menu.

2.13.1 Editing System Parameters

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

For information on how to handle change sets when multi approval is in use, see Sec-
tion 2.13.2 (Viewing and Approving Pending Change Sets).
If operator has change sets waiting for approval, first page after login will be change
set list and Pending Change Sets links is shown on the sidebar. When change set is
opened (as in Open change set is clicked), links changes to Current Change Set.
This indicates that possible changes that the operator makes are stored to opened
change set. Otherwise changes create a new change set.
2.13.2 Viewing and Approving Pending Change Sets
All changes that have been selected to require multi approval create change sets. A
change set contains one or more add, modify, or delete operations. The change sets
can be viewed on the Change Set List page.
To access this page, click System Configuration on the menu and click the
Pending Change Set List option.
Change Set Types
There are two types of changes sets; one for system changes and one for CA-
changes. The first one requires Require for services to be checked.
If current change set contains changes for system configuration, CA changes cannot
be attached to it. Instead an error message is shown. To fix the error the current
change set should be closed.
Following rules apply
 Change sets can contain changes only for ona CA.
 CA and system changes cannot be mixed.
 Only operators having super user rights to ALL CAs can operate system
configuration changes.
 Operators having super user rights to one CA can operate only change sets
specific to that CA.
Viewing a Change Set
Click View next to the change set you want to review. This opens the Change Set
page.

Figure 2-45 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 Description to save the description. Editing the description later will clear cur-
rent approvals.
The added, changed, or deleted object can be reviewed by clicking the number next
to the listed change. The object is shown with a grayed ”page header” and ”footer”
with additional info on the change set in the header.
Figure 2-46 The Change Set page
Approving a Change Set
To approve the change set, click the Approve button.
Committing the Change Set
After the required number of operators have approved the change set, it can be com-
mitted. Click Commit to make the change set active. After committing, the changes
take effect and the change set is removed from the pending change sets list.

Removing the Change Set
The change set can be removed by clicking the Remove button on the Change Set
page. Doing this immediately loses the change set and all changes contained in it.
2.13.3 Cross-Certification
When two independent CA hierarchies need to be connected or a sub-CA needs to be

created, cross certification is involved. In the case of independent PKI domains, two
CAs may both issue CA certificates for each other. In the case of sub-CA creation, 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-47 Searching for certificate requests
Type in some search criteria and click the Search button to see the list of certificate
requests generated with Insta Certifier. Choose the correct certification request from
the drop-down menu and click the Commit button.
A cross-certificate request can be generated by clicking the Re-issue button on the

CA certificate page. This operation will create a in the database a request that can be
used in cross-certification.
If CMP is used for cross-certification, External Enrollment Client Service needs to be
selected in the Enroll Client Service list and the enrollment URL given in the 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-48 Sending the cross-certificate request
If you want to use manual cross-certification, click the View PKCS10 Request button
to view the certificate request. When performing manual cross-certification, the re-
quest needs to be copied and pasted to a file and then sent to the CA.
2.13.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-49 Inserting a certification request
2.13.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 to
the issued cross certificate.
The issued cross-certificate needs to be copied and pasted in base-64-encoded
(PEM) format in the large text input field. Click the View Certificate button to see the
contents of the issued cross-certificate.
Imported certificates are set as expired according to not-after, same as certificates
with CA within the system.

Figure 2-50 The certificate can be pasted in the text input field
2.13.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 or
PKCS#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 affects
one certificate. Any other certificates with same private key data are unaffected. Key
must be imported to them separately (or their keys removed) if old key data needs to
be removed from database.
One possible use for this feature is moving existing software key to hardware token.
This is done by first exporting the key in PKCS#8 file through View Private Key and
then importing it to the hardware token. The key can then used in Certifier by import-
ing it back.

Import Private Key option automatically recognizes if a matching PKCS#11 private

key is present. Please configure and insert the right token before starting the import
operation. If no PKCS#11 key is detected, the user is given an option to import a soft-
ware key instead.
Software key import needs a base-64-encoded (PEM-encoded) private key file which
is copied to Software private key input box. Private Key Format field can usually
be left to default autodetect option, but in case Certifier has problems in decoding the
private key selecting the precise format might help. Passphrase is needed when de-
coding encrypted private key files like PKCS#8 or PKCS#12 and is not used other-
wise.
2.13.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 the
regular request editing page. The buttons at the bottom of the page are different, as
only the Proceed and Cancel buttons are available.
This option can be used to create CA certificates, for example. See Section 2.7.1
(Creating a New Certification Authority).
Most fields on this page correspond to those on the Certification Request page.
See 2.4 (Processing Requests). Fill in data as necessary.

Figure 2-51 The Make New Certificate page - CA certificate
Validity period defaults to the current time. At least Not after should be changed to
a later value.
Key generation parameters can be adjusted by clicking Set Key Generation

Parameters. This opens the Key Generation / Import page. On this page, Key
Provider Type, Key type, and Key size can be selected. If a hardware security
module (HSM) is used, additional settings are available. See Section 4.3 (CA Private
Key Options). Clicking Continue will return to the Make New Certificate page.

After this, the selected key type and length are shown in the Public key field on the
Make New Certificate page.
The Signature algorithm field contains SHA-1, SHA-224, SHA-256, SHA-384 and
SHA-512 algorithms. Definition sets the signature algorithm the CA uses to sign the
certificate. The default value is SHA-1 when using RSA key type. For EC key type, the
signature algorithm is automatically selected based on issuer key size. Selection is
based on NIST recommendations (2011).
The CRL distribution point extension is usually added to the certificate in the policy
processing stage by the issuing CA. However, certificate creation through the Create
Certificate option bypasses all CA policies. Thus, the CRL distribution point
needs to be explicitly added when creating the certificate. Selecting From Issuing
CA Configuration adds the CRL distribution extension to the certificate. Selecting
Static URI allows a URI to be entered in the text box.
Clicking the Proceed button will start the key and certificate creation.
Creating a CA Certificate
When the page is accessed from CA creation, some of the certificate attributes are
pre-filled with usable default values. Also, two extensions are selected by default.
Basic Constraints must be set on all CA certificates with the CA flag set. The path
length can be used to control whether this CA can issue other CA certificates. Path
length is the maximum number of CA certificates that can be located under this certifi-
cate in path validation. Setting this value to zero means that this CA can issue only
end-user certificates.
Key usage is also defined with a few default bits. CRL Sign and Key Cert Sign must
be defined in the CA certificate because it must be able to sign the certificates and
CRLs it issues.
If the Make New Certificate page was accessed from CA creation, clicking
Proceed will return the operator to the CA creation page. Note, however, that key
generation may take some time depending on key size.
2.13.8 Configuring Certificate Transparency
Certificate Transparency page has related settings:

 Broker URL – defines the address where the core components will send SCT
requests. E.g. https://192.164.10.11:443.
Multiple Log Servers can be added. Each Log Server has the following configuration
parameters:
 Id – internal ID, cannot be changed by the Administrator.
 Name – freely configurable name that is used in the Certificate Transparency
policy module to reference the Log Server.
 Timeout seconds – how long SCT reply is waited for.
 URL – address of the Log Server.
 Public key PEM – Log Server public key in PEM format. The key is used to veri-
fy SCT signature.

2.13.9 Managing CRLs
In the CRL management page CRLs can be downloaded as CSV file or deleted. Su-
per-user access rights are required for both operations.
CRLs are selected by search options. Select CA specifies the issuer for the CRLs,
Issued after and Issued before are used to specify the time period when the CRLs
were issued. The Issued after field is inclusive while the Issued before is exclusive.
The time period is compared only the the issuance time and not the CRL validity
times.
The search never matches the latest CRL for any distribution point, i.e. the CRL that
can be viewed via distribution point’s View CRL link is not in the exported CSV and
cannot be deleted.
By pressing Download CSV the CRLs matching the search criteria will be sent to the
browser as a CSV file.
By pressing Delete from database the CRLs matching the search criteria will be
permanently deleted from the database. Confirm delete must be checked in order to
perform the deletion.
2.13.10 Managing Trust Anchors
In the Trust Anchor (TA) management page Trust Anchor certificates can be viewed,
deleted and uploaded. Super-user access rights are required for these operations.
These TA certificates are trusted roots in case a CMP client authenticates itself with a
certificate from external CA in CMP init message. This behaviour is specified in RFC
4210 E.7. In-Band Initialization Using External Identity Certificate.
The list of Trust Anchors show the TA certificate subject and issuer fields, status, seri-
al number and validity times. By clicking the subject name link a Trust Anchor page
opens that allows you to change TA related settings.
Editing TA Settings
The TA configuration has an option Require CRL. When set, a CRL check is required
when using the TA certificate for validation. If the CRL is required but not available,
certificate validation against the Trust Anchor will fail.
To add a CRL, it must be copied as a binary or PEM file into the directory
var/pki/trust_anchor_crls under the Certifier installation directory. Certifier
polls this directory and reads the CRL files from it. All successfully read files will be
moved to var/pki/trust_anchor_crls/ok directory, and if the reading or CRL
adding fails for some reason, the CRL file is moved to
var/pki/trust_anchor_crls/failed.
Successfully added CRLs are stored into the Certifier database, thus the 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 expiration
time. Only the latest CRL added to the database will be used. CRLs that are issued
earlier than the current CRL in the database are imported from the file system.

CRL can be removed by clicking the Remove CRL button. Note however, that if a
certificate has been checked against the CRL and marked as revoked, removing the
CRL does not change the revoked status of the certificate.
Partial or delta CRLs are not supported and only one CRL per Trust Anchor is used at
a time. The CRL is used as long as it is not removed or replaced with a new. When
adding a CRL, the issuing date is checked and only a newer CRL will replace the old
one.
Path validation
If there exists a sub CA hierarchy between the Trust Anchor certificate and the end
entity certificate used in signing the CMP initialization message, then the sub CA 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, they
are 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 allows
signature validation of CMP poll messages even if the certificate is not included in the
poll message.
2.13.11 Changing the Master Password
All Certifier software private keys are stored in encrypted format in the internal data-
base. Every Certifier installation has a master password, which is used to protect
these objects. If the master password is lost, the whole PKI system may become in-
operational, since the CA and RA software private keys (as well as other encrypted in-
formation) cannot be accessed any more. Therefore it is critical to be extremely care-
ful when changing this password.
After a new Insta Certifier installation, the password has a default value. It is highly
recommended that after the installation the master password is changed on the
Change Master Password page.

Figure 2-52 The Change Master Password page
When the password is given for the first time, the current password field can be left
empty (default value is used when it is empty). The new password needs to be given
in the New master password field and confirmed again in the New master
password again field. Check or uncheck the option Store new password. When
checked the new password will be stored into the database in encrypted form. This
way Certifier can start automatically without asking the password from the user at
start-up. Click the Set master password button to take the new password in use.
To change back to the default master password, enter the Current master
password and click the Clear master password button.
Entered master password must apply with configured master password policy. Master
password policy is defined in system parameters.
After the master password has been taken in use, it has to be given to Insta Certifier
every time the Engine is restarted - otherwise signature operations will not be 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 master
password field is prompted and the operator can type in the master password.
2.13.12 CA Passphrase
Clicking the Show CA Passphrase Status lists all CAs with keys stored in hardware
tokens that need PIN codes. These CAs aren’t available until their passphrase have
been given through this page. To activate all keys, use Login. In cluster environment,
activation must be done separately on each cluster node. Activation of one node in
the cluster does not activate other cluster nodes.

Some hardware providers require login before showing any objects (e.g. public keys).
In these cases, select the token from Provider name list, enter the PIN to Slot PIN
and click Login. If login was successful, notification appears (“Login successful to
provider x, slot y”), otherwise error is notified. After successful login, all keys in select-
ed slot are activated. Some module providers require login before any keys are visible
(e.g. Use existing PKCS#11 key option in key generation can’t find any keys). For
example login is required when using SafeNet module, but not with Thales nShield.
2.13.13 User-Defined Policy Modules
Custom policy modules can be created under User Defined Policy Modules. The
custom modules are essentially macros that consist of other policy modules.
To create a new custom policy module, click Add. Give a suitable name for the 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 can
add policy modules to the custom module as if you were editing a normal policy chain.
The policy chains in which the custom modules are allowed are the following.
receive-request
The Receive Request chain.
accept-request
The Accept Request chain.
view-request
The View Request chain.
update-request
The Update Request chain.
psk
PSK-specific policy chains. See Section 2.5.4 (Adding Policy Module Attributes).
entity
Entity-specific policy chains. See Section 2.5.4 (Adding Policy Module Attributes).
conditional test
Test clauses (IF, ELSE IF) of the Conditional policy module. See document Policy
chain and modules.
2.13.14 Viewing System Configuration
Clicking Show System Configuration shows a plain-text summary of the Insta Cer-
tifier system configuration.

2.13.15 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.
On the same page is Generate CRLs without shutdown. By clicking the button, all
CAs with CRL publishing configured, will generate and publish new CRL. CRLs are
published with extended validity period if Estimated restart time is set.
2.14 Revocation Interface
The Revocation Interface template set is a limited UI for operators to search certifi-
cates and revoke, suspend and re-activate them. The interface is similar to the Admin-
istration Interface, but only has the search and revocation related features.
2.15 Statistics
Statistics page is a summary of certificates, requests and services that the system
has. Statistics depends on operator access rights; only CAs that the operator has ac-
cess to (at least read access) are included in statistics. Similarly only services that the
operator has access to are shown. Super user operators have view on all CAs and
services (shown as [all]).
Summary of operators and entities are only shown to super users.
OCSP statistics are only shown when OCSP service is in use and operator has ac-
cess to CA that the OCSP is providing status information.

Figure 2-53 Certificates and requests

Figure 2-54 Server, service, operator and entity summary
Figure 2-55 OCSP statistics

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 running
on Certifier Server instance(s). These services perform the message-transport-related
server-side functionality of certificate enrolment or certificate life-cycle management.
There is a dedicated Certifier Service for each protocol:
 SCEP Service for enrollment services for VPN applications such as routers and
software clients.
 CMP Service acting as a certificate life-cycle management server.
 Web Enrollment Service for a web-based enrollment interface.
Each of these services does a protocol level verification to the request before the re-
quest is passed on to be handled by CA policies. The requests are checked to be
formally and cryptographically correct, and in case of CMP, the CMP protection is
verified either by using a pre-shared key or a certificate. If the request passes 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. The
CMP 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 and
RFC4211 also known as CMPv2. The CMP messages currently supported in the CMP
Service are:
 Initial request
 Certification requests signed by an initialized end entity
 Key update request
 Revocation request (according to error message: hold or revoke). Notice that re-
voking already revoked/expired certificate does nothing (client sees this as ok,
but nothing is done). Holding revoked/expired certificate is an error.
 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 valid
private 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 the
URL is http://host:8080/pkix/. These parameters can be modified by editing the CMP
Service via the Certifier Administration Service. See Section 2.12.3 (Editing the CMP
Service).
The communication between RAs and CAs of Insta Certifier uses CMP. Also Insta
Token Master, whether used as an RA or end entity, uses CMP for requesting certifi-
cates from the CA or RA.
Insta Certifier ships with a simple command-line utility that supports the client side of
the corresponding server-side functionality of the CMP Service. It can be used to gen-
erate private keys and performing enrollment, key updates and revocation requests.
For more information, see document Command Line Interface.
If engine is too busy serving server, server will response to CMP client with 503 ser-
vice unavailable. On other engine connection errors, server will response to CMP cli-
ent with 500 internal server error. Server logs engine connection errors.
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.12.8
(Editing the SCEP Service). The default enrolment URL for SCEP client is thus
http://host:8080/scep/. These parameters have to be configured in the enrollment 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 appropriate
CA certificate, which must have been verified using some offline method (fingerprint
check). The verifications should be done to prevent man-in-the-middle attacks, in
which someone is impersonating the CA. The CA certificate can be retrieved from the
SCEP Service by an HTTP GET operation. In addition to the enrollment URL the end
entity needs to know the name of the CA that identifies it within the Insta Certifier in-
stallation. This is needed since there may be several CAs providing SCEP within a
single Certifier installation. The name that is used to identify CAs in SCEP 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 not
used for this).
The initial end-entity authentication in SCEP is achieved either manually or by using
shared secrets. When using a pre-shared secret scheme, the Insta Certifier 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, the
shared secret is then used as a challenge password inside the request. The SCEP
Service forwards the encrypted certification request to the Certifier Engine, which
finds the policy bound to the preshared key and processes the request according to
the policy.

When using manual authentication, the end entity calculates the MD5 fingerprint on
the generated PKCS #10 certification request. When the Certifier Engine receives the
request from the SCEP Service, it stores the request in the Database as a pending
certification request. Later the end entity has to manually authenticate itself to the In-
sta Certifier operator with this fingerprint. The operator then compares it to the one
found in the Database. If they match, the operator manually approves the certification
request. The client can poll the issued certificate from the SCEP Service after this.
As the PKCS#7 request payload containing the PKCS#10 request is encrypted using
the CA/RA’s public key, no one else but the end entity and the CA/RA can know the
fingerprint, and thus we know that the request is legitimate. (The end entity as we now
know, has access to the private key, whose public components are inside the
PKCS#10).
When the SCEP is performed between an end entity and an RA, the end entity needs
also the RA certificate in addition to the CA certificate. So when the RA certificate is
fetched by the end entity, also the CA certificate is sent in a PKCS#7 envelope to the
end entity by the SCEP Service. This RA certificate can be used for both encryption
and authentication in the enrollment.
3.3 Web Enrollment Service
In Insta Certifier, web-based enrollment services for Internet browsers are provided by
the Web Enrollment Service. The default HTML template files that are shipped with
Insta Certifier provide web forms for posting certificate requests, scripts that enable
browsers to perform the key generation, and a web page that can be used to down-
load CA certificates and CRLs. TLS is also supported to provide additional confidenti-
ality and optionally client authentication in the web enrollment. The following sections
explain the different ways to do the certificate enrollment with a browser and the relat-
ed services.
3.3.1 PKCS#10 Enrollment
Web-form-based PKCS#10 enrollment is the simplest enrollment option supported by

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

submitting.

Figure 3-1 PKCS#10 enrollment form
Several client applications generate a text file containing the PKCS#10 request after
the key generation. The PKCS#10 request looks something like the following exam-
ple:
-----BEGIN CERTIFICATE REQUEST-----

MIIBwjCCASsCAQAwYjEQMA4GA1UEBhMHRmlubGFuZDEoMCYGA1UEChMfU1NIIENvbW11bmljYXR
pb25zIFNlY3VyaXR5IEx0ZDENMAsGA1UECxMEVGVjaDEVMBMGA1UEAxMMMTkyLjE2OC4yLjQ2MI
GdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKBgQC3RCZScukV5VacEv7t2dlbCNaFUI8c+WkqQZOBH
l88eYPSjImxK4sF/6siNT5596X/LTSbImlLta56K3FbsYDmOuR6OFT6TVgi909z2jIcgn0c3JjR
enn87thTu9ZXYJApt6+/ENSC0PtXcwwXvbNEn79D29o90Szgk8w+/dRZxQIBJaAiMCAGCSqGSIb
3DQEJDjETMBEwDwYDVR0RBAgwBocEwKgCLjANBgkqhkiG9w0BAQQFAAOBgQBsjd4qSie3Iycqff
OI7uMHziZgHX0MMugVzJArlgtmM/Z7E8jeoB2v8ghLLEqFMvLLx+1vDkGgaJM52OZkC6VBT1YJg
XRVOpeJEI8B21yATN/yI/2H6tEzodODQ1IZuFtkNvgI2I9JWKNAXUkpxAoi2ot4tPqzMOrPe4qu
A1m7Nw==
-----END CERTIFICATE REQUEST-----
When this string is pasted to the enrollment form and submitted, a request will be pro-
cessed in Engine. If Engine cannot automatically issue the certificate, a polling ID is
given to the end entity. This id can later be used for polling the issued certificate. The
default polling page in the Web Enrollment Service is enroll-poll.html.

3.3.2 Browser-Based Enrollment
Insta Certifier allows client-side enrollment to be performed using the most popular
web browsers, Microsoft Internet Explorer, Firefox and Opera.
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 key
inside 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 forwards
it to Certifier Engine. If the certificate approval is configured to be automatic, theWeb
Enrollment Service pushes the issued certificate to the browser to be installed. If the
request has to be manually approved, it can be downloaded later, using the request
identifier issued by the Certifier Engine, and displayed to the end entity instead of the
certificate.
When using Internet Explorer, a Microsoft ActiveX control (xenroll.dll) can be
used to perform the client-side enrollment, including the key generation. The control
provides a scriptable interface for this. The most relevant functions of the interface are
CreatePKCS10 and acceptPKCS7. The CreatePKCS10 function creates a private
key in the Windows registry and a base-64-encoded PKCS #10 request, which can
then be posted to the Enrollment Service. When the Engine has issued the certificate,
it can be installed to be used by Windows client applications such as IE and Outlook
Express, by using the acceptPKCS7 function.
Enrollment Forms
The default forms for Firefox and MS IE enrollment in Insta Certifier are enroll-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. See
Section 2.12.10 (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 to
be used in an environment where these are required. For special cases, user may re-
quire to enter a Card ID or a Profile ID.
The user may also request a key usage extension for the certificate. The extension
can include the Digital Signature, Key Encipherment, and Data Encipherment
key usages. The Email Protection, IKE Intermediate, Client Authentication,
Server Authentication, Code Signing, OCSP Signing, and Time Stamping 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 box
should 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 can
be given in the enrolment form to enable automatic certificate issuing. This field is not
shown in the web enrollment page without TLS, since pre-shared keys should not be
sent as plain text.
The Key size of the private key should also be selected.
Additional Private Key Options (MS IE only)
With Microsoft Internet Explorer, additional Private Key Options are available. The
user can select the cryptographic provider (CSP) to use for key operations. The 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 will
also be available. Selecting a token-based provider will generate the key pair securely
on the token.
With IE, the user can also select the certificate store type, either current user or
local machine (for Windows IPSec and L2TP). As the names imply, the first store is
used for storing personal certificates (for e-mail and TLS) and the latter for storing
machine-specific certificates.
With IE, the user can also select to use Private key protection. Selecting this check
box will cause Windows to prompt for security level of the key.
 High security will protect the key with a password, which will be asked every time
the key is used. This is a suitable setting if the key is used for non-repudiation
signatures, but may be cumbersome if the key is used for TLS or IPSec authenti-
cation.
 Medium security level (default if private key protection is selected) will ask for
confirmation every time the key is used. This setting is suitable for S/MIME use,
for example, but again may slow the operation unacceptably if the key is used for
TLS or IPSec.
 Low security level (default if private key protection is not selected) will not require
confirmation from the user when the key is used.
Advanced Request Editing
If allowed by the Web Enrollment Service settings, the Advanced Options button is
shown on the browser enrollment page. Clicking this button immediately begins key
generation. After the key has been generated the advanced editing page opens. The
layout of this page is similar to the certification request processing page.

Figure 3-3 Advanced request editing
The following fields can be edited:

 Subject name
 Validity period
 Extensions, see Section 2.4.8 (Certificate Extension Fields)
 Pre-shared key
 Profile ID
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 (Internet
Explorer only) and other parameters can be given in the URL when either the
enroll-ie-start.html, enroll-ns-start.html or simple-enroll.html

page templates are used. Use the ’?’ character in between the template name and the
parameters, and the ’&’ character between the individual parameters.
All options just set the default values in the form. The corresponding selections are
still shown to the user and they can be manually edited.
The supported parameters for enroll-ie-start.html are:

 psk : Sets the pre-shared key in the form.
 ca : Default CA, given as object id (for example ca=12)
 keysize : Default key size
 csp : Default CSP name, or 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
 card-id: certificate Card ID
 profile-id: profile to use when enrolling the certificate
The supported parameters for enroll-ns-start.html are:

 ca : Default CA, given as object id (for example ca=12)
 c : C component in distinguished name (DN)
 o : O component in DN
 ou : OU component in DN
 cn : CN component in DN
 email : E-mail subject alternative name
 dns : DNS subject alternative name
 ip : IP subject alternative name
These are the same options as in enroll-ie-start.html, except that csp,

protect, and keysize are not available. Key size cannot be set in URL because it
is done in the keygen tag in Netscape.
The supported parameters for simple-enroll.html are:

 keysize : Default key size
 csp : Default CSP name, or 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:

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%20Provi
der%20v1.0
https://pki.certificate.fi:8081/enroll-ns-start.html?psk=1234
3.3.3 Downloading CA/RA Certificates and CRLs
Both CA and RA certificates, and the CRLs can be downloaded from the
Certification Authorities page (enroll-ca-list.html) by clicking CA List in
the main menu of the Web Enrollment Services.
All the CAs and RAs, whose statuses are not Private and are included in the
Accessible CAs list in the Web Enrollment Service configuration, can be viewed in
this page. The following buttons can be found under each CA/RA entry:
View Certificate as PEM
The CA/RA certificate can be viewed in base-64-encoded format (also known as
PEM, privacy enhanced mail encoding). Certificate can be installed in the root CA
storage of Windows by opening this file with Internet Explorer and choosing Install
in the certificate viewer dialog of Windows.
View Certificate
The CA/RA certificate details can be viewed with the Insta Certifier’s web-based
Certificate Viewer by clicking this button. The certificate can be downloaded in 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 select
Save).
Download Certificate
With Netscape Navigator, the CA can be installed by using this option. Clicking this
button will start the New Certificate Authority wizard of Netscape Navigator.
Download CRL
The current CRL of the CA can be downloaded in binary format by clicking this 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) format
by clicking this button (some web browsers require user to click right button of the
mouse 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 to
be specifically enabled in the Web Enrollment Service configuration page. See Sec-
tion 2.12.10 (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.5.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.5.3 (Adding and Modifying Pre-Shared
Keys). This key has to be distributed to the user and the user has to enter it in the web
enrollment page. Remember that TLS protection is needed for confidentiality when
shared keys are used in the enrollment. In effect, using TLS client authentication 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 Enrollment
Service.
Registering a New Account
If allowed by the Web Enrollment Service, a user can send registration information
(including an e-mail address) through the Web Enrollment Service. Based on this in-
formation, Insta Certifier creates an entity and a pre-shared key for the user and
sends the pre-shared key to the given e-mail address.
Clicking the Register menu item on the main page opens the Register New User
Account page. On this page the user can give a name, e-mail address, and 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 for
valid entities, the certificate is issued regardless of any PSK use count. If this needs to
be limited, the correct option is to use the Automatically issue with valid PSK pol-
icy module.

Your Account
The Your Account main menu item available when the user has logged in the Web
Enrollment Service using an account. Clicking the menu item displays all pending re-
quests and issued certificates of the user. All of the certificates may not be stored in
the certificate storages of the browser (such as PKCS#10 enrolled VPN certificates).
But also these certificates can be viewed if they are associated to the user entity with
pre-shared keys.
A certificate can be viewed in detail by clicking the View Certificate button. On the
Certificate page, the certificate can be suspended by clicking the Revoke button.
This should be done if the user suspects that someone may have a copy of the private
key. If the certificate that is used for TLS client authentication is suspended, even the
user cannot log in any more.
Note that instead of revocation, the certificate is actually suspended. From the user’s
point of view, this is essentially the same as revocation. However, the backdoor has
been left for the Certifier operator to reactivate the certificate if the user suspended it
mistakenly.
The user can log out from the account by clicking Close Session on the Main Page.
Self-Revocation Using a PSK
If allowed by the Web Enrollment Service settings, users can suspend their 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.12.10 (Customizing the Web Enrollment
Pages).
If revocation is allowed, the Revoke Certificate option is shown on the enrollment

pages. Clicking this option opens the Revoke Certificates With Pre-Shared Key
page where the PSK can be given. When the pre-shared key is entered and the
Show All Certificates button is clicked certificates enrolled with the PSK are dis-
played.
Clicking View Certificate will display the Revoke Your Certificate page where the
contents of the certificate are shown in detail. Clicking Revoke on this page will 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’s
point of view, this is essentially the same as revocation. However, the backdoor has
been left for the Certifier operator to reactivate the certificate if the user suspended it
mistakenly.

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 is
a generic cryptographic interface, originally intended to be a cryptographic token inter-
face standard. Nowadays PKCS#11 interface is also used for offloading cryptographic
operations to hardware.
Insta Certifier is able to use keys available in PKCS#11 modules. PKCS#11 module is
a device and/or a piece of software which provides the PKCS#11 API. Insta Certifier
has been tested with the PKCS#11 implementation of Thales and SafeNet.
Thales HSMs
Thales nShield is supported via PKCS#11 interface in all versions of Certifier.
SafeNet HSMs
Since Certifier version 7.1, SafeNet Luna HSMs are supported via PKCS#11 inter-
face.
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. Thales nShield and SafeNet Luna devices have been tested to work
as recommended.
4.1.2 Preparing an Thales HSM for Use
There are three important Thales-specific terms that you need to understand when
setting up a secure CA private key environment with Thales 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 private
key embodied in the security world. Different HSMs with the same security world
can use each other’s card sets.
Administrator Card Set
The Administrator Cards are not used in normal operation, but only in cases when
the security world is set up or restored, or when Operator Cards are recovered.
Operator Card Set
The Operator Cards are used to protect the created CA/RA private keys. An Oper-
ator Card must be inserted when Insta Certifier is started.
The following steps are required before taking Thales HSMs in use. See Thales User
Guide for more information.
 Make sure the Thales HSM is in correct operational mode. This can be checked
by running the command enquiry provided by Thales (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 Thales. Alternatively, the new-world com-
mand can be used. See the Thales 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 world
of the keys can be restored.
We also recommend that the Administrator Card Set created within the security
world creation consists of at least two cards. The Administrator Cards are not
used in normal operation, but only in cases when the security world is set up or
restored, or when Operator Cards are recovered.
The security world information is stored in a file kmdata/local/world. This file
is not security sensitive, since it is encrypted with the key in the Administrator
Card. The copy of the file is needed when recovering the security world. So,
again we recommend that you back up the world file. It is also a good practice to
do the world restoration once before starting to use the HSM to ensure that the
restoration works.
The Operator Cards are used to protect the created keys. KeySafe can be used to
create Operator Card Sets. Thales HSM can utilize n/m protection, but Insta Certifier
supports only 1/m protection at the moment. (However, Certifier Engine can be started
using the with-nfast utility, which allows preloading of n/m keys, so the dual control
can be achieved that way.)
It is up to the Certification Practice Statement (CPS) of the CA to define whether the
CA keys are recoverable. If so, the Operator Card sets should be made recoverable
as well. It is worth noticing that a single card set may protect multiple keys.
Again, we recommend that the Operator Cards are created so that there are more
than one spare cards available. When an Operator Card is lost, the spare cards can
be used. If the card set is made recoverable, a new card set can be created if enough
cards from the old card set are available.

After the Operator Card Set has been created, the keys can be created either by us-
ing the KeySafe tool of Thales or by using the GUI as specified in Section 4.3 (CA Pri-
vate Key Options).
4.1.3 Adding PKCS #11 Modules to the Certifier Engine
PKCS#11 module can be set with default options during the Certifier setup procedure.
These settings can be modified and PKCS#11 modules added by editing the configu-
ration file of the Insta Certifier engine. The configuration file is named engine.conf and
it can be found under the Insta Certifier installation directory in the conf sub-directory
(for example, /usr/local/certifier/conf/engine.conf).
The PKCS#11 module configuration is in the top level of the ca-engine block. The fol-
lowing example adds Thales nShield PKCS #11 module to the engine installation.
(provider (type "pkcs11")

(library "/opt/nfast/toolkits/pkcs11/libcknfast.so")
(info "read-only(no) threads(no)")))
The information which needs to be changed is the path to the dynamically loaded
PKCS#11 shared object.
The defaults are:
 Thales: /opt/nfast/toolkits/pkcs11/libcknfast.so
 SafeNet: /usr/safenet/lunaclient/lib/libCryptoki2_64.so
Note: When the info parameter is set to "read-only(no)", keys can be created via the
PKCS#11 interface. If the read-only option is missing, or it is set to "read-only(yes),
only existing keys can be used via the PKCS#11 interface. In addition, "threads(no)"
has to be added under info when an Thales module is used on Linux platforms.
Once the PKCS#11 modules are added to Insta Certifier Engine, the Engine needs to
be restarted. To check whether the Engine has detected the installed PKCS#11 keys,
log in to the Administration Service, and click System Configuration. Click Show CA
Passphrase Status. The created PKCS#11 keys should be visible in the appearing
key list.
Note 2: When the info parameter includes “reinitialization(yes)” or there is no such pa-
rameter, PKCS#11 provider reinitialization calls are enabled. If reinitialization needs to
be disabled (e.g. provider doesn’t need reinitialization to see keys generated outside
Certifier while Certifier is running), set “reinitialization(no)”. This parameter is provider
specific.
(info "read-only(no) reinitialization(yes)")
Note 3: External commands can be bind to key generation and reinitialization. Key
generation command is executed after key is successfully generated on the HSM.
Reinitialization command is executed before reinitialization begins. Command is
blocking, which means engine waits for command to finish before doing the actual re-
initialization. Command can be used to synchronize keys in clustered environment:
key generation might push keys to HSM and reinitialization command might pop them
to other cluster node. Each HSM provider differs. Certifier user must have permissions
to execute the command. Definitions are: generate-cmd(<command(s)>) for key gen-
eration and reinitialize-cmd(<command(s)>) for reinitialize. Define absolute path to
command or commands. For example:

(info "read-only(no) generate-cmd(run_sync.sh) reinitialize-cmd(run_sync.sh)")
Reinitialization can be executed via administration GUI from Key Generation / Import
page and from CA Passhrase Status page. Reinitialization is executed from com-
mand line with /usr/local/certifier/lib/reinitialize-providers.sh script. Script does not re-
quire interaction. Reinitialization is done to all found providers that do not have “rei-
nitialization(no)” defined. Notice that some HSM providers do not require reinitializa-
tion after key synchronization.
Note 4: If automatic pin feed is used and HSM hardware requires login before any
keys are visible (e.g. SafeNet), set “alternative-automatic-login (1)”. This is not requr-
ied when using Thales hardware:
(info "read-only(no) alternative-automatic-login(1)")
Once the PKCS#11 modules are added to Insta Certifier Engine, the Engine needs to
be restarted. To check whether the Engine has detected the installed PKCS#11 keys,
log in to the Administration Service, and click System Configuration. Click Show CA
Passphrase Status. The created PKCS#11 keys should be visible in the appearing
key list.
Note: Certifier accesses the PKCS#11 interface with the privileges of Certifier user
created during the Certifier installation and setup (default user name “certfier”). It may
be that the PKCS#11 module requires additional rights to be given to the Certifier us-
er. For example when using Thales, the user must be added to “nfast” user group be-
fore using the Thales PKCS#11 module with Certifier.
HSM alarm is set when (cluster is notified except when stated otherwise):
 Device becomes blocked (too many PIN tries). Certifier needs to be restarted to
unset the alarm.
 Token is removed and keys that the engine is caching are in that token. Alarm is
unset when token is inserted.
 Provider becomes disabled. Alarm is unset when provider is enabled.
 Provider fails. Certifier needs to be restarted to unset the alarm.
 PIN is wrong. Alarm is unset when HSM login succeeds. This event does not no-
tify cluster.
Trap is send when all these events occur. Notice that all these alarms depend on ven-
dor specific PKCS#11 interface to notify engine.
4.2 Checking the Key Backup
It is crucial that the key backup is properly implemented in the PKCS#11 module. The
PKCS#11 vendor should document the key backup procedure and the key backup
should be tested before the CA with a HSM key is made operational. It is recom-
mended to test the key restoration in another host instead of the host where the keys
are created to make the check as authentic as possible.

4.2.1 Key backup with Thales HSMs
When the key or security world is generated, the encrypted version of the data is
stored to the kmdata directory (/opt/nfast/kmdata/) and its subfolders, which
should be included in the backup regime.
If the entire Thales device was rendered unusable or/and the security world was lost,
the prerequisite for the keys to be used is that the security world is restored. The se-
curity 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 the
kmdata/local directory.
It is a good failsafe practice to have a Thales HSM with the same security world in-
stalled on a spare HSM in case the computer and the original HSM are damaged. If
the new HSM contains the same security world, the backed up keys are easier to take
into use.
The security world is stored in the world file, encrypted with the Administrator Card
Set. If you need to restore the security world, you need to have both the Administrator
Card and the world file available.
When you create the key, you can define whether the key can be restored (= Recov-
ery feature in KeySafe). When you set this flag, the keys can be used with a replaced
card set. Without that flag, the keys can be only used with the card set that was used
to create the key.
Having listed all the precautions the change of a CA key is such a drastic operation,
that all the precautions should be used to avoid it.
4.3 CA Private Key Options
When creating a certificate in Make New Certificate page, the key generation pa-
rameters, (which include the used HSM), can be specified by clicking Set Key
Generation Parameters.
To use an existing PKCS#11 key, select Use existing PKCS#11 key for the key
provider, and click refresh. Certifier will then show all the detected PKCS#11 keys.
You should be able to see the keys created with the key management utilities.
If private key is generated outside Certifier while Certifier is running, click Reinitial-
ize. This reinitializes all PKCS#11 providers (except when reinitialization is disabled in
configuration) and loads the keys again. Reinitialization is usually required with HSM
hardware that stores keys to server hard drive instead of inside the HSM. External
commands can be executed before reinitialization (e.g. rsync), see engine configura-
tion appendix.
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 tokens
allowing you to select the token you wish to generate the key with.
You can specify some of the PKCS#11 attributes, though the default attributes are
sensitive. In some cases you might want to clear the Exportable flag in order to
make it impossible to leak the CA key out programmatically. In some devices 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 a person who can run
arbitrary commands on the host running the Certifier Engine.
Note, that in most cases the HSM vendor provides the tools which can be used to
generate keys and restore them. Some vendors use proprietary flags, which affect the
key backup and restore procedures. In those cases, it is recommended that the keys
are generated/backed up and restored using the vendor’s own tools. See the vendor’s
documentation for more information.
Depending on HSM vendor, generating/using EC keys with HSM may require addi-
tional licensing. Check your vendor’s manual for more information.

Appendix 1 Certifier Engine and Server Con-

figuration Files
Most of the Insta Certifier configuration tasks can be done via the administration user
interface of the Administration Service. However, there are some parameters that are
not stored in the database or edited via Administration Service. They need to be given
in configuration files to the ssh-ca-engine and ssh-ca-server commands.
The default configuration files (engine.conf and server.conf) can be found in

the certifier/conf/ directory. When Engine is started up without TLS protection
in insecure mode, engine-insecure.conf can be used as an configuration file.
Parameter definitions mean absolute path and key value to parameter. For example,
ca-engine.keep-alive and ca-engine.pins.enabled with ca-engine.pins.path means
following in the engine.conf:
(ca-engine
;; other parameters…
(keep-alive 0)
;; other parameters…
(pins (enabled #t)
(path “/some/path/to/pins”)) ;; notice the ending ‘)’-character
)
Keyword value depends on the parameter, e.g. string, Boolean (#t/#f/true/false).
Appendix 1–1 Certifier Engine Configuration File
The adjustable parameters of the engine.conf are the following:
ca-engine.data-source-name
The ODBC data source name of the database connection. When used outside the
embedded Certifier Database, the value of this parameter needs to be the DSN of
the appropriate database.
ca-engine.service-address
The address and the port that Certifier Engine listens to.
ca-engine.keep-alive
TCP keep-alive option. If the value is set to something else than the default zero
(0), it indicates the seconds between the keep-alive packets sent by the TCP/IP
stack. This is operating system’s TCP/IP stack level option and can be used to
make sure that the TCP connection stays up during idle periods. However, this is
not a good option to detect connection breaks in general case because of the
keep-alive algorithm may cause considerable delays before the connection is de-
clared broken. See Appendix 1-2 heartbeat-interval for Certifier Server for broken
connection detection.

ca-engine.tls
This parameter defines whether TLS is being used between Certifier Servers and
Certifier Engine. For insecure configuration this is set to false.
ca-engine.pid-directory
The location of the PID files.
ca-engine.view-syslog-messages-file-path
File location where the View Syslog Messages page searched for log data. File
and directory must be accessible to ‘certfier’ user (must have read permissions). If
parameter is not set or empty, log file defaults to
/usr/local/certifier/var/log/certifier.log. If file can’t be read, search returns an empty
string.
ca-engine.syslog-facility
The system log facility name can be given in here.
ca-engine.configuration.max-unfinished-publications
The maximum number of concurrent publishing attempts. If this limit is reached, the
publication status of the oldest unpublished certificate is set as failed and the certif-
icate publication will not be automatically tried again. This limit does not concern
CRL publishing.
ca-engine.configuration.max-crl-publication-safety-limit
CRL generation is usually quite fast (typically a couple of seconds), but with ex-
tremely large databases or overloaded systems it may require more time. Because
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.
ca-engine.configuration.expired-timeout-period
One of the certificate statuses in the system is expired. A certificate is marked with
this status after its validity period has ended. This status is used only as a method
of optimization, as it divides the certificate set in the database and enables more
efficient searches for valid certificates.
This status cannot feasibly be updated in real time, but is done in batches instead.
This variable controls the period between the times that these batches are run.
Usually the value is set to one hour or less.
The shorter the period, the more accurate the expired status becomes.
ca-engine.configuration.dynamic-crl-validity-period
In some cases the actual CRL generation may be unnecessary. But even in those
cases it might occasionally be useful to see the ’current’ CRL. If the CRL update
period is set to zero (meaning that the CRL distribution point is disabled), request-
ing the current CRL will generate a new CRL on the fly, with the validity period
starting at the current time and ending after the value specified for dynamic-crl-
validity-period, which is given in seconds.
ca-engine.configuration.heartbeat-interval
The interval (measured in minutes) of the heartbeats written in system log, when
the Certifier Engine process is running.

ca-engine.configuration.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 not
stored in the database. The default value is true. Please note that non-repudiation
may require storing CRLs in order to enable later verification of a signature.
ca-engine.configuration.prefer-utf8
Encode ASN.1 strings as UTF8 rather than printableString. UTF8 is recommended
and printableString should be used only if required for compatibility.
ca-engine.tls-cipher-suites
This feature controls the used and accepted algorithms in TLS protected network
connections. Preferred cipher suites can be set separately for Certifier Engine,
Certifier Server and services. The suite selection for the Server defines the 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. The
first common suite in these configurations is selected in the TLS negotiation. If no
common suite is found, the connection fails.
The value is a list of cipher suites separated with a colon (’:’). Note that the list
must always end with a colon (’:’). The first suite on the list is the most preferred
one.
The default configuration for all cipher suites is ”AES256-SHA:AES128-
SHA:DESCBC3-SHA:RC4-SHA”. If the parameter is not set at all, then all support-
ed cipher suites are accepted.
ca-engine.scep.envelope-data-encryption-algorithm
Determine SCEP response envelope data encryption. Values are either “aes-cbc”
or “des-cbc”. If not defined in configuration, engine will use AES 128 CBC (aes-
cbc).
ca-engine.scep.digest-algorithm
Determine SCEP response digest (hash) algorithm. Either “sha1” or “md5”. If not
defined in configuration, engine will use SHA-1 (sha1). Only enable MD5 if CA is
serving older SCEP clients without SHA-1 support.
ca-engine.pins.enabled
Enable/disable automatic HSM PIN feed. Values are “#t” for enable and “#f” for
disable. If this block is missing from configuration file, PIN feed is done automati-
cally if ‘./var/pins’ file is found. Notice, that in cluster environment, automatic activa-
tion only affects the node where the activation is done. Activating HSM in one node
does not activate HSM on other nodes.
ca-engine.pins.path
Define ‘pins’ file path (see also ca-engine.pins.enabled). Default is
/usr/local/certifier/var/pins (created with ssh-ca-pins script). If this block is missing
from the configuration file, default path is used.
ca-engine.pins.merge-errors
When enabled with value “#t”, HSM login errors are handled as one, e.g. if pins file
includes 10 pin entries, with merge-errors enabled, error is only handled (syslog
message, HSM state change and HSM failure trap) if none of the 10 pins succeed.

By default, merging is disabled. When disabled, each login error is handled sepa-
rately, e.g. for each failed pin error is logged and trap is sent.
ca-engine.maximum-operator-failed-login-attempts
Global variable for controlling maximum login tries the operator can do. Value 0 or
if the key is missing from the configuration means login tries are disable (operator
can try login infinitely). Otherwise value determines the maximum attempts, e.g. 5
means operator login can fail 4 times and the 5th fill lock the account (set it to inac-
tive mode). Operator can be activated via UI by another operator or with ssh-ca-
repair script which also is able to reset the attempts counter.
snmp.enabled
Set “true” or “false” to enable SNMP traps. Notice that SNMP configuration in en-
gine.conf is global. Each CA can have its own SNMP configuration. More infor-
mation about SNMP can be found in Certifier NMS guide.
snmp.server-address
Endpoint for SNMP traps (NMS). If IPv6 is used, define address as
udp6:[address]:port (port can be omitted). For example, localhost is defined as
udp6[::1].
snmp.app-name
Leave as “certifier-engine”.
snmp.security-name
Authentication for the Certifier host with NMS. Used when traps are send in
SNMPv3 system. See Certifier NMS guide for more information.
snmp.security-passphrase
Security passphrase for NSM authentication (see security name). See Certifier
NMS guide for more information.
snmp.engine-id
Identifier for the trap sender. Leave as “certifier”.
snmp.engine-id-type
Possible options are “text” (using engine-id parameter), “ipv4”, “ipv6” or “mac”.
When ipv4/ipv6/mac is selected, engine-id the corresponding IP address.
snmp.nic
Sets network interface, e.g. “eth0”.
Appendix 1–2 Certifier Server Configuration File
The server.conf file contains both server and service specific parameters. The
server-specific parameters are the following:

ca-engine.address
The address of the Certifier Engine, to which Certifier Server is connecting, and a
flag to specify whether TLS is being used for protection.
Multiple addresses can be configured by separating them with a semicolon (;). If
the connection to the first address fails, the second is tried and so on. This requires
the Certifier Engines to be identical in terms of TLS settings and certificates. This
feature is mainly for HA cases where a secondary Engine host takes over in case
the primary fails.
ca-engine.keep-alive
TCP keep-alive option. If the value is set to something else than the default zero
(0), it indicates the seconds between the keep-alive packets sent by the TCP/IP
stack. This is operating system’s TCP/IP stack level option and can be used to
make sure that the TCP connection stays up during idle periods. However, this is
not a good option to detect connection breaks in general case because of the
keep-alive algorithm may cause considerable delays before the connection is de-
clared broken. See heartbeat-interval for broken connection detection.
ca-engine.tls
This parameter defines whether TLS is being used between Certifier Servers and
Certifier Engine. For insecure configuration this is set to false.
ca-engine.tls-client-subject-name
The subject name used for TLS certificate.
pid-directory
The location of the PID files.
pki-directory
The location of the directory where the Certifier Server private key and certificates
are stored.
heartbeat-interval
Interval in seconds between Server heartbeat events with minimum value of 20.
When the event occurs, Server sends heartbeat message to the Engine and ex-
pects Engine to answer. If two answers are missed in a row, Server disconnects
and tries to reconnect Engine. Heartbeat is also written to the system log if ten
minutes or more has elapsed since the last writing. The same heartbeat event is
logged also at the Engine when it receives it. Heartbeat message from Server in-
cludes server id, heartbeat counter (each heartbeat adds to counter, starting from
1) and server name. Server starts sending heartbeat message to Engine when it
receives its configuration from Engine. This means that first Server heartbeat
(counter 0) is not sent to Engine.
In the server.conf configuration file you can also define parameters that are defined
for all Certifier Services of specific type running on that Certifier Server. These pa-
rameters are mainly related to the web server data (such as the location of the HTML
templates). Normally they are needed only for Administration Services and Web En-
rollment Services. The service-specific adjustable parameters of the server.conf file
are the following:

syslog-facility
The system log facility name for the log messages related to the Service can be
specified here.
dos
Parameters for the denial of service avoidance mechanism.
host-rate-limit
Maximum number of requests from one client host during a ten second period.
max-packet-size
Maximum request packet size.
session-idle-ttl
How many seconds the web sessions may be idle before the Web server drops the
session.
initial
Session may be idle this many seconds after the first request.
normal
Session may be idle this many seconds after subsequent requests.
path-mime-types
The location of the file that describes the mappings from filename extensions to
MIME types.
mime-paths
Describes mapping between mime-type and the directory containing files of this
type. The default configuration can include the following entries:
text
The location of the HTML templates used in the GUI. Several directories can be
specified.
image
The location of the images (GIF, JPEG etc.) used by the GUI. Several directories
can be specified.
tls-cipher-suites
This feature controls the used and accepted algorithms in TLS protected network
connections.
Preferred cipher suites can be set separately for Certifier Engine, Certifier Server
and services.
The suite selection for the Server defines the algorithms suggested for the internal
connection between the Server and the Engine. The selection for the Engine de-
fines the algorithms accepted by the Engine. The first common suite in these con-
figurations is selected in the TLS negotiation. If no common suite is found, the con-
nection fails.

For services, the suite selection is only applicable for services that support TLS.
These are the Administration service and the Web Enrollment service. The pre-
ferred cipher suite determines what algorithms are used between the Certifier ser-
vice and a web browser.
The value is a list of cipher suites separated with a colon (’:’). Note that the list
must always end with a colon (’:’). The first suite on the list is the most preferred
one.
The default configuration for all cipher suites is ”AES256-SHA:AES128-
SHA:DESCBC3-SHA:RC4-SHA”. If the parameter is not set at all, then all support-
ed cipher suites are accepted.
library-path
The location of the Scheme code libraries used in the GUI.

Appendix 2 Database
Insta Certifier uses an embedded database for internal data storage, Adaptive Server
Anywhere from Sybase Inc. This database should not be confused with the optional
public LDAP directory which is used for certificate and CRL publishing. Certifier 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 and
entity management related data. The operation log data and most of the configuration
definitions are also stored in the Database. All the software CA/RA private keys are
stored in the database encrypted with the master password.
All the information in an Adaptive Server Anywhere database is stored in a single 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 during
Certifier Engine stop. It is used to hold temporary data, that does not need to be kept
between sessions.
Appendix 2–1 Setting up Backup Procedure
A properly set up backup plan is needed to ensure data recovery in case of hardware
malfunction. One method is to use hardware mirroring which will work on physical 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 failures
are very unlikely to affect both disks at the same time.
Establishing Backup Policy
For successful data recovery, the current backup of the database file (or the database
file itself) and one of the two transaction log files must be available. To guarantee total
recovery, establish a regular backup policy using cron or something similar.
On Unix software mirroring and automated database backups are set up by 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 the
Certifier Database

 Directory (on your file system) where the Certifier Database backups will be cop-
ied to. This directory should also be located on a different physical disk from the
Certifier Database. If this is not he case, even if you arrange automated copying
of the backups to a removable media or to a remote host you are exposed to a
catastrophic disk failure during the time window between the end of the backup
and the end of the copy operation.
 The backup schedule (daily/weekly/monthly). Please note that this schedule af-
fects the amount of lost information only in the case of a catastrophe destroying
both your disks at the same time. If either one of the disks survives, you will be
able recover the database completely.
The script will:
 Enable/disable software mirroring for the Database
 Enable/disable up a daily/weekly/monthly cron job for automated full database
backups.
○ The cron job will be run as the certifier user. The backup is done with the
script bin/ssh-ca-backup.
○ The backups will include the database, configuration files, internal PKI da-
ta in the var/pki directory.
○ Each new backup will be saved in a separate subdirectory and the older
backups will not be erased.
○ Also the Thales HSM security world files are automatically backed up if
they are located in the default directory.
 Modify the cron.allow file if that is/was required for enabling the cron job.
 Modify bin/ssh-ca-runenv to reflect the new backup policy.
Data Integrity Check
Backup as such is worthless if the data itself is corrupted. Checking the database
thoroughly is a somewhat long process it is not normally done at startup. However af-
ter (or before) each backup it is recommended to run a special validation utility:
dbvalid -c "connection_string" -f
To check the backup (as opposed to the running system), the backup database must
be run under an additional database engine in read-only mode (-r option in dbeng7) to
prevent modifications to the backup. Checking the backup database can be useful for
performance reasons as the validity check can be performed on a separate, spare
machine.
The ssh-ca-backup script by default performs dbvalid before proceeding with the
backup.
Appendix 2–2 Recovery
To recover a backup run the command:
./bin/ssh-ca-backup -restore
This command will:

 Restore the Certifier database from the most recent backup and apply the current
transaction log (or its mirror) to it.
 Restore the configuration files in the conf/ subdirectory.
 Restore the var/pki subdirectory
This command will not automatically restore the Thales HSM security world files. To
accomplish this, run the following command instead:
./bin/ssh-ca-backup -restore -with-nfast
In case the backup files should be restored into a new installation as in migration, then
the command should be:
./bin/ssh-ca-backup -restore-lossy [-bak-dir <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, a
new certificate must be enrolled for that server before it can be used. This probably
requires some operator activity to set up a pre-shared secret for the server. If there
are no functioning servers in the system, Insta Certifier must be started in insecure
configuration mode first.
Appendix 2–3 Remote Live Backup
In live backup, the dbbackup process has a continuous TCP connection to the 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 also
be 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, so
anyone with access to your network can also get access to your database.
The best way is either to run the whole setup in a physically trusted network or use
some method to secure the connections (IPSec, Secure Shell tunnel, TLS tunnel or
such). In such cases dbbackup also needs DoBroadcast=NONE option which disa-
bles UDP-broadcast-based database auto-discovery.
To run the live backup, use the following command:
source ./bin/ssh-ca-runenv
dbbackup -c "connection_string" -l transaction.log backup-directory

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, and
password parts, the connection string must contain
links=tcpip(Host=serveraddress) in which serveraddress is the address
of the machine running the database. Additionally if database is running in non-
standard port, ServerPort=portnumber option must be given.
Live backup will only backup the transaction log, the database file itself is not backed
up. All committed transactions are automatically flushed to the remote transaction log
by the live backup process. This however is not transactional; when a transaction is
committed to the database it is not ensured that it is already in the live backup trans-
action log. In case of failure, a few transactions can be lost if the recovery is done
from the live backup.
The dbbackup process exits when the database connection is lost. This means that it
must be encapsulated into a script that automatically restarts the process in such
case, probably integrated into a monitoring solution which also either tries to restart
the current server machine or switches the Insta Certifier to a spare unit.
When implementing a normal backup process for Insta Certifier, it must be remem-
bered that the live backup transaction log is truncated when normal transactions logs
are (the -x option for dbbackup). Best way to ensure that no data is lost during 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, transaction 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/sh
if [ "X‘uname‘" = XLinux ] ; then BASE=/usr/local/certifier ; fi
if [ "X‘uname‘" = XSunOS ] ; then BASE="‘pkginfo -r certifier\* |
tail -1‘/certifier" ; fi
if [ -z $BASE ]; then
echo Unsupported OS; exit 2
fi
if [ $# != "2" ]; then
echo "Usage: $0 backup-dest-dir server-address"; exit 1;
fi
PREFIX=$1
ADDR=$2
. $BASE/sybase/bin/asa_config.sh
SSH_CA_DBCONN=${SSH_CA_DBCONN:-"eng=certdbeng;dbn=certifier;uid=DBA;pwd=SQL"}
SSH_CA_DBCONN="$SSH_CA_DBCONN;CommLinks=tcpip(Host=$ADDR;DoBroadcast=NONE)"
if [ -f $PREFIX/live-transaction.log ]; then
rm -f $PREFIX/live-transaction.log.old
mv -f $PREFIX/live-transaction.log $PREFIX/live-transaction.log.old
fi
nohup dbbackup -c $SSH_CA_DBCONN -l $PREFIX/live-transaction.log $PREFIX >

$PREFIX/live-backup.out 2>&1 < /dev/null &
echo $! > $PREFIX/live-backup.pid

As a safety measure, the script will first move the possibly existing transaction log and
delete the older backup in the process. If wanted, this could also be changed to 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 against
local, limited hardware failure, such as single malfunctioning hard disk, but also
against total loss of the active database machine including its database.
Machine A: Machine B:
Disk 1: <---------------> Live backup:
certifier.db transaction.log
transaction.log
Disk 2: <---------------> Full backup:
mirror.log certifier.db
On the main, active machine (A) we have the database server running as a part of full
Insta Certifier installation.
It has two separate disks (1 and 2) and it uses transaction log mirror. Spare machine
(B) continuously runs live backup process which maintains almost up-to-date 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 all
three transactions logs are also truncated. Machine B does not contain a running Insta
Certifier installation, although it can contain a pre-installed system to help in the 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 main
transaction.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 backup
can be arranged with either of backup scripts in Section Appendix 2–1 (Setting up
Backup Procedure) which can be run a cron jobs. Connection strings must be 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, either
deliberately or by some real failure, the live backup process must be restarted. One
way is to add another script which will monitor the live backup process and restart it
automatically. In such case, some additional care must be taken to ensure that the old
transaction log is not overwritten.
Appendix 2–5 Configuration parameters
Database maximum cache usage limit can be configured by setting variable CERTI-
FIER_DATABASE_MAX_CACHE_SIZE in /usr/loca/certifier/bin/ssh-ca-env script. Pa-
rameter value is <decimal number>[k|m|g], where k is kilo, m mega and g gige, e.g.
100m sets the maximum cache to 100 megabytes. Memory limit can’t be larger than
system overall memory, otherwise database won’t start.
Set maximum cache size if database memory usage is too large for the system.

Appendix 3 Migrating Certifier
Appendix 3–1 Migration Steps
An already existing Certifier installation can be migrated from one host to another by
performing these steps.
Install the new Certifier
Install the installation package (rpm/pkg/depot) to the new host as described in 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, in
order to avoid a break in certificate validation, you must ascertain that none of the
CRLs are about to expire during the migration.
This is done with the administration interface 2.12.14 (System Shutdown) request in
the System Configuration Menu.
After shutting down the Certifier Engine with the System Shutdown request, the data-
base and the server must be also stopped. Please run the ssh-ca-stop script (see
Section 4.1 (Starting and Stopping Certifier Manually)).
Disable database log mirroring
If you have enabled Sybase database log mirroring (either with ssh-ca-backupconf or
manually with the Sybase tools), you must disable mirroring before proceeding with
migration and enable it again on the target system after migration.
Database mirroring can be disabled with ssh-ca-backupconf, see Section A.3.1 (Set-
ting up Backup Procedure).
Disable database live backup
If you have enabled Sybase database remote live backupping, you must disable the
live backup before proceeding and enable it again on the target system after migra-
tion. If you need assistance with this step, please use your official support e-mail ac-
count 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 under var/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 directory
specified in the backup configuration.
Transfer the backup
On Unix: Transfer the fresh backup to the new host. The exact steps depend on your
host/network setup. If the new host is accessible with a Secure Shell connection, this
might be achieved with the following commands:
cd /opt/certifier/var/bak
tar cf - ca-bak-current | ssh root@your-new-host \
"mkdir /opt/certifier/var/migration ; cd /opt/certifier/var/migration; tar xf -"
Transfer your hardware crypto modules

If your Certifier installation includes crypto hardware modules, they must be migrated
to the new host as well. Please consult your hardware crypto module documenta-
tion/support for details.
Setup the new Certifier
Run the ssh-ca-setup as described in Section Installing Certifier in the Administrator’s
Guide. Note that the ssh-ca-backup must be run as certifier user, not as root.
./ssh-ca-setup
bin/ssh-ca-backup -restore-lossy -bak-dir var/migration
Subordinate Servers
Subordinate server installations are not migrated, as their configurations live in the
main installation database. When migrating old subordinate servers to new hosts, 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 (under directory certifier/var/log/ in a
default installation) are not transferred from the old host to the new host with this pro-
cedure. You should copy or archive those files manually as appropriate.
Cleanup

Remove the var/migration directory from your new host.

Appendix 4 IPv6
By default Certifier is installed using IPv4 version of IP protocol. To enable IPv6 con-
figurations must be changed manually.
Appendix 4–1 Syntax
Appendix 4–1–1 Service address
Basic syntax definition for IPv6 is http://[address]:port/ or

http://[address]:port/directory/. For Certifier services (e.g CMP and
SCEP) port must always be defined. Directory is optional. Notice that when you bind
services to same port they must be separated with different directories. If one service
uses meta address [::], no other services can be bound to that port.
Localhost (IPv4 127.0.0.1) is defined as [::1] and meta address (IPv4 0.0.0.0) as [::].
Examples:
 Configure basic CMP service bind address to use IPv6: define the address as
http://[::]:8080/pkix/ (equivalent to IPv4 http://0.0.0.0/pkix/)
 Configure local engine and server installation to communicate using IPv6, define
ca-engine.service-address in engine.conf as tcp://[::]:7001/ and in serv-
er.conf ca-engine.address as tcp://[::1]:7001/.
Appendix 4–1–2 Cluster
When creating cluster configuration using /usr/local/certifier/cluster/config tool, you

can use IPv6 addresses instead of IPv4. For example:
./config add 2 fe80::250:56ff:fe24:dbca
See Cluster manual for details on creating cluster configuration.
Appendix 4–1–3 PostgreSQL
When giving the IPv6 address of the PostgreSQL server during setup, the network in-
terface name or id must also be defined. For example:
fe80::250:56ff:fe24:dbca%eth3 or fe80::250:56ff:fe24:dbca%2

Certifier 7.3 ReferenceGuide

Uploaded by

Copyright:

Available Formats

Certifier 7.3 ReferenceGuide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Certifier 7.3 ReferenceGuide

Uploaded by

Copyright:

Available Formats

Insta Certifier 7.

Insta Certifier : Reference Guide

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

Insta Certifier : Reference Guide

2.8.4 Using a Local CA with RA .................................................................................... 49

Insta Certifier : Reference Guide

2.15 Statistics ...................................................................................................................... 112

Certificate Life-Cycle Management Services........................................................................... 115

Using External CA/RA Private Keys ......................................................................................... 127

Appendix 1 Certifier Engine and Server Configuration Files ................................................. 133

Appendix 2 Database ................................................................................................................ 140

Appendix 3 Migrating Certifier ................................................................................................. 146

Appendix 4 IPv6 ........................................................................................................................ 149

Insta Certifier : Reference Guide

About This Document

Styles and Conventions

Convention Usage Example

# chkconfig --list certifier

Insta Certifier : Reference Guide 1

Parts of the administration view

Figure 2-1 The top menu of the Administration GUI

Insta Certifier : Reference Guide 2

Figure 2-2 The main menu of the Administration GUI

Navigating the administration interface

2.2 Database Search

Insta Certifier : Reference Guide 3

2.2.1 Database Search Options

Insta Certifier : Reference Guide 4

Figure 2-3 The Database Search page

Insta Certifier : Reference Guide 5

quick brown +fox -dog

Insta Certifier : Reference Guide 6

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

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

Insta Certifier : Reference Guide 7

Figure 2-7 Selecting the entity

Insta Certifier : Reference Guide 8

Number of Results Shown

2.2.2 Search Results

Insta Certifier : Reference Guide 9

List of affected certificates is displayed. Click Proceed to commit the operation.

List of affected requests is displayed. Click Proceed to commit the operation.

2.3 Syslog Search

Insta Certifier : Reference Guide 10

Figure 2-8 Syslog Search page

Insta Certifier : Reference Guide 11

2.4 Processing Requests

Insta Certifier : Reference Guide 12

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

Insta Certifier : Reference Guide 13

2.4.1 Certificate Profile

Insta Certifier : Reference Guide 14

Windows 2000 logon with smart cards

Insta Certifier : Reference Guide 15

When issuer key is EC type:

2.4.4 Serial Number

2.4.5 Subject Name

2.4.6 Validity Period

Figure 2-10 The validity period options

Insta Certifier : Reference Guide 16