Pki Appliance Operations Manual: Public Key Infrastructure by Primekey

PKI Appliance
Operations Manual
Public Key Infrastructure by PrimeKey
Ver: 2.7.2
2018-01-19
Copyright ©2018 PrimeKey Solutions
Published by PrimeKey Solutions AB
Lundagatan 16
171 63 Solna
Sweden
To report errors, please send a note to support@primekey.com
Notice of Rights
All rights reserved. No part of this book may be reproduced or transmitted in any form by any means,
electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the
publisher. For more information on getting permission for reprints and excerpts, contact sales@primekey.com
Notice of Liability
The information in this book is distributed on an “As Is” basis without warranty. While every precaution has
been taken in the preparation of the book, neither the authors nor PrimeKey shall have any liability to any
person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by
the instructions contained in the book or by computer software and hardware products described in it.
Trademarks
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as
trademarks. Where those designations appear in this book, and PrimeKey was aware of a trademark claim,
the designations appear as requested by the owner of the trademark. All other product names and services
identified throughout this book are used in editorial fashion only and for the benefit of such companies with
no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to
convey endorsement or other affiliation with this book.
Contents
I Preamble 1
1 Release Notes 2
2 Introduction 3
2.1 Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Styling Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2 Daily operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 PKI Appliance Overview 5

3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
II Advanced Installation 6
4 Using External CA for Installation 7

4.1 Smart Card Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Use-Case: Smart Card Installation in Firefox . . . . . . . . . . . . . . . . . . 10
Use-Case: Install the first PKI Appliance . . . . . . . . . . . . . . . . . . . . 13
Use-Case: Install a PKI Appliance with an existing Management CA . . . . . 21
III Appliance Operations 22
5 WebConf 23
Use-Case: Create a new TLS server side certificate for Application Interface . . . . 23
Use-Case: Upload a new trusted CA for TLS authentication and new super-
admin certificate for Management Interface . . . . . . . . . . . . . . 31
Use-Case: Configure a new trusted CA for TLS authentication and new su-
peradmin certificate for Application Interface . . . . . . . . . . . . . 35
6 Maintenance 38
6.1 PKI Appliance State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2 Reasons for Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3 Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7 Support Package 43
IV EJBCA GUI Operations 45
8 Certificate Life Cycle Management 46

8.1 Introduction to Certificate Life Cycle Management . . . . . . . . . . . . . . 46
8.1.1 Entity Issuance and Maintenance . . . . . . . . . . . . . . . . . . . . 46
8.1.2 Creation of Entity and Certificates . . . . . . . . . . . . . . . . . . . 46
8.1.3 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.1.4 Revocation, Re-issuance, Un-Revoke . . . . . . . . . . . . . . . . . . 47
8.1.5 Deletion of an End Entity . . . . . . . . . . . . . . . . . . . . . . . . 47
8.2 Certification Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.2.1 Types of Certification Authorities . . . . . . . . . . . . . . . . . . . . 48
9 Creating a CA Hierarchy 50
9.1 Use-Case: Creation of the RootCA . . . . . . . . . . . . . . . . . . . . . . . 51
Creating a Certificate Profile for the RootCA . . . . . . . . . . . . . . . . . . 51
Create Crypto Token for RootCA . . . . . . . . . . . . . . . . . . . . . . . . 53
Creating an RootCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.2 Use-Case: Create Certificate Profile for SubCAs . . . . . . . . . . . . . . . . 58
9.3 Use-Case: Create End Entity Profile for SubCAs . . . . . . . . . . . . . . . . 62
9.4 Use-Case: Import RootCA as External CA in node A . . . . . . . . . . . . . 64
9.5 Use-Case: Create SignCA as SubCA in node A . . . . . . . . . . . . . . . . . 66
Create Crypto Token for SignCA . . . . . . . . . . . . . . . . . . . . . . . . 66
Creating SignCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.6 Use-Case: Create AuthCA as SubCA in node A . . . . . . . . . . . . . . . . 74
Create Crypto Token for AuthCA . . . . . . . . . . . . . . . . . . . . . . . . 74
Creating AuthCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.7 Use-Case: Create SSLCA as SubCA in node A . . . . . . . . . . . . . . . . . 84
Create Crypto Token for SSLCA . . . . . . . . . . . . . . . . . . . . . . . . 84
Creating SSLCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
9.8 Use-Case: Create Certificate Profiles for End Entities that will use the SubCAs 94
Create Certificate Profile for End Entities that will use AuthCA . . . . . . . . 94
Create Certificate Profile for End Entities that will use SignCA . . . . . . . . 95
Create Certificate Profile for End Entities that will use SSLCA . . . . . . . . 97
9.9 Use-Case: Create End Entity Profiles for SubCAs . . . . . . . . . . . . . . . 99
Create End Entity Profile for AuthCA . . . . . . . . . . . . . . . . . . . . . 99
Create End Entity Profile for SignCA . . . . . . . . . . . . . . . . . . . . . . 100
Create End Entity Profile for SSLCA . . . . . . . . . . . . . . . . . . . . . . 103
9.10 Use-Case: Create End Entities that will use the SubCAs . . . . . . . . . . . . 105
Create an End Entity that will use SSLCA . . . . . . . . . . . . . . . . . . . 105
Create an End Entity that will use AuthCA . . . . . . . . . . . . . . . . . . . 107
Create an End Entity that will use SignCA . . . . . . . . . . . . . . . . . . . 109
10 Managing End Entities 111
10.1 Use-Case: Searching for end entities . . . . . . . . . . . . . . . . . . . . . . 111
10.2 Certificate Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
10.2.1 Use-Case: Revoking a Certificate using EJBCA . . . . . . . . . . . . 112
10.2.2 Use-Case: Re-issuing a Certificate using EJBCA . . . . . . . . . . . . 112
V VA Setup 113
11 Setting up a VA 114
11.1 Online Certificate Revocation Protocol . . . . . . . . . . . . . . . . . . . . . 114
11.2 CRL Distribution Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
11.3 VA setup scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
11.4 Use-Case: Install PKI Appliance as dedicated VA . . . . . . . . . . . . . . . 117
11.5 Use-Case: Create OCSP Keys in VA-Appliance . . . . . . . . . . . . . . . . . 132
11.6 Use-Case: Create OCSP Key Binding in VA and publisher in CA-Appliance . 133
11.7 Use-Case: Set up a VA-Appliance which fetches CRLs from external server . . 144
VI EJBCA Advanced Administration 148
12 Separation of privileges 149

12.1 EJBCA Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . 149
12.1.1 Managing EJBCA Roles . . . . . . . . . . . . . . . . . . . . . . . . . 149
Use-Case: Create an End Entity Certificate Profile for the Adminis-
trator CA . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Use-Case: Issue New Administrator Credentials . . . . . . . . . . . . 151
Use-Case: Create a CA Administrator Group . . . . . . . . . . . . . . 152
Use-Case: Adding New Administrators to the CA Administrator Group 152
Use-Case: Creating a New RA Administrator Group . . . . . . . . . . 153
Use-Case: Adding New Administrators to the RA Administrator Group 154
Use-Case: Creating a New Supervisor Group . . . . . . . . . . . . . . 154
Use-Case: Adding New Administrators To the Supervisor Group . . . 155
Use-Case: Adding New Administrators to the Super Administrator
Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Use-Case: Test the Different Administrators . . . . . . . . . . . . . . 156
12.1.2 CWA Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
13 Key Recovery 158

13.1 Profile Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Use-Case: Configure EJBCA for Recovery . . . . . . . . . . . . . . . . . . . 159
Use-Case: Configure Profiles to Enable Recovery . . . . . . . . . . . . . . . . 159
Use-Case: Add a User and Issue an Entity . . . . . . . . . . . . . . . . . . . 159
Use-Case: Recovering the Lost Entity . . . . . . . . . . . . . . . . . . . . . 160
14 Approval Process 162
Use-Case: Configure CA for Approvals . . . . . . . . . . . . . . . . . . . . . 162
Use-Case: Approve Issuing of the End Entity . . . . . . . . . . . . . . . . . . 163
Use-Case: Remove Approvals From CA . . . . . . . . . . . . . . . . . . . . . 164
15 Timed Services 165

15.1 CRL Updater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Use-Case: Configure a CRL Updater . . . . . . . . . . . . . . . . . . . . . . 165
15.2 HSM Keep Alive Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
15.3 Custom Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
16 Customising the Web GUI 167

16.1 Changing the language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Use-Case: Change the default language . . . . . . . . . . . . . . . . . . . . 167
16.2 Hiding Menu Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Use-Case: Access the public GUI without the menu options . . . . . . . . . . 168
17 Key Management 169

Use-Case: Create Crypto Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Use-Case: Create the CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Use-Case: Renew superadmin certificate . . . . . . . . . . . . . . . . . . . . . . . 170
18 Logging and Monitoring 175

18.1 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
18.1.1 Security Audit log vs System log . . . . . . . . . . . . . . . . . . . . 175
18.2 Monitoring and Health-Check . . . . . . . . . . . . . . . . . . . . . . . . . . 175
18.2.1 snmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
VII Appliance in High Availability Setup 180
19 HA Setup 181
19.1 Scope of availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
19.1.1 How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
19.1.2 Synchronization of key material . . . . . . . . . . . . . . . . . . . . . 181
19.1.2.1 Pre-cluster setup generation of keys . . . . . . . . . . . . . 181
19.1.2.2 Post-cluster setup generation of keys . . . . . . . . . . . . . 182
Use-Case: Synchronize key material . . . . . . . . . . . . . . . . . . . . . . 182
19.1.3 Network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
19.1.4 Cluster traffic security considerations . . . . . . . . . . . . . . . . . . 183
19.2 Continuous service availability . . . . . . . . . . . . . . . . . . . . . . . . . . 183
19.3 Levels of availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
19.3.1 Stand alone instance . . . . . . . . . . . . . . . . . . . . . . . . . . 183
19.3.2 Hot stand-by with manual fail-over . . . . . . . . . . . . . . . . . . . 183
19.3.3 High availability with automatic fail-over . . . . . . . . . . . . . . . . 184
19.4 High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Use-Case: Setting up a 2 node cluster from scratch . . . . . . . . . . . . . . 184
Use-Case: Setting up a 3 node cluster from scratch . . . . . . . . . . . . . . 185
Use-Case: Extending a cluster from n to n+1 nodes . . . . . . . . . . . . . . 185
19.5 Backup, Restore and Update . . . . . . . . . . . . . . . . . . . . . . . . . . 186
19.5.1 Backing up a cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
19.5.2 Restoring a cluster from backup . . . . . . . . . . . . . . . . . . . . 186
Use-Case: Restoring a cluster from a backup taken on node 1 . . . . 187
Use-Case: Restoring a cluster from a backup taken on node 2 or node
3, PKI Appliance firmware version 2.2.0 (or older) . . . . . 187
Use-Case: Restoring a cluster from a backup taken on node 2 or node
3, PKI Appliance firmware version 2.3.0 . . . . . . . . . . . 187
19.5.3 Updating the software (firmware/applications) on a cluster . . . . . . 188
Use-Case: Software update on a three node cluster from 2.2.0 to 2.3.0 188
19.6 Controlled full cluster shutdown and startup . . . . . . . . . . . . . . . . . . 189
19.6.1 Shutting down the cluster in controlled manner . . . . . . . . . . . . 189
19.6.2 Starting a fully shutdown cluster . . . . . . . . . . . . . . . . . . . . 189
19.7 Operational Caution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Use-Case: Changing the IP Address of the Application Interface of a
node in a three node cluster . . . . . . . . . . . . . . . . . 190
Replacing a failed cluster node . . . . . . . . . . . . . . . . . . . . . . . . . 191
20 PKCS#11 Slot Smart Card Activation 192

20.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
20.2 Installation/Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
20.2.1 "Number of users required" . . . . . . . . . . . . . . . . . . . . . . . 193
20.2.2 "Number/copies of user smart cards" . . . . . . . . . . . . . . . . . . 193
20.2.3 "Require smart cards to activate system after boot" . . . . . . . . . . 193
20.2.4 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
20.2.4.1 Example with default values . . . . . . . . . . . . . . . . . 194
20.2.4.2 Slots 0 and 1 . . . . . . . . . . . . . . . . . . . . . . . . . 194
20.3 Application/Activation of a slot . . . . . . . . . . . . . . . . . . . . . . . . . 194
20.3.1 Activation on boot/slot 0 . . . . . . . . . . . . . . . . . . . . . . . . 195
VIII SignServer GUI Operations 196
21 Managing Workers with Admin Web 197

21.1 Use-Case: Setting up a PDF Signer . . . . . . . . . . . . . . . . . . . . . . . 197
21.1.1 Adding a PDF Signer . . . . . . . . . . . . . . . . . . . . . . . . . . 197
21.1.2 Generate keys for PDF Signer . . . . . . . . . . . . . . . . . . . . . . 198
21.1.3 Create CSR for the Signer . . . . . . . . . . . . . . . . . . . . . . . . 199
21.1.4 Configure EJBCA for CSR signing from SignServer Workers . . . . . . 202
21.1.5 Install the certificates in SignServer . . . . . . . . . . . . . . . . . . . 207
21.2 Use-Case: Signing and verifying a PDF document . . . . . . . . . . . . . . . 207
21.2.1 Sign a PDF document using the PDF Signer . . . . . . . . . . . . . . 207
21.2.2 Verify the signed PDF with Adobe Reader . . . . . . . . . . . . . . . 208
21.3 Use-Case: Rekeying signers . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
21.3.1 Generate a new key . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
21.3.2 Create a certificate signing request . . . . . . . . . . . . . . . . . . . 214
21.3.3 Install the certificates . . . . . . . . . . . . . . . . . . . . . . . . . . 215
22 Managing Workers with Admin GUI 217

22.1 Use-Case: Setting up a PDF Signer . . . . . . . . . . . . . . . . . . . . . . . 217
22.1.1 Adding a PDF Signer . . . . . . . . . . . . . . . . . . . . . . . . . . 217
22.1.2 Generate keys for PDF Signer . . . . . . . . . . . . . . . . . . . . . . 219
22.1.3 Create CSR for the Signer . . . . . . . . . . . . . . . . . . . . . . . . 221
22.1.4 Configure EJBCA for CSR signing from SignServer Workers . . . . . . 223
22.1.5 Install the certificates in SignServer . . . . . . . . . . . . . . . . . . . 228
22.2 Use-Case: Signing and verifying a PDF document . . . . . . . . . . . . . . . 229
22.2.1 Sign a PDF document using the PDF Signer . . . . . . . . . . . . . . 229
22.2.2 Verify the signed PDF with Adobe Reader . . . . . . . . . . . . . . . 229
22.3 Use-Case: Rekeying signers . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
22.3.1 Generate a new key . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
22.3.2 Create a certificate signing request . . . . . . . . . . . . . . . . . . . 236
22.3.3 Install the certificates . . . . . . . . . . . . . . . . . . . . . . . . . . 236
PKI Appliance
Operations Manual – Public Key Infrastructure by PrimeKey
LIST OF FIGURES Ver: 2.7.2
List of Figures
4.1 Logical hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.2 Node A -Physical Infrastructure with online PKI Appliance . . . . . . . . . . 8
4.3 Node B - Physical Infrastructure with offline PKI Appliance . . . . . . . . . . 9
4.4 Security Devices in Firefox . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5 Device Manager in Firefox . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6 Load module in Firefox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.9 First login to the PKI Appliance . . . . . . . . . . . . . . . . . . . . . . . . 13
4.10 Notification for untrusted network . . . . . . . . . . . . . . . . . . . . . . . 13
4.11 Checking TLS fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.12 Confirm TLS fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.13 Provide OTP password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.14 Choose installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.15 Configure Network Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.16 Configure date and timezone . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.17 Configure Management CA . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.18 Pre-installation Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.19 Enroll process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.20 Provide smart card password . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.21 Key generation in the smart card . . . . . . . . . . . . . . . . . . . . . . . . 18
4.22 Successful enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.23 Authentication to the system . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.24 Confirmation of connection to the system . . . . . . . . . . . . . . . . . . . 19
4.25 EJBCA Public Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.26 WebConf Access tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.27 Management CA Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.28 EJBCA Administration in first PKI Appliance . . . . . . . . . . . . . . . . . 21
4.29 EJBCA Administration in first PKI Appliance . . . . . . . . . . . . . . . . . 21
5.1 EJBCA TLS check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2 EJBCA TLS check certificate . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3 EJBCA CN value for TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.4 WebConf Access tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9 (237)
PKI Appliance
5.5 WebConf Create CSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.6 WebConf Download CSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.7 EJBCA Search End Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.8 EJBCA Edit End Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.9 EJBCA Edit End Entity, cont. . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.10 EJBCA Create Certificate from CSR . . . . . . . . . . . . . . . . . . . . . . 28
5.11 EJBCA Enroll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.12 EJBCA Save certificate chain . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.13 WebConf: Activate certificate chain . . . . . . . . . . . . . . . . . . . . . . 30
5.14 WebConf: Upload certificate chain . . . . . . . . . . . . . . . . . . . . . . . 30
5.15 EJBCA login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.16 EJBCA TLS cert CN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.17 WebConf Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.18 WebConf Access add a new client certificate for TLS authorization . . . . . . 33
5.19 WebConf Upload the new trusted CA chain . . . . . . . . . . . . . . . . . . 34
5.20 WebConf TLS is updated . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.21 WebConf New configuration for Management Interface is in use . . . . . . . 35
5.22 Import new trusted CAs as External ones in EJBCA . . . . . . . . . . . . . . 36
5.23 Add a new trusted client certificate as superadmin in EJBCA . . . . . . . . . 36
5.24 Configure the serial number of the trusted certificate in EJBCA . . . . . . . . 37
9.1 Node B with RootCA installed . . . . . . . . . . . . . . . . . . . . . . . . . 50

9.2 Node A with SubCAs and ManagementCA installed. . . . . . . . . . . . . . . 51
9.3 Certificate Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
9.4 Clone a certificate profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.5 Certificate Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.6 Crypto Tokens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.7 Crypto Tokens settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.8 Key pair creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.9 Certification Authorities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.10 Create CA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
9.11 CA certificate data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
9.12 CA CRL data settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.13 Clone SUBCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.14 Create from template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.15 Edit Certificate Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.16 Edit Certificate Profile 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.19 Create End Entity profile for SUBCAs. . . . . . . . . . . . . . . . . . . . . . 62
9.20 Edit End Entity Profile for SubCAs. . . . . . . . . . . . . . . . . . . . . . . 63
9.21 Edit End Entity Profile for SubCAs 2. . . . . . . . . . . . . . . . . . . . . . 63
9.22 Fetch RootCA certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
10 (237)
PKI Appliance
9.23 Save RootCA pem file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

9.24 Import RootCA as External CA. . . . . . . . . . . . . . . . . . . . . . . . . 65
9.25 Crypto Token creation for SignCA. . . . . . . . . . . . . . . . . . . . . . . . 67
9.26 Create keys for SignCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.27 Create SignCA in Certification Authorities. . . . . . . . . . . . . . . . . . . . 68
9.28 SignCA settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.29 SignCA will be signed by ’External CA’. . . . . . . . . . . . . . . . . . . . . 69
9.30 CA CRL data settings for SignCA. . . . . . . . . . . . . . . . . . . . . . . . 69
9.31 Create CSR for SignCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
9.32 Generation of CSR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
9.33 Create an End Entity for SignCA in the PKI Appliance where RootCA is
installed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.34 Sign CSR request for SignCA. . . . . . . . . . . . . . . . . . . . . . . . . . . 72
9.35 Download signed .pem for SignCA. . . . . . . . . . . . . . . . . . . . . . . . 72
9.36 Upload signed CSR for SignCA. . . . . . . . . . . . . . . . . . . . . . . . . . 73
9.37 Activated SignCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9.38 Crypto Token creation for AuthCA. . . . . . . . . . . . . . . . . . . . . . . . 75
9.39 Create keys for AuthCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.40 Create AuthCA in Certification Authorities. . . . . . . . . . . . . . . . . . . 76
9.41 AuthCA settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.42 AuthCA Signed by ’External CA’. . . . . . . . . . . . . . . . . . . . . . . . . 77
9.43 CA CRL data settings for AuthCA. . . . . . . . . . . . . . . . . . . . . . . . 77
9.44 Create CSR for AuthCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
9.46 Certification Authorities status. . . . . . . . . . . . . . . . . . . . . . . . . . 79
9.47 Create an End Entity for AuthCA in the PKI Appliance where RootCA is
installed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
9.48 Sign CSR request for AuthCA. . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.49 Download signed .pem for AuthCA. . . . . . . . . . . . . . . . . . . . . . . . 81
9.50 Edit AuthCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
9.51 Upload signed CSR for AuthCA. . . . . . . . . . . . . . . . . . . . . . . . . 82
9.52 Activated AuthCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9.53 Crypto Token creation for SSLCA. . . . . . . . . . . . . . . . . . . . . . . . 85
9.54 Create keys for SSLCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
9.55 Create SSLCA in Certification Authorities. . . . . . . . . . . . . . . . . . . . 86
9.56 SSLCA settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
9.57 SSLCA Signed by ’External CA’. . . . . . . . . . . . . . . . . . . . . . . . . 87
9.58 CA CRL data settings for SSLCA. . . . . . . . . . . . . . . . . . . . . . . . 88
9.59 Create CSR for SSLCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
9.61 Create an End Entity for SSLCA in the PKI Appliance where RootCA is installed. 90
9.62 Sign CSR request for SSLCA. . . . . . . . . . . . . . . . . . . . . . . . . . . 91
9.63 Download signed .pem for SSLCA. . . . . . . . . . . . . . . . . . . . . . . . 91
11 (237)
PKI Appliance
9.64 Edit SSLCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

9.65 Upload signed CSR for SSLCA. . . . . . . . . . . . . . . . . . . . . . . . . . 92
9.66 Activated SSLCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.67 Create Certificate Profile for AuthCA. . . . . . . . . . . . . . . . . . . . . . 94
9.68 Certificate Profile Settings for AuthCA. . . . . . . . . . . . . . . . . . . . . . 95
9.69 Certificate Profile Settings for AuthCA 2. . . . . . . . . . . . . . . . . . . . 95
9.70 Create Certificate Profile for SignCA. . . . . . . . . . . . . . . . . . . . . . . 96
9.71 Certificate Profile Settings for SignCA. . . . . . . . . . . . . . . . . . . . . . 96
9.72 Certificate Profile X.509 extensions Settings for SignCA. . . . . . . . . . . . 97
9.73 Certificate Profile Settings for SignCA cont. . . . . . . . . . . . . . . . . . . 97
9.74 Clone Certificate Profile for SSLCA. . . . . . . . . . . . . . . . . . . . . . . 98
9.75 Certificate Profile Settings for SSLCA. . . . . . . . . . . . . . . . . . . . . . 98
9.76 Certificate Profile X.509 extensions Settings for SSLCA. . . . . . . . . . . . . 98
9.77 Create End Entity Profile for AuthCA. . . . . . . . . . . . . . . . . . . . . . 99
9.78 Subject DN Attributes for AuthCA End Entity Profile. . . . . . . . . . . . . . 100
9.79 Main certificate data for AuthCA End Entity Profile. . . . . . . . . . . . . . 100
9.80 Create End Entity Profile for SignCA. . . . . . . . . . . . . . . . . . . . . . 101
9.81 Subject DN Attributes for SignCA End Entity Profile. . . . . . . . . . . . . . 102
9.82 Main certificate data for SignCA End Entity Profile. . . . . . . . . . . . . . . 102
9.83 Clone End Entity Profile for SSLCA. . . . . . . . . . . . . . . . . . . . . . . 103
9.84 Subject DN Attributes for SSLCA End Entity Profile. . . . . . . . . . . . . . 104
9.85 Main certificate data for SSLCA End Entity Profile. . . . . . . . . . . . . . . 104
9.86 Create End Entity for SSLCA. . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.87 Keystore Enrollment for testsrv.course. . . . . . . . . . . . . . . . . . . . . . 106
9.88 Enrollment for testsrv.course. . . . . . . . . . . . . . . . . . . . . . . . . . . 107
9.89 Save testsrv.course.p12 file. . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
9.90 Create End Entity for AuthCA. . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.91 Browser Certificate for Auth_User_1. . . . . . . . . . . . . . . . . . . . . . 109
11.1 Peer Connector CA-VA setup. . . . . . . . . . . . . . . . . . . . . . . . . . . 115

11.2 VA setup for CRL Downloader service. . . . . . . . . . . . . . . . . . . . . . 116
11.3 Rename ManagementCA to PeerMgmtCA. . . . . . . . . . . . . . . . . . . . 117
11.4 Fetch PeerMgmtCA certificate . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.5 Download PeerMgmtCA certificate . . . . . . . . . . . . . . . . . . . . . . . 119
11.6 VA network settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.7 Install VA with existing ManagementCA . . . . . . . . . . . . . . . . . . . . 120
11.8 Upload external CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.9 Copy issuer value from VA-WebConf . . . . . . . . . . . . . . . . . . . . . . 121
11.10Create End Entity in CA-Appliance for VA TLS connections . . . . . . . . . . 122
11.11Create End Entity in CA-Appliance for VA TLS connections cont. . . . . . . 122
11.12Create CSR for Application Interface in VA . . . . . . . . . . . . . . . . . . 123
11.13Download CSR for Application Interface in VA . . . . . . . . . . . . . . . . . 123
11.14Create certificate in CA for VA Application Interface from CSR . . . . . . . . 124
12 (237)
PKI Appliance
11.15Sign certificate for VA Application Interface from CSR . . . . . . . . . . . . 124

11.16Download signed certificate for VA Application Interface . . . . . . . . . . . 125
11.17Activate new certificate for VA Application Interface . . . . . . . . . . . . . . 125
11.18Updating Application Interface access in VA . . . . . . . . . . . . . . . . . . 125
11.19Rename ManagementCA to PeerMgmtCA in VA . . . . . . . . . . . . . . . . 126
11.20Configure connections in VA . . . . . . . . . . . . . . . . . . . . . . . . . . 126
11.21Configure connections in CA . . . . . . . . . . . . . . . . . . . . . . . . . . 127
11.22Create a Peer Connector in CA . . . . . . . . . . . . . . . . . . . . . . . . . 127
11.23Ping to test the connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.24Peer systems request in VA . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.25Authorize connection request from CA . . . . . . . . . . . . . . . . . . . . . 129
11.26Create a new role for incoming request . . . . . . . . . . . . . . . . . . . . . 129
11.27Modify Authorization for incoming connections in VA . . . . . . . . . . . . . 130
11.28Manage peer connector in CA . . . . . . . . . . . . . . . . . . . . . . . . . . 130
11.29Manage Peer Connector in CA . . . . . . . . . . . . . . . . . . . . . . . . . 131
11.30Check status of deta synchronization in CA . . . . . . . . . . . . . . . . . . 131
11.31Crypto Token for OCSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
11.32Create new OCSP key binding. . . . . . . . . . . . . . . . . . . . . . . . . . 133
11.33Configure OCSP Key Binding. . . . . . . . . . . . . . . . . . . . . . . . . . 134
11.34Created OCSP key binding. . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
11.35Download the CSR for OCSP key binding. . . . . . . . . . . . . . . . . . . . 135
11.36Edit OCSPEndEntityProfile. . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
11.37Edit OCSPEndEntityProfile cont. . . . . . . . . . . . . . . . . . . . . . . . . 136
11.38Edit OCSPEndEntityProfile cont. . . . . . . . . . . . . . . . . . . . . . . . . 137
11.39Add OCSP End Entity in CA-Appliance. . . . . . . . . . . . . . . . . . . . . 138
11.40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
11.41OCSP CSR is signed successfully. . . . . . . . . . . . . . . . . . . . . . . . . 139
11.42Upload the signed OCSP CSR in VA. . . . . . . . . . . . . . . . . . . . . . . 139
11.43Enable OCSP key binding. . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
11.44Set default responder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
11.45Add a publisher in the CA-Appliance. . . . . . . . . . . . . . . . . . . . . . . 141
11.46Configure the publisher in CA-Appliance. . . . . . . . . . . . . . . . . . . . . 142
11.47Import external CA in VA-Appliance. . . . . . . . . . . . . . . . . . . . . . . 144
11.48Configure the CDP of the CA. . . . . . . . . . . . . . . . . . . . . . . . . . 145
11.49Add CRL Downloader service. . . . . . . . . . . . . . . . . . . . . . . . . . . 145
11.50Configure CRL Downloader service. . . . . . . . . . . . . . . . . . . . . . . . 146
17.1 EJBCA Search End Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

17.2 EJBCA superadmin certificate . . . . . . . . . . . . . . . . . . . . . . . . . 171
17.3 EJBCA Certificate enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . 173
17.4 EJBCA Choose certificate to authenticate . . . . . . . . . . . . . . . . . . . 173
17.5 EJBCA Renewed superadmin certificate . . . . . . . . . . . . . . . . . . . . 174
21.1 Add new worker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
13 (237)
PKI Appliance
21.2 Generate key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

21.3 Configure key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
21.4 Generate key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
21.5 Provide CSR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
21.6 Save CSR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
21.7 Manage Certificate Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
21.8 Clone EndUser certificate profile. . . . . . . . . . . . . . . . . . . . . . . . . 202
21.9 Edit SignerCertificateProfile. . . . . . . . . . . . . . . . . . . . . . . . . . . 203
21.10Provide CRL distribution point. . . . . . . . . . . . . . . . . . . . . . . . . . 203
21.11Create SignerEndEntityProfile. . . . . . . . . . . . . . . . . . . . . . . . . . 204
21.12Add end entity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
21.13Sign CSR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
21.14CSR created. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
21.15Add certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
21.16Sign PDF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
21.17Fetch RootCA certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
21.18Adobe Reader Preferences. . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
21.19Import trusted certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
21.20Browse for the trusted certificate. . . . . . . . . . . . . . . . . . . . . . . . . 210
21.21Edit trust of the certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
21.22Enable trust options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
21.23Validate signature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
21.24Signature details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
21.25Revocation details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
21.26Generate key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
21.27Provide CSR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
21.28Choose certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
22.1 Add new worker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

22.2 Choose property file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
22.3 Apply Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
22.4 Generate key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
22.5 Configure key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
22.6 Generate key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
22.7 Provide CSR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
22.8 Save CSR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
22.9 Manage Certificate Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
22.10Clone EndUser certificate profile. . . . . . . . . . . . . . . . . . . . . . . . . 223
22.11Edit SignerCertificateProfile. . . . . . . . . . . . . . . . . . . . . . . . . . . 224
22.12Provide CRL distribution point. . . . . . . . . . . . . . . . . . . . . . . . . . 224
22.13Create SignerEndEntityProfile. . . . . . . . . . . . . . . . . . . . . . . . . . 225
22.14Add end entity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
22.15Sign CSR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
14 (237)
PKI Appliance
22.16CSR created. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

22.17Certificate installed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
22.18Worker is active. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
22.19Sign PDF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
22.20Fetch RootCA certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
22.21Adobe Reader Preferences. . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
22.22Import trusted certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
22.23Browse for the trusted certificate. . . . . . . . . . . . . . . . . . . . . . . . . 231
22.24Edit trust of the certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
22.25Enable trust options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
22.26Validate signature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
22.27Signature details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
22.28Revocation details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
22.29Generate key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
22.30Provide CSR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
22.31Choose certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
15 (237)
PKI Appliance
Ver: 2.7.2
Part I
Preamble
1 (237)
PKI Appliance
1. RELEASE NOTES Ver: 2.7.2
Chapter 1
Release Notes
PKI Appliance 2.7.2 Release Notes
This is a maintenance release to 2.7.1 which mainly brings new versions of EJBCA
and SignServer to the PKI Appliance.
With the new EJBCA version custom certificate extensions for CV certificates are
available. There are also improvements on CT logs.
SignServer comes with support for one click certificate renewals from within
EJBCA.
New Features:
* EJBCA Enterprise 6.10.1.2 - Please check out EJBCA release notes for more
detailed information
* SignServer 4.2.0 - Please check out SignServer release notes for more details
Minor tweaks and bug fixes:

* TimeMonitor was not active after restoring from an old backup (<= 2.5.1)
* In some cases of improper shutdown some configuration was lost. This is fixed
now.
* 2-node cluster setup now possible without errors on restore from old versions
* Improved error reporting for Jboss
Known Issues and Limitations:

* Setting up a peer connector fails when DHE is selected
2 (237)
PKI Appliance
2. INTRODUCTION Ver: 2.7.2
Chapter 2
Introduction
This manual provides an in depth understanding of the public key infrastructure (PKI) prod-
ucts and services provided by PrimeKey and is intended to serve as a guide to understanding
and implementing PKI as a product and service within the PKI Appliance.
2.1 Audience
This guide is intended for use by Information Technology (IT) professionals with an interest
in implementing the PKI products provided by PrimeKey in their environment using the
PKI Appliance. The guide is presented in a structured manner so that it begins with an
introduction to the subject and progressively moves into more deeper technical topics. This
allows the guide to be useful for a wide variety of personnel from managers to integrators.
The lowest common denominator between the various groups of audiences is the shared
interest in implementing PKI using PrimeKey products.
2.1.1 Styling Conventions

The following items explain the styling conventions that are used throughout this document,
together with an example below each description:
• Buttons on the GUI are represented like Create .
• Options from popup menus or values that can be choosen like RSA 2048
• Links in the GUI that need to be selected/clicked upon are displayed in blue like:
Search End Entities.
• Values that has to provided in text fields are presented as: a new value.
• Group titles or GUI text that is not selectable is represented as: RA Functions.
• Informative messages provide additional explanation of the steps being performed, or
the configuration being applied. For example:
3 (237)
PKI Appliance
2. INTRODUCTION Ver: 2.7.2
i This is an informative message containing extra information.
• Warning messages are used to draw the attention to a critical or sensitive step that
has to be performed, or to critical piece of information that has to be provided. For
example:
! This is a warning message.
• Shell listings are used to specify commands that should be run on a server in a terminal,
by a specific operating system user. For example:
Run as user
df -h
2.1.2 Daily operations

Exercises are indicated by the "Use-Case" prefix as illustrated below. Exercises provide a step
by step approach to perform an activity and require the practical environment:
Use-Case: Install PKI Appliance

While following the exercises outlined in this document, the following guidelines apply:
i Unless the instructions explicitly state so, do not deviate from the instruc-
tion order. All steps should be performed in the sequence that they are
outlined in. Do not jump back and forth between different exercises, unless
the instructions explicitly state so.
4 (237)
PKI Appliance
3. PKI APPLIANCE OVERVIEW Ver: 2.7.2
Chapter 3
PKI Appliance Overview
3.1 Description
EJBCA Enterprise Appliance is a PKI-in-a-box and combines the flexibility, reliability and
feature set of EJBCA Enterprise software, with a secure technology stack and enterprise-
grade hardware including a FIPS 140-2 Level 3 certified HSM. Through the combination of
built in CA, RA and VA functionality and a variety of interfaces like OCSP, CMP, SCEP and
WebServices, EJBCA Enterprise Appliance provides a unique turn-key PKI solution.
EJBCA Enterprise Appliance is based on an unified and controlled technology stack which
reduces technical risks for the entire PKI project and reduces patch management efforts
during operation. Simplified management and maintenance workflows lower the setup time
and operational costs and reduce the TCO.
High flexibility, performance, support for high-availability and load-balancing make the EJBCA
Enterprise Appliance suitable for critical infrastructure setups within commercial and gov-
ernmental organization of all sizes.
As of version 2.4.0 the EJBCA Enterprise Appliance (or PKI Appliance) exists in three
different product sizes, designated as S, M or L. Previous unlabeled versions are equivalent
to the M size. While the L version takes advantage of recently available bigger hard disks
to provide for more database space, the S version is a highly reduced version with smaller
database size and also a reduced speed HSM.
5 (237)
PKI Appliance
Ver: 2.7.2
Part II
Advanced Installation
6 (237)
PKI Appliance
4. USING EXTERNAL CA FOR INSTALLATION Ver: 2.7.2
Chapter 4
Using External CA for Installation
In this chapter we will implement the scenario where two different PKI Appliances will be
installed using the same ManagementCA certificate which is installed in a Smart Card.
Following instructions will guide the administrator to:
• configure MARX CrypToken smart card with Firefox,
• install first PKI Appliance and install the SuperAdmin certificate in the smart card,
• install the second PKI Appliance by using an ExternalCA certificate.
i General installation instructions can be found in ??.
The use-case is that we have ManagementCA to be the super-administrator for operat-

ing both PKI Appliances (node A, node B) and a logical hierarchy with ROOTCA as a the
root certification authority which signs 3 different subCAs (SignCA, AuthCA and SSLCA
see figure 4.1).
7 (237)
PKI Appliance
Figure 4.1: Logical hierarchy
Due to the fact and that in many cases ROOTCA is required to be offline, physical
infrastructure differs than logical hierarchy. In one PKI Appliance (node A), we install
ManagementCA together with the 3 subCAs (see figure 4.2).
Figure 4.2: Node A -Physical Infrastructure with online PKI Appliance
The second box will host the ROOTCA which will be offline as soon it will the sign
SubCAs (see figure 4.3).
8 (237)
PKI Appliance
Figure 4.3: Node B - Physical Infrastructure with offline PKI Appliance
9 (237)
PKI Appliance
4.1 Smart Card Setup

smart card we use to install the superadmin certificate via Firefox, is "MARX CrypToken"
from SafeSign. The operating system is Ubuntu 14.04 and the drivers used for the smart
card SafeSignIdentityClient-3.0-33.amd64.deb.
i The same process that is described here can be done in analogous ways
with smart cards from different branches.
Use-Case: Smart Card Installation in Firefox

In Firefox open Preferences, navigate to Advanced tab and press Security Devices (see
fig. 4.4)
Figure 4.4: Security Devices in Firefox
10 (237)
PKI Appliance
A list of Security Modules and Devices are listed in this window. Through Load we
can define a new Security Device (see fig. 4.5).
Figure 4.5: Device Manager in Firefox
Module Name and Module filename has to be provided. In Module filename we

have to point to the library that our smart card is using (see fig. 4.6).
Figure 4.6: Load module in Firefox
11 (237)
PKI Appliance
The new device is now listed in the Device Manager window. At that point we will be
able to login to the device via Log In and providing the password which is used to lock
the smart card (see fig. 4.7).
As soon as the login process is successful, we have configured smart card with Firefox
correctly (see fig. 4.8).
12 (237)
PKI Appliance
Use-Case: Install the first PKI Appliance

1. Provide the IP_ADDRESS in Firefox with which you have configured the PKI Appliance
through the display. The message that shows in the browser is that this connection is
untrusted (see fig. 4.9).
Figure 4.9: First login to the PKI Appliance
2. To check if we can trust this connection we have to compare if TLS fingerprint is the
same with the one that shows in the PKI Appliance display. Just press Add Exception...
and on the next window View... (see fig. 4.10 and 4.11)
Figure 4.10: Notification for untrusted network
13 (237)
PKI Appliance
3. Under Fingerprints group is located SHA1 Fingerprint. The first values has to match
with the one that is displayed in the PKI Appliance front display.
Figure 4.11: Checking TLS fingerprint
4. After we have confirmed that we trust the TLS certificate for the connection, we can
continue with the installation process by The fingerprints are the same as shown
in fig. 4.12
i Through TLS fingerprint, the PKI Appliance is authenticated to us
Figure 4.12: Confirm TLS fingerprint
14 (237)
PKI Appliance
5. Text field that shows up is the Authentication code: under Authenticate section.
Here we have to provide the OTP (One Time Password) which is shown in the PKI
Appliance display (see fig. 4.13).
i This way user authenticates himself to the box.
Figure 4.13: Provide OTP password
6. Figures from 4.14 up to 4.18 show the settings which have to be configured before the
installation process begins.
i For detailed description of the settings refer to ??
Figure 4.14: Choose installation
Figure 4.15: Configure Network Settings
15 (237)
PKI Appliance
Figure 4.16: Configure date and timezone
Figure 4.17: Configure Management CA
Figure 4.18: Pre-installation Summary
16 (237)
PKI Appliance
7. When the installation comes to its end, user will be prompt to Get superadmin certificate
before he can finalize the process. By pressing Enroll a pop-up window will let us
to choose which security device will be use for enrollment (see fig. 4.19).
Figure 4.19: Enroll process
8. Next figures show the prompt for smart card key (4.20), the key generation (4.21) and
confirmation that enrollment is complete (4.22).
Figure 4.20: Provide smart card password
17 (237)
PKI Appliance
Figure 4.21: Key generation in the smart card
Figure 4.22: Successful enrollment
9. Now that the SuperAdmin certificate is installed in the smart card we can finalize the
installation.
10. When we will try to login to the PKI Appliance or EJBCA’s Public Pages we will be
prompted to choose a certificate to authenticate to the system (see fig. 4.23)
Figure 4.23: Authentication to the system
18 (237)
PKI Appliance
11. As in the first time we will have to confirm the connection (see fig. 4.9) and confirm
the exception with Confirm Security Exception (see fig. 4.24)
Figure 4.24: Confirmation of connection to the system
12. Navigate to IP_ADDRESS_application/ejbca in EJBCA’s Public Pages and under Re-

trieve section and Fetch CA Certificates link get the certificate of ManagementCA
(see fig. 4.25). The certificate can be downloaded via Download as PEM.
Figure 4.25: EJBCA Public Pages
19 (237)
PKI Appliance
13. Navigate to IP_ADDRESS in WebConf and under ACCESS tab copy the clientcert value.
It will be used as information to install the next PKI Appliance as shown in fig. 4.26
Figure 4.26: WebConf Access tab
20 (237)
PKI Appliance
Use-Case: Install a PKI Appliance with an existing Management CA

1. In order to install the next PKI Appliance follow the steps described in 4.1 until you
reach Management CA Settings section as shown in fig. 4.17.
2. The option that has to be chosen is Use Existing Management CA and in SuperAdmin
full Subject DN field, paste the one you have copied in step 13 above.
Figure 4.27: Management CA Setting
3. The rest of the installation can be completed now.
4. At that point both of the PKI Appliances are using the same certificate as superadmin
with is installed in the smart card. The difference is that only the first one hosts
ManagementCA (see fig. 4.28 and 4.29)
Figure 4.28: EJBCA Administration in first PKI Appliance
Figure 4.29: EJBCA Administration in first PKI Appliance
21 (237)
PKI Appliance
Ver: 2.7.2
Part III
Appliance Operations
22 (237)
PKI Appliance
5. WEBCONF Ver: 2.7.2
Chapter 5
WebConf
Use-Case: Create a new TLS server side certificate for Applica-

tion Interface
In this exercise we will create a new server TLS certificate for the Application Interface using
WebConf.
First we will check which is the present TLS certificate that is used.
1. Open in the browser the Application Interface.
2. Click on the icon where is located before the URL (see figure 5.1) and press More information
.
23 (237)
PKI Appliance
Figure 5.1: EJBCA TLS check
3. Press View Certificate shown in fig. 5.2.
Figure 5.2: EJBCA TLS check certificate
4. Various information about the certificate are displayed. Among them is also CN with
the value node1-tls-app (see figure 5.3).
Now we will create a new TLS server certificate for the Application Interface.
1. Navigate to the tab ACCESS in WebConf
24 (237)
PKI Appliance
Figure 5.3: EJBCA CN value for TLS
2. In Server side SSL/TLS configuration and under Application Interface press

Generate new key pair (see figure 5.4)
Figure 5.4: WebConf Access tab
3. New options will appear (see figure 5.5) and we will create a CSR with Create CSR
25 (237)
PKI Appliance
Figure 5.5: WebConf Create CSR
4. At that point we can download CSR with Download CSR (see figure 5.6).
Figure 5.6: WebConf Download CSR
5. Now we’ll use EJBCA Admin pages. In RA Functions press Search End Entities. .
In Search end entity with username write tls_app. The result shows in figure 5.7
6. Click Edit End Entity. A popup window will appear.
7. Set Status to New ,
26 (237)
PKI Appliance
Figure 5.7: EJBCA Search End Entities
8. for Password set foo123,
9. in CN, Common Name set node1-tls-app-new (see figure 5.8),
Figure 5.8: EJBCA Edit End Entity
10. and at last set Token to User Generated (see figure 5.9).
27 (237)
PKI Appliance
Figure 5.9: EJBCA Edit End Entity, cont.
11. Navigate to Public Web
12. Under Enroll open Create Certificate from CSR (see figure 5.10).
Figure 5.10: EJBCA Create Certificate from CSR
13. For Username use tls_app,
14. as Enrollment code provide the password we used earlier foo123,
15. Browse... to the file appliance-app.csr.pem,
16. and as Result type choose PEM - full certificate chain (see figure 5.11)
17. Press OK .
28 (237)
PKI Appliance
Figure 5.11: EJBCA Enroll
18. At that point we’ll save the pem file with name node1tlsappnew.pem (see figure 5.12)
Figure 5.12: EJBCA Save certificate chain
19. Navigate to WebConf to Access tab. As you see in fig. 5.6, we can Browse... for
Next chain: and upload node1tlsappnew.pem.
20. It is the time to activate the certificate chain to the server with Activate new cert
(see figure 5.13). The procedure will take a while until the new TLS certificate will be
active (see figure 5.14).
29 (237)
PKI Appliance
Figure 5.13: WebConf: Activate certificate chain
Figure 5.14: WebConf: Upload certificate chain
21. We can verify that the server is using the new certificate by refreshing application
pages. We will be asked to confirm the new connection (see figure 5.15). Once this is
done, we can see the new certificate as shown on fig. 5.1.
Figure 5.15: EJBCA login
30 (237)
PKI Appliance
22. When we verify the certificate that is used for the TLS connection, we can see that it
is the one we created, with the new CN node1-tls-app-new as in fig 5.16.
Figure 5.16: EJBCA TLS cert CN
From now on each time we login to the Application Interface the new TLS certificate
will be used.
Use-Case: Upload a new trusted CA for TLS authentication and new super-
admin certificate for Management Interface
In this exercise we will change the client certificate and update the trusted CA for Manage-
ment Interface using WebConf.
The new superuser certificate has to be issued from the same CA (MyCustomCA) that we will
install for TLS authentication. First we have to provide the information about the certificate
(MyUsername.pem) that will be used as superuser.
1. Open the WebConf and navigate to Access tab (see fig. 5.17)
31 (237)
PKI Appliance
Figure 5.17: WebConf Access
2. Check the Subject DN of the certificate using openssl
Run as <user>
\$ openssl x509 -in MyUsername.pem -subject

subject= /C=MyCountry/O=MyCompany/SN=MyLastName/GN=MyFirstName \
/serialNumber=G824734/CN=MyFirstName MyLastName/UID=R4501ZHE
-----BEGIN CERTIFICATE-----
MIID3zCCAsegAwIBAgIIdzHlq8R4dnAwDQYJKoZIhvcNAQELBQAwPTETMBEGA1UE
AwwKTXlDdXN0b21DQTESMBAGA1UECgwJTXlDb21wYW55MRIwEAYDVQQGEwlNeUNv
dW50cnkwHhcNMTUwMTEzMDkxOTIzWhcNMTYwMTEzMDkyNjAzWjCBoDESMBAGA1UE
BhMJTXlDb3VudHJ5MRIwEAYDVQQKDAlNeUNvbXBhbnkxEzARBgNVBAQMCk15TGFz
dE5hbWUxFDASBgNVBCoMC015Rmlyc3ROYW1lMRAwDgYDVQQFEwdHODI0NzM0MR8w
HQYDVQQDDBZNeUZpcnN0TmFtZSBNeUxhc3ROYW1lMRgwFgYKCZImiZPyLGQBAQwI
UjQ1MDFaSEUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5Dr5dRsio
TvihzdeQQ1cCbDDM/KqN729+wuNcfO3btlMhXMRMrSdBz2gZgfIDfbNjWnmOmkF5
...
qqh6BtM4h2SpLlzcpELvOA6ySUEsfvaVpK4I7ebLFDFhtTM=
-----END CERTIFICATE-----
i In the subject value slashes (/) have to be replaced with commas (,)
3. Under PKI Appliance Management Accounts and MatchType choose clientcert

(see figure 5.18), provide the Subject DN:
(C=MyCountry, O=MyCompany, SURNAME=MyLastName, GN=MyFirstName, se-
rialNumber=G824734, CN=MyFirstName MyLastName, UID=R4501ZHE ) of the cer-
32 (237)
PKI Appliance
tificate and press Add .
! EJBCA is using org.bouncycastle.asn1.x500.style.BCStyle which interprets

SN as serialNumber. We inherit this in org.cesecore.util.CeSecoreNameStyle
(Legacy reasons). That means that the user has to make sure that he will
replace SN with SURNAME otherwise there is the danger of getting locked
out!
Figure 5.18: WebConf Access add a new client certificate for TLS authorization
4. Under Trusted CAs for TLS client authentication section we will Browse.. for
the MyCustomCA-chain.pem file (see fig. 5.19).
! It has to be the whole chain from the issuer CA of the client certificate up
to the trusted RootCA.
33 (237)
PKI Appliance
Figure 5.19: WebConf Upload the new trusted CA chain
5. Press Activate new CA certifcate
6. TLS will update the new trust of CA as shown in fig. 5.20
Figure 5.20: WebConf TLS is updated
7. When update is done, the new trusted configuration is used for authentication in the
Management Interface (see fig. 5.21).
34 (237)
PKI Appliance
Figure 5.21: WebConf New configuration for Management Interface is in use
Use-Case: Configure a new trusted CA for TLS authentication and new

superadmin certificate for Application Interface
In this exercise we will change the client certificate and update the trusted CA for Application
Interface using WebConf. First we will configure EJBCA and then WebConf .
The new superuser certificate has to be issued from the same CA (MyTrustedSubCA signed
by MyTrustedRootCA) that we will install for TLS authentication. First we have to provide
the information about the certificate (MyClientAuthenticationCertificate.pem) that will be
used as superuser.
1. Open the EJBCA admin web and navigate to Certification Authorities tab and use
Import CA certificate... (see fig. 5.22) to upload all CA certificates that belong to
the new trust chain. In our paradigm it is MyTrustedRootCA and MyTrustedSubCA.
35 (237)
PKI Appliance
Figure 5.22: Import new trusted CAs as External ones in EJBCA
2. Open Administrator Roles link and click Administrators next to Super Adminis-
trator Role as shown in fig. 5.23
Figure 5.23: Add a new trusted client certificate as superadmin in EJBCA
36 (237)
PKI Appliance
3. Check the Subject DN of the client certificate which will be used to authenticate using
openssl
Run as <user>
> openssl x509 -in MyClientAuthenticationCertificate.pem -serial -\

noout
serial=2b4306acbf69224
4. Use the following values (see fig. 5.24) and press Add :
• CA: MyTrustedSubCA
• Match with: X.509: Certificate serial number (Recommended)
• Match type: Equal, case sens.
• Match value: 2b4306acbf69224
Figure 5.24: Configure the serial number of the trusted certificate in EJBCA
Now EJBCA is configured to use this certificate. But the last step is to configure We-
bConf so the Application Interface will also authenticate MyTrustedSubCA-chain.pem
5. Follow the same process but for the Application Interface in analogous ways as de-
scribed in Use-Case: Upload a new trusted CA for TLS authentication and new super-
admin certificate for Management Interface.
37 (237)
PKI Appliance
6. MAINTENANCE Ver: 2.7.2
Chapter 6
Maintenance
The PKI Appliance may not be able to operate its services due to specific events like update
installation, RAID failing or similar. In order to avoid showing a customer endless long er-
ror messages during usage the PKI Appliance will be set into a state that we call maintenance.
During maintenance all access to EJBCA/SignServer over HTTP(S) will be disabled and
each request will serve a message giving information that the system is undergoing mainte-
nance and cannot be accessed right now.
6.1 PKI Appliance State

The PKI Appliance has three different states:
• Operational
• Maintenance
• Offline
To find out which state the PKI Appliance is in check WebConf (going to ’WebConf→Platform→Troubleshooting’.
The three states will be described briefly by the following sections.
‘Operational’ State
The PKI Appliance is fully operational. All subsystems are working as expected.
38 (237)
PKI Appliance
’Maintenance’ State
The PKI Appliance is in ‘Maintenance’ and application services are cut off due to an auto-
matically detected reason.
‘Maintenance’ can superseed the state ’Offline’.
’Offline’ State
The PKI Appliance is in maintenance and application services are cut off due to a manual
setting in WebConf.
Note:
1. This state will be entered only if the manual setting has been activated and no other
automatically detected reason appears. Any automatically detected reason will change
the state from “Offline” to “Maintenance”. The “Offline” setting would still be active
but invisible. If all automatically detected reasons disappear the PKI Appliance would
still be in maintenance but again be in “Offline” state.
2. A customer cannot see a difference between “Offline” and “Maintenance” but an oper-
ator knows that an “Offline” state indicates a maintenance set manually in WebConf.
A “Maintenance” state indicates a real world problem and not a choice to take the
PKI Appliance services offline.
3. Setting the PKI Appliance “Offline” in WebConf during a “Maintenance” that has been
detected automatically can make sense. For example an operator wants to check the
integrity of the PKI Appliance on his own after an incident before he exposes services
to customers.
6.2 Reasons for Maintenance

The PKI Appliance will be set to ’Maintenance’ automatically for various reasons:
• Factory Reset During Operational
• RAID Failure
• HSM Alarm
• Database is Down
• Application Update
39 (237)
PKI Appliance
Factory Reset During Operation

If the Factory Reset procedure has been triggered during operation the PKI Appliance will
be set to ‘Maintenance’ automatically until the next reboot which finished the Factory Reset.
This event is not recoverable.
RAID Failure
If both SSD hard disk drives fail the PKI Appliance would enter an inconsistent state that
could even not trigger any error message until caches are finally flushed. Detection of a fa-
tally broken RAID therefor enables ‘Maintenance’ and prevents any data from being created
that cannot be recovered later.
HSM Alarm
If the embedded HSM has detected an alarm the PKI Appliance will enter ‘Maintenance’.
It does not make sense to run EJBCA/SignServer without a working HSM because all key
materials are erased by the HSM due to the alarm.
Database is Down
If the embedded database system stops operating (disk fill, ...) the PKI Appliance enters
‘Maintenance’ until the database is available again.
This event is recoverable.
Application Update
If an operator updates an application using WebConf the PKI Appliance will enter ‘Mainte-
nance’ until the update procedure has been finished.
This event is recoverable.
40 (237)
PKI Appliance
Manual Setting ’Offline’

Setting the PKI Appliance ‘Offline’ using ’WebConf→Platform→Troubleshooting’ means ac-
tivating maintenance manually without any real world reason. This functionality can be used
to disable customer access to EJBCA/SignServer without shutting down the whole PKI Ap-
pliance. A customer will see the notification page described in section 6.3.
Note: ‘Offline’ state setting will not persist a reboot of the PKI Appliance.
6.3 Effects
The following sections describe changes and information shown when the PKI Appliance is
operating in maintenance.
Notification Page
Every HTTP(S) request to EJBCA/SignServer will lead to a HTTP 501 status code response
showing a web page giving information that the PKI Appliance is currently not operational
and running in maintenance.
Note: OCSP requests will also receive an HTTP 501 status code with that notification
page inside the responses body.
Front Display
Each time the PKI Appliance enters maintenance the messages set on the front display will
include a message showing ’MAINTENANCE (line break) Services unavail’.
The message will be removed from the set when the PKI Appliance State will switch
back to operational.
WebConf
Troubleshooting Section
In WebConf→Platform→Troubleshooting all maintenance reasons will be listed. Setting the
PKI Appliance ‘Offline’ will be reflected in a change of the button ‘Offline’ to ’Online’ only.
Warning Messages
During maintenance each time an operator opens a page in WebConf a white on red message
appears in the upper left that shows ’Services Unavailable’. This message will disappear when
leaving maintenance only if the page gets reloaded or a new page is opened.
41 (237)
PKI Appliance
SNMP
If SNMP is enabled it will indicate the PKI Appliance state and also give a human readable
combined message of all reasons for maintenance. Further details can be found in section
SNMP.
Syslog
Syslog and avmserver.log will contain detailed messages about changing events leading to
state changes of the PKI Appliance.
Support Package
Each time the PKI Appliance enters maintenance a ‘Support Package’ will be created. This
even happens if the PKI Appliance has been set ’Offline’ manually. Note: If the PKI Appliance
is already in maintenance no additional ‘Support Package’ will be created. For example: If
the SSD hard disk drives all fail and minutes later the factory reset is triggered only one
‘Support Package’ will be created. Read more about ‘Support Packages’ in the chapter 7.
42 (237)
PKI Appliance
7. SUPPORT PACKAGE Ver: 2.7.2
Chapter 7
Support Package
Basically a ‘Support Package’ is an archive file that contains a snapshot of all relevant PKI
Appliance subsystem logging files and some additional configuration and debugging details.
A Support Package can be manually created by an operator (WebConf→Platform→Support).

In addition to this every time the PKI Appliance enters maintenance (see section Mainte-
nance) a ‘Support Package’ will be created automatically.
‘Support Packages’ will be created and stored on the PKI Appliance. They can be
downloaded using an operators access to WebConf→Platform→Support. Up to ten Support
Packages will be stored. Any additional created Support Package will delete the oldest one
stored.
A completed ‘Factory Reset’ will remove any stored ‘Support Packages’.
A ’Support Package’ will contain the following files:
• all_sysinfo: Runtime information for all subsystems
• sfp_avmserver.log: AVM subsystem logging file
• sfp_dom-vm-PrimeLFSversion: Firmware version information
• sfp_ips_client_stderr,stdout: IP configuration
• sfp_virsh_list_all: List of all running virtual subsystems
• vadm_etc-webconf-machineID.properties: Version information
• vdb_df-h: Disk fill information
• vgw_var-log-httpd-errorlog: Webserver logging files
43 (237)
PKI Appliance
7. SUPPORT PACKAGE Ver: 2.7.2
• vgw_var-log-syslog: Syslog of virtual gateway subsystem
• vhsm_hsm_diag_stderr,stdout: HSM’s diagnostic output
44 (237)
PKI Appliance
Ver: 2.7.2
Part IV
EJBCA GUI Operations
45 (237)
PKI Appliance
8. CERTIFICATE LIFE CYCLE MANAGEMENT Ver: 2.7.2
Chapter 8
Certificate Life Cycle Management
8.1 Introduction to Certificate Life Cycle Management

Lifecycle management, in the context of PKI, is the process by which entities and certificates
are managed from creation, revocation, re-issuance, revocation and deletion. Simply stated,
the life of an end entity or certificate should be managed from inception through archival or
purging from your PKI infrastructure. These functions are easily performed in the adminis-
trative web interface or from the command line interface (CLI). In this lesson we will manage
an end entity through its lifecycle from the CLI.
8.1.1 Entity Issuance and Maintenance

During the lifecycle of an end entity or certificate there are several required tasks and other
tasks which are specific to certain situations. For instance, when creating an end entity
several steps must be employed and are required for the creation of the end entity. However,
once an end entity is created, you are not required to verify it, create certificates for it, nor
revoke or re-issue it. These tasks will be situation specific.
8.1.2 Creation of Entity and Certificates

Creating an end entity and its associated certificates is the main function of a certificate
authority. An administrator must be aware that issuance of an end entity in no way attests
to the identity of that end entity. The function of verifying an end entity’s identity (whether
an individual or a piece of equipment) should be performed prior to allowing issuance of the
end entity or any associated certificates and is usually performed by some external function
that is interfaced into the registration authority. For instance, when issuing an end entity to
a user for authentication an administrator should take either physical or digital precautions
to ensure the identity of that user prior to providing the user with an end entity and the
associated certificates. This can be done in a myriad of ways depending on the requirements
of your organisation.
46 (237)
PKI Appliance
8.1.3 Verification
Once an end entity or certificate is issued, administrators can verify the information related
to that end entity or certificate prior to delivering them to the end entity for use. While this
is an optional step, it is recommended during initial testing and deployment to ensure proper
configuration of end entity profiles and other operational functions, via a quick command
line verification of the information being issued.
8.1.4 Revocation, Re-issuance, Un-Revoke

Situation specific revocation, re-issuance, revocation and un-revoking an end entity is per-
formed by an administrator or an automated process as a reaction or proaction to an event.
For instance, if an employee of an organisation goes on an extended leave, the administrator
can revoke the certificate with a status of ’On Hold’ essentially suspending the certificate
which can then be un-revoked when the employee returns. Re-issuance and un-revoking
are two entirely separate and distinct tasks. Re-issuance is the process in which new keys
and certificates are generated for a specific end entity. Un-revoke is used for one task only
to restore a certificate that has been put in an On Hold status during revocation. Lastly,
revocation is used to deactivate a certificate’s usefulness, making it invalid for its intended
or other uses. Revoking a certificate does not delete the certificate, it simply invalidates it.
8.1.5 Deletion of an End Entity

Deletion of an end entity sounds like a simple enough task of removing that entity from
the PKI infrastructure, but this must be done with extreme care. In many situations the
PKI infrastructure is being used for authentication, digital signing or other tasks that have
legal implications. Maintaining the end entity and its associated audit trail of PKI activity is
commonly desirable. It is better practice to use revocation to suspend or remove rights than
to simply delete an end entity because you will retain the entity, its audit trail and other
essential data that may be required for compliance or legal reasons.
8.2 Certification Authorities

Certificate authorities are often organised in a hierarchic model, similar to a business organ-
isational chart. A root CA is the top level CA. This CA can be used to issue all end entity
certificates or issue an Intermediate CA that will issue all end entity certificates. If the root
CA’s keys become compromised, all of the certificates issued become invalid. Therefore,
protecting the root CA’s keys is highly crucial. Intermediate CAs are CAs issued and signed
by the root CA. These CAs will issue the end entity certificates. The main purpose for this
separation is to physically and digitally protect the root CA’s keys by taking it offline and off
the network. If an intermediate CA is compromised it can be resigned without affecting the
entire infrastructure.
47 (237)
PKI Appliance
8.2.1 Types of Certification Authorities

Certification authorities (CAs) can be classified using various taxonomies. The primary of
these is by hierarchy. Using this classification, certification authorities can be classified as
the following:
Root CA
These CAs are self signed and usually offline. As there is no CA above these CAs, they
are based on the notion of self trust. The root CA is the penultimate trust entity and
hence trusts itself.
Subordinate CA
A subordinate CA (sub CA) is an entity that is trusted by the root. A sub CA is usually
created for organisational, functional, security or other commercial and non commercial
reasons. While it may be functionally possible to issue all possible certificates from
a single CA, this may not be desirable for security and organisational reasons. For
examples, a Qualified CA (QC) is one that issues certificates for digital signatures
that have the equivalence of normal digitally binding signatures. The compliance
requirements of these certification authorities require that a dedicated CA be used
for issuing qualified certificates. Sub CAs may be created on a functional basis. For
example
• Authentication CA
• Signing CA
• Encryption CA
Alternatively, sub CAs may be created on an organisational basis
• Human resources CA
• Finance CA
• Document Verifier CA
Sub CAs can also be created in a hybrid fashion as illustrated
• Finance Signing CA
• Finance Authentication CA
Electronic travel documents have a clearly documented acceptable hierarchy. The

ICAO standard for travel documents stipulates the following hierarchy
• Country Signing Certification Authority (CSCA) that issues Document Signer

Certificates
For second generation electronic documents, the following certification authority hier-
archy applies
• Country Verifier Certification Authority (CVCA)
48 (237)
PKI Appliance
• Document Verifier Certification Authority (DVCA)
Certification authorities can also be classified based on the format of certificates issued.
• X.509 CA based on the X.509 standard

• CVC CA based on the card verifiable standards
49 (237)
PKI Appliance
9. CREATING A CA HIERARCHY Ver: 2.7.2
Chapter 9
Creating a CA Hierarchy
This exercise involves the creation of several CAs to illustrate the manner in which authorities
are created. To illustrate certificate life cycle management using EJBCA, the following CAs
are created:
• Root CA (RootCA) as ROOTCA
• SSL CA (SSLCA) as SubCA
• Authentication CA (AuthCA) asSubCA
• Signing CA (SignCA) as SubCA
The scenario that is about to be implemented is also described in Using External CA

for Installation chapter. The PKI Appliance that hosts ROOTCA (node B) will be offine
after is finished with signing SubCAs in node A (see fig. 9.1 and 9.2).
Figure 9.1: Node B with RootCA installed
50 (237)
PKI Appliance
Figure 9.2: Node A with SubCAs and ManagementCA installed.
9.1 Use-Case: Creation of the RootCA

Instructions below will guide you on how to create a ROOT Certification Authority with
the name RootCA in node B PKI Appliance.
Creating a Certificate Profile for the RootCA

The first step is the creation of a certificate profile for the RootCA using Administration
web-pages of EJBCA. We will use a template (ROOTCA) for that which we’ll clone.
When the CA is renewed it will look in the profile for the default values, simplifying the
renewal process.
1. Click on Certificate Profiles under CA Functions.
2. Click Clone for ROOTCA (fig. 9.3).
Figure 9.3: Certificate Profiles.
3. Enter RootCACertificateProfile in the Name of new certificate profile: (fig. 9.4).
51 (237)
PKI Appliance
Figure 9.4: Clone a certificate profile.
4. Click Create from template
5. Going back to Certificate Profiles, the new profile is now displayed among the
others (fig. 9.5).
Figure 9.5: Certificate Profiles.
6. Click on Edit for the newly created profile.
7. Change Available bit lengths to 4096
8. Change Validity to 3650d
9. Enable Path Length Constraint and set Value to 1
10. Select Any CA on Available CAs
11. Click on Save .
52 (237)
PKI Appliance
Create Crypto Token for RootCA

At that point we will create a Crypto Token and generate public keys which will be used
from RootCA.
1. Access the EJBCA Administration GUI.
2. Navigate to CA Functions > Crypto Tokens
3. Click on the Create New... hyperlink (fig. 9.6).
Figure 9.6: Crypto Tokens.
4. Populate the form with the following values as shown in fig. 9.7
• Name: RootCA CryptoToken

• Type: PKCS#11
• Authentication Code : foo123 (which was the password previously set)
! Make sure that you have manually generated slot password for that slot!
• PKCS#11 Reference Type: Slot ID

• PKCS#11 Reference: 2
i The index numbers would be different depending on the installation
• Leave the Auto-activation box unchecked.
5. Click Save
53 (237)
PKI Appliance
Figure 9.7: Crypto Tokens settings.
6. In the settings page the following message will be visible: CryptoToken created suc-
cessfully.. Create the following keys as shown in fig. 9.8
• In the section below, enter defaultKey as the key alias, RSA 4096 and click
the Generate new key pair button.
• Next click the Test button.

• The following message should be visible defaultKey tested successfully.
• Enter signKey with RSA 4096 and click the Generate new key pair button.
• Next click the Test button. The following message should be visible signKey
tested successfully.
• Enter testKey with RSA 1024 and click the Generate new Key pair but-
ton. The following message should be visible testKey tested successfully.
54 (237)
PKI Appliance
Figure 9.8: Key pair creation.
Creating an RootCA
This section involves the actual creation of the RootCA
1. Click on Certification Authorities.
2. Enter RootCA in Add CA field (9.9).
3. Click on Create .
Figure 9.9: Certification Authorities.
4. Select, for Signing Algorithm SHA256WithRSA
5. Select, for Crypto Token RootCA CryptoToken (fig. 9.10)
6. Change Validity (*y *mo *d) to 10y .
55 (237)
PKI Appliance
Figure 9.10: Create CA.
i The values used in the profile are for renewal
7. Enter the Subject DN as CN=RootCA, O=EJBCA Course, C=SE.
8. As Certificate Profile choose RootCACertificateProfile (fig. 9.11).
Figure 9.11: CA certificate data.
9. As CRL Expire Period (*d *h *m) defines how long a CRL is valid for. Enter 2d
into this field.
i The letter “d” after the number specifies days
10. As CRL Issue Interval (*d *h *m) enter 0d. This defines how often the CRLs are
to be issued. In this case the CRLs will be issued once every day but will be valid for
two days.
11. As CRL Overlap Time (*d *h *m) enter 6h as in figure 9.12.
56 (237)
PKI Appliance
Figure 9.12: CA CRL data settings.
i This value defines the number of minutes both CRLs are valid for. For
example, thirty minutes before the first CRL will expire it will issue a new
CRL.
12. Click on Create
57 (237)
PKI Appliance
9.2 Use-Case: Create Certificate Profile for SubCAs

In this step we will create Certificate Profile for SubCAs which will be created in another
PKI Appliance. This profile will be used when RootCA will sign SubCA’s certificate.
1. Navigate to Administration pages
2. Click Certificate Profiles under CA Functions
3. Press Clone for SUBCA profile (fig. 9.13)
Figure 9.13: Clone SUBCA.
58 (237)
PKI Appliance
4. Provide SubCACertificateProfile in Name of new certificate profile:
5. Press Create from template (fig. 9.14)
Figure 9.14: Create from template.
6. Back in the Certificate Profiles edit the newly created SubCACertificateProfile

with Edit (fig. 9.15)
Figure 9.15: Edit Certificate Profile.
59 (237)
PKI Appliance
7. Choose 4096 in Available bit lengths and 5y for Validity(*y *mo *d) or end
date of the certificate (fig. 9.16)
Figure 9.16: Edit Certificate Profile 2.
8. Enable Path Length Constraint and set Value to 0
9. In Key Usage check only Key certificate sign and CRL sign (fig. 9.17)
60 (237)
PKI Appliance
10. Under section Other data and in Available CAs choose RootCA (fig. 9.18)
11. Click Save
61 (237)
PKI Appliance
9.3 Use-Case: Create End Entity Profile for SubCAs

In this step we will create End Entity Profile for SubCAs which will be created in another
PKI Appliance. This profile will be used when we will create end entities for SubCAs.
1. Navigate to Administration pages
2. Click End Entity Profiles under RA Functions
3. Provide SubCAEndEntityProfile in the text field and press Add (see fig. 9.19)
Figure 9.19: Create End Entity profile for SUBCAs.
4. Highlight SubCAEndEntityProfile and click Edit End Entity Profile
5. Uncheck the End Entity E-mail
6. Under Subject DN Attributes , Add the following values as shown in fig. 9.20
• CN, Common name and select Required and Modifiable
• O, Organization and select Required and Modifiable
• C, Country and select Required and Modifiable
62 (237)
PKI Appliance
Figure 9.20: Edit End Entity Profile for SubCAs.
7. Under Main certificate data choose the following values as shown in figure 9.21
• Default Certificate Profile: SubCACertificateProfile

• Available Certificate Profiles: SubCACertificateProfile
• Default CA: RootCA
• Available CAs: RootCA
• Default Token: User Generated
• Available Tokens: User Generated
Figure 9.21: Edit End Entity Profile for SubCAs 2.
8. Click Save
63 (237)
PKI Appliance
9.4 Use-Case: Import RootCA as External CA in node A

Implementation of PKI infrastructure that is described in the current guide has an online
and one offline PKI Appliance. Now that RootCA is setup, there is the possibility to install
it in the one that is online. The reasons to do it are:
• It is easy to understand the logical hierarcy when navigating to Certification

Authorities. There we can see that the SubCAs are installed locally but also that
there is a ROOTCA which signed them, having the indication External CA - meaning
that is installed in the offline PKI Appliance.
• When CSRs are created and has to be signed by RootCA, no other import is needed
(RootCAs certificate). The chain is autogenerated (like in 11).
• When we do Certificate enrollment from a CSR we just need to PEM - Certificate only
as Result type (like in 16)
In the case that we want to import RootCA’s certificate in the PKI Appliance which is
online, the procedure below describes how to:
1. Navigate to Fetch CA Certificates under Retrieve section in Public Web in node B

where RootCA is installed.
2. Under CA:RootCA there is the option to download the CA certificate: or CA certifi-

cate chain: as shown in fig. 9.22.
Figure 9.22: Fetch RootCA certificate.
3. In that case Download as PEM for CA certificate chain:
64 (237)
PKI Appliance
4. Save the file (see fig. 9.23).
Figure 9.23: Save RootCA pem file.
5. Navigate to Certification Authorities in PKI Appliance node A where the pem file
will be imported.
6. Click on Import CA certificate...
7. Provide RootCA in The name this CA will be given
8. Browse... for the RootCA-chain.pem (see fig. 9.24)
9. Click Import CA certificate
Figure 9.24: Import RootCA as External CA.
65 (237)
PKI Appliance
9.5 Use-Case: Create SignCA as SubCA in node A

Here we will create the first of the SubCAs which is SignCA. This CA together with the other
SubCAs will be installed in the PKI Appliance node A (where ManagementCA is installed)
and will be signed by RootCA.
Create Crypto Token for SignCA

from AuthCA.
3. Click on the Create New... hyperlink.
• Name: SignCA CryptoToken

• Type: PKCS#11
• Authentication Code : foo123

• Check the Auto-activation box.
5. Click Save
• In the section below, enter defaultKeySignCA as the key alias, RSA 4096 and
click the Generate new key pair button

• The following message should be visible defaultKeySignCA tested successfully.
• Enter signKeySignCA with RSA 4096 and click the Generate new key pair
button
66 (237)
PKI Appliance
Figure 9.25: Crypto Token creation for SignCA.
• Next click the Test button. The following message should be visible signKeySignCA
• Enter testKeySignCA with RSA 1024 and click the Generate new Key pair
button The following message should be visible testKeySignCA tested success-
fully.
Figure 9.26: Create keys for SignCA.
Creating SignCA
This section involves the actual creation of the SignCA
2. Enter SignCA in Add CA field (9.27).
3. Click on Create... .
67 (237)
PKI Appliance
Figure 9.27: Create SignCA in Certification Authorities.
5. Select, for Crypto Token SignCA CryptoToken (fig. 9.28)
Figure 9.28: SignCA settings.
68 (237)
PKI Appliance
6. Enter the Subject DN as CN=SignCA,O=EJBCA Course,C=SE.
7. In Signed By choose External CA (fig. 9.29).
i Using External CA some fields become gray and non-editable
Figure 9.29: SignCA will be signed by ’External CA’.
8. As CRL Expire Period (*d *h *m) defines how long a CRL is valid for. Enter 12h
into this field.
9. As CRL Issue Interval (*d *h *m) enter 0. This defines how often the CRLs are to
be issued. In this case the CRLs will be issued once every day but will be valid for two
days.
Figure 9.30: CA CRL data settings for SignCA.
69 (237)
PKI Appliance
CRL.
11. In Externally signed CA creation/renewal click on Browse... and upload RootCA.pem

file.
i This step is NOT needed in the case that we have imported RootCA as an
External CA! Otherwise, RootCA.pem can be downloaded from the Public
Web of the PKI Appliance which is installed the RootCA.
12. Click on Make Certificate Request as in fig. 9.31
Figure 9.31: Create CSR for SignCA.
13. This will give the option to download or copy the request. In this case save the .csr
file with Save File (see fig. 9.32)
Figure 9.32: Generation of CSR.
14. At that point check the status of the CAs. Click Certification Authorities under
CA Functions. Status for SignCA is Waiting for Certificate Response
70 (237)
PKI Appliance
15. Now back in the PKI Appliance where RootCA is installed (node B), we have to
create an End Entity which will be binded with SignCA certificate. Navigate to RA
Functions -> Add End Entities and provide the following values: (see fig. 9.33)
• End Entity Profile choose SubCAEndEntityProfile

• In Username text field enter signCA
• In Password and Confirm Password enter foo123
• In CN, Common name provide SignCA
• In O, Organization provide EJBCA Course
• In C, Country (ISO 3166) provide SE
• Choose SubCACertificateProfile in Certificate Profile
• Choose RootCA as CA
• and at last User Generated as Token
• Click Add
Figure 9.33: Create an End Entity for SignCA in the PKI Appliance where RootCA is installed.
16. Click under Enroll -> Create Certificate from CSR and fill values with the following:
(see fig. 9.34)
• Username with signCA
i It is the End Entity we created before.
• Enrollment code with foo123
71 (237)
PKI Appliance
• Click on Browse... and upload the SignCA_csr.pem

• As Result type choose PEM - full certificate chain
i The chain is NOT needed if we have RootCA as External CA. It is enough

to choose PEM - certificate only
• Click OK
Figure 9.34: Sign CSR request for SignCA.
17. Save SignCA.pem file as shown in fig. 9.35
Figure 9.35: Download signed .pem for SignCA.
18. Go back in the PKI Appliance where SignCA is installed (node A). Click Certification
Authorities, highlight SignCA, (Waiting for Certificate) and press Edit CA
72 (237)
PKI Appliance
19. Under Externally signed CA creation/renewal section and Step 2: Browse... for
the SignCA.pem (see fig. 9.36)
20. Click Receive Certificate Response
Figure 9.36: Upload signed CSR for SignCA.
21. Navigating to Certification Authorities we will see that SignCA is now active
(see fig. 9.37).
Figure 9.37: Activated SignCA.
73 (237)
PKI Appliance
9.6 Use-Case: Create AuthCA as SubCA in node A

Here we will create the second of the SubCAs which is AuthCA. This CA together with the
other SubCAs will be installed in PKI Appliance node A (where ManagementCA is installed)
and will be signed by RootCA.
Create Crypto Token for AuthCA

from AuthCA.
• Name: Auth CryptoToken

• Type: PKCS#11

5. Click Save
• In the section below, enter defaultKeyAuthCA as the key alias, RSA 4096 and

• The following message should be visible defaultKeyAuth tested successfully.
• Enter signKeyAuthCA with RSA 4096 and click the Generate new key pair
button
74 (237)
PKI Appliance
Figure 9.38: Crypto Token creation for AuthCA.
• Enter testKeyAuthCA with RSA 1024 and click the Generate new Key pair
button The following message should be visible testKey tested successfully.
Figure 9.39: Create keys for AuthCA.
Creating AuthCA
This section involves the actual creation of the AuthCA
2. Enter AuthCA in Add CA field (9.40).
75 (237)
PKI Appliance
Figure 9.40: Create AuthCA in Certification Authorities.
5. Select, for Crypto Token Auth CryptoToken (fig. 9.41)
Figure 9.41: AuthCA settings.
76 (237)
PKI Appliance
6. Enter the Subject DN as CN=AuthCA,O=EJBCA Course,C=SE.
Figure 9.42: AuthCA Signed by ’External CA’.
into this field.
days.
Figure 9.43: CA CRL data settings for AuthCA.
CRL.
77 (237)
PKI Appliance
file.
External CA. Otherwise, RootCA.pem can be downloaded from the Public
Web of the PKI Appliance which is installed the RootCA (check Use-Case:
Import RootCA as External CA in node A).
Figure 9.44: Create CSR for AuthCA.
14. At that point check the status of the CAs. Click Certification Authorities under
CA Functions. Status for AuthCA is Waiting for Certificate Response (see fig.
9.46)
78 (237)
PKI Appliance
Figure 9.46: Certification Authorities status.
15. Now back in the PKI Appliance where RootCA is installed (node B), we have to
create an End Entity which will be binded with AuthCA certificate. Navigate to RA
Functions -> Add End Entities and provide the following values: (see fig. 9.47)
• In Username text field enter authCA

• In CN, Common name provide AuthCA
• Click Add
79 (237)
PKI Appliance
Figure 9.47: Create an End Entity for AuthCA in the PKI Appliance where RootCA is
installed.
(see fig. 9.48)
• Username with authCA

• Click on Browse... and upload the AuthCA_csr.pem

(check Use-Case: Import RootCA as External CA in node A)

• Click OK
80 (237)
PKI Appliance
Figure 9.48: Sign CSR request for AuthCA.
17. Save AuthCA.pem file as shown in fig. 9.49
Figure 9.49: Download signed .pem for AuthCA.
18. Go back in the PKI Appliance where AuthCA is installed (node A). Click Certification
Authorities, highlight AuthCA, (Waiting for Certificate) and press Edit CA (see
fig. 9.50)
81 (237)
PKI Appliance
Figure 9.50: Edit AuthCA.
the AuthCA.pem (see fig. 9.51)
Figure 9.51: Upload signed CSR for AuthCA.
21. Navigating to Certification Authorities we will see that AuthCA is now active
(see fig. 9.52).
82 (237)
PKI Appliance
Figure 9.52: Activated AuthCA.
83 (237)
PKI Appliance
9.7 Use-Case: Create SSLCA as SubCA in node A

Here we will create the third of the SubCAs which is SSLCA. This CA together with the
other SubCAs will be installed in PKI Appliance node A (where ManagementCA and other
SubCAs are installed) and will be signed by RootCA.
Create Crypto Token for SSLCA

from SSLCA.
• Name: SSLCA CryptoToken

• Type: PKCS#11

5. Click Save
84 (237)
PKI Appliance
Figure 9.53: Crypto Token creation for SSLCA.
• In the section below, enter defaultKeySSLCA as the key alias, RSA 4096 and

• The following message should be visible defaultKeySSLCA tested successfully.
• Enter signKeySSLCA with RSA 4096 and click the Generate new key pair
button
• Next click the Test button. The following message should be visible signKeySSLCA
• Enter testKeySSLCA with RSA 1024 and click the Generate new Key pair
button The following message should be visible testKeySSLCA tested success-
fully.
85 (237)
PKI Appliance
Figure 9.54: Create keys for SSLCA.
Creating SSLCA
This section involves the actual creation of the SSLCA
2. Enter AuthCA in Add CA field (9.55).
Figure 9.55: Create SSLCA in Certification Authorities.
5. Select, for Crypto Token SSLCA CryptoToken (fig. 9.56)
86 (237)
PKI Appliance
Figure 9.56: SSLCA settings.
6. Enter the Subject DN as CN=SSLCA,O=EJBCA Course,C=SE.
Figure 9.57: SSLCA Signed by ’External CA’.
into this field.
days.
87 (237)
PKI Appliance
Figure 9.58: CA CRL data settings for SSLCA.
CRL.

file.
External CA. Otherwise, RootCA.pem can be downloaded from the Public
Web of the PKI Appliance which is installed the RootCA (check Use-Case:
Import RootCA as External CA in node A).
Figure 9.59: Create CSR for SSLCA.
88 (237)
PKI Appliance
14. Now back in the PKI Appliance where RootCA is installed (node B), we have to create
an End Entity which will be binded with SSLCA certificate. Navigate to RA Functions
-> Add End Entities and provide the following values: (see fig. 9.61)
• In Username text field enter sslCA

• In CN, Common name provide SSLCA
• Click Add
89 (237)
PKI Appliance
Figure 9.61: Create an End Entity for SSLCA in the PKI Appliance where RootCA is installed.
(see fig. 9.62)
• Username with sslCA

• Click on Browse... and upload the SSLCA_csr.pem

(check Use-Case: Import RootCA as External CA in node A)

• Click OK
90 (237)
PKI Appliance
Figure 9.62: Sign CSR request for SSLCA.
16. Save AuthCA.pem file as shown in fig. 9.63
Figure 9.63: Download signed .pem for SSLCA.
17. Go back in the PKI Appliance where SSLCA is installed (node A). Click Certification
Authorities, highlight SSLCA, (Waiting for Certificate) and press Edit CA (see
fig. 9.64)
91 (237)
PKI Appliance
Figure 9.64: Edit SSLCA.
the SSLCA.pem (see fig. 9.65)
Figure 9.65: Upload signed CSR for SSLCA.
20. Navigating to Certification Authorities we will see that SSLCA is now active (see
fig. 9.66).
92 (237)
PKI Appliance
Figure 9.66: Activated SSLCA.
93 (237)
PKI Appliance
9.8 Use-Case: Create Certificate Profiles for End Entities that

will use the SubCAs
CertificateProfiles define different types of certificates, with regards to DN-contents,
extensions etc.
At that point we will create Certificate Profiles for the End Entities that will use the SubCAs
(SignCA, AuthCA, SSLCA) we created in the previous steps.
Create Certificate Profile for End Entities that will use AuthCA
This section involves the creation of the Certificate Profile for the End Entities that will use
AuthCA
2. Enter AuthCAEndEntityCertificateProfile in the text field (see fig. 9.67).
3. Click on Add .
Figure 9.67: Create Certificate Profile for AuthCA.
4. Use End Entity as Type
5. Choose 2048 bits in Available bit lengths
6. The Signature Algorithm has to Inherit from issuing CA
7. Type 730d in Validity
8. In the Key Usage section check Digital Signature and Key encipherment
94 (237)
PKI Appliance
Figure 9.68: Certificate Profile Settings for AuthCA.
9. Choose Client Authentication in Extended Key Usage as shown in fig. 9.68
10. Choose AuthCA from Available CAs under Other data (see fig. 9.69)
11. Click Save
Figure 9.69: Certificate Profile Settings for AuthCA 2.
Create Certificate Profile for End Entities that will use SignCA
SignCA
2. Enter SignCAEndEntityCertificateProfile in the text field (see fig. 9.70).
3. Click on Add .
95 (237)
PKI Appliance
Figure 9.70: Create Certificate Profile for SignCA.
7. Type 730d in Validity (see fig. 9.71)
Figure 9.71: Certificate Profile Settings for SignCA.
8. In the Key Usage section check Digital Signature and Non-repudiation
9. Un-check Use in Extended Key Usage as shown in fig. 9.72
10. Choose SignCA from Available CAs under Other data (see fig. 9.73)
11. Click Save
96 (237)
PKI Appliance
Figure 9.72: Certificate Profile X.509 extensions Settings for SignCA.
Figure 9.73: Certificate Profile Settings for SignCA cont.
Create Certificate Profile for End Entities that will use SSLCA
SSLCA. For that purpose we will clone a template.
2. Press Clone for SERVER.
3. Enter SSLCAEndEntityCertificateProfile in Name of the new certificate profile:

(see fig. 9.74)
4. Click on Create from template .
5. Back in Certificate Profiles click Edit for the newly created profile.
9. Type 730d in Validity
10. In the Key Usage section check Digital Signature and Key encipherment
97 (237)
PKI Appliance
Figure 9.74: Clone Certificate Profile for SSLCA.
11. In Extended Key Usage choose Server Authentication as shown in fig. 9.75
Figure 9.75: Certificate Profile Settings for SSLCA.
12. Under Other data in Available CAs choose SSLCA (see fig. 9.76)
Figure 9.76: Certificate Profile X.509 extensions Settings for SSLCA.
13. Click Save
98 (237)
PKI Appliance
9.9 Use-Case: Create End Entity Profiles for SubCAs

EndEntityProfiles defines which parts of user DN should be registered for various types of
end entities. It defines which parts that is already pre-set, and which can be altered etc. It
also contains other information, that is specific to each individual end entity, for issuance of
certificates.
For each SubCA we will configure a different End Entity Profile.
Create End Entity Profile for AuthCA

This section involves the creation of the End Entity Profile for the End Entities that will use
AuthCA.
1. Click on End Entity Profiles under RA Functions.
2. Write AuthCAEndEntityProfile in Add Profile text field.
3. Click Add .
4. Highlight AuthCAEndEntityProfile from List of End Entity Profiles (see fig.9.77)
5. Click Edit End Entity Profile
Figure 9.77: Create End Entity Profile for AuthCA.
6. In Subject DN Attributes and Subject DN Attributes Add O, Organization and

C, Country(ISO 3166)
7. Check on Required in all of these values.
99 (237)
PKI Appliance
8. Provide the values EJBCA Course and SE on respectively fields above (see fig. 9.78).
9. Check Modifiable for Cn, Common name but not for the other values.
Figure 9.78: Subject DN Attributes for AuthCA End Entity Profile.
10. Under Main certificate data choose AuthCAEndEntityCertificateProfile for both

Default Certificate Profile and Available Certificate Profile.
11. Choose AuthCA for both Default CA and Available CA.
12. In Default Token choose User Generated
13. In Available Tokens choose User Generated and P12 file (see fig. 9.79)
14. Click Save
Figure 9.79: Main certificate data for AuthCA End Entity Profile.
Create End Entity Profile for SignCA

SignCA.
100 (237)
PKI Appliance
2. Write SignCAEndEntityProfile in Add Profile text field.
3. Click Add .
4. Highlight SignCAEndEntityProfile from List of End Entity Profiles (see fig. 9.80)
Figure 9.80: Create End Entity Profile for SignCA.

9. Check Modifiable for Cn, Common name
101 (237)
PKI Appliance
Figure 9.81: Subject DN Attributes for SignCA End Entity Profile.
10. Under Main certificate data choose SignCAEndEntityCertificateProfile for both De-
fault Certificate Profile and Available Certificate Profile.
11. Choose SignCA for both Default CA and Available CA.
13. In Available Tokens choose User Generated (see fig. 9.82)
! Remember that we have used Non-repudiation in its certificate profile. That

ensures that users only are responsible for the creation and storage of their
public key in a smart card ! Create Certificate Profile for End Entities that
will use SignCA
14. Click Save
Figure 9.82: Main certificate data for SignCA End Entity Profile.
102 (237)
PKI Appliance
Create End Entity Profile for SSLCA

SSLCA.
2. Write SSLCAEndEntityProfile in Add Profile text field.
3. Highlight SslServerProfile
4. Click Use selected as template .
5. Highlight SSLCAEndEntityProfile from List of End Entity Profiles (see fig. 9.83)
Figure 9.83: Clone End Entity Profile for SSLCA.

10. Check Modifiable for Cn, Common name
103 (237)
PKI Appliance
Figure 9.84: Subject DN Attributes for SSLCA End Entity Profile.
11. Under Main certificate data choose SSLCAEndEntityCertificateProfile for both De-
fault Certificate Profile and Available Certificate Profile.
12. Choose SSLCA for both Default CA and Available CA.
14. In Available Tokens choose P12 file , User Generated , JKS file and PEM file
(see fig. 9.85)
15. Click Save
Figure 9.85: Main certificate data for SSLCA End Entity Profile.
104 (237)
PKI Appliance
9.10 Use-Case: Create End Entities that will use the SubCAs
Now that CAs and Profiles are configured it is time to add some End Entities which will use
those SubCAs.
First End Entities will be created providing values required depending on the End Entity
Pofile. Then either we will Create Browser Certificate either Create Keystore.
Create an End Entity that will use SSLCA

This section involves the creation of the End Entities that will use SSLCA.
1. Click on Add End Entity under RA Functions.
2. Provide the various fields with the following values (see fig.9.86) :
• End Entity Profile : SSLCAEndEntityProfile

• Username : testsrv.course
• Password : foo123
• Confirm Password : foo123
• CN, Common name : testsrv.course
• DNS Name : testsrv.course
• Certificate Profile : SSLCAEndEntityCertificateProfile
• CA : SSLCA
• Token : P12 file
• Click Add .
105 (237)
PKI Appliance
Figure 9.86: Create End Entity for SSLCA.
4. Under Enroll click Create Browser Certificate
5. Provide Username with testsrv.course
6. Password with foo123 (see fig. 9.87)
7. Click OK
Figure 9.87: Keystore Enrollment for testsrv.course.
8. For Key length: choose 2048 bits (see fig. 9.88)
9. Click on Enroll
106 (237)
PKI Appliance
Figure 9.88: Enrollment for testsrv.course.
10. The next step is to save the testsrv.course.p12 keystore (see fig. 9.89)
Figure 9.89: Save testsrv.course.p12 file.
Create an End Entity that will use AuthCA

This section involves the creation of the End Entities that will use AuthCA.
2. Provide the various fields with the following values (see fig.9.90) :
• End Entity Profile : AuthCAEndEntityProfile

• Username : Auth_User_1
• CN, Common name : Auth User 1
107 (237)
PKI Appliance
• Certificate Profile : AuthCAEndEntityCertificateProfile
• CA : AuthCA
• Token : P12 file
• Click Add .
Figure 9.90: Create End Entity for AuthCA.
4. Under Enroll click Create Keystore
5. Provide Username with Auth_User_1
6. Password with foo123 (see fig. 9.91)
7. Click OK
108 (237)
PKI Appliance
Figure 9.91: Browser Certificate for Auth_User_1.
8. For Key length: choose 2048 bits
9. For Certificate Profile : AuthCAEndEntityCertificateProfile
10. Click on Enroll
Create an End Entity that will use SignCA

This section involves the creation of the End Entities that will use SignCA.
2. Provide the various fields with the following values :
• End Entity Profile : SignCAEndEntityProfile

• Username : Sign_User_1
• CN, Common name : Sign User 1
• Certificate Profile : SignCAEndEntityCertificateProfile
• CA : SignCA
• Token : User Generated

• Click Add .
4. Under Enroll click Create Browser Certificate
5. Provide Username with Sign_User_1
109 (237)
PKI Appliance
6. Password with foo123
7. Click OK
8. For Key length: choose 2048 bits
9. For Certificate Profile : SignCAEndEntityCertificateProfile
10. Click on Enroll
110 (237)
PKI Appliance
10. MANAGING END ENTITIES Ver: 2.7.2
Chapter 10
Managing End Entities
Managing End Entities is a task performed by administrators on a regular basis. In larger

PKI deployments, dedicated staff is assigned the management of end entities and associated
CRL lists. In this section covers the following items.
• Searching for end entities
• Suspension and revocation of certificates
• Renewing end entities
10.1 Use-Case: Searching for end entities

1. Click on Search End Entities.
2. Enter Auth_User_1 in the Search end entity with username text field.
3. Click on Search
10.2 Certificate Revocation

As described previously, there is no mechanism for recalling a certificate once it has been
issued. Although there would be a business need to disable use of the certificate once it has
been issued. This could be for a number of reasons.
As an example, if a user looses a token that contains his certificate, this needs be revoked
such that if an adversary finds this, it cannot be used in the digital evironment.
In the real world, black lists serve this purpose. If for example, a user looses his passport,
the passport number goes into a blacklist of lost passports. Thus this passport cannot be
used in the future.
In a similar manner if a certificate is to be revoked, this goes into a black list. This
black list is updated on a regular basis and circulated and published in a manner accessible
to subscribers. This list is referred to as a certificate revocation list (CRL)
111 (237)
PKI Appliance
10. MANAGING END ENTITIES Ver: 2.7.2
It may also be possible to provide a service for online checking where by a third party
that wishes to check the validity of a certificate.
10.2.1 Use-Case: Revoking a Certificate using EJBCA

2. Enter Auth_User_1 in the Search end entity with username text field.
3. Click on Search
4. Click on View Certificates for Auth_User_1.
5. Select Unspecified as the revocation reason in the bottom of the page.
6. Click on Revoke
7. A message will appear asking if you are sure you want to revoke the certificate, click
on Ok to accept.
8. Close the popup window.
10.2.2 Use-Case: Re-issuing a Certificate using EJBCA

2. Enter Auth_User_1 in the Search end entity with username text field and click on
Search
3. Click on Edit End Entity for Auth_User_1.
4. Enter foo123 in the Password and Confirm Password text fields.
5. Set Status to New
6. Click on Save
7. Click on Public Web > Create Browser Certificate
8. Enter Auth_User_1 as the username and then enter the password.
9. Click on OK
10. Select 1024 ( Medium Grade in Firefox) as Key length.
11. Click OK
112 (237)
PKI Appliance
Ver: 2.7.2
Part V
VA Setup
113 (237)
PKI Appliance
11. SETTING UP A VA Ver: 2.7.2
Chapter 11
Setting up a VA
11.1 Online Certificate Revocation Protocol

The Online Certificate Status Protocol (OCSP) provides a mechanism by which the revoca-
tion status of a certificate may be checked via an online protocol, called OCSP. OCSP also
provides administrators and programmers with a method to get revocation information on
a specific certificate in real time rather than rely on a CRL that might not have the latest
information or may become large and unwieldy over time.
OCSP communication is very bandwidth efficient and uses a fraction of the bandwidth com-
pared to downloading a large CRL file potentially can.
Some disadvantages when implementing OCSP responders are that communication to the
OCSP responders is required when performing the check. Software or services can not cache
the OCSP requests. To overcome this limitation, some organisations implement a hybrid
model that includes OCSP and CRL technologies. Another disadvantage of OCSP technol-
ogy is that it is inherently more complex than CRLs which are simple signed text files or
LDAP records.
11.2 CRL Distribution Point

A CRL distribution point is an attribute of a certificate that allows the retrieval and checking
of a CRL over the internet by an application.
Some compliance standards state the need for a CRL distribution point in issued subscriber
certificates.
11.3 VA setup scenarios

This chapter will describe two different VA/OCSP setups:
• The first one describes the process where CA-Appliance connects directly with VA-
Appliance via Peer Connector as shown in fig. 11.1.
This configuration is described in:
114 (237)
PKI Appliance
– Use-Case: Install PKI Appliance as dedicated VA,

– Use-Case: Create OCSP Keys in VA-Appliance and
– Use-Case: Create OCSP Key Binding in VA and publisher in CA-Appliance
Figure 11.1: Peer Connector CA-VA setup.
115 (237)
PKI Appliance
• The second setup is more complicated. In that case CA-Appliance publishes CRLs in
an external server and VA-Appliance uses CRL Downloader service to fetch CRLs from
the external server (see fig. 11.2). It is described in:
– Use-Case: Set up a VA-Appliance which fetches CRLs from external server shows
how to setup the VA-Appliance to get CRLs from the external server.
Figure 11.2: VA setup for CRL Downloader service.
116 (237)
PKI Appliance
11.4 Use-Case: Install PKI Appliance as dedicated VA

In CA-Appliance we will rename ManagementCA to PeerMgmtCA.
1. Navigate to AdminWeb and open Certification Authorities link in CA-Appliance
2. Rename the ManagementCA to PeerMgmtCA by highlighting the first one and while
providing the second one in the Add field, press Rename as shown in fig. 11.3
i We rename ManagementCA to a more appropriate one which describes the

purpose it will be used for.
Figure 11.3: Rename ManagementCA to PeerMgmtCA.
Now it is time to get the certificate of the PeerMgmtCA. This will be used for the
installation of VA-Appliance instance.
3. In Public Web under Retrieve section open Fetch CA Certificates see fig. 11.4
117 (237)
PKI Appliance
Figure 11.4: Fetch PeerMgmtCA certificate
118 (237)
PKI Appliance
4. The certificate can be downloaded via Download as PEM next to CA Certificate: (see
fig. 11.5)
Figure 11.5: Download PeerMgmtCA certificate
Now it is time to install VA-Appliance. The installation steps that will be followed
are described in Using External CA for Installation except from the steps that will be
referenced below:
5. When user is prompted to configure network values, adopt a name that defines the
functionality of that PKI Appliance like in fig. 11.6
Figure 11.6: VA network settings
119 (237)
PKI Appliance
In Management CA Settings configuration, an existing one (from CA-Appliance)

will be used.
6. Choose the Use existing Management CA and Browse... for the .pem file that
has been downloaded in a previous step (see fig. 11.7)
Figure 11.7: Install VA with existing ManagementCA
7. Once the .pem is uploaded, fill the SuperAdmin full Subject DN: with the one that
has been used in CA-Appliance (see fig. 11.8).
i This value can be obtained from WebConf in CA-Appliance in ACCESS

tab under MatchValue.
Figure 11.8: Upload external CA
Continue with the rest setup and finish the installation in VA-Appliance.
120 (237)
PKI Appliance
Next step is to change the Application Interface TLS certificate in VA-Appliance.
i We will create a new one which will be signed by PeerMgmtCA.
8. In VA-Appliance, navigate in ACCESS tab (in WebConf) and copy the value of Issuer:
CN= as shown in fig. 11.9
Figure 11.9: Copy issuer value from VA-WebConf
Back in CA-Appliance we will create an end entity which will be issued the new TLS
certificate.
9. In CA-Appliance and AdminWeb create a new end entity via Add End Entity and
provide the following values (see fig. 11.10 and 11.11):
• End Entity Profile SslServerProfile

• Username: ssl_va_app
• Password (or Enrollment Code) foo123
• Confirm Password foo123
• CN, Common name <the_value_you_copied_in_the_previous_step>
• IP Address <the_value_you_copied_in_the_previous_step>
• Certificate Profile SslServerProfile
• CA PeerMgmtCA
• Token User Generated

• Press Add
121 (237)
PKI Appliance
Figure 11.10: Create End Entity in CA-Appliance for VA TLS connections
Figure 11.11: Create End Entity in CA-Appliance for VA TLS connections cont.
122 (237)
PKI Appliance
10. In VA-Appliance we will create a CSR.
• Navigate to ACCESS tab in WebConf in VA-Appliance

• Under Application Interface press Generate new key pair
• A new button will be displayed to create the CSR. Press Create CSR (see
fig. 11.12)
Figure 11.12: Create CSR for Application Interface in VA
• Press Download CSR and save the file as shown in fig. 11.13
Figure 11.13: Download CSR for Application Interface in VA
11. In PublicWeb of CA-Appliance open Create Certificate from CSR (see fig. 11.14).
123 (237)
PKI Appliance
Figure 11.14: Create certificate in CA for VA Application Interface from CSR
12. Provide the Username, Enrollement code which were used for end entity addition
and Browse... for the .csr.pem file we downloaded before (see fig. 11.15).
13. For Result type choose PEM - full certificate chain
14. Press OK
Figure 11.15: Sign certificate for VA Application Interface from CSR
15. Save the signed request as shown in fig. 11.16.
124 (237)
PKI Appliance
Figure 11.16: Download signed certificate for VA Application Interface
16. In VA-Appliance upload the signed request via Browse... (see fig. 11.13)
17. The Next Issuer: is displayed now (see fig. 11.17). Press Activate new cert .
Figure 11.17: Activate new certificate for VA Application Interface
The new configuration will take some seconds to be updated (see fig. 11.18).
Figure 11.18: Updating Application Interface access in VA
18. Since we have renamed ManagementCA to PeerMgmtCA in CA-Appliance instance

we will do the same for VA-Appliance (see fig. 11.19)
125 (237)
PKI Appliance
Figure 11.19: Rename ManagementCA to PeerMgmtCA in VA
19. In VA-Appliance open AdminWeb
20. Navigate to Peer Systems under System Functions
21. Enable only Allow incoming connections. as shown in fig. 11.20.
Figure 11.20: Configure connections in VA
22. In CA-Appliance open AdminWeb
23. Navigate to Peer Systems under System Functions
126 (237)
PKI Appliance
24. Enable only Allow outgoing connections. as shown in fig. 11.21.
25. in the same page create a new connector with Add
Figure 11.21: Configure connections in CA
26. Provide the following values for the connector setup (see fig. 11.22):
• Name: VA1
• URL: https://<application_VA_IP>:443/ejbca/peer/v1
• Authentication Key Binding: Identity created during installation
• Enabled: ticked
27. Press Create
Figure 11.22: Create a Peer Connector in CA
28. Try to ping the connector with Ping button.
127 (237)
PKI Appliance
i At that point we manage to ping VA-peer but no privileges have been

configured yet. That’s why we get the message: Unable to connect to peer.
Unauthorized (see fig. 11.23).
Figure 11.23: Ping to test the connection

In the same view in VA-Appliance we can see that the CA-peer tried to connect with it.
The options that are displayed are to Clear the request or Create authentication
as shown in fig. 11.24. At that point we will create authentication for CA-peer:
29. Press Create authentication
Figure 11.24: Peer systems request in VA
30. We now have the option to either assign an existing role Super Administrator Role
or - Create new role - (see fig. 11.25)
128 (237)
PKI Appliance
Figure 11.25: Authorize connection request from CA
For that connection we will create a new role (see fig. 11.26).
31. Choose - Create new role - as Role:
32. Press Select
Figure 11.26: Create a new role for incoming request
33. Rename Role: as CA_Peer and enable Generic rules:, CAs: and all Publishing:
options (see fig. 11.27)
129 (237)
PKI Appliance
Figure 11.27: Modify Authorization for incoming connections in VA
34. In CA-Appliance manage the peer connector by opening Peer Systems and press
Manage as shown in fig. 11.28
Figure 11.28: Manage peer connector in CA
35. Provide the following values (see fig. 11.29):
• Push certificate: enabled

• Push integrity protection enabled
• Only check for discrepancies (dry run): enabled
• Press Certificate Profile
• Select SslServerProfile
36. Press Start
130 (237)
PKI Appliance
Figure 11.29: Manage Peer Connector in CA
37. The result of that configuration is that now CA-peer is authorized to connect to VA-
peer and perform the actions we configured it in the previous step.
i In the Status field we can see that 3 has been added (see fig. 11.30).
Figure 11.30: Check status of deta synchronization in CA
131 (237)
PKI Appliance
11.5 Use-Case: Create OCSP Keys in VA-Appliance

At that point we will create a Crypto Token and generate a public key (in VA-Appliance)
which will be used from OCSP to sign responses (see fig. 11.31).
4. Populate the form with the following values:
• Name: OCSP key

• Type: PKCS#11
• PKCS#11 Library: Internal HSM

Figure 11.31: Crypto Token for OCSP.
• Check the Auto-activation.

• Click Save
132 (237)
PKI Appliance
• In the settings page the following message will be visible: CryptoToken created
successfully..
5. Create the key for signing OCSP responses.
• Enter signKey with RSA 2048 and click the Generate new key pair button
11.6 Use-Case: Create OCSP Key Binding in VA and publisher

in CA-Appliance
1. In VA-Appliance navigate in Administration pages and open Internal Key Bindings.
2. Create new key binding via Create new... link (see fig. 11.32).
Figure 11.32: Create new OCSP key binding.
3. Provide the following values to set up the key binding (see fig. 11.33):
• Name: VA OcspKeyBinding
• Crypto Token: OCSP key
• Key Pair Alias: signKey
• Signature Algorithm: SHA256WithRSA

• Certificate Authority: PeerMgmtCA and press Add
• ResponderID: KEYHASH
• Include signing certificate in response: checked
• Include certificate chain in response: checked
• Press Create
133 (237)
PKI Appliance
Figure 11.33: Configure OCSP Key Binding.
134 (237)
PKI Appliance
The result is the creation of the key binding and we get the following message: VA
OcspKeyBinding created with id 1255634201 as shown in fig. 11.34.
Figure 11.34: Created OCSP key binding.
4. Click the Back to OcspKeyBinding overview link.
5. Download the CSR via CSR button.
6. Save the file (see fig. 11.35).
Figure 11.35: Download the CSR for OCSP key binding.
7. Navigate to End Entity Profiles under RA Functions back in CA-Appliance.
135 (237)
PKI Appliance
8. Provide OCSPEndEntityProfile in Add Profile text field.
9. Press Add .
10. Highlight OCSPEndEntityProfile and press Edit End Entity Profile (see fig.
11.36).
Figure 11.36: Edit OCSPEndEntityProfile.
11. Uncheck End Entity E-mail
12. Under Subject DN Attributes, next to Subject DN Attributes drop-down menu

choose O, Organization , check Required and provide PrimeKey Labs
13. In the same menu choose C, Country , enable Required and provide SE (see fig.
11.37)
Figure 11.37: Edit OCSPEndEntityProfile cont.
14. Under Main certifcate data section configure the following values (see fig. 11.38):
136 (237)
PKI Appliance
• Default Certificate Profile: OCSPSIGNER

• Available Certifcate Profile: OCSPSIGNER
• Default CA: PeerMgmtCA
• Available CAs: PeerMgmtCA
• Default Token: User Generated

• Available Tokens: User Generated
• Click Save
Figure 11.38: Edit OCSPEndEntityProfile cont.
15. Open Add End Entity in CA-Appliance and provide the following values (see fig.
11.39):
• End Entity Profile: OCSPEndEntityProfile

• Username: OCSP_end_entity
• Password (or Enrollment Code): foo123
• Confirm Password: foo123
• CN, Common Name: OCSP
• Certificate Profile: OCSPSIGNER
• CA: PeerMgmtCA
• Token: User Generated

• Click Add
137 (237)
PKI Appliance
Figure 11.39: Add OCSP End Entity in CA-Appliance.
16. In Public Web of CA-Appliance click Create Certificate from CSR and fill the text
fields with following (see fig. 11.40):
• Username: OCSP_end_entity
• Enrollment code: foo123
• Request file: Browse... for the CSR we downloaded in previous step.
• Result Type: PEM - full certificate chain
• Press OK
Figure 11.40: .
138 (237)
PKI Appliance
Figure 11.41: OCSP CSR is signed successfully.
17. Save the signed CSR as shown in fig. 11.41
18. Back in the VA-Appliance and Internal Key Binding link.
19. Under Import externally issued certificate section use Browse... to upload the
signed CSR (see fig. 11.42).
20. Press Import
Figure 11.42: Upload the signed OCSP CSR in VA.
139 (237)
PKI Appliance
21. In the same page we have to enable the key binding with Enable button (see fig.
11.43).
Figure 11.43: Enable OCSP key binding.
22. Under Set Default Responder choose VA OcspKeyBinding .
23. Click Set
Figure 11.44: Set default responder.
24. In CA-Appliance open Publishers under CA Functions in Admin Web.
25. Write VA1 Publisher in the text field
26. Press Add
27. Now highlight VA1 Publisher and press Edit Publisher (see fig. 11.45).
140 (237)
PKI Appliance
Figure 11.45: Add a publisher in the CA-Appliance.
28. Configure this publisher as follows (see fig. 11.46):
• Publisher Type: Validation Authority Peer Publisher

• Remote System: VA1 (XXXXXXXX)
• Enable usage in the followings:
– Store certificate at the Validation Authority
– Store CRL at the Validation Authority
– Use queue for CRLs
– Use queue for certificates
• Press Save and Test Connection
• Press Save
141 (237)
PKI Appliance
Figure 11.46: Configure the publisher in CA-Appliance.
29. Back in the CA-Appliance via Search End Entities link we can view a certificate
that belongs to the end entity that we’re intressted and download it as <certifi-
cate_to_be_controlled>.pem
30. Run the following command to check its validity towards the OCSP setup:
Run as <user>
openssl ocsp -issuer <issuer>.pem -CAfile <issuer>.pem -cert \

<certificate_to_be_controlled>.pem -req_text -url \
http://<VA_application_interface>:80/ejbca/publicweb/status/ocsp \
-resp_text
142 (237)
PKI Appliance
The output looks like the following:

OCSP R e q u e s t Data :
V e r s i o n : 1 ( 0 x0 )
Requestor L i s t :
C e r t i f i c a t e ID :
Hash A l g o r i t h m : s h a 1
I s s u e r Name Hash : C45788773EDFD1434ED1D8A3C6E3CF176D78B82A
I s s u e r Key Hash : EE5D0AE56A64E9001423A2F6FBFDBFF8BC4266E3
S e r i a l Number : 41DC620FBFCB39C6
Request E x t e n s i o n s :
OCSP Nonce :
04104775 FF9F9A74069EE07ED378AEA83E99
OCSP R e s p o n s e Data :
...
Xu40z8I796LuqZx99W7eYyAutEir+ZLo31szYuDI+Q==
−−−−−END CERTIFICATE−−−−−
R e s p o n s e v e r i f y OK
s s l _ a p p . pem : good
T h i s Update : Dec 4 1 4 : 2 2 : 1 7 2014 GMT
143 (237)
PKI Appliance
11.7 Use-Case: Set up a VA-Appliance which fetches CRLs

from external server
The following setup refers to the description shown in fig. 11.2. In that case the CA is
publishing CRLs in an external server. Configuration below deals with the VA which uses the
CRL Downloader service to fetch and store those CRLs. We assume that the CA is already
publishing CRLs in the external server (this paradigm is for ManagementCA but it holds in
analogous ways for other CAs too). So in the VA-Appliance we have to:
1. Import ManagementCA as External CA in the VA-Appliance. The procedure is

desrcibed in Use-Case: Import RootCA as External CA in node A section.
2. Click Certification Authorities, highlight ManagementCA, (External CA) and

press Edit CA (see fig. 11.47).
Figure 11.47: Import external CA in VA-Appliance.
3. In CRL Specific Data and next to External CRL Distribution Point provide the url
from the external server where the CLR is located (see fig. 11.48).
144 (237)
PKI Appliance
Figure 11.48: Configure the CDP of the CA.
4. Open Services under System Functions.
5. In Add Service provide CRL Downloader and press Add .
6. Highlight CRL Downloader (Inactive) and Edit Service (see fig. 11.49)
Figure 11.49: Add CRL Downloader service.
7. Setup the service with the following values as shown in fig. 11.50:
• Select Worker: CRL Downloader

• CAs to Check: ManagementCA
• Ignore nextUpdate and always download the CRL: enabled
145 (237)
PKI Appliance
i By enabling this option CRL will be downloaded ignoring the nextUpdate

values which is configured in the CA.
• Period: 1 Days
• Active: enabled
• Pin to Specific Node(s): cos-ejbca
• Press Save
Figure 11.50: Configure CRL Downloader service.
Now that we have configured the service to download CRLs from the external server we
have to configure OCSP key binding to authenticate VA-Appliance to sign the responces of
OCSP requests.
This procedure is described in Use-Case: Create OCSP Key Binding in VA and publisher in
CA-Appliance from steps 1 - 24. Just have to consider some naming references that can
differ. Please notice the changes that have to be considered:
• ManagementCA instead of PeerMgmtCA
• and the CA-Appliance is analogous to the CA where ManagementCA is installed.
146 (237)
PKI Appliance
When OCSP key binding is configured, VA-Appliance is ready to respond in OCSP

requests like the following (<unknown_status_certificate>.pem is a certificate signed from
ManagementCA):
Run as <user>
openssl ocsp -issuer ManagementCA.pem -CAfile ManagementCA.pem -cert \

<unknown_status_certificate>.pem -req_text -url \
http://<VA_application_interface>:80/ejbca/publicweb/status/ocsp
The output looks like the following:

OCSP R e q u e s t Data :
V e r s i o n : 1 ( 0 x0 )
Requestor L i s t :
C e r t i f i c a t e ID :
Hash A l g o r i t h m : s h a 1
I s s u e r Name Hash : C45788773EDFD1434ED1D8A3C6E3CF176D78B82A
I s s u e r Key Hash : 320 A617F62005EF984C12ADA0D981A899A300F68
S e r i a l Number : 0758 A7080983F917
Request E x t e n s i o n s :
OCSP Nonce :
04106 C08FFAF175C99CC261E9543CBA525C3
R e s p o n s e v e r i f y OK
<u n k n o w n _ s t a t u s _ c e r t i f i c a t e >.pem : good
T h i s Update : Dec 18 1 0 : 3 7 : 2 2 2014 GMT
147 (237)
PKI Appliance
Ver: 2.7.2
Part VI
EJBCA Advanced Administration
148 (237)
PKI Appliance
12. SEPARATION OF PRIVILEGES Ver: 2.7.2
Chapter 12
Separation of privileges
12.1 EJBCA Access Management

EJBCA provides inherent role based access control for administration and operations. The
authentication to the system is provided via a client certificate and handled as a client SSL
based model to the web application server thus handled outside EJBCA directly by the JBoss
application server.
12.1.1 Managing EJBCA Roles

There are four built in roles provided by EJBCA
CA administrator
A CA administrator can manage certificate profiles, end entity profiles, log configuration
and create RA administrators.
RA administrator
An RA administrator can create, modify, revoke, and delete end entities. An RA
administrator can view existing end entities and their audit history.
Supervisor
A Supervisor can view existing end entities and search the EJBCA log to see end entity
audit history.
Super Administrator
The Super Administrator has overall access to EJBCA and can edit system config-
uration, manage CAs, and create publishers (LDAP, AD, and custom). The Super
Administrator can also create CA administrators.
In this exercise you will utilize all four administrator roles that exist in EJBCA. You
will log into the administrative web interface to use the different administrator roles and
graphically view the interface differences for each role.
149 (237)
PKI Appliance
Use-Case: Create an End Entity Certificate Profile for the Administrator CA

You will create a new end entity profile that you will use to create the new administrators.
1. In the browser on the host machine, open the Administration web interface
2. Click Certificate Profiles in the CA Functions group.
3. Select AuthCertificateProfile from the list box above.
4. Enter AdministratorCertificateProfile in the Add Profile field.
5. Click the Use Selected as Template button.
6. Select AdministratorCertificateProfile .
7. Click the Edit Certificate Profile button.
8. Scroll down to locate the Available CAs list box.
9. Select ManagementCA .
10. Click the Save button,
Creating a New End Entity Profile for the End Entities Using the Administrator CA You
will create a new end entity profile that you will use to create new administrators.
1. Using a web browser, open the Administration web interface and click on End Entity
Profiles.
2. Select AuthEndEntityProfile from the list box.
3. Enter AdministratorEndEntityProfile into the Add Profile field.
4. Click on the Use Selected as Template button.
5. Select AdministratorEndEntityProfile from the list box.
6. Click the Edit End Entity Profile button.
7. For the value of Default Certificate Profile, select AdministratorCertificateProfile

.
8. For the value of Available Certificate Profiles, select AdministratorCertificateProfile

.
9. Scroll down and find the Default CA entry.
10. Select ManagementCA .
150 (237)
PKI Appliance
11. For the Available CAs value, select ManagementCA .
12. Click the Save button.
Use-Case: Issue New Administrator Credentials

This exercise involves the creation of new administrator credentials for each role. The
administrator credentials are certificates with private key material stored in browsers.
Issue a new certificate for the following administrators:
• CA Administrator
– Username = CA_Administrator
– CN = CA Administrator
• RA Administrator
– Username = RA_Administrator
– CN = RA Administrator
• Supervisor
– Username = Supervisor_Administrator
– CN = Supervisor Administrator
• Super Administrator
– Username = SuperAdministrator
– CN = Super Administrator
1. Go to the RA Functions section.
2. Click the Add End Entity link.
3. For the End Entity Profile, choose your end entity profile: AdministratorEndEntityProfile
4. Enter the user name CA_Administrator.
5. In the Password and Confirm Password text field enter foo123.
6. Enter CA Administrator in the Common Name text field.
7. Click Add
8. Click Public Web to enter the public web interface.
9. Click Create Browser Certificate.
10. Enter the user name and password for the user you created.
151 (237)
PKI Appliance
11. Click OK
12. For Key length choose 2048 bit key ( HIGH GRADE if you are using Firefox).
13. Click OK
14. Repeat steps 1 through 13 for the three other administrators.
After the certificates have been generated they should appear in your browser (Firefox,
Safari or Internet Explorer).
Use-Case: Create a CA Administrator Group

This exercise involves the creation of a CA Administrator Group and the assigment of users
to this group.
1. In the Administrative web interface, locate the System Functions group.
2. Click the Administrator Roles link.
3. Click the Add link located at the bottom center of the page.
4. Enter CAAdministratorGroup when prompted for a new name and then click the OK
button.
5. Click the Access Rules link next to the newly created CAAdministrator Group.
6. Select CA Administrators from the Role Template drop down menu.
7. From the Authorized CAs list box, select AuthCAv1 and SSLServerCAv1 .
Use-Case: Adding New Administrators to the CA Administrator Group

This exercise involves the addition of the created CA Administrator user role to the CA
Administrator Group.
1. In the Administrative web interface, locate the RA Functions group.
2. Click Search End Entities
3. Enter CA_Administrator in the Search end entity with username text field and then
click the Find button.
4. Click View Certificates. Doing so opens a new window or tab (depending on your
browsers configuration).
152 (237)
PKI Appliance
5. Copy the value of the Certificate Serial Number using Ctrl-C or Command-C de-
pending on the host operating system (Windows/Linux or Apple respectively).
6. Click the Close button and then select the Administrative web interface tab or
window containing the search results.
7. Click the Administrator Roles link in the System Functions group.
8. Click the Administrators link to the right of the CAAdministratorGroup entry.
9. Select ManagementCA from the CA popup menu. Leave the Match with and
Match type popup menus with their default values.
10. Paste the value of Certificate Serial Number in the Match Value field.
11. Click the Add button.
This process makes the entity associated with that certificate serial number a member of the
CAAdministratorsGroup.
Use-Case: Creating a New RA Administrator Group

You will create a new RA administrator group.
1. In the Administrative web interface, locate the System Functions group.
2. Click the Administrator Roles link.
3. Click the Add link located at the bottom center of the page.
4. Enter RAAdministratorGroup as the name and then click the OK button.
5. Click the Access Rules link to the right of the RAAdministratorGroup.
6. Select RA Administrators from the Role drop down menu.
7. In the Authorized CAs list box, select AuthCAv1 and SSLServer-CAv1 .
8. In the End Entity Rules select everything.
9. In the Edit End Entity Profiles list box, select AuthEndEntityProfile and SSLServerEndEntityProfile
.
10. Leave the Other Rules value as is.
153 (237)
PKI Appliance
Use-Case: Adding New Administrators to the RA Administrator Group

In this exercise, the newly created RA Administrator is added to the RA Administrator group.
1. In the Administrative web interface, locate the RA Function group.
2. Click the Search End Entities link.
3. Enter RA_Administrator in the Search end entity with username field and then
click the Find button.
4. Click the View Certificates link located to the right of the search results. Doing so
opens a new window or tab (depending on your browser’s configuration).
5. Copy the value of the Certificate Serial Number, using Ctrl-C or Command-C de-
pending on the host operating system (Windows/Linux or Mac OS X respectively).
6. Click the Close button and reselect the administrative web interface tab or window
containing the search results.
7. Click on Administrator Roles link in the System Functions group link.
8. Click on the Administrators link for RAAdministratorGroup.
9. Select ManagementCA from the popup menu, leave the Match with and Match
type popup menus with their default values.
10. Paste the value of Certificate Serial Number in the Match Value
11. Click on the Add button
Use-Case: Creating a New Supervisor Group

You will create a new administrator group for the Supervisor.
1. In the administrative web interface locate the System Functions group.
2. Click on Administrator Roles link.
3. Click on the Add link at the bottom center of the page.
4. Enter SupervisorGroup as the name and click the OK button.
5. Click on Access Rules link to the right of the SupervisorGroup.
6. Select Supervisors from the drop down menu.
7. In the Authorized CAs listbox select AuthCAv1 and SSLServerCAv1 .
8. In the Edit End Entity Profiles listbox select AuthEndEntityProfile and SSLServerEndEntityProfile
.
154 (237)
PKI Appliance
9. Leave the Other Rules value as is.
10. Click on the Save button.
Use-Case: Adding New Administrators To the Supervisor Group

You will add your supervisor to the supervisor group.
1. In the administrative web interface locate the RA Functions group
2. Click on Search End Entities link
3. Enter Supervisor_Administrator in the Search end entity with username text field
and click on the Find button.
4. Click on View Certificates link to the right of the search results, this will open a
new window or tab (depending on your browsers configuration)
5. Copy the value of Certificate Serial Number, using Ctrl-C or Command- C depending
on the host operating system (Windows/Linux or Mac OS X respectively).
6. Click the Close button and then reselect the Administrative web interface tab or
window containing the search results.
7. Click the Administrator Roles link located in the System Functions group.
8. Click the Administrators link for SupervisorGroup.
9. Select ManagementCA from the popup menu. Leave the Match with and Match
10. Paste the value of Certificate Serial Number in the Match Value.
Use-Case: Adding New Administrators to the Super Administrator Group

In this exercise, the newly created user will be added to the Super Administrator Group
! DO NOT delete the Super Administrator Role. Pay special attention to

configuration changes to this role as miss-configuration could render the
system to unstable state
1. In the Administrative web interface, locate the RA Functions group.

2. Click the Search End Entities link.
3. Enter SuperAdministrator in the Search end entity with username text field and
then click the Find button.
155 (237)
PKI Appliance
4. Click the View Certificates link located to the right of the search results. Doing so
opens a new window or tab (depending on your browser’s configuration).
5. Copy the value of Certificate Serial Number, using Ctrl-C or Command-C depending
on the host operating system (Windows/Linux or Mac OS X respectively).
6. Click the Close button and reselect the Administrative web interface tab or window
containing the search results.
7. Click the Administrator Roles link in the System Functions group.
8. Click the Administrators link for Super Administrator Role.
9. Select ManagementCA from the popup menu. Leave the Match with and Match
10. Paste the value of Certificate Serial Number in the Match Value.
Use-Case: Test the Different Administrators
! At this point you have to restart your browser
Log in to the EJBCA Admin web by closing the browser and then opening it to the same
URL again. You should see a list with all of the different administrators. Log in as each
administrator type to see the differences among them.
12.1.2 CWA Roles

The CWA 14167-1:2003 provides the following recommenation for roles along with the de-
scription provided. The CWA is a compliance standard commonly used for
Security Officers
Having overall responsibility for administering the implementation of the security poli-
cies and practices.
Registration Officers
Responsible for approving end entity Certificate generation/revocation/ suspension.
System Administrators Are authorised to install, configure and maintain TWSs, but with
controlled access to security-related information.
System Operators
Are responsible for operating TWSs on a day-to-day basis. Authorised to perform
system backup and recovery.
156 (237)
PKI Appliance
System Auditors
Authorised to view archives and audit logs of TWSs.
157 (237)
PKI Appliance
13. KEY RECOVERY Ver: 2.7.2
Chapter 13
Key Recovery
Key recovery is the use of the CA to recover private keys. The CA is able to recover the
keys because it stores them in an encrypted format in the database.
Key recovery can be used for the following types certificates
• Encryption
This is because if a file is encrypted using a public key, the private key is required to
retrieve this. If this is lost, the encrypted data is lost forever.
Key recovery should never be used for the following certificate types
• Authentication
• Digital Signing
If the digital signing private key is lost, the easiest way to continue operations is to have
another digital signing certificate issued with a newly-generated key pair. The data in the
signed documents is never lost and all digital signatures will still be valid if created before
the key was lost and certificates revoked.
Key recover does not have a role in the retrieval of authentication certificates. If the
private key is lost, the easiest way to continue operations is to issue a new authentication
certificate with a newly-generated key pair. Since best practice dictates that an authenti-
cation key never encrypt persistent data (only session data, that is useless within seconds)
there is no need to backup the private key. All authentication prior to the revocation of the
certificate is still valid.
13.1 Profile Requirement

To be able to use key recovery in EJBCA you must activate the key recovery functionality.
You also have to enable the profiles for key recovery.
158 (237)
PKI Appliance
Use-Case: Configure EJBCA for Recovery

This exercise allows an operator to enable key recovery within the CA application.
1. Open the Administrative web interface
2. Click the System Functions > System Configuration link.
3. Select Enable Key Recovery.
4. Click the Save button to commit the changes.
Use-Case: Configure Profiles to Enable Recovery

You will create a new profile that will enable key recovery. The profile used in this exercise
is just an example of the process. You should not enable key recovery for authentication
certificates in a production environment.
1. Open the Administrative web interface.
2. Click the RA Functions > End Entity Profiles link.
3. Select AuthEndEntityProfile from the End Entity Profiles list box.
4. Enter AuthKeyRecEndEntityProfile in the Add Profile text field.
5. Click on the Use selected as template button.
6. Select AuthKeyRecEndEntityProfile and click on the Edit End Entity Profile

button.
7. For Default Token select User Generated .
8. For Available Token select User Generated and P12 .
9. For Key Recoverable select the following options: Use , Default , Reuse old certificate
and Required .
Use-Case: Add a User and Issue an Entity

Now it is time to use your new profile to issue a certificate that we will utilize to perform a
key recovery.
1. Open the Administrative web interface.
2. Click the RA Functions > Add End Entity link.
159 (237)
PKI Appliance
3. From the End Entity Profile popup menu select AuthKeyRecEndEntityProfile .
4. For Username enter keyrec-user1.
5. Enter foo123 in the Password and the Confirm Password field.
6. For Subject DN enter KeyRec User 1 in the CN field.
7. In the Token drop down list select P12 file .
8. Click Add
9. Click the Public Web link to open the public web interface.
10. Click Create Keystore
12. Click OK .
13. For Key length select 2048 bits key.
14. Click OK
15. Save the file as keyrec-user1.p12
Use-Case: Recovering the Lost Entity

Now you will pretend that the user has lost their certificate and you as an administrator have
to perform key recovery.
1. Open the Administrative web interface
2. Click the RA Functions > Search End Entity link.
3. Enter keyrec-user1 in the Search end entity with username text field.
4. Click Search and from the results click View Certificates link for keyrec-user1.
5. Click on Recover Key and close the pop up window.
6. Click on Edit End Entity.
7. Enter foo123 in the Password and Confirm Password field.
8. Click Save .
160 (237)
PKI Appliance
11. Click Create Keystore.
13. Click OK .
14. For Key length choose 2048 bits key (the key size does not matter since it will
recover the old key).
15. Click Enroll
16. Save the file as keyrec-user1-second.p12.
161 (237)
PKI Appliance
14. APPROVAL PROCESS Ver: 2.7.2
Chapter 14
Approval Process
The Approvals process is one way to enforce dual control. When approvals are activated, one
additional administrator is required to accomplish the task. This also provides a mechanism
in which external registration authorities (RA) can validate a user’s information to ensure
that they should be getting a certificate and then place them into an approvals queue for
approval by an administrator. EJBCA supports approvals for adding and editing end entities.
This means that one administrator or administrative process alone will not be able to issue
a certificate for a specified end entity. This is often a good choice if your organisation must
provide checks and balances to the certificate issuance process. The Approvals workflow
for the key recovery process ensures that no single administrator can perform key recovery.
For example, an encryption key used to encrypt/decrypt classified information cannot be
recovered by a single individual. It will require at least two administrators to accomplish
this task, thus providing a safeguard. The Approvals for revocation workflow provides that
two or more administrators are required to approve a revocation request. Depending on the
setup of the infrastructure, this might not be desirable since you typically want to be able to
revoke a rogue certificate as fast as possible. However, in certain instances this functionality
may be desirable or even required.
The Approvals for CA-token activation workflow can ensure that no single individual can
activate a CA. Because the CA is a powerful tool capable of issuing credentials for your
organisation, this workflow is commonly used. For example, this is recommended for root
CA deployments to ensure that no single person can create new CA(s) for the organisation.
Use-Case: Configure CA for Approvals

This exercise enables approvals on AuthCAv1 to ensure that more than one administrator is
required to add and edit end entities.
The first step is to change the CA settings to allow approvals to be implemented
1. Using a web browser on the host system, open the Administrative web interface. Select
the SuperAdmin user.
2. Click the Admin Web > CA Functions > Certification Authorities link.
162 (237)
PKI Appliance
3. Select AuthCAv1 from the list box.
4. Click the Edit CA button.
5. Select the Add/Edit End Entity in the Approval Settings list box.
6. Select 1 under Number of Required Approvals.
8. In the Administrative web interface select Admin Web > System Functions > Administrator
Roles link.
9. Select RAAdministratorGroup and then click the Access Rules link.
10. Add Approve End Entities in the End Entity Rules list box.
12. Click Admin Web > RA Functions > Add End Entity link.
13. Select the AuthEndEntityProfile from the End Entity Profile popup menu .
14. Enter the following values in the associated text boxes, leaving all others at their
default values:
• Username = approval_user1
• Password = foo123
• CN = Approval User 1
15. Click on Add
Use-Case: Approve Issuing of the End Entity

Close your browser and access the administrative GUI as the new RA Administrator created
in earlier.
1. In the Administrative web interface, select Supervisor Functions > Approve Actions.
2. You should see Add End Entity. Approve the end entity by clicking the Approve
button
i The approval window is a popup window. You must have popups enabled
in your browser to approve a certificate
163 (237)
PKI Appliance
4. Click Create Browser Certificate.
6. Click OK .
7. For Key length choose 2048 bit key ( HIGH GRADE for Firefox).
8. Click Enroll
Use-Case: Remove Approvals From CA

This exercise removes approvals from the CA so that To be able to do later exercises without
having to approve every end entity you will remove the approval on AuthCAv1.
1. Log in to the Administrative web interface using SuperAdmin
2. In the Administrative web interface, select CA Functions > Certificate Authorities

link.
3. Select AuthCAv1 from the list box.
4. Click the Edit CA button.
5. Deselect the Add/Edit End Entity in the Approval Settings list box.
164 (237)
PKI Appliance
15. TIMED SERVICES Ver: 2.7.2
Chapter 15
Timed Services
EJBCA provides a number of time triggered services. These are similar to cron jobs in linux
based environments or windows services in windows based environments. These jobs can be
configured to run at specific intervals. The services provided by EJBCA are the CRL Issuer
and Custom Service.
15.1 CRL Updater

The CRL issuer is a service that can be activated by an administrator that will use the CRL
Expire Interval, CRL Issue Interval and CRL Overlap Time and determine whether it should
issue a new CRL for the particular CA for which it is configured.
Use-Case: Configure a CRL Updater

In this exercise, the CRL updater service will be configured. The CRL updater automatically
creates a CRL at a time configured by the application.
1. Open the Admin Web Interface in your browser on the host system
2. Click on Services in the System Functions
3. Enter CRLUpdate in the Add Service text field
4. Click Add
5. Select the CRLUpdate entry in the List of Services text box.
6. Click the Edit Service button
7. Select CRL Updater from the Select Worker popup menu.
8. Select Any CA under CAs to Check list box.
165 (237)
PKI Appliance
15. TIMED SERVICES Ver: 2.7.2
9. From the Select Interval popup menu, select Periodic Interval .
10. In the Period field, enter 30 and then select minutes from the popup menu
11. For the Select Action popup menu leave the No Action default setting
12. Select the Active checkbox.
13. Leave the Description text box blank.
15.2 HSM Keep Alive Service

The service periodically (with configured interval) goes through all available Crypto Tokens
and makes a test signature if the following conditions are met:
• The crypto token is a PKCS#11 crypto token, i.e. have a PKCS#11 library path
configured.
• The crypto token is active.
• The crypto token have a key with alias testKey.
If these conditions are met, a test signature with the testKey is performed. In addition, if
security audit log protection is configured, a test string is protected with the security audit
log protection, also testing this crypto token (which is not available in the crypto tokens in
the GUI).
This will ensure that all configured PKCS#11 slots are used regularly, preventing con-
nection timeouts that could lead to service downtime. You only need to enable this service if
you encounter HSM timeouts. The occurance of such timeouts depend on the specific HSM
used, networking equipment etc.
15.3 Custom Service

The custom service is a service that can be implemented to facilitate code your organisation
or third party has developed. It is an interface that provides execution of the custom code
at a predetermined interval of minutes or hours.
166 (237)
PKI Appliance
16. CUSTOMISING THE WEB GUI Ver: 2.7.2
Chapter 16
Customising the Web GUI
There are limited customization options available for configuring both the public and admin-
istrative web GUI.
16.1 Changing the language

It is possible to change the language of the web GUI. There are several supported language.
Most of the translations are provided by the community. The currently supported languages
are:
• English
• German
• Spanish
• French
• Italian
• Japanese
• Portuguese
• Swedish
Use-Case: Change the default language

1. Access the administrative GUI using appropriate credentials
2. Navigate to System Functions -> My Preferences -> Preferred Language
3. Select ES from the drop down menu
4. Click Save
167 (237)
PKI Appliance
16. CUSTOMISING THE WEB GUI Ver: 2.7.2
5. Observe the language changes in the web page
6. Select EN from the drop down menu
7. Click Save
16.2 Hiding Menu Options

It is possible to hide the menu options for the EJBCA public web. This can be useful when
trying to disable enrolment or access to functions via the public web but still allowing access
to it for the purpose of viewing.
In order to hide the menu of the public web, simply type the URL with the additional
option hidden=true
You can configure web URL based entitlements to prevent access to normal public GUI
URL using a proxy server or some other tool.
Use-Case: Access the public GUI without the menu options

Type the following URL on your browser to access the public GUI:
http://IP_ADDRESS/ejbca/?hidemenu=true
168 (237)
PKI Appliance
17. KEY MANAGEMENT Ver: 2.7.2
Chapter 17
Key Management
PrimeKey’s PKI Appliance has an built in FIPS 140-2 Level 3 certified HSM. It is used to
generate and store cryptographic keys used by the CAs and to perform all signing operations
during issuance of certificates, CRLs and answering OCSP requests. The keys can be man-
aged in the Crypto Tokens menu in EJBCA.
The following HSM manufacturer is used in the PKI Appliance:
• Utimaco CryptoServer Se50 HSM
Use-Case: Create Crypto Tokens

1. Access the EJBCA administration GUI using a user with role Superadministrator
3. Click on the Create New ... hyperlink
4. Populate the form with the following values
• Name: Crypto_HSM
• Type: PKCS#11
i Make sure that you have manually generated slot password for that slot!

• Check the Auto-activation box
169 (237)
PKI Appliance
5. Click Save The following message will be visible: CryptoToken created successfully.
6. In the section below, enter defaultKey as the key alias, RSA 2048 and click the
Generate new key pair button.
7. Next click the Test button.

8. The following message should be visible defaultKey tested successfully.
9. Enter signKey and click the Generate new key pair button.
10. Next click the Test button. The following message should be visible signKey tested
successfully.
11. Enter testKey and click the Generate new Key pair button. The following mes-
sage should be visible testKey tested successfully.
Use-Case: Create the CA

1. Access the EJBCA administration GUI using a user with an appropriate role
2. Navigate to CA Functions > Certification Authorities
3. Type HSMCAv1 as the name and click Create
4. Enter the following items to create the CA
• Crypto Token: Crypto_HSM
• Validity: 5y
• Subject DN: C=SE, CN=HSMCAv1
• CRL Expire Period: 1d
• CRL Issue Interval: 1d
• CRL Overlap Time: 5m
5. Click Create
Use-Case: Renew superadmin certificate

Each certificate has an expiration date. There is always the option for administrators to
renew it when it expires, though the best practice would be to have procedures that prevent
last minute panic situations. The worst case scenario is when administrator’s certificate
expires. Then he’s locked out of the system. Here we will describe a workaround for that
scenarios where the administrator has to have physical access to the PKI Appliance and run
commands in console (if ssh is inactive).
First we will look the current certificate for superadmin:
170 (237)
PKI Appliance
1. Open Admin Web and navigate to RA Functions and Search End Entities,
2. write superadmin in Search end entity with username text field (see figure 17.1)
3. Click Search
Figure 17.1: EJBCA Search End Entity
4. Check the values in superadmin certificate (serial nr., valid from/to, SHA-1, etc in
figure 17.2) by clicking View Certificates
Figure 17.2: EJBCA superadmin certificate
5. Open a terminal and provide the following command to log in to the PKI Appli-
ance
171 (237)
PKI Appliance
Run as <user>
> ssh root@<mgmt interface>

root@<mgmt interface>'s password:
i You’ll have to provide the root password
6. Log in to the VM that hosts EJBCA
Run as root
> ssh cos-ejbca
7. Navigate to EJBCA_HOME/bin
Run as root
> cd /opt/ejbca/bin/
8. Renew the superadmin certificate
Run as root
> ./ejbca.sh ra setendentitystatus superadmin 10

...
New status for end entity superadmin is 10
9. Set password foo123 for superadmin
Run as root
> ./ejbca.sh ra setpwd superadmin foo123

Setting password (hashed only) foo123 for user superadmin
10. Open Public Web of EJBCA and click on Create Browser Certificate Provide
superadmin and foo123 in Username and Enrollment code respectively (see figure
17.3).
172 (237)
PKI Appliance
Figure 17.3: EJBCA Certificate enrollment
11. Restart your browser.
12. Open EJBCA web.
i You will be asked to choose a certificate to authenticate (see fig. 17.4)
Figure 17.4: EJBCA Choose certificate to authenticate
13. Navigate in Admin Web and check the new certificate (see fig. 17.5). You’ll notice
173 (237)
PKI Appliance
that values are matching with the one which is used to authenticate.
Figure 17.5: EJBCA Renewed superadmin certificate
174 (237)
PKI Appliance
18. LOGGING AND MONITORING Ver: 2.7.2
Chapter 18
Logging and Monitoring
18.1 Logging
18.1.1 Security Audit log vs System log
EJBCA provides two different types of logs:
• Security Audit Log - Use for PKI auditors to audit important security PKI events that
the system performed.
• System Log - Used to monitor daily operations in the system, debug and track down
errors etc.
The Security Audit Log logs certificate life cycle events. The Security Audit log logs
important events such as "Certificate issued", "Certificate Profile edited", "Administrator
accessed resource". One of the most important aspects to consider is that the Security
Audit log does not log things that do not happen. Things that do not happen are for
example invalid requests that the system rejects, because the PKI system did not perform
any important audit-able event.
The System Log logs all events that are interesting to monitor, such as rejecting invalid
requests, reading profiles etc.
The main purpose of the Security Audit Log is to provide information to an auditor, and
the auditor wants to know what the system has done, what certificates were issued etc, but
is not so interested in what the system did not do.
The Security Audit Log is stored in the database and the System Log is stored in log files.
By default the System Log also contains the Security Audit Log, but this can be configured.
Security Audit Log
18.2 Monitoring and Health-Check

In EJBCA there exists a health check service that can be used for health monitoring. It is
also useful for cluster, as it can be checked by load balancers to determine if a node should
175 (237)
PKI Appliance
be active in the cluster (healthy) or taken out of the cluster (unhealthy). The servlet is
located in the URL: http://IP_ADDRESS/ejbca/publicweb/healthcheck/ejbcahealth .
The following configuration parameters may be set to configure authorization and what
the service checks:
• healthcheck.amountfreemem, default: 1 - The number of Mb of memory that must be

free.
• healthcheck.dbquery, default: select 1 - Parameter indicating the string that should

be used to do a minimal check that the database is working.
• healthcheck.authorizedips, default: 127.0.0.1 - Specifies which remote IPs that may

call this healthcheck servlet. Use ’;’ between multiple IPs.
• healthcheck.catokensigntest; default: false - if the check of CA tokens should actually

perform a signature test on the CA token, or it should only see if the token status is
active.
• healthcheck.publisherconnections, default: false - Defines if test connections against

all configured publishers should be performed.
By editing a maintenance file on the server, you can make the service return an error
message stating that the server is down for maintenance. This is very useful in a cluster
when you can take cluster nodes in and out of rotation by editing a simple text file.
• healthcheck.maintenancefile, default: not set - location of file containing information

about maintenance.
• healthcheck.maintenancepropertyname default: DOWN_FOR_MAINTENANCE -

the healthcheck.maintenancefile should contain a single line like this
DOWN_FOR_MAINTENANCE=true.
The following parameters configure what message or HTTP error code the health service
returns.
• healthcheck.okmessage, default: ALLOK - Text string used to say that every thing is
ok with this node.
• healthcheck.sendservererror, default: true - if a HTTP errorcode 500 should be sent

in case of error.
• healthcheck.customerrormessage, default: null - Set this parameter if you want a static

error message instead of one generated by the HealthChecker.
If an error is detected one or several of the following error messages is reported.
• MEM: Error Virtual Memory is about to run out, currently free memory : number -
The JVM is about to run out of memory.
176 (237)
PKI Appliance
• DB: Error creating connection to database - JDBC Connection to the database failed,
this might occur if DB craches or network is down.
• CA: Error CA Token is disconnected: CAName - This is a sign of hardware problems

with one or several of the hard ca tokens in the node.
• MAINT: DOWN_FOR_MAINTENANCE - This is reported when the healthcheck.maintenancefile

is used and the node is set to be off line.
• Error when testing the connection with publisher: PublisherName - This is reported
when a test connection to one of the publishers failed.”
18.2.1 snmp
You can activate snmp access to the PKI Appliance by checking this button. All snmp
requests are combined in the "public" community. Now the PKI Appliance will answer to the
two standard MIBS SNMPv2-MIB and HOST-RESOURCES-MIB. Additionaly the following
parameters can be accessed with the following OIDs:
OID
Example Value Value
.1.3.6.1.4.1.22408.1.1.2.1.2.118.109.1
Status of all VMs, 0 if all are running, 1 otherwise 0
.1.3.6.1.4.1.22408.1.1.2.1.3.99.112.117.1
Temperature of the CPU 27
.1.3.6.1.4.1.22408.1.1.2.1.4.118.100.98.49.1
Database usage in % 2
.1.3.6.1.4.1.22408.1.1.2.1.4.118.100.98.50.1
1 if space for db exceeds 80% usage, 0 otherwise 0
.1.3.6.1.4.1.22408.1.1.2.1.4.102.97.110.49.1
rpm of cpu fan 1025
.1.3.6.1.4.1.22408.1.1.2.1.4.102.97.110.50.1
rpm of system fan 1 1126
.1.3.6.1.4.1.22408.1.1.2.1.4.102.97.110.51.1
.1.3.6.1.4.1.22408.1.1.2.1.4.102.97.110.52.1
.1.3.6.1.4.1.22408.1.1.2.1.4.102.97.110.53.1
0 if cpu fan ok, 1 otherwise 0
.1.3.6.1.4.1.22408.1.1.2.1.4.102.97.110.54.1
0 if system fans are ok, 1 otherwise 0
177 (237)
PKI Appliance
.1.3.6.1.4.1.22408.1.1.2.1.5.108.111.97.100.49.1
Load average of the system. Intervals are 1 min, 5 min, 15 min 0.19 0.10 0.06
.1.3.6.1.4.1.22408.1.1.2.1.5.108.111.97.100.50.1
Load average of the system. Intervals is 1 min 0.19
.1.3.6.1.4.1.22408.1.1.2.1.5.108.111.97.100.51.1
.1.3.6.1.4.1.22408.1.1.2.1.5.108.111.97.100.52.1
.1.3.6.1.4.1.22408.1.1.2.1.5.114.97.105.100.49.1
Status of RAID, 0 if active, 1 otherwise 0
.1.3.6.1.4.1.22408.1.1.2.1.5.114.97.105.100.50.1
Status of RAID as string active
.1.3.6.1.4.1.22408.1.1.2.1.5.114.97.105.100.51.1
Devices in RAID Total Devices : 2
.1.3.6.1.4.1.22408.1.1.2.1.5.114.97.105.100.52.1
Devices in RAID as int 2
.1.3.6.1.4.1.22408.1.1.2.1.5.114.97.105.100.53.1
Devices active in RAID Raid Devices : 2
.1.3.6.1.4.1.22408.1.1.2.1.5.114.97.105.100.54.1
Devices active in RAID as int 2
.1.3.6.1.4.1.22408.1.1.2.1.7.118.101.114.115.105.111.110.1
Version of PKI Appliance PrimeKeyAppliance.2.3.0
.1.3.6.1.4.1.22408.1.1.2.1.8.99.108.117.115.116.101.114.49.1
Local node ID 1
.1.3.6.1.4.1.22408.1.1.2.1.8.99.108.117.115.116.101.114.50.1
Db cluster size 3
.1.3.6.1.4.1.22408.1.1.2.1.8.99.108.117.115.116.101.114.51.1
Currently active nodes in db cluster 3
.1.3.6.1.4.1.22408.1.1.2.1.8.99.108.117.115.116.101.114.52.1
Local db cluster (galera) state 4
.1.3.6.1.4.1.22408.1.1.2.1.8.99.108.117.115.116.101.114.53.1
Local db cluster (galera) state as string Synced
.1.3.6.1.4.1.22408.1.1.2.1.8.99.108.117.115.116.101.114.54.1
Last transaction ID 208
.1.3.6.1.4.1.22408.1.1.2.1.8.104.101.97.108.116.104.101.49.1
EJBCA healthcheck as raw string ALLOK
.1.3.6.1.4.1.22408.1.1.2.1.8.104.101.97.108.116.104.101.50.1
EJBCA healthcheck returns 0 for "ALLOK", 1 otherwise 0
178 (237)
PKI Appliance
.1.3.6.1.4.1.22408.1.1.2.1.8.104.101.97.108.116.104.115.49.1
Signserver healthcheck as raw string ALLOK
.1.3.6.1.4.1.22408.1.1.2.1.8.104.101.97.108.116.104.115.50.1
Signserver healthcheck returns 0 for "ALLOK", 1 otherwise 0
.1.3.6.1.4.1.22408.1.1.2.2.4.104.115.109.49.1
Status of HSM as string STATUS_is_OPER
.1.3.6.1.4.1.22408.1.1.2.2.4.104.115.109.50.1
Enum of Status of HSM 0
.1.3.6.1.4.1.22408.1.1.2.2.4.104.115.109.51.1
Status of HSM, 0 if operational, 1 otherwise 0
.1.3.6.1.4.1.22408.1.1.2.2.4.104.115.109.52.1
Battery voltage of HSM 3.100 V
.1.3.6.1.4.1.22408.1.1.2.2.4.104.115.109.53.1
Battery state, 0 if ok, 1 otherwise 0
.1.3.6.1.4.1.22408.1.1.2.2.4.104.115.109.55.1
Battery voltage of external HSM battery 3.272 V
.1.3.6.1.4.1.22408.1.1.2.2.4.104.115.109.56.1
Battery state, 0 if ok or absent, 1 otherwise 0
.1.3.6.1.4.1.22408.1.1.2.2.4.104.115.109.54.1
Serial Number of HSM CS445661
.1.3.6.1.4.1.22408.1.1.2.1.6.109.97.105.110.116.49.1
Maintenance State as int, 0 if operational, 1 if offline or 2 if 0
maintenance
.1.3.6.1.4.1.22408.1.1.2.1.6.109.97.105.110.116.50.1
Maintenance State as string Operational
Alternatively all OIDs can be reached by the following three snmpwalk commands (replace
the ip address with the one of your system):
# for the standard group

snmpwalk -v2c -On -c public 192.168.5.162
# for the system group
snmpwalk -v2c -On -c public 192.168.5.162 .1.3.6.1.4.1.22408.1.1.2.1
# for the HSM group
snmpwalk -v2c -On -c public 192.168.5.162 .1.3.6.1.4.1.22408.1.1.2.2
179 (237)
PKI Appliance
Ver: 2.7.2
Part VII
Appliance in High Availability Setup
180 (237)
PKI Appliance
19. HA SETUP Ver: 2.7.2
Chapter 19
HA Setup
19.1 Scope of availability

For the PKI Appliance the availability is defined as being able to keep the service running with
full data integrity for the applications running on the PKI Appliance that uses the internal
SQL database.
19.1.1 How it works

The cluster implementation used on the PKI Appliance uses regular network connectivity
over the Application Interface for all cluster communication. This means that cluster nodes
don’t have to be placed physically close to each other as long as they have good network
connectivity.
However, this also means that a node cannot distinguish between a node failure of
another node and broken network connectivity to the other node. To avoid the situation
where the cluster nodes operate independently and get diverging data sets (a so called split
brain situation), the cluster nodes take a vote and will cease to operate unless they are part
of the majority of connected nodes. This ensures that there is only one data set that is
allowed to be updated at the time. In the case of a temporary network failure, disconnected
nodes can easily synchronize their data to the majority’s data set and continue to operate.
19.1.2 Synchronization of key material

Key material stored in the HSM is not automatically synchronized after the cluster has been
set up. Manual synchronization is however possible.
19.1.2.1 Pre-cluster setup generation of keys

If suitable for your use-case, you could generate all keys that will be used during the instal-
lations life-time after installing the first node, but before starting the cluster configuration
for the additional nodes. This way, all additional cluster nodes will be provisioned with the
181 (237)
PKI Appliance
complete key material on installation and no additional manual key synchronization will be
necessary.
19.1.2.2 Post-cluster setup generation of keys

When generating new keys (or in any other way modifying the key material) after the cluster
has been setup, you need to manually synchronize the key material.
Note that applications that are connected to the shared database may malfunction if
they try to use references to keys that are not yet synchronized. For example, if a Certificate
Authority in EJBCA is renewed with new key generation, other cluster nodes shortly after
the renewal will try to use the new key. This will fail since the key generation was local to
the node where it was performed.
Use-Case: Synchronize key material

1. On Node 1: Generate the key pair(s) on the first node.
2. On Node 1: Go to the HSM tab of the PKI Appliance WebConf and download a "Clus-
ter Key Synchronization Package" by clicking Download protected HSM backup
.
3. On Node n: Go to the HSM tab of the PKI Appliance WebConf and upload the
package.
4. Repeat step 3 for each node (n>1).
5. Configure the application to start using the new key pair(s).
Since node 1 has higher database quorum vote weight, it is generally advised to generate
the keys there to avoid a reboot and potential downtime in a two node setup.
19.1.3 Network topology

All cluster nodes should have a dedicated connection to all other nodes in the cluster.
However the cluster can propagate the data as long as all nodes are connected to at least
one other node.
The network connection is done via the GRE protocol (IP protocol number 47, see
https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers). Since GRE is an
IP protocol, it is not based on either TCP or UDP and has no concept of ports. It is an
IP protocol by itself. That means that it can not simply be made available with a port
forwarding behind a NAT (Network Address Translation). A fully transparent VPN solution
will be required if the cluster is supposed to be installed over different locations.
If you do have network equipment that is able to encapsulate the protocol, you might
still run into the issue of network address complications. This is easiest worked around
by setting up the systems in a simpler network configuration (e.g. same site) and later
shipment/reconfiguration.
182 (237)
PKI Appliance
A cluster node will never forward traffic between two other nodes to avoid networking
loops. Compared to using the spanning tree protocol (STP), this means that a broken
network connection between two nodes will not trigger any downtime of other connections.
If you prefer the dynamic loop prevention behaviour, you could add managed switches in
front of the Application Interfaces of the PKI Appliances. Please note that if the network
topology change prevents network traffic between the nodes for too long, your cluster nodes
might stop operation and require manual interaction. Rapid Spanning Tree Protocol (RSTP)
might be an interesting alternative to STP in this case.
19.1.4 Cluster traffic security considerations

The current version of the PKI Appliance uses no protection for the cluster traffic. IPSec
will be used in a later release, but for now you need to ensure that this sensitive traffic is
protected by other means.
19.2 Continuous service availability

To ensure that service clients always connect to an operational node in the cluster, an external
load-balancer should be used for automatic fail-over and/or load distribution.
In the case a custom application is being developed for consumption of the services
provided by the PKI Appliances’ external interfaces, this could also be handled by making
the custom application connect to any of the nodes that is found to be operational.
If lower availability and manual interaction is acceptable in case of a node failure, this
could also be solved by redirecting a DNS name to the service.
19.3 Levels of availability

19.3.1 Stand alone instance
This is a basic single node installation of the PKI Appliance. In case of a node failure a
new PKI Appliance needs to be reinstalled from a backup. All data between the time of the
latest backup and the failure will be lost. If a cold stand-by (spare) PKI Appliance is not
available, the time of delivery of a new box needs to be taken into account when calculating
the acceptable downtime.
19.3.2 Hot stand-by with manual fail-over

In this setup, two nodes are connected as a cluster where the first installed node has a higher
quorum vote than the second node.
In the case the second node fails, the first node will continue operating but the second
node will be set into maintenance. In the case the first node fails, the second node will cease
to operate and will be set into maintenance. To bring back the second node into service it
requires manual interaction via the PKI Appliance administrative interface (WebConf).
183 (237)
PKI Appliance
To avoid data loss, the manual interaction is required and the secondary should only be
promoted if the first node really is dead and will be replaced.
19.3.3 High availability with automatic fail-over

This is a setup with three or more nodes. In case of a node failure, the remaining nodes will
still be able to form a cluster through a majority quorum vote and continue to operate. If
the PKI Appliance that has failed is still switched on it will be set into maintenance.
The first cluster node always has a slightly higher quorum vote than the rest of the nodes.
In a setup of an even (4 or more) number of nodes where the nodes are divided over two
sites, the site that has the first node will continue to operate if the connectivity between the
sites fails.
19.4 High Availability

Use-Case: Setting up a 2 node cluster from scratch
1. Make a fresh install according to the normal installation procedure or restore a node
from backup.
2. If possible, generate all keys in the HSM that will be used during the installations
life-time to avoid manual key synchronization later.
3. Go to the cluster tab on the initial node in the PKI Appliance WebConf and add a
connection to where the next node’s Application Interface will be.
4. From the same tab, download the setup bundle for the second node.
5. Factory reset the second node and connect to the web based installer
6. Select Connect to cluster and upload the setup bundle.
7. At this point, both network cables need to be connected to the second node. Start
the installation procedure.
8. After installation completes, you should be able to manage the new node using the
same credentials as the first one.
If the first node has been used for a while before the second node was connected, you
might need to wait until the data is fully synchronized, even after the cluster connection has
completed. When the Local node state in the WebConf’s Status tab shows Ok, the node
is ready for use.
184 (237)
PKI Appliance
Use-Case: Setting up a 3 node cluster from scratch

1. Make a fresh install according to the normal installation procedure or restore a node
from backup.
2. If possible, generate all keys in the HSM that will be used during the installations
life-time to avoid manual key synchronization later.
3. Go to the Cluster tab on the initial node in the PKI Appliance WebConf and add the
two connections to where the next nodes’ Application Interface will be.
4. From the same tab, download the setup bundle for the two new nodes.
5. Factory reset the second node and connect to the web based installer
6. Select Connect to cluster and upload the setup bundle for node 2.
7. At this point, both network cables need to be connected to node 2. Start the instal-
lation procedure.
9. Even if a full synchronization between the first and second node is still running at this
point, you can proceed with the cluster connection of the third node.
10. Factory reset the third node and connect to the web based installer
11. Select Connect to cluster and upload the setup bundle for node 3.
If the first node has been used for a while before the two new nodes were connected, you
might need to wait until the data is fully synchronized, even after the cluster connection has
completed. When the Local node state in the WebConf’s Status tab shows Ok, a node is
ready for use.
Use-Case: Extending a cluster from n to n+1 nodes

1. Go to the cluster tab on all of the existing (n) nodes in the PKI Appliance WebConf
and add a connection to where the next node’s Application Interface will be.
2. From the same tab on one of the nodes, download the setup bundle for the new node
(n+1).
3. Factory reset the new node (n+1) and connect to the web based installer
4. Select Connect to cluster and upload the setup bundle.
185 (237)
PKI Appliance
5. At this point, both network cables need to be connected to the new node. Start the
installation procedure.
6. After installation completes, you should be able to manage the new node (n+1) using
the same credentials as the first one.
When the Local node state in the WebConf’s Status tab shows Ok, the new node is ready
for use.
19.5 Backup, Restore and Update

In the domain of High Availability/Clustering, the topics of backup, restore and update have
to be handled differently as compared to stand alone instances of the PKI Appliance to not
disrupt operation.
19.5.1 Backing up a cluster

Although that you have set up a High Availability Setup to prevent any outages, you should
always take full-out scenario into consideration. In this case, and only in this case, you will
have to recover your cluster from a backup. From operational perspective, it might make
sense to decide to take backups only from node 3 (which is designed to be at a disaster
recovery site off-location) to reduce load and network traffic on the nodes at the main site.
However, it is only with PKI Appliance version 2.3.0 that we properly support recovering
with a backup taken on node 3. Even then, the procedure to recover a full-out disaster is
more complicated if the system is to be restored from a backup of node 3 or node 2 rather
than node 1.
If you can afford, we recommend to set up a automated backup schedule on all of your
nodes to make sure to be able to recover everything, out of every situation, even if perhaps
a failure takes a long time to be discovered.
Generally speaking, a backup always contains all information of a cluster node (config-
uration and database), including its node identity. For example, a backup file taken from
node 3 will not just create any node of a cluster, but exactly node 3 when restored. A node
2 or node 3 is always configured to not run alone after a boot, but only in conjunction with
a node 1 or if manually forced into primary, to be repeated after every reboot. Therefore,
having a backup of node 1 is always preferable when you need to recover your cluster from
a full-out scenario.
19.5.2 Restoring a cluster from backup

A backup file of a cluster node should only be used in the highest emergency of a full-out
scenario. If at least one node remains operational, the cluster should always be reestablished
from the last good node. Pick your case from the following list of Use-Cases:
186 (237)
PKI Appliance
Use-Case: Restoring a cluster from a backup taken on node 1

A backup file of any cluster node should only be restored in a case of utmost emergency. If
you really have to, the first step in recovering your cluster is to restore the backup of the
node 1 to the machine designated to be node 1. Please refer to chapter ?? (on page ??)
for a description on how to restore a backup to a PKI Appliance. The machine should come
up operational, with other cluster nodes/cluster connections configured, but not connected
to them. Make sure that the assigned IP addresses are matching according to your plans.
You can now go ahead, download the cluster setup bundles and start connecting the other
remaining nodes to your node 1 as to reestablish high availability.
Use-Case: Restoring a cluster from a backup taken on node 2 or node 3, PKI

Appliance firmware version 2.2.0 (or older)
A restore of a backup taken on node 2 or node 3 with a PKI Appliance software version
2.2.0 or older is currently not supported. Please contact PrimeKey Support or your local
PrimeKey Partner for support.
Use-Case: Restoring a cluster from a backup taken on node 2 or node 3, PKI

Appliance firmware version 2.3.0
A backup file of any cluster node should only be restored in a case of utmost emergency. If a
cluster needs to be recovered from backup, it is highly recommended to do so with a backup
file that has been created on node 1. If you really have to, the first step in recovering your
cluster from a node 2 or node 3 backup file is to restore the backup to the according machine.
A backup file from node 2 should be restored to the PKI Appliance designated to be node
2, likewise a backup file from node 3 should be restored to the PKI Appliance designated to
be node 3. Please refer to chapter ?? (on page ??) for a description on how to restore a
backup to a PKI Appliance. After reboot, the WebConf will be reachable and operational,
but the database will refuse to start up in this situation, hence the applications will not yet
be operational. (The button Force into Active (formely "Force into Primary") )that the
WebConf offers only starts the database, it does not yet start the applications).
The second step of recovering your cluster is to reestablish your node 1. Make sure
that the assigned IP address is matching according to your plans. You can now go ahead,
download the cluster setup bundle and start connecting the PKI Appliance designed to be
node 1 to the Appliance that you just restored from backup. Node 1 should come up
operational. You might need to force node 1 into primary.
The next step is to connect the remaining third node (node 2 or node 3, depending on
whether you started the operation with node 3 or node 2). To do so, add the cluster node
to the configuration of your two nodes, download either cluster setup bundle and set up the
third PKI Appliance. It should come up fine, operational on database and application.
Once that you have connected all three nodes to each other, you will have to reboot the
cluster node that you initially restored from backup. It will now come up with database and
application operational.
187 (237)
PKI Appliance
19.5.3 Updating the software (firmware/applications) on a cluster

Updating the software of the PKI Appliance will always require a reboot. A reboot of a PKI
Appliance in a cluster should always be scheduled with care as to not accidentally degrade
cluster performance. It is a common mistake to ease up on the operational caution when it
is known that some technical measures are in place to take care of outages and thus give
away any safety margins. In a cluster, software update should be applied on a single node at
a time. Only if the node you are currently working on is completely done with the update
and confirmed to be back up and running should you proceed to updating the next node.
Starting with version 2.2.0, the PKI Appliance firmware is to be updated separately from
the applications installed on the platform of the PKI Appliance. You are supposed to upgrade
both the firmware and the application, starting with the firmware.
A PKI Appliance on a version older than 2.2.0 can not simply be customer-upgraded due
to major architectural changes. Please contact PrimeKey Support or your local PrimeKey
partner for support.
For procedures on how to update a cluster on PKI Appliance version 2.3.0 to an even
newer version, please refer to the even newer documentation delivered with the new software
version.
Use-Case: Software update on a three node cluster from 2.2.0 to 2.3.0

To update a three node cluster from PKI Appliance version 2.2.0 to 2.3.0, please proceed
with the following steps:
1. Before starting any configuration changes on a cluster node, you should assert that the
node has been running fine up to now. This is the only way to know for sure whether
you actually broke anything if the procedure does not succeed as expected.
2. You might also want to make a last manual backup of the PKI Appliance
3. Make sure this cluster node is declared as not operational, (e.g. disabling in load
balancing frontend), so that:
• no other operator does any maintenance on any other node while we deliberately
reduce redundancy on the cluster,
• nobody relies on the availability of this node during maintenance downtime,
• and no alarm is raised if this node gets unavailable.
4. Start the software update procedure on this node by updating the PKI Appliance
firmware first, then updating the COS applications. This should generally be the same
procedure as described in ??: Install firmware, reboot, install application.
5. After the cluster node has been rebooted, check that the node is operating correctly.
6. After you asserted that this node is up and running, verify that the entire cluster is in
good shape, i.e. that all of the cluster nodes of your cluster confirm that your cluster
is back up and running with redundancy.
188 (237)
PKI Appliance
7. Announce this cluster node to be operational back again or whatever you need to undo
from step 3.
8. Continue with updating your cluster by applying the same steps on the next cluster
node, restarting at step 1.
19.6 Controlled full cluster shutdown and startup

This section describes how to do a controlled shutdown of the whole cluster and get back
to a fully running state.
19.6.1 Shutting down the cluster in controlled manner

When shutting down an N node cluster, start with the highest node number and wait until
the node is fully shutdown before proceeding with the next one. This ensures that the quorum
is kept as long as possible and in the end node 1 is the most up to date node.
19.6.2 Starting a fully shutdown cluster

Start by identifying the node that had an OK database status last before the shutdown. If
you performed a controlled shutdown as described in 19.6.1, node 1 is guaranteed to have the
most up to date data. Since the cluster uses synchronous replication, a power outage that
takes down all nodes forming the quorum allows you to start with any of these nodes. If you
have shutdown the nodes in some other order or a minority of nodes had been disconnected,
you need to keep track of which server was holding the quorum last (had database status
OK in WebConf).
1. Power up all nodes.
2. Once the node that has the most up to date copy of the clustered data has started,
promote the node using Force into Active (formerly "Force into Primary").
3. Wait until all N nodes are fully started and database status is OK on each node.
4. If the node you promoted was any other than node 1, reboot this node and wait until
its database status is OK.
19.7 Operational Caution

The cluster will now continuously respond to requests, synchronize the data, and evaluate
the health of the cluster to ensure availability on one hand, but also data integrity on the
other hand. As described earlier, a node will rather stop working than to risk a split brain
situation. A split brain situation develops when two nodes believe they are lone survivors,
continue to serve requests, causing two different database sets.
189 (237)
PKI Appliance
To prevent accidental degradation of the cluster health, some precautions need to be

taken. A planned network reconfiguration could be mistaken to be an emergency by the
cluster, for example.
Maintenance operations on the cluster such as rebooting, updating, network reconfigu-
ration, ... should be restricted to only one node at a time, with ample time for the node to
reconnect and synchronize after the task is completed. Before you proceed to the next node,
make sure that your cluster is back to full health.
Use-Case: Changing the IP Address of the Application Interface of a node in a three

node cluster
In a PKI Appliance cluster, the internal communication is being transferred over the Appli-
cation Interface. Hence, if you need to change the IP address of the Application Interface,
cluster communication will fail at first and you will have to take some manual configuration
steps to bring back the node into play:
1. Before starting any configuration changes on a cluster node, it is good practice to

assert that the node has been running fine up to now. This is the only way to know
for sure whether you actually broke anything if the procedure does not succeed as
expected.
2. You might also want to make a last manual backup of the PKI Appliance.
3. We’ll assume here that you have announced this cluster node as being not operational
(e.g. disabled in a frontend load balancer) for the time of the change.
4. Now start the actual change by changing the Application Interface IP address on the
cluster node in WebConf, see chapter ?? ?? on page ??.
5. Navigate your browser to the Cluster tab of the WebConf on all of the other cluster
nodes.
6. Wait for the cluster node to appear offline/not connected in the cluster connections
table, the IP address should now be in an editable input field.
7. On every of the other cluster nodes, correct the application IP address of the cluster
node in the cluster table.
8. Confirm the operation by hitting Apply . It could be that you have to wait a couple
of seconds before you are allowed to click that button.
9. After the cluster reconfiguration has finished, all cluster nodes should be connected to
all of the other cluster nodes.
10. When everything works as expected, you should not forget to bring back the node into
the load balancer.
190 (237)
PKI Appliance
Replacing a failed cluster node

To replace a failed cluster node, follow the same procedure as you would for adding the
cluster node for the first time. See chapter 19.4 Use-Case: Extending a cluster from n to
n+1 nodes on page 185 for more detailed information. Restoring the node from a backup
will not work because the database content in the backup file will be outdated.
191 (237)
PKI Appliance
20. PKCS#11 SLOT SMART CARD ACTIVATION Ver: 2.7.2
Chapter 20
PKCS#11 Slot Smart Card

Activation
20.1 Introduction
All sensitive cryptographic material of the PKI Appliance is stored on a Hardware Secu-
rity Module (HSM). This HSM protects your key material against physical attacks. The
keys required by the PKI Appliance and your infrastructure are organized in so-called slots,
commonly used with the cryptographic API PKCS#11. To operate on these keys, these
slots must be activated with some authentication code. Depending on your requirements
for availability, usability and security, you can select whether those authentication codes
should be stored on the PKI Appliance or not. This can be chosen per slot. Slots with
stored authentication codes can be auto-activated for immediate availability. The generated
and automatically stored authentication codes are of very high quality. This choice can be
changed even later during the operation of the PKI Appliance.
If even manually entered authentication codes do not meet the security requirements, there
is an option for a two-factor authorization: It is possible to additionally require an activation
with smart cards for one or more slots. This choice has to be done during installation.
20.2 Installation/Configuration
PKCS#11 slot smart card activation can be enabled per slot but only during the installation
of the PKI Appliance. To do so, untick (Automatically generated) Authentication
Code for the slot you want to give more security. You will then be given the possibility to tick
Smart card activated for that slot. Then you will see some more options available for the
general slot smart card activation settings. You still have to define an authentication code
per slot. You can either chose something trivial like 1234 since you are relying to external
secrets anyways, or you can make it even more secure by defining a real secret authentication
code which will be required additionally upon activation.
192 (237)
PKI Appliance
20.2.1 "Number of users required"

It can be chosen how many smart cards should be required to activate a slot. This way a
very important application can be secured even further. However, there is no quorum (like
"3 out of 5") available. If Number of users required: 5 has been chosen, then 5 different
user credentials will be generated and written to 5 different smart cards, all of which need
to be present when activating a slot. The default setting of the PKI Appliance is to create
only one user credential to be required.
20.2.2 "Number/copies of user smart cards"
! Unlike the backup key share on the smart cards, the user credentials can not
be copied from card to card. A lost, broken or blocked smart card can not
be replaced. Therefore the PKI Appliance offers to create sufficient copies,
once and for all.
The default setting of the PKI Appliance is to create 2 smart cards with the same user
credential.
20.2.3 "Require smart cards to activate system after boot"

For highest security concerns, smart card activation can also be enabled for PKCS#11 slot
0, which contains the key that is used to sign the audit log. Since EJBCA produces an audit
log entry for every single action, it needs access to slot 0 for every single action, including
start-up. This effectively means that EJBCA will not be reachable after a system startup
unless slot 0 has been successfully activated by smart card.
20.2.4 Procedure
For every slot activation user that has been chosen, the following procedure will first run
during the installation:
• The user credentials are generated in memory.
• For every copy that has been chosen, the user credentials will be written to a smart
card. It is required to enter the PIN (default PIN on delivery: 123456 ) and acknowledge
with "OK".
• The user credentials (only public key) are read into the HSM, it will only be required
to press the OK button.
After the installation, it is strongly advised to change the PINs of the smart cards through
the WebConf.
193 (237)
PKI Appliance
20.2.4.1 Example with default values

The procedure with an PKI Appliance Security Level of "2 out of 3" and slot smart card
activation on slot 7 with default values 1 user and 2 copies will look like this:
• Backup key shares handling
– One audible alert (bee-beep)

– Generation of the backup key and writing to three cards (with PIN and OK)
– Reading of the backup key from two cards (with PIN and OK)
• Handling of one slot activation user
– Generation of user credentials

– User credential being written to one card (with PIN and OK)
– User credential being written to one card (with PIN and OK)
– Creation of the user within the HSM by reading the public key, (only OK)
20.2.4.2 Slots 0 and 1

If the installation is configured to have smart card activation on slot 0 and slot 1 (Management
CA) Require smart cards to activate system after boot the installation procedure will be
extended by more PIN pad operations since the installer needs access to these slots to create
the keys needed for operation, audit log signature and Management CA respectively.
These extensions will be activation procedures as described in the next section.
20.3 Application/Activation of a slot

Whenever the application will attempt a "Login" to the slot (as when activating a Crypto-
Token in EJBCA), the PKI Appliance will automatically and immediately request the smart
card(s) to be inserted to the PIN pad. This can be noticed by a small audible alert (bee-
beep). The PKI Appliance physical front display will give a short hint at which slot is being
activated and user card is required to be inserted.
! The user cards will always be required in ascending order, always starting
with User 1.
Whenever some PKCS#11 slot activation with smart card goes wrong, the internal PKI
Appliance mechanism will restart all applications, which in turn requires that all slots need
to be activated again.
194 (237)
PKI Appliance
20.3.1 Activation on boot/slot 0

If Require smart cards to activate system after boot has been chosen during installation, on
every system start/boot, the PKI Appliance will first require the successful activation of slot
0 before it can continue with start up. Smart card and PIN have to be entered within one
hour after system start.
195 (237)
PKI Appliance
Ver: 2.7.2
Part VIII
SignServer GUI Operations
196 (237)
PKI Appliance
21. MANAGING WORKERS WITH ADMIN WEB Ver: 2.7.2
Chapter 21
Managing Workers with Admin Web
This chapter uses the new Administration Web interface. For the old Administration GUI
interface, see chapter 22.
21.1 Use-Case: Setting up a PDF Signer

This section describes the setup of a worker for signing PDF documents but the process is
very similar also for other types of workers.
21.1.1 Adding a PDF Signer

1. Click the Workers menu and then the Add... link at the bottom.
Figure 21.1: Add new worker.
2. Click From Template when asked for the method of adding the worker.
197 (237)
PKI Appliance
3. Choose pdfsigner.properties in the drop-down menu and click Next .
4. The sample properties for that worker are displayed and can be adjusted if needed.
Press Apply button.
5. The new worker is added.
21.1.2 Generate keys for PDF Signer
i We assume that the crypto token of the HSM is already activated. In

other case HSMCryptoToken10 (or the one that will be used) has to be
activated by choosing HSMCryptoToken10 from the list of workers, press
Activate and providing the authentication code.
1. The PDFSigner is at this point OFFLINE with the error listed "No signer certificate
available". Click Renew key... button (see fig. 21.2).
Figure 21.2: Generate key.
198 (237)
PKI Appliance
2. At this point we can configure values for the key generation (see fig. 21.3)
Figure 21.3: Configure key.

• Key algorithm: RSA
• Key specification: 2048
4. Click on Generate to start the key generation.
21.1.3 Create CSR for the Signer

1. Next step is to generate the CSR for the PDF worker. Click on Generate CSR...
button and provide the following values (see fig. 21.5):
• Key: Next key

• Signature algorithm: SHA256WithRSA
• DN: CN=My PDF Signer 1
199 (237)
PKI Appliance
Figure 21.5: Provide CSR.
200 (237)
PKI Appliance
2. Click on Download button and save the file as pdfSigner_req.p10 (see fig. 21.6).
Figure 21.6: Save CSR.
3. Click on Cancel to leave the page.
i At this point we have to bring the request to the CA for issuance. In the
current instance we will use EJBCA for that purpose.
201 (237)
PKI Appliance
21.1.4 Configure EJBCA for CSR signing from SignServer Workers

1. Open EJBCA Administration Web page.
2. Navigate to Certificate Profiles in CA Functions (see fig. 22.9).
Figure 21.7: Manage Certificate Profiles.
3. Click on Clone next to ENDUSER profile to copy this certificate profile.
4. Provide SignerCertificateProfile as name of new certificate profile and click Create from template
afterwards (see fig. 22.10).
Figure 21.8: Clone EndUser certificate profile.
202 (237)
PKI Appliance
5. Next to the new SignerCertificateProfile click Edit button (see fig. 22.11).
Figure 21.9: Edit SignerCertificateProfile.
6. Enable Use option in CRL Ditribution Points and provide the URL in CRL Dis-
tribution Point (see fig. 22.12) and delete the auto-generated text in CRL Issuer
field.
7. Click Save
Figure 21.10: Provide CRL distribution point.
8. At RA Functions open End Entity Profiles link.
9. Fill the text field Add Profile with SignerEndEntityProfile.
10. Press Add button.
203 (237)
PKI Appliance
11. Highlight SignerEndEntityProfile and press Edit End Entity Profile (see fig.
22.13)
Figure 21.11: Create SignerEndEntityProfile.
12. For both Default Certificate Profile and Available Certificate Profiles choose
SignerCertificateProfile .
13. Press Save button.
14. At RA Functions click on Add End Entity link and provide the following values (see
fig. 22.14):
• End Entity Profile: SignerEndEntityProfile

• Username: pdfSigner
• CN, Common name: PDF Signer
204 (237)
PKI Appliance
Figure 21.12: Add end entity.
16. Navigate to Public Web.
17. Under Enroll open Create Certificate from CSR link and fill the text fields and
options with (see fig. 22.15):
• Enrollment Code: foo123
• Open Browse... and upload the pdfSigner_req.csr file
• Result type: PEM - full certificate chain
• Press OK
205 (237)
PKI Appliance
Figure 21.13: Sign CSR.
18. Figure 22.16 shows that CSR is signed and the certificate is downloaded.
Figure 21.14: CSR created.
206 (237)
PKI Appliance
21.1.5 Install the certificates in SignServer

1. Back in SignServer Administration Web press Install certificates...
2. Use Browse button to load the PDFSigner.pem certificate in the text area and
then click Add to have it uploaded.
3. If the CA certificates where not included in the first PEM file repeat the previous step
for each issuing CA certificate in order up to the root.
Figure 21.15: Add certificates.
4. Finally click Install button to install it in the worker.
5. The worker should now be in status ACTIVE.
i If the worker is not active use Status Summary tab to check if there
are any errors or the token is listed as offline.
21.2 Use-Case: Signing and verifying a PDF document

This use case assumes that a PDF Signer has been previously setup with the name "PDF-
Signer". See section 21.1.
21.2.1 Sign a PDF document using the PDF Signer

1. Open http://<Application_IP>/signserver URL and click Signing and Validation
Demo.
2. Click PDF link, upload a pdf file and press Submit button (see fig. 22.19). The file
will be signed by PDF worker.
As an alternative the page called "Generic signing" can instead be used. On that page the
user has to input the name of the worker (ie "PDFSigner") that should process the request.
207 (237)
PKI Appliance
Figure 21.16: Sign PDF.
21.2.2 Verify the signed PDF with Adobe Reader

If certificates from your own CA are used and not from a CA already trusted by Adobe
Reader, your CA certificates have to be imported in the application. Note: in a real world
scenario you would want to use certificates issued by a CA already trusted by the application
or have a strategy for how to distribute your CA certificate within your organization.
1. From EJBCA Public Web fetch the CA certificate via Fetch CA Certificates and
Download as PEM (see fig. 22.20)
i The file will be downloaded as ManagementCA.pem. But as Adobe Reader

does not support the .pem file extension, rename it to ManagementCA.cer
instead.
2. In Adobe Reader open Preferences -> Signatures and press More... button in
Identities & Trusted Certificates (see fig. 22.21.)
208 (237)
PKI Appliance
Figure 21.18: Adobe Reader Preferences.
209 (237)
PKI Appliance
3. Click on Trusted Certificates on the menu on the left and then the Import button
from the options on the top of the window (see fig. 22.22).
Figure 21.19: Import trusted certificates.
4. Use the Browse ... to upload the ManagementCA.cer file and click Import
button to install it (see fig. 22.23).
Figure 21.20: Browse for the trusted certificate.
210 (237)
PKI Appliance
5. Now that the certificate is installed press Edit Trust button (see fig. 22.24).
Figure 21.21: Edit trust of the certificate.
6. At least enable the options Use the certificate as a trusted root and Certified documents
(See fig. 22.25). Press OK .
Figure 21.22: Enable trust options.
211 (237)
PKI Appliance
7. Open the document that was signed in step 2 and click Validate All Signatures
(see fig. 22.25).
Figure 21.23: Validate signature.
8. A confirmation dialog pops up which asks you if you want to verify the signatures.
Click OK button to confirm.
9. If the validation is done, another dialog tells you Completed validating all signatures.
Confirm this dialog by clicking OK .
10. The last button on the left will show signature details. Click on Certificate Details...
link (see fig. 22.27).
Figure 21.24: Signature details.
11. The Revocation tab shows information about CRL (see fig. 22.28).
212 (237)
PKI Appliance
Figure 21.25: Revocation details.
213 (237)
PKI Appliance
21.3 Use-Case: Rekeying signers

Eventually the signer certificate will expire and a new certificate is needed for it to continue
working.
The current validity of a signer can be seen in the Administration Web by opening the
signer page and click the Status Properties tab. The field Validity not after shows the
date after which the signer can not be used due to its certificate has expired or its private
key usage period will end.
21.3.1 Generate a new key

1. Open the worker and click Renew key... button.
2. If not already filled in, provide the values for:
• Key algorithm: example: RSA

• Key specification: example: 2048
The Administration Web will suggest the name of the new key to be the current name
with its numeric suffix increased by one (see fig. 21.26).
At this point a new key is available in the HSM slot but the signer is still using the old key as
pointed out with its DEFAULTKEY property. A new property called NEXTCERTSIGNKEY
has been created with the name of the new key so that the GUI will remember it.
21.3.2 Create a certificate signing request

1. Next step is to generate the CSR for the new key. Click on Generate CSR... button
and provide the following values (see fig. 21.27):
• Key: Next key
214 (237)
PKI Appliance
• Signature algorithm: example: SHA256WithRSA

• DN: example: CN=My Signer 1,O=My Organization,C=SE
2. Click Generate
3. Click on Download button and save as mysigner_req.csr.
4. Click on Cancel to leave the page.
5. Bring the request file to the CA to obtain the signer certificate and any CA certificates.
21.3.3 Install the certificates

1. Click Install certificates...
2. If you got one PEM certificate containing both the signer certificate followed by the
CA certificate(s) then you can only have to Browse for that and then add it with
Add . If you got one signer certificate file and the CA certificate(s) separately, then
first browse and add the signer certificate and then each of the issuing CA certificates
in order.
Figure 21.28: Choose certificates.
3. Click Install button to install all the added certificates.
215 (237)
PKI Appliance
4. At this point the Administration GUI has changed the DEFAULTKEY property to point
to the new key and removed the NEXTCERTSIGNKEY property. The worker status
should now switch to ACTIVE.
If the worker status is not ’ACTIVE’ use Status Summary tab to check if there are any
errors or the token is listed as offline.
216 (237)
PKI Appliance
22. MANAGING WORKERS WITH ADMIN GUI Ver: 2.7.2
Chapter 22
Managing Workers with Admin GUI
This chapter uses the old Administration GUI. For the new Administration Web interface see
chapter 21.
22.1 Use-Case: Setting up a PDF Signer

This section describes the setup of a worker for signing PDF documents but the process is
very similar also for other types of workers.
22.1.1 Adding a PDF Signer

1. In the drop down menu open File and click on Add Worker/Load configuration option
(see fig. 22.1).
Figure 22.1: Add new worker.
2. User will be prompted to choose one of the templates for worker configuration.
3. Click ... button from Load From File
217 (237)
PKI Appliance
4. Choose pdfsigner.properties file and click Open button (see fig. 22.2)
Figure 22.2: Choose property file.
5. The sample properties for that worker are displayed and can be adjusted if needed.
Press Apply button (see fig. 22.3).
Figure 22.3: Apply Configuration.
218 (237)
PKI Appliance
6. The new worker is added. Press OK in the confirmation dialog.
22.1.2 Generate keys for PDF Signer
i We assume that the crypto token of the HSM is already activated. In

other case HSMCryptoToken10 (or the one that will be used) has to be
activated by choosing HSMCryptoToken10 from the list of workers, press
Activate and providing the authentication code.
1. The PDFSigner is at this point OFFLINE with the error listed "No signer certificate
available". Highlight PDFSigner and click Renew key... button (see fig. 22.4).
219 (237)
PKI Appliance
2. At this point we can configure values for the key generation (see fig. 22.5)
Figure 22.5: Configure key.
• Key algorithm: RSA

• Key specification: 2048
4. Click on Generate to start the key generation.
220 (237)
PKI Appliance
5. A confirmation dialog shows that the key have been created for the signer. Click on
OK .
22.1.3 Create CSR for the Signer

1. Next step is to generate the CSR for the PDF worker. Click on Generate CSR...
button and provide the following values (see fig. 22.7):
• Key: Next key
• Signature algorithm: SHA256WithRSA

• DN: CN=My Custom PDFSigner 1
221 (237)
PKI Appliance
2. Click on ... button, provide filename pdfSigner_req.csr and the folder it will be
saved to (see fig. 22.8).
Figure 22.8: Save CSR.
3. Click on Generate .
4. A confirmation dialog shows that the CSR is generated. Click on OK .
i At this point we have to bring the request to the CA for issuance. In the
current instance we will use EJBCA for that purpose.
222 (237)
PKI Appliance
22.1.4 Configure EJBCA for CSR signing from SignServer Workers

1. Open EJBCA Administration Web page.
2. Navigate to Certificate Profiles in CA Functions (see fig. 22.9).
Figure 22.9: Manage Certificate Profiles.
3. Click on Clone next to ENDUSER profile to copy this certificate profile.
4. Provide SignerCertificateProfile as name of new certificate profile and click Create from template
afterwards (see fig. 22.10).
Figure 22.10: Clone EndUser certificate profile.
223 (237)
PKI Appliance
5. Next to the new SignerCertificateProfile click Edit button (see fig. 22.11).
Figure 22.11: Edit SignerCertificateProfile.
6. Enable Use option in CRL Ditribution Points and provide the URL in CRL Dis-
tribution Point (see fig. 22.12) and delete the auto-generated text in CRL Issuer
field.
7. Click Save
Figure 22.12: Provide CRL distribution point.
8. At RA Functions open End Entity Profiles link.
9. Fill the text field Add Profile with SignerEndEntityProfile.
224 (237)
PKI Appliance
11. Highlight SignerEndEntityProfile and press Edit End Entity Profile (see fig.
22.13)
Figure 22.13: Create SignerEndEntityProfile.
12. For both Default Certificate Profile and Available Certificate Profiles choose
SignerCertificateProfile .
13. Press Save button.
14. At RA Functions click on Add End Entity link and provide the following values (see
fig. 22.14):
• End Entity Profile: SignerEndEntityProfile

• CN, Common name: PDF Signer
225 (237)
PKI Appliance
Figure 22.14: Add end entity.
16. Navigate to Public Web.
17. Under Enroll open Create Certificate from CSR link and fill the text fields and
options with (see fig. 22.15):
• Enrollment Code: foo123
• Open Browse... and upload the pdfSigner_req.csr file
• Result type: PEM - full certificate chain
• Press OK
226 (237)
PKI Appliance
Figure 22.15: Sign CSR.
18. Figure 22.16 shows that CSR is signed and the certificate is downloaded.
Figure 22.16: CSR created.
227 (237)
PKI Appliance
22.1.5 Install the certificates in SignServer

1. Back in SignServer Administration GUI press Install certificates...
2. Use ... button to upload the PDFSigner.pem certificate in both Signer certificate
and Certificate chain.
3. Click Install button to install it.
4. A message is displayed which informs that the certificate is installed (see fig. 22.17).
Press OK .
Figure 22.17: Certificate installed.
5. Figure 22.18 shows that the worker is active now.
i If the worker is not active use Status Summary tab to check if there
are any errors or the token is listed as offline.
Figure 22.18: Worker is active.
228 (237)
PKI Appliance
22.2 Use-Case: Signing and verifying a PDF document

This use case assumes that a PDF Signer has been previously setup with the name "PDF-
Signer". See section 22.1.
22.2.1 Sign a PDF document using the PDF Signer

1. Open http://<Application_IP>/signserver URL and click Signing and Validation
Demo.
2. Click PDF link, upload a pdf file and press Submit button (see fig. 22.19). The file
will be signed by PDF worker.
Figure 22.19: Sign PDF.
As an alternative the page called "Generic signing" can instead be used. On that page the
user has to input the name of the worker (ie "PDFSigner") that should process the request.
22.2.2 Verify the signed PDF with Adobe Reader

If certificates from your own CA are used and not from a CA already trusted by Adobe
Reader, your CA certificates have to be imported in the application. Note: in a real world
scenario you would want to use certificates issued by a CA already trusted by the application
or have a strategy for how to distribute your CA certificate within your organization.
1. From EJBCA Public Web fetch the CA certificate via Fetch CA Certificates and
Download as PEM (see fig. 22.20)
i The file will be downloaded as ManagementCA.pem. But as Adobe Reader

does not support the .pem file extension, rename it to ManagementCA.cer
instead.
229 (237)
PKI Appliance
2. In Adobe Reader open Preferences -> Signatures and press More... button in
Identities & Trusted Certificates (see fig. 22.21.)
Figure 22.21: Adobe Reader Preferences.
230 (237)
PKI Appliance
3. Click on Trusted Certificates on the menu on the left and then the Import button
from the options on the top of the window (see fig. 22.22).
Figure 22.22: Import trusted certificates.
4. Use the Browse ... to upload the ManagementCA.cer file and click Import
button to install it (see fig. 22.23).
Figure 22.23: Browse for the trusted certificate.
231 (237)
PKI Appliance
5. Now that the certificate is installed press Edit Trust button (see fig. 22.24).
Figure 22.24: Edit trust of the certificate.
6. At least enable the options Use the certificate as a trusted root and Certified documents
(See fig. 22.25). Press OK .
Figure 22.25: Enable trust options.
232 (237)
PKI Appliance
7. Open the document that was signed in step 2 and click Validate All Signatures
(see fig. 22.25).
Figure 22.26: Validate signature.
8. A confirmation dialog pops up which asks you if you want to verify the signatures.
Click OK button to confirm.
9. If the validation is done, another dialog tells you Completed validating all signatures.
Confirm this dialog by clicking OK .
10. The last button on the left will show signature details. Click on Certificate Details...
link (see fig. 22.27).
Figure 22.27: Signature details.
11. The Revocation tab shows information about CRL (see fig. 22.28).
233 (237)
PKI Appliance
Figure 22.28: Revocation details.
234 (237)
PKI Appliance
22.3 Use-Case: Rekeying signers

Eventually the signer certificate will expire and a new certificate is needed for it to continue
working.
The current validity of a signer can be seen in the Administration GUI by selecting the
signer and click the Status Properties tab. The field Validity not after shows the date
after which the signer can not be used due to its certificate has expired or its private key
usage period will end.
22.3.1 Generate a new key

1. Select the worker and click Renew key... button.
2. If not already filled in, provide the values for:
• Key algorithm: example: RSA

• Key specification: example: 2048
The Administration GUI will suggest the name of the new key to be the current name
with its numeric suffix increased by one (see fig. 22.29).
3. Click Generate to start the key generation.
4. A message will be displayed saying: "Renewed keys for all chosen signers."
5. Click on OK .
At this point a new key is available in the HSM slot but the signer is still using the old key as
pointed out with its DEFAULTKEY property. A new property called NEXTCERTSIGNKEY
has been created with the name of the new key so that the GUI will remember it.
235 (237)
PKI Appliance
22.3.2 Create a certificate signing request

1. Next step is to generate the CSR for the new key. Click on Generate CSR... button
and provide the following values (see fig. 22.30):
• Key: Next key
• Signature algorithm: example: SHA256WithRSA

• DN: example: CN=My Signer 1,O=My Organization,C=SE
2. Click on ... button, provide filename mysigner_req.csr and the folder it will be
saved to.
3. Click Generate
4. Bring the request file to the CA to obtain the signer certificate and any CA certificates.
22.3.3 Install the certificates

1. Click Install certificates...
2. If you got one PEM certificate containing both the signer certificate and any signer
certificate then you can use the ... button in the Certificate chain column to select
the file.
If you instead got two files, one with the signer certificate and one with the CA
certificates use the Signer certificate column for the signer certificate file and the
Certificate chain for the CA certificate file.
3. Click Install button to install it.
4. A message is displayed which informs that certificates are installed. Press OK .
236 (237)
PKI Appliance
Figure 22.31: Choose certificates.
5. At this point the Administration GUI has changed the DEFAULTKEY property to point
to the new key and removed the NEXTCERTSIGNKEY property. The worker status
should now switch to ACTIVE.
If the worker status is not ’ACTIVE’ use Status Summary tab to check if there are any
errors or the token is listed as offline.
237 (237)

Pki Appliance Operations Manual: Public Key Infrastructure by Primekey

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Pki Appliance Operations Manual: Public Key Infrastructure by Primekey

Hochgeladen von

Copyright:

Verfügbare Formate

PKI Appliance

Public Key Infrastructure by PrimeKey

To report errors, please send a note to support@primekey.com

3 PKI Appliance Overview 5

4 Using External CA for Installation 7

III Appliance Operations 22

IV EJBCA GUI Operations 45

8 Certificate Life Cycle Management 46

VI EJBCA Advanced Administration 148

12 Separation of privileges 149

13 Key Recovery 158

15 Timed Services 165

16 Customising the Web GUI 167

17 Key Management 169

18 Logging and Monitoring 175

VII Appliance in High Availability Setup 180

20 PKCS#11 Slot Smart Card Activation 192

VIII SignServer GUI Operations 196

21 Managing Workers with Admin Web 197

22 Managing Workers with Admin GUI 217

4.1 Logical hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.1 EJBCA TLS check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.5 WebConf Create CSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

9.1 Node B with RootCA installed . . . . . . . . . . . . . . . . . . . . . . . . . 50

9.23 Save RootCA pem file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

9.64 Edit SSLCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

11.1 Peer Connector CA-VA setup. . . . . . . . . . . . . . . . . . . . . . . . . . . 115

11.15Sign certificate for VA Application Interface from CSR . . . . . . . . . . . . 124

17.1 EJBCA Search End Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

21.1 Add new worker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

21.2 Generate key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

22.1 Add new worker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

22.16CSR created. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

PKI Appliance 2.7.2 Release Notes

Minor tweaks and bug fixes:

Known Issues and Limitations:

2.1.1 Styling Conventions

i This is an informative message containing extra information.

! This is a warning message.

2.1.2 Daily operations

Use-Case: Install PKI Appliance

PKI Appliance Overview

Using External CA for Installation

• configure MARX CrypToken smart card with Firefox,

• install the second PKI Appliance by using an ExternalCA certificate.

i General installation instructions can be found in ??.

The use-case is that we have ManagementCA to be the super-administrator for operat-

Figure 4.1: Logical hierarchy

Figure 4.2: Node A -Physical Infrastructure with online PKI Appliance

Figure 4.3: Node B - Physical Infrastructure with offline PKI Appliance

4.1 Smart Card Setup

Use-Case: Smart Card Installation in Firefox

Figure 4.4: Security Devices in Firefox

Figure 4.5: Device Manager in Firefox

Module Name and Module filename has to be provided. In Module filename we

Figure 4.6: Load module in Firefox

Figure 4.7: Device Manager in Firefox

Figure 4.8: Device Manager in Firefox

Use-Case: Install the first PKI Appliance

Figure 4.9: First login to the PKI Appliance

Figure 4.10: Notification for untrusted network

Figure 4.11: Checking TLS fingerprint

i Through TLS fingerprint, the PKI Appliance is authenticated to us