Certifier 5.2.3 AdministrationGuide

www.insta.fi

Insta Certifier 5.2.3

Administrator's Guide

Insta Certifier : Administrator's Guide

Version 5.2.3

Date 16 September 2013

© 2013 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)

Table of Contents


Table of Contents

About This Document ................................................................................................................... 1

Installing Insta Certifier ................................................................................................................ 2

2.1 Planning the Installation ..................................................................................................... 2

2.1.1 System Requirements ............................................................................................ 2

2.1.2 Insta Certifier Components..................................................................................... 3

2.1.3 Basic Installation Options ....................................................................................... 3

2.1.4 Certifier Database .................................................................................................. 3

2.1.5 Directory Server ..................................................................................................... 3

2.1.6 Upgrading from a previous version ......................................................................... 4

2.2 Installing the Insta Certifier Software .................................................................................. 4

2.2.1 Full Installation ....................................................................................................... 4

2.2.2 Server Installation .................................................................................................. 6

2.3 Removing the Insta Certifier Software ................................................................................ 6

2.3.1 Removing ............................................................................................................... 7

2.4 License File ........................................................................................................................ 7

Getting Started with Insta Certifier .............................................................................................. 8

3.1 Administration Interface ..................................................................................................... 8

3.2 Security Settings ................................................................................................................ 9

3.2.1 Changing the Master Password ............................................................................. 9

3.2.2 Protecting the Administration Connection ............................................................. 10

Configuring the PKI Service ....................................................................................................... 19

4.1 Creating Certification Authorities ...................................................................................... 19

4.1.1 Considerations When Creating a CA .................................................................... 19

4.1.2 Creating a New CA .............................................................................................. 20

4.1.3 Initial Configuration .............................................................................................. 23

4.2 Creating Registration Authorities ...................................................................................... 25

4.2.1 Creating an External Enrollment Client Service .................................................... 26

4.2.2 Creating a New RA .............................................................................................. 26

4.2.3 Enrolling the RA Certificate .................................................................................. 27

4.2.4 Using a Local CA with RA .................................................................................... 29

4.3 Creating Certifier Servers ................................................................................................. 30

4.4 Configuring Certifier Services ........................................................................................... 31

4.4.1 Administration Service ......................................................................................... 33

4.4.2 CMP Service ........................................................................................................ 33

4.4.3 SCEP Service ...................................................................................................... 36

4.4.4 Web Enrollment Service ....................................................................................... 37

4.5 Managing Operators ........................................................................................................ 40

Table of Contents


4.5.1 Creating a New Operator ..................................................................................... 40

4.5.2 Controlling Operator Access ................................................................................ 42

4.5.3 Removing an Operator ......................................................................................... 43

4.5.4 Operator password requirements ......................................................................... 43

4.6 Dual Admin Control .......................................................................................................... 44

4.6.1 Setting Multi Approval in Use ............................................................................... 45

4.6.2 Approving Own Changes ..................................................................................... 47

4.6.3 Reviewing and Approving Changes Made by Other Operators ............................ 47

4.7 Cross-Certification ........................................................................................................... 48

4.7.1 Online Cross-Certification for Existing CA ............................................................ 49

4.7.2 Manual Cross-Certification for Existing CA ........................................................... 50

4.7.3 Manual Off-line Cross-Certification for a New CA ................................................. 51

4.8 Configuring an Offline Certification Authority .................................................................... 51

Setting up PKI Policies ............................................................................................................... 52

Configuring Publishing and OCSP ............................................................................................ 53

6.1 LDAP Publishing .............................................................................................................. 53

6.1.1 Configuring a Publishing Service.......................................................................... 53

6.1.2 Certificate Publishing via LDAP ............................................................................ 55

6.1.3 CRL Publishing via LDAP .................................................................................... 57

6.2 Validation Authority with OCSP Responder ...................................................................... 59

6.2.1 Configuring database connection ......................................................................... 59

6.2.2 Creating the service ............................................................................................. 60

6.3 OCSP Responder ............................................................................................................ 62

6.4 HTTP Publishing .............................................................................................................. 64

6.4.1 CRL Publishing via HTTP .................................................................................... 64

6.5 External Publishing .......................................................................................................... 65

6.6 Conditional Certificate Publishing ..................................................................................... 67

Managing a PKI ........................................................................................................................... 68

7.1 Processing Certification Requests .................................................................................... 68

7.1.1 Approving Requests Manually .............................................................................. 68

7.2 Managing End Entities ..................................................................................................... 71

7.2.1 Adding an Entity for Automatic Enrollment ........................................................... 71

7.2.2 Removing an Entity .............................................................................................. 73

7.3 Revoking and Suspending Certificates ............................................................................. 73

7.3.1 Revoking Certificates ........................................................................................... 73

7.3.2 Suspending Certificates ....................................................................................... 74

7.4 Monitoring with SNMP ...................................................................................................... 75

7.5 Auditing ............................................................................................................................ 75

7.5.1 Committed change set is logically same as revision, technically they are different (as uncommitted change set is not same as revision).Auditing Example ............................................................................................................ 76

Troubleshooting .......................................................................................................................... 79

Table of Contents


8.1 Problems with Starting Insta Certifier ............................................................................... 79

8.2 Problems with Certifier Services....................................................................................... 79

8.3 Problems when Connecting to the Web Services ............................................................. 80

8.4 Problems with Certificate Enrollment ................................................................................ 80

8.5 Problems with Request Processing .................................................................................. 81

8.6 Problems with LDAP Publishing ....................................................................................... 81

Chapter 1: About This Document

Insta Certifier : Administrator's Guide 1

Chapter 1

About This Document

Insta Certifier is a complete solution for providing certification services in an X.509 Public-Key Infrastructure (PKIX). This document gives instructions on the installation, configuration, and use of Insta Certifier.

This document is intended for the persons responsible for the deployment and opera-tion of an Insta Certifier -based PKI.

This document contains the following information:

installing the Insta Certifier software

getting started with Insta Certifier

setting up the PKI

defining the CA and RA policies

configuring publishing

managing the PKI

troubleshooting

To use the information in this document, you should have basic knowledge of public-key infrastructures and X.509 certificates.

Insta Certifier Product Description contains important background information about Insta Certifier and PKI in general, and we recommend that you familiarize yourself with that document before installing and starting Insta Certifier. Insta Certifier Refer-ence Guide contains a thorough description of the user interface and information needed for advanced configuration of Insta Certifier.

Styles and Conventions

The following conventions are used in this document:

Convention Usage Example

Bold GUI elements, variables, emphasis Click System Configuration

Monospace Filenames, commands, directories Configuration file engine.conf

Italics Terms and references Certification Authority

Command lines and configuration file contents are shown as in this example:

# chkconfig --list certifier

Chapter 2: Installing Insta Certifier


Chapter 2

Installing Insta Certifier

This chapter gives instructions on the installation and removal of Insta Certifier. The chapter contains the following information:

planning the installation

installing the software

removing the installation

2.1 Planning the Installation

2.1.1 System Requirements

Supported Platforms

Red Hat Enterprise Linux 6 (x86_64)

CentOS 6

Scientific Linux 6

Other Linux distributions may also be supported.

Hardware

The following minimum hardware is required:

256 MB system RAM (1 GB recommended)

80 MB disk space for the full installation (Engine + Server + Database).

The Database will require more disk space as it grows. 2 GBs of disk space is recommended for a PKI with a hundred thousand certificates and daily published CRLs.

20 MB disk space for a Certifier Server installation

TCP/IP connection

Software

Required software packages:

Net-SNMP 5.x. Package names depend on Linux distribution. In Red Hat the re-quired packages are net-snmp and net-snmp-libs. Notice that if SNMP is not go-



ing to be used only net-snmp-libs package is required. If Certifier SNMP function-ality is being used also net-snmp is required (includes the Net-SNMP daemon).

A web browser is required to connect to the Administration and Web Enrollment Ser-vices. One of the following browsers is recommended:

Microsoft Internet Explorer 7 or later

Firefox

2.1.2 Insta Certifier Components

Insta Certifier is composed of two main components. These are:

Certifier Engine

Certifier Server(s)

The Certifier Server can have different front-end services running. These include the Administration, Web Enrollment, SCEP, CMP, Publishing, OCSP Responder and Ex-ternal Enrollment Client services.

The different services can be divided between multiple Certifier Servers running on different machines, or the services can be run on the same Certifier Server. The communication between the Servers and Engine is protected with TLS which is pro-vided as a part of both Certifier Server and Certifier Engine.

The Certifier Engine can be located on a separate machine than the Certifier Servers. This is because it operates the CA private key, and therefore also the hardware should be stored in a physically secure place.

In addition to the Engine and Server(s), Insta Certifier includes an embedded data-base for internal data storage. Directory Server is an optional component that is re-quired if certificates and other data need to be published.

2.1.3 Basic Installation Options

There are two basic installation options, full installation and server installation. Full in-stallation installs all Insta Certifier components on the same machine (including the Database). Server installation installs only the Certifier Server component.

2.1.4 Certifier Database

In the normal full installation, the internal Certifier Database (Sybase SQL Anywhere 11.0.1) is installed on the same computer as the Certifier Engine. The Certifier Engine is the only process that connects to the Database. In the Certifier Server installation, the Database is not installed at all.

2.1.5 Directory Server

Insta Certifier uses LDAP for certificate and CRL publishing. The directory structure and other LDAP specific information is explained in Chapter 6. LDAP publishing pa-rameters are not configured during the Insta Certifier installation, but later via the ad-ministration GUI.



For example the OpenLDAP directory server (http://www.openldap.org/) or Red Hat Directory Server (http://www.redhat.com/directory_server/) can be used with Insta Certifier.

2.1.6 Upgrading from a previous version

See RELEASE-NOTES contained on the installation media for instructions concerning upgrading from a previous version of Insta Certifier.

2.2 Installing the Insta Certifier Software

The Insta Certifier software is installed by running the rpm installation command. There are separate RPM packages for full installation and the Certifier Server installa-tion. The full installation installs all Certifier components (Engine + Server + Data-base). The server installation installs only the Certifier Server component.

2.2.1 Full Installation

To install Insta Certifier, do the following:

1. Install the RPM package by giving one of the following commands as root.

○ If you are doing the initial full installation of Insta Certifier, the command is:

# rpm -i certifier-<v>.x86_64.rpm

In the command, <v> is the current release version of Insta Certifier (for example, 5.2.0).

2. Run the setup program:

# /usr/local/certifier/ssh-ca-setup

The setup program will ask you the following information:

A. Randomness source for CA private key generation.

If none is given as the file used for randomness source (this is the default

if random devices are not detected in the /dev directory), the setup pro-

gram will gather data from the system containing at least some unpredict-ability and use that to seed the random number generator. If you are not confident that this will give you enough randomness for your CA private key generation, you should create the randomness source file yourself. Make sure you delete that file after using it with the setup script.

B. Whether to use SNMP or not. If SNMP support is enabled, Certifier will send SNMP traps to NMS. Certi-fier uses SNMPv3 authentication without encryption.

C. SNMP Manager (NMS) IP address where traps will be sent.

D. User credentials (security name and password) for sending traps using SNMPv3 authentication.

E. User credentials (security name and password) that can be used by the NMS to perform SNMPv3 queries to the Certifier Engine host.



F. Subject name for the internal TLS certificate.

G. Username by which Certifier is run.

H. Confirmation for modifying the syslogd(8) configuration file

/etc/syslog.conf or /etc/rsyslog.conf.

3. After the setup program has been run, both the Certifier Engine and the Certifier

Server can be started up by running the following command (either as root or as

the certifier user specified in the setup):

# /usr/local/certifier/ssh-ca-start

Initial Setup

The Insta Certifier setup initializes the Database structure and creates an internal CA (Insta Certifier Internal CA).

The internal CA issues the TLS certificates required for secure communication be-tween the Certifier Engine and Certifier Server. These certificates are created during the setup.

You should not change the configuration of the internal CA, as the Certifier Engine and Certifier Servers need to renew their certificates in regular intervals to stay opera-tional.

The CAs that will be used to sign the end-entity certificates in the PKI can be generat-ed via the GUI later. The instructions for doing that can be found in Section 4.1 Creat-ing Certification Authorities.

The Certifier setup creates two Certifier Services, an Administration Service and a Web Enrollment Service, in the Certifier Server. The first steps after the installation should be to turn on the security settings for these Services. Section 3.2 Security Set-tings provides instructions for doing this.

Directory Structure

The Insta Certifier full installation creates the following directory structure:

certifier/

admin-templates/ - HTML templates for the Administration Service

admin-html/ * The default HTML template set

bin/ - Certifier binaries and shell scripts

conf/ - Certifier configuration files

enroll-templates/ - HTML templates for the Web Enrollment Service

enroll-html/ * The default HTML template set

lib/ - Scheme libraries and other files

modules/ * Policy module Scheme files

profiles/ * Certificate profile Scheme files

snmp-mibs/ * Certifier SNMP MIB files.

sybase/ - Sybase Adaptive Server Anywhere database

var/ - Various non-static files

pki/ * Private key and certificate directory

run/ * PID file directory

log/ * Syslog output (optional)

stats/ * Statistics and alarm information files for SNMP agent.

In the Certifier Server installation, the Database is not installed and there is no sybase directory.



2.2.2 Server Installation

The prerequisite for this installation is that a Certifier Subordinate Server entity and a pre-shared key have been created beforehand in the Administration Service.

The prerequisite for upgrading an existing Server installation is that a new pre-shared key has been created beforehand for this existing Server entity in the Administration Service.

To install the Certifier Server, do the following:

1. Install the RPM package by giving one of the following commands as root.

○ If you are doing the initial server-only installation, the command is:

# rpm -i certifsub-<v>.x86_64.rpm

In the command, <v> is the current release version of Insta Certifier (for example, 5.2.0).

2. Run the setup program:

# /usr/local/certifsub/ssh-ca-setup

The setup will prompt you for the following information:

A. Username by which Certifier is run.

B. Pre-shared key. This is the pre-shared key (without the reference number) created for the Certifier Subordinate Server entity in the Administration Service in the format: [key]

C. (c) The TCP address of the Certifier Engine. The default address is: tcp://localhost:7001/

The installation will now proceed and the new Certifier Server will enroll a TLS certificate from Insta Certifier Internal CA.

Note: The default policy of the internal CA is automatic acceptance for valid server entities. Do not change this policy, as the Certifier Engine and Certifier Servers need to renew their certificates in regular intervals to stay operational.

3. After the setup is complete, you can start the Certifier Server by giving the follow-ing command (either as root or as the certifier user specified in the setup):

# /usr/local/certifsub/ssh-ca-start

2.3 Removing the Insta Certifier Software

The uninstallation will remove:

everything in the certifier or certifsub directory, including the directory itself

any modifications done in the syslog daemon configuration during installation

the database transaction log mirror file if mirroring was used (Full installation on-ly).



2.3.1 Removing

Removing the Full Installation

To remove the full installation, give the following command:

# rpm -e certifier

Removing the Server Installation

To remove the server installation, give the following command:

# rpm -e certifsub

2.4 License File

Insta Certifier requires a valid license file. The file is lib/license-data.lic. After

the installation, the license file contains license data that is valid for setting up the Cer-tifier. The license is valid for two hours from the starting of Certifier.

After the installation a valid license file must be copied over the setup license. It is recommended to restart Certifier after that if it is running.

The current license information can be viewed in administration GUI’s About window. The license information contains:

Product – always Insta Certifier

Owner – to whom the license has been granted

Product version – for which versions of the product this license is valid.

Valid not after – the expiration time of the license (can be unlimited)

Usage – the usage purpose for which the license has been granted

Number – the license number

Info – optional informational text about the license.

Chapter 3: Getting Started with Insta Certifier


Chapter 3

Getting Started with Insta Certifier

This chapter gives instructions on connecting to the Administration Interface for the first time and making the necessary security settings.

3.1 Administration Interface

The Certifier Administration Interface is by default available at

http://localhost:8083/.

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.

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 three 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 (Figure 3-1) contains About and Logout links, and a quick Search button.

Figure 3-1 Top menu

The main menu Figure 3-2 contains links to the setting pages of the administration GUI. Some options may be hidden on the menu, depending on the administrator set-tings.

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, or OK buttons provided on the UI page, or just select a new link from the main menu.



Figure 3-2 Main menu

3.2 Security Settings

This section gives instructions on making initial security settings after Insta Certifier have been installed. As the Administration Service is not secured yet after the installa-tion, the steps explained in this section should preferably be done on a local host iso-lated from the network. After the security settings have been configured, Insta Certifier can be connected to the network.

Going through the following steps should also familiarize you with some of the Certifi-er concepts such as Service configurations, operator authentication, entity mappings, and certificate enrolment.

3.2.1 Changing the Master Password

Internal communication between the components of Insta Certifier is protected with TLS. The private keys used in TLS are stored in the database and protected by a master password. Also all the CA and RA software private keys are protected with it. You should change this password immediately after installing Insta Certifier.

To change the master password:

1. Connect to the Administration Service using your browser (http://localhost:8083/).



2. Fill in the root operator’s Login (admin) and Password (admin) fields. Click Pro-ceed.

3. On the main menu, click System Configuration.

4. On the System Configuration Menu page, click Change Master Password. Notice that password requirements depend on master password policy.

5. Enter the new password twice (current password is empty).

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

7. Click Commit to make the change.

The master password is asked whenever the machine running Insta Certifier is re-started. If the engine is started automatically at reboot, or the password is not given

when starting it with the ssh-ca-start command, the engine will start in locked

mode, that is, no private-key operations are possible. In this mode, the master pass-word can be given in the Administration GUI.

Note: in some operating system versions the boot-up screen is interactive. In such cases the master password is asked also at reboot (if not stored to database). How-ever, the interactive screen may not be visible by default and may lead to system hang. To prevent this, the interactive screen should be made visible (e.g. by clicking esc-key, or clicking “show details” depending on the OS).

Optionally, also a server password can be used. See Insta Certifier Reference Guide for more information.

3.2.2 Protecting the Administration Connection

Initially the operator communicates with the Administration Service over an unprotect-ed HTTP connection. This means that all administration traffic is sent unencrypted and is subject to eavesdropping. It is recommended that the connection to the Admin-istration Service is protected with TLS, or alternatively the Administration Service ad-dress binding is limited to localhost (127.0.0.1). There are three levels of protection:

unprotected HTTP

TLS protected HTTP

TLS protected HTTP with client authentication

The highest protection is achieved by using TLS with client authentication, where op-erators use certificates to authenticate themselves.

Insta Certifier Internal CA and private keys and certificates for Certifier Servers are generated during the setup (see Section 2.2.1 Initial Setup). Thus TLS with client au-thentication is automatically used for internal communication between the Insta Certi-fier components. However, the Administration Service needs its own TLS server certif-icate, and optionally the administrators’ need TLS client certificates in addition to these internal TLS certificates.

Note: In the following instructions, Insta Certifier Internal CA is used for issuing certifi-cates for Certifier Services and Certifier operators. In a real-life setup, you may want



to create a dedicated CA for this purpose. See Chapter 4.1 Creating Certification Au-thorities for instructions.

Changing the Password and Creating a Pre-Shared Key

It is recommended to change the root operator’s (admin) password if you are planning to use an unprotected connection or a TLS protected connection without client au-thentication. Changing the password is optional if you are planning to use a TLS pro-tected connection with client authentication. In the latter case, you must create a pre-shared key for the operator. You can also create a new operator with super-user ac-cess rights and disable or remove the original root operator (admin).

1. Connect to the Administration Service using your browser (http://localhost:8083/).

2. Fill in the root operator’s Login (admin) and Password (admin) fields. Click

Proceed.

3. On the main menu, click Operators.

4. Click View Operator. The Operator page opens, see Figure 3-3.

5. (If you are going to use TLS protection with client authentication, this step is op-

tional.) Change your password by typing the new phrase to Password and

Confirm fields.

6. (Pre-shared key is required if you are going to use TLS protection with client au-

thentication. In all other cases, you can skip this step.) Click Add under Pre-shared keys. A new pre-shared key is generated. Write down the key, it will be needed later.

7. Click Commit Changes.



Figure 3-3 Operator with PSK

Setting TLS Protection

Note: the following steps instruct setting TLS protection (without client authentication) for the Administration Service. If you want to use TLS protection with client authentica-tion, skip these steps and follow the instructions in the next section.

To set the Administration Service to use TLS protection:

1. On the main menu, click Servers.

2. Click View Server. The Edit Server Entity page opens.

3. Select Administration Service from the service list and click Add.

4. On the Administration Service editing page, make the following settings:

A. Fill in the Service bind address http://0.0.0.0:8082/. If the port 8082 is reserved, choose another port number.



Note: On this page, the Service bind address must be given beginning with http (not https) even when TLS protection is used.

B. From the Security Settings box, select TLS Protected HTTP Connection.

C. For the TLS Server Certificate CA, select Insta Certifier Internal CA.

D. The rest of the settings can be left at their default values for now. When

finished with the settings, click Continue. See Figure 3-4.


The newly generated Administration Service certificate is now shown under Client certificates on the Edit Server Entity page. Click the Status Query button on the bottom of the page to verify Service status. The Administration Service should show

status: running.

To verify that TLS really works, log out from the current session (click Logout on the top menu). Log in to the new TLS-protected Administration Service in https://localhost:8082/ (https instead of http). Now you can remove the non-protected Administration Service:



3. Click the Remove button next to the old Administration Server, which does not have TLS protection and uses port 8083.


Now only TLS-protected administration sessions are allowed.

Setting TLS Protection with Client Authentication

To use TLS protection with client authentication, you have to enroll a client certificate

for the root operator from a CA that is on the list of Client Authentication CAs in the Administration Service settings. See Figure 3-4 Edit Configuration for Administration Service page.



Figure 3-4 Edit Configuration for Administration Service page

In the following steps, Insta Certifier Internal CA created during the installation of Insta Certifier is used as the client authentication CA.

Before enrolling the TLS certificate, the Web Enrollment Service should be protected:



3. Click Edit near the name of the existing Web Enrollment Service.

4. On the Web Enrollment Service editing page, make the following settings:

A. From the Security Settings box, select TLS Protected HTTP Connection.

B. For the TLS Server Certificate CA, select Insta Certifier Internal CA.

C. For the Accessible CAs, select All CAs. By default, Insta Certifier Inter-nal CA is not shown on the web enrollment pages. This is the recom-mended setting in a real-life setup.

D. For the Entity Mapping method, select Pre-Shared Key.



E. The rest of the settings can be left at their default values. When finished

with the settings, click Continue.


Now the Web Enrollment Service is protected with TLS and the pre-shared key can be

given in the enrolment page. Click the Status Query button on the bottom of the

page to verify Service status. The Web Enrollment Service should show status: running.

The following steps are required to create a private key and to request a certificate:

1. Connect to the Web Enrollment Service with your browser (https://localhost:8080/).

2. On the main menu, click CA List.

3. Install the certificate of the client authentication CA (in this case, Insta Certifier In-ternal CA) in your browser:

○ On Microsoft Internet Explorer: Click Download Certificate next to the

CA you wish to get the certificate from. Click Open. The Windows Certifi-

cate dialog box opens. Click Install Certificate and follow the steps of the Certificate Manager Import Wizard to install the CA certificate into the Windows certificate store.

○ On Firefox and Opera: Click Download Certificate next to the CA you wish to get the certificate from. Follow the browser’s instructions and if asked, select the purposes you want to trust this certificate for (e.g. Trust this CA to identify web sites). The certificate is installed to the borwser’s certificate store.

4. Back in the Web Enrollment Service, click the link corresponding to your browser

(MSIE or Firefox, Opera or other browser supporting KEYGEN HTML tag). The End Entity Certificate Enrollment page opens.

5. Enter the following information:

A. Fill in the subject name fields.

B. Select the Client Authentication extended key usage box.

C. Fill in the pre-shared key you were given previously when you changed the admin password.

D. On Microsoft Internet Explorer, you can also set the CSP (cryptographic

service provider) to be used and the Certificate store type. You can leave the CSP to its default value. Select current user as the certificate

store and clear the Private key protection check box. Using additional security in private key storage will cause the browser to prompt you for confirmation on key usage several times per page when using the TLS-protected Administration Service.

E. When you have filled in the relevant settings, click Submit Request. See Figure 3-5 Enrolling a TLS client certificate for example settings.

6. The browser will prompt you to generate a private key:

○ On Microsoft Internet Explorer, assuming you cleared the Private key protection check box, the key and the request will be generated automat-ically and sent to Insta Certifier.



○ On Firefox and Opera, click OK. If set in your browser, you will be prompt-ed for the password for the Software Security Device. Type in your pass-

word and click OK.

7. The default CA policy for Insta Certifier Internal CA is to automatically accept re-quests for valid server and operator entities. This means that after the Engine has received the request forwarded by Web Enrollment Service, the certificate will be automatically created and sent to the browser.

○ On Microsoft Internet Explorer: Click Install as User Certificate to add the certificate to the Windows certificate store. To view the certificate store

now, click Tools → Internet Options on the MS IE menu. On the

Content tab page click the Certificates button. The certificate is shown

under the Personal tab.

○ On Firefox: Click Install Certificate to add the certificate to the browser’s

certificate store. To view the certificate store now, click Tools → Options

on the menu, and select Advanced. Click View Certificates. The certifi-

cate is shown under Your Certificates.

○ On Opera: To view the certificate store now, click Tools → Preferences

on the menu, and select Advanced. Click Manage Certificates. The cer-

tificate is shown under Personal.



Figure 3-5 Enrolling a TLS client certificate

When connecting to the Administration Service, remember to always use the same browser that was used in TLS client certificate enrollment. A certificate enrolled with Netscape cannot be used with Microsoft Internet Explorer and vice versa, because the same private key cannot be easily accessed by both browsers.

For more details about the enrollment process, see Insta Certifier Reference Guide.

Next, set the Administration Service to use TLS protection:

1. Log in to the Administration Service.



4. Select Administration Service from the service list and click Add.

5. On the Administration Service editing page, make the following settings:



A. Fill in the Service bind address http://0.0.0.0:8082/. If the port 8082 is reserved, choose another port number.


B. From the Security Settings box, select TLS with client authentication.

C. For the TLS Server Certificate CA, select Insta Certifier Internal CA.

D. The rest of the settings can be left at their default values for now. When

finished with the settings, click Continue.


The newly generated Administration Service certificate is now shown under Client

certificates on the Edit Server Entity page. Click the Status Query button on the bottom of the page to verify Service status. The Administration Service should show

status: running.

To verify that TLS client authentication works, first close the current session and then log in to https: //localhost:8082 (https instead of http). You will be prompted to choose

your TLS client certificate from a list. Select your certificate and click OK.

The login screen will now automatically show the operator login name that is bound to the client certificate (see Figure 3-6 The Insta Certifier login screen).

Figure 3-6 The Insta Certifier login screen

Once you have verified that you are able to log in by using TLS client authentication, you can remove the non-protected Administration Service instance:



3. Click the Remove button next to the old Administration Server, which does not have TLS protection and uses port 8083.


Now only TLS-protected client-authenticated administration sessions are allowed.

Chapter 4: Configuring the PKI Service


Chapter 4

Configuring the PKI Service

This chapter gives instructions on the basic steps necessary to get the public-key in-frastructure (PKI) up and running with Insta Certifier.

4.1 Creating Certification Authorities

Ability to manage several CAs with complex hierarchies is one of the many useful fea-tures of Insta Certifier. You can create and manage an unlimited number of CAs with one Insta Certifier installation.

New certification authorities can be created by the CA operator via the administration GUI. For every CA, the root operator has to configure the following:

CA policy that governs the issuance of certificates

LDAP configuration for certificate and CRL publishing

(optionally) CRL publishing period

(optionally) OCSP service

These can be edited by choosing the CA Hierarchy option in the GUI and clicking the name of the CA. CA policy and LDAP publishing are discussed in more detail in Chap-ter 5 and Chapter 6.

During the setup process Insta Certifier Internal CA was created. This CA is used for issuing certificates to Insta Certifier Servers and optionally also to Certifier Services. You should create new CAs for issuing the end-entity certificates.

Even though one CA (the root CA) could be used to sign all the end-entity certificates in the PKI, it is recommended to separate different certificate profiles for separate CAs. For example, one CA could publish TLS server certificates and another TLS cli-ent user certificates.

4.1.1 Considerations When Creating a CA

A certification authority consists of two parts. The CA entity, as understood by the Administration Service, consists of name, policy configuration, and publishing infor-mation. The actual CA certificate and the corresponding private key are separate da-tabase objects, and the CA entity contains a binding to one CA key pair.

When creating a new CA, all the CA private key and certificate parameters have to be considered carefully. They set restrictions to CA usage and affect the security of the CA. Especially important are the following:



Subject name

The distinguished name of the CA, the identity of the CA which is bound to the CA key pair.

Key type

RSA, EC and DSAkey types are supported by Insta Certifier.

Key length

The CA key length should be at least 2048 bits when using RSA key type. Longer keys are cryptographically stronger (but are slower to use). When using EC key type, 256 bit EC private key is equal to 3072 bit RSA private key.

Validity period

The root CA key update may be a heavy process for clients, so the validity period should not be too short. On the other hand, longer validity requires also stronger keys.

Path length constraint

The path length constraint gives the maximum number of CA certificates that may follow the CA certificate in the certification path. If the value is zero, the CA cannot sign CA certificates. If an unlimited path length is selected, the CA certificate will not contain a path length constraint at all.

4.1.2 Creating a New CA

To create a new CA:


2. On the main menu, click CA Hierarchy. CA List is displayed.

3. Click the Create New CA button. The Create New Certification Authority page opens see Figure 4-1.

4. Fill in the basic information about the new CA entity.

CA Name is a short name for the CA entity. The name is used in the administra-

tion GUI and in the Enrollment Services. Description is a longer, free-form de-scription string.

Status is either Active or Inactive. The active CAs are operative. The inactive CAs cannot be used.

The Default policy can be either Deny All, Manual Request Approval, or

Automatic Request Approval.

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 de-fault time and the time specified in the incoming requests are always used.

If you have not yet created a Publishing Service, leave the Publishing settings to their default values and configure them later. For more information, see Chap-ter Chapter 6.



CA Certificate is the most important part of this form. When you write a free-

form search string and click the Search button, a match list of existing certificates will be shown in the pop-up menu. You can then create a CA which is bound to

the selected certificate by clicking the Proceed button.

Figure 4-1 Basic CA entity configuration

5. If you have already previously created CA keys and a certification request, and have now received a CA certificate that has been signed by an off-line CA, you

can import the certificate by clicking the Import certificate button.

6. If the CA certificate does not exist, you can create it by clicking the Make new certificate button, which will proceed to certificate creation (Figure 4-2 Creating a new CA certificate). After this, the form will be shown with the CA certificate field automatically set to the newly created certificate.

A. When creating the root CA for your PKI, select the Issuer to be self-signed. When creating the first CA for managing end-entity certificates,

select the Issuer to be your root CA. Later when creating new CAs, you can select the issuer according to your plan for the certification hierarchy.

B. Serial number can be set, but it is generally recommended not to. When not set, the serial number is automatically selected to be a random number (depending on the other related settings). If set, the serial number can be any valid positive number in range 1 – 1040. If set for a subordinate CA or other certificate issued by an existing CA, it is checked that the CA has not issued another certificate with the same serial number. Also Insta Certifier does not allow setting this to a same number that any self-signed certificate already has.

C. Subject name must be a valid distinguished name (DN) and should be selected with care. Such things as the intended use of the CA, publishing to LDAP, etc. all affect the choice.

D. Validity period defaults to the current time. At least Not after should be changed to a later value. With CA certificates, validity periods of one year

or even several years are not uncommon. The Public Key size is also



linked to this decision, as it is usually a good idea to use stronger keys for certificates with longer validity periods.

E. Click Set Key Generation Parameters to open the Key Generation / Import page. On this page, select the Key Provider Type (either RSA/DSA or EC). If there is a hardware security module (HSM) in use, it can be selected as a private key storage device in the key provider list

(see Insta Certifier Reference Guide for more information). Select Key type and Key size and click Continue. When using EC key, named curve is selected instead of key size.

The selected key type and length are now shown in the Public key field

on the Make New Certificate page. When using EC key, selected named curve is shown.

F. The Signature algorithm field contains the available algorithms. Defini-tion sets the signature algorithm the CA uses to sign the certificate. The default value is SHA-1 when issuer is using RSA type key. When issuer key is EC type signature algorithm is automatically selected based on is-suer key size. For 256 bit EC key, signature algorithm is ECDSAWith-SHA256, for 384 bit EC key, ECDSAWithSHA384 and for 521 bit, EC-DSAWithSHA512. Notice that when importing an EC key the signature al-gorithm selection shows RSA but the signature will be ECDSA (depending on issuer); PKCS#8 data is decoded after proceed, therefore the key type is unknown until then.

G. The Extensions field contains all extensions in the certificate. The most

important is the Basic constraints extension, which must be present in all CA certificates that have the CA flag selected (it is selected by default).

The Key usage bits might need changing, depending of the intended use.

Additional extensions such as Email or IP address can be added by se-lecting an extension from the list and clicking Add.

H. Finally, create the certificate by clicking the Proceed button.

7. At this point, you are back in the Create New CA form, which has the newly cre-ated CA as the certificate. If all the other fields are complete, you can now create

the CA by clicking Proceed. Note that if you cancel CA creation now, the newly created certificate is still in the Database and can be directly bound to a new CA at some later time.



Figure 4-2 Creating a new CA certificate

4.1.3 Initial Configuration

A newly created CA has a very minimal configuration, and as the first thing after creat-ing a new CA, you should configure its policy and publishing attributes. You can do

this through the CA Hierarchy display by clicking the name of the CA. This brings

you to the Certification Authority page shown in Figure 4-3.



Figure 4-3 The CA configuration

The CA name, Description, and Status fields were already set during CA creation, but can be further modified in this view.

The CA certificate field shows the certificate bound to this CA. The certificate can be changed with Change button, but doing this might cause problems with clients that use certificates issued by this CA.

The Certificate publish methods field contains short information about the current-ly configured publishing method for certificates issued by this CA. This method can be

edited by clicking the Edit publish button. See Chapter 6 for more information.



If automatic renewal has been configured, the Renewal period field shows how

much in advance the keys are renewed prior to the current certificate expiration. Time until next renew field shows how much time is left before the next renewal.

The CRL Update field contains information about the CRL distribution point associat-

ed with this CA. Update period is the interval used in CRL generation, and is given in seconds (for example 3600) or in minutes (50m) or in hours (15h) or in days (370d).

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

cation. The Edit publish button is used to actually edit the publishing parameters used for the CRLs.

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.

The Commit changes button updates the name, description, status, CRL update type and update period to the Database.

The Edit policy button is used to edit the policy configuration associated with this CA. See Chapter 5 for more information.

4.2 Creating Registration Authorities

In addition to CAs, you can create and manage RAs within the Insta Certifier installa-tion. An RA is very similar to a CA in Certifier. An RA needs to have a policy, it can re-ceive end-entity requests and it may publish certificates in the directory. The major dif-ference is that an RA does not issue certificates or CRLs, instead it signs certification requests with its own private key, and sends them to the CA. Most of the everyday CA administration functions are similar to RA functions. However, the RA creation is a bit different, since RA usually enrolls its certificate from a CA that is not running on the same installation. If using a local CA, the request processing does not involve sepa-rate RA signing when the request is forwarded to the CA.

It is not mandatory to deploy separate RA servers to distribute the certification request processing. With Insta Certifier, multiple CA administrator accounts could be added to the CA system to handle the end-entity registration. However, there are advantages of using a real RA system. These include:

Each approval of a certification request involves digital signature with the RA key for more secure auditing of the certification process. Note that the signing key is RA-server-specific, not administrator specific.

Management of logical user groups (for example one department or organization) can conveniently be dedicated to specific RAs without creating a logical CA for each user group.

There is no need to expose the Administration Service to remote administrators over the public network.

End users can enroll in the PKI via an enrollment server within their own internal network.

The choice of whether to deploy Certifier RAs or only remote administrators depends strongly on the planned certification practices of the CA.



In the following example, where the CA is not running on the same instance as the RA, it is assumed that:

There is an online CMP connection from the RA server to the CA server. 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 (all) valid entities or 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 enrolment.

4.2.1 Creating an External Enrollment Client Service

First, you need to create an External Enrollment Client Service in the RA server. This service is needed for performing the RA side of the RA-CA communication.



3. Click View Server to open the Edit Server Entity page.

4. Select External Enrollment Client Service from the service list, and click Add.

5. Give Service description for the service and click Continue.


The RA creation itself consists of two parts. First the local RA is created. The second step is to get the RA certificate from the CA.

4.2.2 Creating a New RA

To create a new RA:


2. On the main menu, click RA List. The RA List is displayed.

3. Click Create New RA button.

4. Fill in the basic information about the new RA:

A. RA Name is a short name for the RA. Description is a longer, free-form description string.

B. Status is either Active or Inactive. The active RAs are operative. The inactive RAs cannot be used.

C. The Default policy can be either Deny All, Manual Request Approval, or Automatic Request Approval.

D. If you have not yet created a Publishing Service, leave the Publishing settings to their default values and configure them later. For more infor-mation, see Chapter 6.

5. Click Proceed to create the new RA.



Figure 4-4 Creating a new registration authority

4.2.3 Enrolling the RA Certificate

Now the newly created RA can be seen under the RA List. The next step is to config-ure the RA-CA connection and to get the RA certificate from the CA:

1. Click the RA name on the RA List page.

2. Configure the RA-CA communications parameters:

A. Select the External Enrollment Client Service, which was created ear-

lier, from the Enroll Client Service list.

B. Select CMP over HTTP connection as the connection type.

C. Fill in the CMP URL in the Connection path field. This is the URL of the CMP Service, which is running on the CA host.

3. Click the Enroll New Certificate button.

4. Click Refresh to update the CA list and select the relevant CA. Fill in the

Reference number and the Key that were given to you by the CA administra-tor. You can also fill in the subject name of the RA certificate request in the

Subject name field. See Figure 4-5 for an example.

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.

5. Click Proceed to start the private key generation and certificate enrollment.



Figure 4-5 Enrolling the RA certificate

If the enrollment succeeded, the RA was able to enroll a certificate for itself and to re-

ceive the CA certificate. This can be verified by clicking the RA name in the RA List. The CA certificate should be shown now in the Remote CA Certificate field and the

RA certificate in the Certificate field. See Figure 4-6 RA configuration.

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 pend-ing request.

After the request has been approved, the RA is operational, it has a private key with a certificate, and the connection to the CA is correctly configured.



Figure 4-6 RA configuration

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

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



4.3 Creating Certifier Servers

The modular architecture of Insta Certifier makes it possible to run different Certifier processes on different computers. The default installation will create the Certifier En-gine, the Certifier Database, and a Certifier Server on the same machine. One Certifi-er Server can run all desired Services, but in most cases several Certifier Servers are useful to maximize the security of the system. After the initial installation, additional Certifier Servers can be installed on other machines. Two Certifier Servers cannot be installed on the same machine.

An example setup of Certifier Servers is shown in Figure 4-7.

Figure 4-7 Insta Certifier example setup

To create a new Certifier Server on another computer, you must first create a Certifier Subordinate Server entity in the Administration Service and then install the Certifier Server software on the other computer.

To create a Certifier Subordinate Server entity:



3. On the Server List page, click Add New Server. The Create New Server Entity page opens.

4. Fill in a suitable Server name and Server description. If you wish to add ser-vices at this stage, follow the instructions found in Section 4.4 Configuring Certifi-

er Services. Otherwise, click Create. The services can always be added later.

5. On the Edit Server Entity page, click Add near the Pre-shared keys field to add a pre-shared secret for the entity. Write down the pre-shared key. It will be needed when installing the Certifier Server software component.




Figure 4-8 Creating a new server entity

The next step is to install the Certifier Server component. For instructions on how to do this, see Section 2.2.2 Server Installation.

After the Certifier Server has been installed and is running, create the desired ser-vices by following the instructions found in Section 4.4 Configuring Certifier Services and in Chapter 6Chapter 6 (Configuring LDAP Publishing and OCSP).

4.4 Configuring Certifier Services

One Certifier Server can contain practically an unlimited number of Certifier Services.

The Edit Server Entity page contains a short description of each added service.



Figure 4-9 Edit Server Entity

This section gives instructions on creating and configuring Certifier Services under a Certifier Server.

Configuration of the External Enrollment Client Service is described is Section 4.2 Creating Registration Authorities. Configuration of the Publishing and OCSP Re-sponder services is described in Chapter 6.



4.4.1 Administration Service

The Administration Service provides the CA and RA operators a graphical user inter-face for performing the PKI management operations (including request processing, certificate revocation, and entity management).

A Certifier installation can have several Administration Services, for example, one service for root operator(s) who create and maintain the PKI and another for operators who do the processing of end-entity certification requests.

To configure an Administration Service:



3. Click View Server on the server you want to view. The Edit Server Entity page opens.

4. To add a new service, select a service from the list and click Add. Click Edit on the Administration Service you want to edit.

5. Make the following settings:

A. Give a short Service description and the Service bind address (the default is http://0.0.0.0:8083/).


B. Select the Access level of the service. In short, Full Super User Access allows all operations to be made through this service (if allowed by the op-

erator’s access level), while Normal Operators Only limits the opera-tions to certificate and entity management. See Insta Certifier Reference Guide for more information.

C. Select also whether the service is TLS-protected or not. If the service uses TLS protection, select the CA that issues TLS certificates to services and select the validity period of the TLS certificate.

D. If the service uses TLS protection with client authentication, select also the CA(s) that are allowed to issue TLS certificates to clients (operators).

E. Click Continue when finished. For an example of settings, see Figure 3-4 in the previous chapter.

6. Click Commit Changes on the Edit Server Entity page to make the changes final.

4.4.2 CMP Service

The CMP Service acts as a server for handling incoming Certificate Management Pro-tocol (CMP) messages (including certification requests and revocation requests).

To configure a CMP Service:






4. To add a new service, select a service from the list and click Add. Click Edit on the CMP Service you want to edit.


A. Give a short Service description and the Service bind address (the

default is http://host:8080/pkix/). Optionally, give also a Service domain name (a fully qualified domain name). The service domain name and ser-vice description will be shown on the web enrollment pages. The service domain name will also be shown on the entity print page.

B. Select the CMP operations that are allowed through this service. For more information on these, see Insta Certifier Reference Guide.

C. Select the CAs that are accessible through this service. If all CAs are ac-

cessible, click All CAs. If only a limited number of CAs are accessible,

click Only selected CAs and add the CAs to the list by selecting a CA name from the drop-down list and clicking Add.

D. Click Continue when finished.




Figure 4-10 Edit Configuration for CMP Service



4.4.3 SCEP Service

The SCEP Service provides certificate enrollment services for clients that support Cisco Systems’ Simple Certificate Enrollment Protocol.

To configure a SCEP Service:




4. To add a new service, select a service from the list and click Add. Click Edit on the SCEP Service you want to edit.


A. Give a short Service description and the Service bind address (the

default is http://host:8080/scep/). Optionally, give also a Service domain

name (a fully qualified domain name). The service domain name and ser-vice description will be shown on the web enrollment pages. The service domain name will also be shown on the entity print page.

B. Select the CAs that are accessible through this service. If all CAs are ac-


click Only selected CAs and add the CAs to the list by selecting a CA name from the drop-down list and clicking Add.

C. Click Continue when finished.




Figure 4-11 Edit Configuration for SCEP Service

4.4.4 Web Enrollment Service

TheWeb Enrollment Service provides a point of connection for the web-based enroll-ment clients that use the certificates issued by Insta Certifier.

To configure a Web Enrollment Service:




4. To add a new service, select a service from the list and click Add. Click Edit on the Web Enrollment Service you want to edit.


A. Give a short Service description and the Service bind address (the default is http://host:8080/). Note: On this page, the Service bind address must be given beginning with http (not https) even when TLS protection is used.



B. Select whether this Web Enrollment Service is TLS-protected or not. If the service uses TLS protection, select also the CA that issues TLS certifi-cates to services and select the validity period for the TLS certificate.

C. If the service uses TLS protection with client authentication, select the Cli-ent Authentication CAs that are trusted by this service. If all CAs are trust-

ed, click Trust all CAs. If only a limited number of CAs are trusted, click

Trust only selected CAs and add the CAs to the list by selecting a CA

name from the drop-down list and clicking Add.

D. Select the CAs that are accessible through this service. If all CAs are ac-


click Only selected CAs and add the CAs to the list by selecting a CA

name from the drop-down list and clicking Add.

E. Click Continue when finished. For an example of settings, see Figure 4-12.

6. Click Commit Changes on the Edit Server Entity page to make the changes fi-nal.

See Insta Certifier Reference Guide for information on customizing the web enroll-ment interface.



Figure 4-12 Edit Configuration for Web Enrollment Service

4.5 Managing Operators

The root operator has super-user privileges, and therefore it is recommended that everyday CA management tasks are performed by an operator with lower privileges.

Even if there is just one operator, it is not recommended to login as the root operator, unless super-user privileges are really needed (for example, for creating a new CA or configuring a CA policy).

4.5.1 Creating a New Operator

The process of creating a new operator differs slightly depending on the protection method used by the Administration Service (see Section 3.2.2 Protecting the Admin-istration Connection).

Figure 4-13 Creating a new operator

When the Administration Service does not require client authentication, you can cre-ate a new operator by doing the following steps:

1. Log in to the Administration Service as the root operator.


3. Click the Create New Operator button.

4. Fill in the Login Name and Password for the operator. Re-type the password in

the Confirm password field. Fill in the Operator Name field. Click Proceed. Notice that password requirements depend on password policy.

5. The operator is created and the Operator page opens. From there you can set

Access Control and Attributes for the operator. For more information on the meaning of the different access levels, see Insta Certifier Reference Guide.

6. Click Commit Changes when finished.



The new operator account is now ready to be used. Transfer the login name and password out-of-band to the person who will be using the account (for example, give it to the operator personally on a piece of paper). The operators should change the password the first time they log in.

Administration Service Uses TLS Protected HTTP with Client Authentication

When TLS protection with client authentication is used, the operator candidate has to enroll himself a TLS client certificate before the operator rights can be given to him. Before the enrollment, an operator entity needs to be generated by the root operator:


2. On the main menu, click Operators. Click the Create New Operator button.

3. Fill in the Login Name (Password is not required since private-key operations

are used to perform client authentication). Click Proceed.

4. The operator is created and the Operator page opens. Click Add near the Pre-shared keys. A new pre-shared key is generated. Write down the Key, and trans-fer it out-of-band to the person who will be using this operator account.

5. Set Access Control and Attributes for the operator. For more information on the meaning of the different access levels, see Insta Certifier Reference Guide.


Now the new operator should enroll a TLS client certificate from the relevant CA by using the enrolment pages of the Web Enrollment Service. For more information, see Insta Certifier PKI Client Guide.

Assuming that you are using the default Insta Certifier Internal CA with default policy (automatic issuance for valid server and operator entities), the request will be ap-proved automatically and the new operator will receive the TLS certificate.

However, in real-life situations it is recommendable to use a separate CA for issuing TLS certificates for operators. If the used CA has a manual policy process the request as instructed in Section 7.1.1 Approving Requests Manually.

After the certificate has been issued, the new operator is able to use TLS client au-thentication and use the new operator account.



Figure 4-14 Editing the operator information

4.5.2 Controlling Operator Access

To modify operator access:



3. Click View Operator on the operator you want to view.



4. Click Add to add Access Control items. Select an item and click Edit to edit an item. For more information on the meaning of the different access levels, see In-sta Certifier Reference Guide. If the operator does not have super-user rights to the system, it makes sense to also hide the super-user options from the GUI. The

UI Level can be set to Hide Super User Options.


4.5.3 Removing an Operator

To remove an operator:



3. Click View Operator on the operator you want to view.

4. Click Remove Operator to remove the operator from the system.

Be careful with this option, since removing an operator means that all the operator certificates are revoked and the shared keys belonging to the operator are deleted.

4.5.4 Operator password requirements

Operator password requirements (strength) can be modified on system parameters page. Policy is same for all operators (regardless of level). Modifiable parameters are minimum password length and character requirements (lower/upper case, numeric and special). Password minimum length will automatically change according to char-acter requirements (i.e if 2 characters of each type is required, password length will be automatically adjusted to at least 8 and no lower value is permitted).

Password change notice parameter defines when Certifier will notify operator for password change. When password “expires”, logging in to administration page will re-direct to operator page and notification will be displayed. Notice that password re-mains usable and mechanism doesn’t enforce the change.

Each operator has operator specific password history which will prevent using the same password again. History will keep last 20 passwords. Oldest password on the list will be removed when 21st password change is done. History will save passwords in SHA-512 format and it’s not visible through web interface.



Figure 4-15 Operator and master password policies

4.6 Dual Admin Control

Dual admin control (multi approval) is a feature, where two or more operators with superuser access are required to approve any changes made to Insta Certifier config-uration through the web-based admin interface. No changes can be committed before the required number of operators have approved the changes.

For the dual admin control to be effective, the host where Certifier Engine is running and where Certifier Database files are located must be secure. This is because by having access to the Certifier Database, a user can change the Insta Certifier configu-ration.

By default, dual admin control is disabled. Before activating the feature, make sure there are enough active operator accounts in the system. This is because adding a new operator under dual admin control requires approval from a specified number of operators before the new operator can be added (multi approval). Insta Certifier con-tains only one operator after the initial setup.

When dual admin control is in use, all add, modify, delete, and write operations except certain HSM-related operations require dual/multiple operator approval.

The fundamental concept in dual admin control is the change set. A change set con-tains one or more add, modify, or delete actions or operations. For example, when an operator modifies the CA policy of a CA and adds a new entity, these two actions form a new change set. Now the other operators, after successfully logging in to Insta Cer-tifier, can approve the changes that the first operator has done. This means the opera-tors can approve the change set. If any of the other operators does any other changes or operations then another change set is created, and this new change set must be approved by the other operators.



A change set can be committed after the required number of operators have approved the change set. After the change set is committed, the changes take effect.

Each change set can also be rejected.

Multi approval policy can be used for defining that specific operators must and can on-ly approve CA-specific change sets. This makes dual admin control usable also in en-vironments where Insta Certifier is hosted by a service provider and the Certifier oper-ators are only allowed to do CA-specific operations.

4.6.1 Setting Multi Approval in Use

To set multi approval in use:

1. On the main menu, click System Configuration. Click the Edit System Parameters option.

2. Select the Enable multi Approval check box.

3. Enter the Number of approvals needed before a change set can be committed.

4. If Require for services is selected, all system level operations (for example, new root CA creation, server and service configuration) require multi approval process.

5. Select the CA scope.

If all CAs require multi approval, select All CAs require multi approval. If only

some CAs require multi approval, select Multi approval for only selected CAs, select the CAs from the drop-down list, and click Add. Or select Multi approval for all except selected CAs, select the CAs that do not require multi

approval, and click Add.

6. Click the Commit button to take changes into use.



Figure 4-16 System parameters page



4.6.2 Approving Own Changes

When an operator makes changes requiring multi approval, an additional link for Cur-rent Change Set appears in the main menu. After the changes have been made, the operator must self-approve them.

To do this:

1. On the main menu, click Current Change Set. The Change Set page opens.

Alternatively, the page can be reached by clicking System Configuration on

the menu, then clicking the Pending Change Set List option, and finally clicking the correct change set.

2. Enter a Description for the change set (to help the other operators to review the change) and click Save next to the text box.

3. To approve the change set, click Approve. Before approving, you can review the changes by clicking the number next to the listed change.

The change set is now shown to be approved by one operator. See Figure 4-17.

Figure 4-17 First operator has approved the change set

4.6.3 Reviewing and Approving Changes Made by Other Operators

To review changes made by other operators:

1. On the main menu, click System Configuration. Click the Pending Change Set List option.

2. Click View next to the change set you want to view. An example of the Change Set List page is shown in Figure 4-18. In the example figure, change sets have already been approved by the operator who has created them (admin).



3. The added, changed, or deleted object can be reviewed by clicking the number

next to the listed change. After reviewing the object. Click Back to return to the

Change Set page.

4. Click Approve to approve the change set.

Figure 4-18 Viewing the change set

The change set has now been approved by two operators and can now be commited. See Figure 4-19 The change set has been approved by two operators.

To commit the change set, click Commit change set. After commiting, the changes take effect and the change set is removed from the pending change sets list.

Figure 4-19 The change set has been approved by two operators

4.7 Cross-Certification

In cross-certification, a CA issues a CA certificate for another entity. It can be a sub-CA certificate within a single PKI domain, or a certificate connecting two independent PKI domains. The certification can be either unilateral or bilateral.

In Section 4.7.1 Online Cross-Certification for Existing CA, unilateral cross-certification is performed between two Insta Certifier deployments. For the purposes of this example it is assumed that there is a remote Insta Certifier installation with a CA that allows automatic certificate issuing for valid entities and that an entity with a preshared key has been created beforehand for the CA to be cross-certified. Also,



there needs to be an External Enrollment Client Service on the local Certifier Server and a CMP Service on the remote Certifier Server.

In real life, cross-certification would most probably require manual issuing. This mode is also supported by Insta Certifier. The necessary steps are given in Section 4.7.2 Manual Cross-Certification for Existing CA.

4.7.1 Online Cross-Certification for Existing CA

Before the actual cross-certificate enrollment can be done, a CA certificate request needs to be generated for an existing CA within Insta Certifier. To create a CA certifi-cate request, do the following steps:


2. On the main menu, click CA Hierarchy.

3. Click the name of the CA that will be cross-certified.

4. Click View Certificate to view the CA certificate.

5. Click the Reissue Certificate... button. The Certificate Request page is dis-played. If necessary, change the subject name or other fields of the request and

click Update. Then continue directly from the side menu.

Now the CA certificate request can be found in the Certifier Database. The next step is to do the actual enrollment.

1. On the main menu, click System Configuration. The System Configuration Menu page opens.

2. Click Cross Certification.

3. Type in the search criteria for the newly generated CA certificate request and

click Search.

4. Select the correct request and click Commit. The Send Cross-Certificate Request page opens (Figure 4-20 Sending cross-certificate request).

5. Select the External Enroll Client Service from the corresponding list. This ser-vice is used to perform the client-side of the enrollment.

6. Type in the CMP Service connection URL in the CA Connection URL field. This is the location of the remote CA issuing the cross-certificate.

7. Click Refresh to see the list of available CAs in the remote Certifier installation, and choose the correct CA. This is the CA from which the cross-certificate is re-quested.

8. Fill in the reference number and key in the corresponding fields. These should have been provided by the issuing CA.

9. Click Proceed to perform the enrollment. Assuming the remote CA operates on an automatic policy, you will receive the new certificate and it is displayed on screen.



4.7.2 Manual Cross-Certification for Existing CA

CMP is used to perform the online cross-certification in the preceding example. How-ever, a typical crosscertification may involve third-party CA technology that does not support online cross-certification. If this is the case, instead of doing CMP, the PKCS#10 certificate request can be provided using alternative transport mechanisms.

Use View PKCS10 Request to view the request, and copy-paste it to a file.

Figure 4-20 Sending cross-certificate request

When doing manual cross-certification, you will need to give the issued cross-certificate to Insta Certifier manually:


2. Click Insert Certificate.

3. Give search criteria for the certification request and click Search. Select the orig-

inal request from the list and click Commit.

4. Copy-paste the issued CA certificate in the PEM Encoded Data field.

5. Click Proceed.

Finally, after receiving the certificate you will have to set the certificate in use.


2. Click the name of the cross-certified CA.

3. Click the Change Certificate button.

4. Search the certificate from the database and click Commit.



4.7.3 Manual Off-line Cross-Certification for a New CA

If you are creating a new sub-ordinate CA which will be signed by an off-line CA, you can create the keys and a certification request prior to creating the CA:


2. Click Create Certification Request.

3. Give the key generation parameters and proceed.

4. Give the request parameters like subject name and appropriate extensions and update the request.

5. Click Cross/Off-line certification request button and proceed as described above.

6. After getting the certificate from the off-line CA, create a new CA. Instead of cre-

ating new keys at the CA creation page, click Import certificate button.

4.8 Configuring an Offline Certification Authority

To enhance security, the root CA can be deployed offline. Together with strict physical security controls this makes the whole PKI very secure. It should be noted that if some online services, such as enrollment, are required, at least one Insta Certifier Engine instance hosting a subordinate CA should be available online to serve Insta Certifier Server instances. The subordinate CA certificate can be acquired from the offline root CA through PKCS#10 -based cross-certification as described in Section 4.7.2 Manual Cross-Certification for Existing CA.

An offline CA could be always running, but it is also possible to start Insta Certifier every time when, for example, there is a need to issue certificates for a new subordi-nate CA, or sign and publish a new CRL. If the latter alternative is used, one must al-ways first give the Insta Certifier master password and/or activate keys protected with HSM. The HSM protected keys might be protected using n out of m key splitting. In this case n persons out of m must be present to insert their smart cards in turn. For nCipher HSM, the key splitting can be used by starting Insta Certifier with the follow-ing command:

# with-nfast ssh-ca-start

See Insta Certifier Reference Guide for more information on using hardware security modules.

By using the above operational procedures, it can be made sure that the PKI opera-tions cannot be done by a single person alone.

As the offline root CA cannot publish certificate revocation lists (CRLs) directly online to the trusted directory, the publishing must be done manually. To enable this kind of publishing, Insta Certifier has support for an external publishing method. This method can be used to write the CRLs into a file that the root operator can later transfer in a floppy disk to the trusted directory. The external publishing method can also be used to execute scripts that publish the CRL by using an unidirectional connection. See Section 6.5 External Publishing.

Chapter 5: Setting up PKI Policies


Chapter 5

Setting up PKI Policies

This chapter gives instructions on defining policies for various PKI objects, especially CAs and RAs. The information is intended for the master administrator of the PKI.

Chapter 6: Configuring Publishing and OCSP


Chapter 6

Configuring Publishing and OCSP

This chapter gives instructions on configuring publishing and setting up the OCSP service.

6.1 LDAP Publishing

A public repository is needed in a PKI to store certificates and certificate revocation lists (CRLs), so that end entities can fetch them when constructing certification paths. In Insta Certifier, Lightweight Directory Access Protocol (LDAP) can be used to pub-lish certificates together with end entity information into a directory server. Also CA certificates and certificate revocation lists can be published in an LDAP directory.

The LDAP configuration of Insta Certifier consists of two parts, directory access infor-mation and directory schema information. The directory access information consists of the properties of a Publishing Service instance. The directory schema, on the other hand, is CA (or RA) -specific definition of the information that the CA or RA publishes in the directory.

6.1.1 Configuring a Publishing Service

The first step in LDAP configuring is to add a Publishing Service instance. Remember that the function of the Publishing Service is to perform LDAP publishing in the direc-tory. In order to perform this function, you have to give the required directory access parameters.

1. Log in to the Administration Service as an administrator.


3. Click View Server button of the Certifier Server instance you would like to use for the LDAP publishing.

4. Select Publishing Service from the drop-down list or click Edit for an existing Publishing Service instance.

5. Enter the following information:

A. A free description of the service (Service description).

B. The IP address or the host name of the directory server (Server Ad-dress), the port number of the LDAP server process (Port).

C. The LDAP Username and LDAP Password of a privileged directory ad-ministrator.



D. If needed, the server address that is going to be included in the CRL dis-

tribution point of the issued certificates (Server Address for URL

Generation).

E. If needed, the URL of the Socks server (Socks URL).

It is also possible to do the publishing through an external client, or to use TLS protection in publishing. See Insta Certifier Reference Guide for more infor-mation.

6. Click Continue to create the Publishing Service instance.


An example of the Publishing Service configuration is shown in Figure 6-3.

Figure 6-1 Publishing Service configuration

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



Remember that the directory administrator whose username and password is given, has to have required privileges to modify and add entries in the directory. You should

get all the LDAP specific parameters from your directory administrator. Server Address for URL Generation is needed only if the clients do not use the same ad-dress as Certifier for accessing LDAP. This field may be needed if, for example, the directory server machine has more than one network interfaces, and the one Publish-ing Service is using is different than the one end entities are using. In that case, the address seen by the end entities should be included in the CRL distribution point URL.

You can add multiple Publishing Service instances in the system to allow publishing into multiple directories. This may be required to achieve redundancy, or separate CAs in the same Insta Certifier installation may use different directory servers.

6.1.2 Certificate Publishing via LDAP

Certificate publishing requires that at least one Publishing Service instance exists. Once you have Publishing Service added, you can configure certificate publishing of a CA:



3. Click the name of the CA whose certificate publishing you want to configure.

4. Click Edit Publish next to Certificate Publish Methods in the CA display.

5. Choose LDAP in the Add New Method drop-down list, and click Add.

6. In the LDAP Server Connection drop-down list, choose the Publishing Service

instance created earlier, and click the Set button next to the Reset to Default box (LDAPv3 strongAuthenticationUser schema is selected).

7. Click Commit Changes to save the settings.

Error! Reference source not found. shows the Edit Certificate Publishing

ethod page with the default fields that were chosen above.



Figure 6-2 Default certificate publishing configuration (LDAPv3 strongAuthenticationUser sche-ma)

Object Name Format defines where in the directory tree certificates are published.

The default value, %{subject-name} means that the subject name of the certificate

is used as the directory path. In this configuration, all certificates that belong to the same logical domain should use uniform subject names, for example country (C), or-ganization (O), and organization unit (OU) fields being identical. This way a hierar-chical directory information tree is formed, and the ”leaves” of the tree contain the in-dividual certificates.

The LDAP Attributes determine which fields are included in the directory entry and what are the contents. The attributes form the so called directory schema, which al-ways has at least one object class and other attributes that have the information con-tent. In the default case, shown in Figure 6-2, standard PKIX directory schema is

used. It has an object class pkiUser, which has an attribute userCertificate.

The value of the attribute userCertificate is Encoded binary certificate, which

means the issued certificate itself is stored to this attribute. Also common name (cn)

attribute is included in the directory schema. The value is Single RDN from user

subject name and the selected RDN is CN. This means that the CN component of the user subject name in the certificate is stored in the directory attribute called cn.

However, normally we may want to include some other fields from the certificate in the

directory entry, and use other object classes than pkiUser. Additional directory at-

tributes can be added freely, however, it is important to check that the directory server supports the chosen attributes as well. Figure 6-3 shows a more complicated certifi-cate publishing configuration, which includes storing e-mail address of the certificate in the directory entry.



Now the Object Name Format is C=FI, O=Insta, CN=%{subject-name:CN},

which means that every certificate is published under sub-tree C=FI, O=Insta in the di-rectory server. The common name of the directory path is taken from the certificate subject name. Remember that this directory schema assumes uniqueness of the common name within the PKI.

The object class used in this example is inetOrgPerson. This object class has mul-

tiple optional attributes, of which userCertificate, email, and cn are used in this

example. The e-mail address of the subject alternative name is stored in the email

attribute.

You can add multiple Certificate Publishing Methods for a single CA to publish certifi-cates in multiple directories. To do this, you have to have multiple Publishing Service instances as well.

Figure 6-3 Publishing configuration example

6.1.3 CRL Publishing via LDAP

CRL publishing configuration is very similar to certificate publishing configuration, there are only a couple of additional parameters that need to be defined.

Again you need at least one Publishing Service instance. To configure CA to publish CRLs using an existing Publishing Service you have to:

1. Log in the Administration Service.




3. Click the name of the CA whose CRL publishing you want to configure.

4. Click Edit Publish next to CRL Publish Methods in the CA display.

5. Choose LDAP in the Add New Method drop-down list, and click Add.

6. In the LDAP Server Connection drop-down list, choose the Publishing Service

instance created earlier, and click the Set button next to the Reset to Default box (LDAPv3 strongAuthenticationUser schema is selected).


Figure 6-4 Default strongAuthenticationUser schema configuration shows the Edit CRL Publishing Methods page with the default fields that were chosen above.

Figure 6-4 Default strongAuthenticationUser schema configuration

Object Name Format defines where in the directory tree the CRLs are published.

The default value, %{subject-name} means that the CA subject name of the certifi-

cate is used as the directory path.



Similarly to certificate publishing, LDAP Attributes define the directory schema includ-ing at least one object class and other attributes. In the default pkiCa schema, the CA certificate is stored in the caCertificate attribute, CRL is stored in the certificateRevo-cationList attribute, and common name of the CA subject name in the cn attribute.

In some cases, because of the requirements of an existing directory deployment or because additional information is needed to publish in the directory, the LDAP attrib-utes need to be modified.

You can add multiple CRL publishing methods for a single CA. Since CRLs need to have high availability, there may be need to add redundancy by publishing them in several directories. Another way to achieve redundancy is to replicate the LDAP direc-tories.

6.2 Validation Authority with OCSP Responder

Online Certificate Status Protocol (OCSP) is an alternative method for providing revo-cation information in addition to the CRLs. Insta Certifier provides two services for sta-tus information via OCSP.

The OCSP Responder Service described in Section 6.3 (OCSP Responder) can be used when the server has no direct connection to the Certifier database. If the server is located so that a direct connection is possible, then a Validation Authority service can be used. The difference between these services is that the OCSP Responder al-ways asks the certificate status from the Certifier Engine while the Validation Authority maintains a local cache of certificate statuses and updates the cache directly from the Ceritifier database. The cache update is done every 30 seconds for changed statuses. The Validation Authority service can also be configured to cache OCSP responses themselves and even generate the responses before clients make any OCSP re-quests.

The Validation Authority has an own private key that it uses to sign the responses and a certificate that is signed by a CA. Because the OCSP response signing is the most time taking step in the OCSP request processing, using the Validation Authority in-stead of OCSP Responder service does not provide much performance advantage unless pre-generated responses are used. However, this makes the OCSP service more vulnerable for reply attacks since it is not possible to support request nonce in pre-generated responses.

The database connection from Certifier server host to the engine host must be ena-bled before creating the Validation Authority service. With Sybase database engine, this can be achieved by following instructions below.

6.2.1 Configuring database connection

Engine Host

1. Change database service executable from dbeng11 to dbsrv11 to allow network connections to the database engine. This can be done by either setting environ-

ment variable DBENG=dbsrv11 or by modifying the default DBENG variable in file

/usr/local/certifier/bin/ssh-ca-env.



2. Make sure that the firewall accepts TCP connections to port 2638 (default ODBC) from the server host.

Server Host

Fix the contents of /usr/local/certifsub/var/odbc.ini:

1. Add ”Links=tcpip(ip=<ip>)” where <ip> is the address of the engine host.

2. Login information from file at the engine host (odbc.ini). Default user ID is

DBA, password is random and must be checked from the mentioned file.

3. Remove DatabaseName line completely.

6.2.2 Creating the service

To create a new Validation Authority service:



3. Click the View Server button of the Certifier Server instance you would like to

use to provide the service. The Edit Server Entity page opens.

4. Select Validation Authority service from the drop-down list and click Add or

click Edit for an existing Validation Authority service instance.

5. Give a free description of the service (Service Description), the URL of the

OCSP responder server (Service bind address), the CA from which the Valida-

tion Authority certificate is enrolled (Validation CA), the key length of the Valida-tion Authority private key, and the requested validity period of the certificate.

6. Select the operation mode (Cache mode): Cache status only maintains only certificate status information and generates an OCSP response on each OCSP

request; Create pre-signed response on first request maintains a cache of

OCSP responses but does not pre-generate them before a first request. Fill with

pre-signed responses in advance generates pre-signed OCSP responses at startup. Note that using pre-signed responses has the drawback of missing the optional nonce from the responses which makes the OCSP more vulnerable to reply-attacks.

7. Select the CAs in Accessible CAs for which the Validation Authority service pro-vides status information.

8. Click Continue to create the service instance.


Figure 6-5 Validation Authority configuration shows the Validation Authority service configuration.



Figure 6-5 Validation Authority configuration

If the CA from which the Validation Authority certificate was requested operates on an automatic policy, the certificate is automatically created. If the issuing CA has manual policy, the certification request needs to be approved. To approve the Validation Au-thority certificate:

1. The request appears on the Edit Server Entity page, under Pending client requests. Click View Request on the Validation Authority certification request.

2. Check that the subject name and the validity period of the certificate are correct.

The request should contain the ekuOcspSigning extended key usage.



3. Click Accept to issue the certificate.

The next step is to take Validation Authority in use in the CA-side:


2. Click the name of the CA whose revocation information is provided by the Valida-tion Authority.

3. Click the Edit Publish button under CRL Publish Methods.

4. Select OCSP from the Add new method list, and click Add.

5. Select the new OCSP Responder Service in the OCSP Service connection list. If you wish to have the Authority Info Access extension (containing the URL of the

OCSP Responder) in the issued certificates, select the Include in Certificates

option. For this to work, the CA policy must contain the Add CRL Distribution

Point module (see Section 5.3 (Sample CA Policies)).

6. Click Commit Changes to take new settings in use.

Now the Validation Authority service is operational and will provide certificate status information on all the certificates issued by the CA. You have to provide the URL of the OCSP service for the end entities. You can also add Authority Info Access exten-

sion in the issued certificates by adding the Set CRL Distribution Point policy mod-ule in the CA policy. This way the HTTP URL of the OCSP responder will be embed-ded in the issued certificates and it does not need to be provided separately to end entities. In addition, the end entities using the OCSP responder need to trust the issu-ing CA.

6.3 OCSP Responder

Online Certificate Status Protocol (OCSP) is an alternative method for providing revo-cation information in addition to the CRLs. An OCSP Responder Service in Insta Cer-tifier can be used to provide certificate status information for OCSP clients. The OCSP Responder has an own private key that it uses to sign the responses and a certificate that is signed by a CA.

To create a new OCSP Responder Service:



3. Click the View Server button of the Certifier Server instance you would like to

use to provide OCSP Responder Service. The Edit Server Entity page opens.

4. Select OCSP Responder Service from the drop-down list and click Add or click

Edit for an existing OCSP Responder Service instance.

5. Give a free description of the service (Service Description), the URL of the

OCSP Responder server (Service bind address), the CA from which the OCSP

responder certificate is enrolled (Responder CA), the key length of the OCSP responder private key, and the requested validity period of the OCSP responder certificate.



6. Click Continue to create the OCSP Responder Service instance.


Figure 6-6 OCSP configuration shows the default OCSP Responder Service configu-ration.

Figure 6-6 OCSP configuration

If the CA from which the OCSP responder certificate was requested operates on an automatic policy, the OCSP responder certificate is automatically created. If the issu-ing CA has manual policy, the OCSP Responder certification request needs to be ap-proved. To approve the OCSP responder certificate:

1. The request appears on the Edit Server Entity page, under Pending client

requests. Click View Request on the OCSP responder certification request.

2. Check that the subject name and the validity period of the certificate are correct.

The request should contain the ekuOcspSigning extended key usage.

3. Click Accept to issue the OCSP responder certificate.

The next step is to take OCSP in use in the CA-side:


2. Click the name of the CA whose revocation information is provided by the OCSP responder.

3. Click the Edit Publish button under CRL Publish Methods.



4. Select OCSP from the Add new method list, and click Add.

5. Select the new OCSP Responder Service in the OCSP Service connection list.

If you wish to have the Authority Info Access extension (containing the URL of

the OCSP Responder) in the issued certificates, select the Include in Certificates option. For this to work, the CA policy must contain the Add CRL Distribution Point module (see Section 5.3 (Sample CA Policies)).


Now the OCSP Responder Service is operational and will provide certificate status in-formation on all the certificates issued by the CA. You have to provide the URL of the OCSP Responder Service for the end entities. You can also add Authority Info Access

extension in the issued certificates by adding the Set CRL Distribution Point policy module in the CA policy. This way the HTTP URL of the OCSP responder will be em-bedded in the issued certificates and it does not need to be provided separately to end entities. In addition, the end entities using the OCSP responder need to trust the issuing CA.

6.4 HTTP Publishing

A full-blown directory server deployment is not always required for the PKI. Especially if there is no need to publish certificates, it could be more convenient to use HTTP as the CRL publishing method. Also, LDAP is not supported by all end-entity applica-tions.

6.4.1 CRL Publishing via HTTP

When CRLs are published via HTTP, the Web Enrollment Service is required to store the CRL in the server behind an HTTP URL. Certificates can be configured to provide such URLs in the CRL Distribution Point extension linking to one of the Web Enroll-ment Service addresses. When a client accesses that URL to fetch a CRL, the Web Enrollment Service gets the CRL from the Certifier Engine, caches it for its validity pe-riod, and then returns it to client.

To enable CRL publishing via HTTP, the Web Enrollment Service must be configured to allow this:


2. Click the View Server button of the Certifier Server instance containing the Web Enrollment Service.

3. Click Edit near the Web Enrollment Service.

4. In the CRL Distribution section, enable the Distribute CRLs for all accessible CAs option. Also make sure that the CAs whose CRLs you want to publish via HTTP are selected in the Accessible CAs section. As the server address is usually not sufficient for external PKI clients to connect to the Enrollment Service, the URL prefix for CRL distribution points must be set to contain correct address and port information. For example, http://enroll.bigcorp.com:8080/ is a valid setting.

5. Click Continue.




To configure a CA to do HTTP CRL publishing, you have to do the following steps:


2. Click the name of the CA whose CRL publishing you want to configure.

3. Click Edit Publish next to CRL Distribution Points in the CA display.

4. Choose HTTP in the Add New Method drop-down list, and click Add.

5. Select the Web Enrollment Service that you would like to use for HTTP publishing from the Web Enrollment Service Connection list. If you wish to have the CRL Distribution Point extension in the issued certificates select the Include in Certifi-cates option. For this to work, the CA policy must contain the Add CRL Distribu-tion Point module (see Section 5.3 (Sample CA Policies)).


7. Type the CRL publishing period length in seconds in the Update Period field in the Certification Authority display.

8. Click Commit Changes to begin the periodic CRL publishing.

Figure 6-7 CRL publishing using HTTP method

6.5 External Publishing

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, select the Include in Certificates check box and write the URI to URL to add text box. Now all certificates issued will contain that URL provided that the CA policy has the Set CRL Distribution Point module added.

The external publishing method contains three action types:

Just add the CRL distribution point extension (CRL publishing only) can be used if just the distribution point extension is needed in certificates.

Write to file simply writes the object to a named file. The current working directory is the Certifier installation directory so it is usually a good idea to give absolute pathname for the file. File format controls the format of the file.

Run command executes an external command to handle the object. Also in this case it is advisable to provide an absolute path to the command. Apart from 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 exe-cutes the command line with special fields replaced with file names.

Figure 6.9 (External publishing) shows an example of external publishing configura-tion. The CRL is simply written to a local network directory.

Figure 6-8 CRL publishing using external method



6.6 Conditional Certificate Publishing

The conditional certificate publish feature allows the operator to specify criteria and policies that define which certificates are published based on the data in the certifi-cate.

All certificate objects in Insta Certifier contain a Publish certificate switch that can be used to control publishing of individual certificates. By default, the switch is selected, but in the request approval phase, or later, the operator can clear the switch.

When automatic request approval is in use, a special CA policy module (Set Meta In-fo: Publish) can be used to control the publication. When used alone, the module can be set to deny publishing for all certificates, but in actual use, the policy is best com-bined with the Conditional policy module.

An example of a conditional publishing policy is shown in Figure 6-9.

This policy sets the publishing switch only for those certificates whose subject name matches the given criteria.

For more information on CA policies, see Section 5.2 (Policy Modules and Policy Chains).

Figure 6-9 Conditional publishing

Chapter 7: Managing a PKI


Chapter 7

Managing a PKI

This chapter gives instructions on performing common everyday management tasks of the PKI service after it has been successfully set up. These tasks are done by the CA and RA operators and they include:

processing certification requests

managing end entities

revoking and suspending certificates

monitoring with SNMP

auditing

7.1 Processing Certification Requests

After the certification authorities have been created, and the directory services and the certification policies have been configured, the PKI is fully functional, and certificates for the end entities can be created and published. This section gives instructions on how to process the certification requests made by the end entities.

7.1.1 Approving Requests Manually

When a CA policy does not allow the certificate to be automatically generated, the op-erator has to manually approve the certification request.

The policy of the CA may, for example, rule that end entities have to personally prove their identities to the operator before the request can be approved. This is typically the case if shared secrets are not used for first-time authentication. Fingerprints (hash values) calculated on the request can be used to securely link the end entity to a re-quest. In this scheme, the end entity writes down the fingerprint after creating a PKCS#10 certification request. Before the request is sent to the CA, it is encrypted with the CA public key. Later, the fingerprint can be personally shown to the operator, and if it matches with the one found in the Insta Certifier Database, it proves that the end entity has generated the request.

In case the certificate policy requires manual approval, perform the following steps as an operator:


2. On the main menu, click Process Requests. A Search Results window showing the pending requests opens. You can search the pending requests further by typ-ing search criteria in the Re-search requests field and clicking Search.



3. Click View Request on the request you want to process. You can now manually edit or add certificate fields to the issued certificate.

4. Click Accept to create and publish the certificate.

When the certification request is approved, the certificate is issued, stored in the in-ternal Database and published to a Directory Server (if so configured). Also the ap-proval operation, including the operator login name, is stored in the Database to ena-ble audit trail of the certificates. If a request is denied, the same request cannot be approved later.

If there were several pending requests matching the search criteria, the next request is automatically opened for processing.

After the certificate has been issued, it can be found in the Certifier Database:

1. On the main menu, click Find Certificates. A Database Search window opens.

2. Type the common name of the certificate holder in the Text search. You can also select additional search criteria.

3. Click Proceed. A Search Results window showing the matching certificates opens.

4. Click View Certificate on the matching entry. The Certificate is displayed.

5. From this window you can view the log history of the certificate (View Log) or, for example Revoke the certificate.



Figure 7-1 Certificate request page

7.2 Managing End Entities

7.2.1 Adding an Entity for Automatic Enrollment

To enable automatic certificate issuance, operators can generate shared keys for au-thorized end entities. In case the certificate policy declares that certification requests with a valid pre-shared key can be approved automatically, the following steps are necessary before the enrollment.

To create an entry for an end entity and a shared key for it:


2. On the main menu, click Add New Entity. The Create New Entity window opens.

3. Fill in the information for the entity. Entity name is the common name of the enti-ty. Entity status should be set to Active. CA binding should be made for the ap-propriate CA. In addition you can fill in attributes for the entity. These will appear in the final certificate. To add an attribute, select the attribute from the list and click Add.

4. Click Create to create the entity. The Entity page is displayed.

5. On the Entity page, you can add and edit attributes, pre-shared keys, and policy modules for the entity. The entity will automatically have one pre-shared key. Click Commit changes when finished.



Figure 7-2 Entity page

Insta Certifier generates a random reference identifier (Key) which has to be trans-ferred securely to the end entity. The reference identifier can be changed by the oper-ator, if required. When using CMP, also a key identifier (Key ID) is required in addition to the key. When using SCEP, the pre-shared key contains only one string, the refer-ence identifier.



Figure 7-3 Pre-shared key (PSK)

You can edit the pre-shared key and set a use limit or policy attributes for it. On the Entity page, next to the Pre-shared keys field, click Edit. The Pre-Shared Key page opens.

By default, the shared secret can be used only once. You can set the use limit to a higher value manually. This allows for the entity to re-request an expired certificate.

7.2.2 Removing an Entity

If for some reason you wish to remove an entity from the system, do the following:

1. On the main menu, click Find Entity.

2. Fill in the relevant search criteria and click Proceed.

3. Click View Entity on the entity you wish to remove.

4. Click Remove Entity. A warning window is displayed.

5. Click Proceed to remove the entity.

Note that removing an entity will also remove any certificates and pre-shared keys the entity might have.

7.3 Revoking and Suspending Certificates

7.3.1 Revoking Certificates

If a key that still has validity time left is compromised, or the right to use it has to be removed for some other reason, the operator must revoke the certificate. After the revocation the serial number of the certificate will be included in the next issued CRL (it is immediately available for OCSP).



To revoke a certificate, do the following steps:


2. On the main menu, click Find Certificates.

3. Give the common name (or a part of it) of the subject name of the certificate and click Proceed.

4. Click the name of the certificate in the search results display.

5. Click Revoke to revoke the certificate.

6. You will asked for confirmation and an optional reason for the revocation. Click Revoke to proceed with the revocation.

The revocation information will be published when the next CRL is published. Howev-er, the next CRL can already be viewed by the operator by going through the following steps:


2. Click the relevant CA item.

3. Click View current CRL.

Mass Revocation

It is also possible to revoke several certificates at the same time. To do this:

1. On the main menu, click Find Certificates.

2. Give the search criteria for the certificates and click Proceed.

3. A list of matching certificates is displayed. On this list, select the boxes on the right side of the certificates you wish to revoke. Select the Revoke marked option from the drop-down list on the bottom right corner of the page. Click Make It So when finished. Alternatively, you can select to Revoke not marked certificates or Revoke all matching certificates (all certificates that matched the previously given search criteria).

4. A warning message listing the certificates to be revoked is displayed. Click Pro-ceed to revoke the certificates. Click Continue when prompted.

7.3.2 Suspending Certificates

While revocation is a final operation and cannot be reversed, suspended certificates can be reactivated. The serial number of the suspended certificate is included in the CRL, but it is removed after reactivation. The steps for suspension are similar to revo-cation. Instead of the Revoke option, select the Suspend option in the Certificate view in the administration GUI.

A suspended certificate can be reactivated by finding the certificate and clicking Reac-tivate in the Certificate view.



7.4 Monitoring with SNMP

Insta Certifier provides monitoring capabilities by SNMPv3. This requires SNMP man-agement software to be run on a host where SNMP traps are sent. The management software needs Insta Certifier SNMP MIB files to interpret the management infor-mation. The MIB files reside in lib/snmp-mibs folder under Insta Certifier installation di-rectory and can be copied to the management host.

Management information of Insta Certifier consists of traps sent at startup and shut-down, traps sent when certain types of errors occur, and also some statistics infor-mation that can be queried from SNMP agent running at the Insta Certifier engine host.

See document Certifier-NMS-guide.pdf for more details.

7.5 Auditing

In general auditing means the possibility to verify afterwards the changes made to In-sta Certifier configurations, which operator made the changes, and how Certifier was configured on a certain moment in the past. For example it might be required that the administrator must be able to verify what kind of policy a specific CA did have when the CA did issue a specific certificate for a certain user.

The need for auditing usually comes from regulations. For example certain quality cer-tificate statements require that the system which issues these quality certificates must be auditable.

All configuration changes through the web-based admin interface leave a visible trail that can be verified afterwards:

Add or delete entity or modify entity configuration

Add or delete CA or RA or modify CA or RA specific policy or configuration

Add or delete operator or modify operator specific configuration

Add or delete server or modify server configuration

An exception is that those changes that are manually made to certification requests by operators are not logged for audit purposes.

Operators can view the changes through the Certifier admin GUI. Several objects in the GUI contain a View Log button that can be used to view the audit log events relat-ed to the object.

Audit log events can also be searched by clicking View Log Entries on the main menu.

Each change is logged individually. If dual admin control is used, change sets are not logged as such. This means, for example, that when a change set that adds a new entity and changes CA policy is committed, the entity addition and CA policy changes are logged separately for audit purposes. For more information about change sets, please see Section 4.6 (Dual Admin Control).

When viewing committed CA change set, difference between change set and previous CA revision is shown. When viewing revision of system parameters, difference be-tween revision (currently viewed) and previous revision is shown.



7.5.1 Committed change set is logically same as revision, technically they are different (as uncommitted change set is not same as revision).Auditing Exam-ple

In the following example, changes made to CA policy are audited.

To search for audit log entries:

1. On the main menu, click View Log Entries.

2. Select the log entry type (in this case, CA data updated), and select the time pe-riod and other parameters for the search. See Figure 7-4.

3. Click Proceed to start the search.

Figure 7-4 Search log entries



The log entries matching to the search criteria are displayed. See Figure 7-5.

Figure 7-5 Search results

To view the object before a logged change, click the view original link next to a log en-try. Changes between revisions can be viewed by clicking the Prev and Next buttons. An example of CA settings is shown in Figure 7-6.

To view the CA policy, click the Edit Policy button. The original CA policy is shown. See Figure 7-7.

Figure 7-6 Auditing CA changes



To view the current policy, go to the current revision by clicking the Next button on the CA page, and click the Edit Policy button. The current CA policy is shown. See Figure 7-7.

Figure 7-7 Viewing changed policy

Chapter 8: Troubleshooting


Chapter 8

Troubleshooting

This chapter lists some possible problem situations with Insta Certifier and suggests corrections. For more troubleshooting information, see the Insta DefSec support web pages at http://www.certificate.fi/.

8.1 Problems with Starting Insta Certifier

? Insta Certifier has been unused for some days and it will not start when I try to get it up and running again.

When Insta Certifier is running, it will time-stamp the Database in regular intervals. When starting, the current time is compared to last time that the Database was used. If too large a discrepancy is found, ssh-ca-engine will not start. In this case the opera-tor can verify if this is an actual error (possibly a skewed system clock). If all seems to be in order, run the following command in the Insta Certifier installation directory to fix the time stamp in the Database to the current system time:

ssh-ca-tool –T

8.2 Problems with Certifier Services

? I have added a new Certifier Server via the Administration interface but I cannot get any Certifier Services on that Server to work.

You must also install the Certifier Server software on the computer. For instructions on how to do this, see Section 2.3.4 (Linux). It is not possible to install several Certifier Servers on one host, but each Certifier Server must be installed on different host ma-chine.

Note that you do not have to install new Certifier Servers to run several Certifier Ser-vices. Each Certifier Server can contain practically an unlimited number of Certifier Services, thus it is possible to create a whole PKI system with just one Certifier Serv-er. But in many cases, it is sensible to install extra Servers to maximize the security of the PKI system.



8.3 Problems when Connecting to the Web Services

? I cannot connect to the Administration Service or the Web Enrollment Service.

Check that cookies are enabled in your browser. Insta Certifier uses cookies to store a session ID.

? When connecting with Netscape Navigator to an Administration Service that uses TLS with client authentication, the browser occasionally crashes.

First check that you are using Netscape Communicator 4.61 or a later version. Next, you should try to select which operator client certificate the browser will use. This is a necessary action if you have enrolled several client certificates from the same CA, but it is a recommended action in all cases. Click the Security Information link in the bot-tom left-hand corner of the browser window. Then click Navigator, choose your opera-tor certificate manually from the list, and click OK.

? When connecting to the Administration Service or Web Enrollment Service, a warning message about ”problem in your time settings” is displayed.

Check that the client and the Certifier Server have the same time settings. Check also that the time zones are set the same. The tolerance for time settings is +/- 1 min in the Administration Service and +/- 5 min in the Web Enrollment Service.

8.4 Problems with Certificate Enrollment

? The certification requests generated by a SCEP client do not reach Certifier En-gine.

Check that you have configured the right URL for the Certifier Server running the SCEP Service in the client side, for example http://myca.certificate.fi/scep/. Also check that the CA’s name identifier given to the client matches with the name that is config-ured in the Certification Authority display in the administration GUI. If you are using shared keys, make sure that the shared key really matches with the one generated for the entity in the administration GUI, and the usage count has not reached the maxi-mum count of the key. Also, the CA policy has to allow requests to be accepted.

For an example of using SCEP, see Insta Certifier Interoperability Guide.

? When using ssh-cmpclient the enrollment fails and I do not receive the issued certificate from the CMP Service.

First you should check the parameters given to ssh-cmpclient. They are listed in Insta Certifier Reference Guide. In CMP, shared key information, consisting of Key and Key ID, is required. Check that those match with an existing Key-Key ID pair of an entity. Use the Find Entity menu item in the Administration GUI. The next step is to make sure that CA policy allows the issuance. If you have the issue-automatic policy module in the receive-request chain it does not matter whether you have chosen to issue all requests or only those with valid entity since using shared keys is mandatory in the CMP protocol.



? When using ssh-scepclient for enrollment I do not receive the issued certifi-cates, instead the enrollment state is stored in the enroll.state file. However, I want my CA to issue certificates automatically.

For some reason Certifier was unable to issue the certificate because of the applied CA policy. In SCEP the shared key is the Key field, Reference Number is not used in SCEP. Check that the key given to (if any) ssh-scepclient matches with the one con-figured in Insta Certifier. Also, there should be an issue-automatic policy module in the receive-request chain in the CA policy. The CA certificate given to the ssh-scepclient has to be of that same CA.

8.5 Problems with Request Processing

? For some reason I cannot view the certification request fields in the Administra-tion GUI. All the requests seem to contain empty fields. What is happening?

Your CA policy probably prevents you from viewing the requests. Check that the view-request policy module is not set to reject-all.

? A certificate is issued correctly, however, its validity period is shorter than was set by the operator or the CA policy.

A certification authority cannot issue certificates that have more validity remaining than the CA certificate itself. Check the validity period of the issuing CA certificate.

8.6 Problems with LDAP Publishing

? I cannot publish certificates in the Directory.

1. Test with an LDAP URL that you really have an LDAP access to the Directory. Try for example the address ldap://myldap/o=certificate.fi??sub? in the browser (assuming that there is the object o=certificate.fi on top of the directory tree). Do this with a browser which is located in the same machine as the LDAP client. If this is not feasible, you can get some level of assurance that the LDAP server is reachable by running:

telnet your ldap-server-host 389

If you can get connected, the problem probably lies in the publishing configurations of Insta Certifier.

2. Check that the subject name of your CA certificate is in the right order (for exam-ple, "C=UK, O=Organization, CN=MyCA"). Read Chapter 6 (Configuring LDAP Publishing and OCSP) carefully. For more information on the configuration syn-tax, consult Insta Certifier Reference Guide.

3. Check that the LDAP Username in the Publishing Service configuration is in the right order which is the reverse from the order used in certificates (for example, "CN=Manager,O=Organization,C=UK").



4. Check that you are publishing your objects to a valid path in the LDAP server. For example, if your LDAP tree starts at C=FI,O=Insta, and your issued certificates have subject names like C=FI,O=Insta,OU=Documentation,CN=Joe User, check that there is an organizationalUnit object in your LDAP tree at C=FI,O=Insta,OU=Documentation.

5. If you try to enforce the path where the certificates are published to with a more elaborate Object Name Format construct like O=MyCompany,OU=people,CN=%fsubject-name:CNg, the publishing will fail if your CA issues certificates which have no CN component in their subject names.

? My directory server is using LDAPv3 and I cannot get binary attributes such as certificates and CRLs published in the directory.

LDAPv3 server expects ”;binary” in the end of the attribute name when the attribute represents a binary object. So in the Attribute Name field of the Publishing Method page, instead of ”usercertificate”, write ”usercertificate;binary”, instead of ”cacertifi-cate”, write ”cacertificate;binary”, and instead of ”certificaterevocationlist”, write ”certif-icaterevocationlist;binary”, and so on.

? I get OBJECTCLASS-VIOLATION errors when publishing.

Possibly your LDAP directory does not know the object classes you have defined for your publishing configuration. For example, pkiUser and pkiCA object classes are not by default supported on some LDAP directories.

This means that LDAP is strict about required and allowed attributes in the published objects. Find and read the schema definitions for the object classes you use carefully, and compare your publishing settings against the sets of ALLOWED and REQUIRED attributes.

If you have run your LDAP server with the schema checks off, successfully published some CRLs or certificates with invalid attributes, and then fixed your publishing set-tings and set the schema checks back on, or if you have boldly modified you schema definitions in the directory, you may have to manually delete all (now invalid) objects you have published with earlier settings.

Make sure your published objects include at least one structural object class. For ex-ample, pkiUser is an auxiliary object class which cannot be the only object class an object belongs to.

? I get OPERATION-NOT-ALLOWED-ON-RDN errors when updating an object.

This usually means that in your publishing configuration some attribute which is part of the LDAP path (for example CN or O) has the update method set to Update by re-place instead of Update by add, which is not allowed by some LDAP directories.

? I have set up a TLS-enabled LDAP server, I have double-checked that the LDAP server TLS certificate is valid and issued by the trusted CA specified in the Pub-lishing Service Use TLS server authenticated LDAP connection. / Trusted root certificate setting, but I still fail to connect.

The LDAP server may use a different port for TLS-enabled LDAP communication, usually 636. If this is the case, the LDAP server probably wants to perform an LDAP



version 2 flavored TLS handshake for the LDAP connection. This is accomplished by setting the LDAP version to v2 in the Publishing Service configuration.

If the TLS-enabled LDAP port is different from the plain LDAP port, you might also want to check whether this is a firewall issue.

Check that the CN subject name component or the DNS subject alternative name in the LDAP server certificate is a full host name (for example, directory.certificate.fi, as opposed to directory).

Check that the host name you use as the LDAP server address in the Publishing Ser-vice configuration matches the name in the certificate. If you use a different alias or an IP address, the name does not match and Insta Certifier refuses to communicate any further with the server.

Certifier 5.2.3 AdministrationGuide

Documents

Transcript of Certifier 5.2.3 AdministrationGuide