Practical Guide to PKI

with Windows Server

Matthew Burr
Practical Guide to PKI with Windows Server

by Matthew Burr

Copyright © 2021 Matthew Burr (https://mjcb.io/)

All rights reserved. This publication is protected by copyright, and permission must be obtained prior to any reproduction of this
publication. No part of the contents of this book may be reproduced or transmitted in any form or by any means without the
express written permission of the author.

ISBN: 978-1-7774422-0-0
ISBN: 978-1-7774422-1-7

Trademarks

• Active Directory Domain Services, Active Directory Certificate Services, Edge, File Explorer, Hyper-V, Internet Explorer,
Microsoft Certificate Server, Windows 10, Windows Server (2000, 2003, 2003 R2, 2008, 2008 R2, 2012, 2012 R2, 2016
and 2019) and Windows Update are trademarked to the Microsoft Corporation.
• Android and Chrome are trademarked to Google LLC.
• Apache HTTP Server is trademarked to the Apache Software Foundation.
• Firefox is trademarked to the Mozilla Foundation.
• iOS, iPad, iPadOS, iPhone, macOS, and Safari are trademarked to Apple Inc.
• Linux is trademarked to Linus Torvalds in the U.S. and other countries.
• Nginx is trademarked to F5 Networks, Inc.
• OpenSSL is trademarked to the OpenSSL Software Foundation.
• Ubuntu is trademarked to Canonical Ltd.
• VirtualBox is trademarked to Oracle.
• VMware Workstation is trademarked to VMware Inc.

Warning and Disclaimer

This book expresses the author’s views and opinions. The information contained within this book is provided without any
express, statutory, or implied warranties. The author will not be held liable for any damages caused by or alleged to be caused
directly or indirectly by this book. Reasonable efforts have been made to ensure the accuracy of the information and contents
of this book. Even though all precautions have been taken in the research and publication of this book, the author assumes no
responsibility for errors or omissions. No liability is assumed for damages resulting from the use of the information contained
in this book.

The examples contained within this book make references to companies, domain names, e-mail addresses, users,
organizations, and other scenarios. All references that are contained within this book are fictitious. There is no association with
any real company with any of the provided examples.

It is strongly recommended to test the steps and procedures provided in this book prior to using it in a production environment.
Details on how to test the steps and procedures in this book are provided.

The author reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

Revision History

2021-09-13 - First Edition Release

Additional Information

See https://mjcb.io/publications/practical-guide-to-pki-with-windows-server/ for additional details, updates, and any online

resources for this book.
I would like to dedicate this book to my wife, who has supported me for all the time that I
spent working on this book, and on all the other projects that I enjoy working on.
Contents at a Glance

About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Chapter 1 - Public Key Infrastructure Overview . . . . . . . . . . . . . . . . . . . 1
Chapter 2 - Certificate Authority Test Environment . . . . . . . . . . . . . . . . . 25
Chapter 3 - Domain Controller and Workstation Setup . . . . . . . . . . . . . . . 51
Chapter 4 - Offline Root CA Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Chapter 5 - Subordinate CA Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Chapter 6 - Deploy Root and Subordinate Certificates . . . . . . . . . . . . . . . 205
Chapter 7 - Online Responder Role Configuration . . . . . . . . . . . . . . . . . . 219
Chapter 8 - Private Key Archive and Recovery . . . . . . . . . . . . . . . . . . . . 251
Chapter 9 - Certificate Template Customization . . . . . . . . . . . . . . . . . . . 265
Chapter 10 - Certificate Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Chapter 11 - AD CS Post-Implementation Tasks . . . . . . . . . . . . . . . . . . . 311
Chapter 12 - AD CS Quick Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

Contents at a Glance | v
Table of Contents

About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Who Is This Book For? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Conventions Used in This Book . . . . . . . . . . . . . . . . . . . . . . . . . xv
Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Information Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Goals of This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
What Won’t This Book Cover? . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Before You Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
AD CS Installation and Configuration Options . . . . . . . . . . . . . xxi
Virtualization Requirements . . . . . . . . . . . . . . . . . . . . . . . xxi
Organization of this Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii
Chapter 1 - Public Key Infrastructure Overview . . . . . . . . . . . . . . . . . . . 1
What Is a Public Key Infrastructure? . . . . . . . . . . . . . . . . . . . . . . . 2
Active Directory Certificate Services Overview . . . . . . . . . . . . . . . . . 4
Active Directory Certificate Services Roles . . . . . . . . . . . . . . . . . . . 6
Certificate Authority Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . 7
One-Tier Certificate Authority . . . . . . . . . . . . . . . . . . . . . . 8
Two-Tier Certificate Authority . . . . . . . . . . . . . . . . . . . . . . 9
Three-Tier Certificate Authority . . . . . . . . . . . . . . . . . . . . . 10
Certificate Authority and PKI Terminology . . . . . . . . . . . . . . . . . . . . 12
X.509 Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Certificate Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Certificate Revocation Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Certificate Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Private Enterprise Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Why Use an Offline Root CA? . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Windows Certificate Management . . . . . . . . . . . . . . . . . . . . . . . . 21
Public Key Infrastructure Overview Next Steps . . . . . . . . . . . . . . . . . 23
Chapter 2 - Certificate Authority Test Environment . . . . . . . . . . . . . . . . . 25
Certificate Authority Environment Design and Overview . . . . . . . . . . . . 26
Certificate Authority Design Considerations . . . . . . . . . . . . . . . . . . 29
Certificate Hierarchy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 30
AD CS Internal URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
AD CS Important Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
AD CS Important Files - TFS-CA01 . . . . . . . . . . . . . . . . . . . . 33
AD CS Important Files - TFS-DC01 . . . . . . . . . . . . . . . . . . . . 34
AD CS Important Files - TFS-ROOT-CA . . . . . . . . . . . . . . . . . . 35
AD CS Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Table of Contents | vii

 Certificate Authority Naming Conventions . . . . . . . . . . . . . . . . . . . 36
Hyper-V Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Hyper-V Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Hyper-V Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Enable Hyper-V using the Control Panel . . . . . . . . . . . . . 40
Enable Hyper-V using PowerShell . . . . . . . . . . . . . . . . 41
Enable Hyper-V using DISM . . . . . . . . . . . . . . . . . . . . 42
Hyper-V Network Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Hyper-V Virtual Machine Generation . . . . . . . . . . . . . . . . . . . 44
Hyper-V Checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Hyper-V Virtual Machine Creation . . . . . . . . . . . . . . . . . . . . 45
Hyper-V Virtual Machine Connection . . . . . . . . . . . . . . . . . . 46
Hyper-V Disk Virtual Floppy Disk Management . . . . . . . . . . . . . 48
Certificate Authority Test Environment Next Steps . . . . . . . . . . . . . . . 50
Chapter 3 - Domain Controller and Workstation Setup . . . . . . . . . . . . . . . 51
Domain Controller Server Setup . . . . . . . . . . . . . . . . . . . . . . . . . 52
AD DS Role Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
AD DS Role Installation - GUI Installation . . . . . . . . . . . . . . . . 53
AD DS Role Installation - CLI Installation . . . . . . . . . . . . . . . . 59
AD DS Role Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
AD DS Role Configuration - GUI Configuration . . . . . . . . . . . . . 62
AD DS Role Configuration - CLI Configuration . . . . . . . . . . . . . 67
AD DS Role Configuration - Validation . . . . . . . . . . . . . . . . . . 69
Create an Active Directory OU Structure . . . . . . . . . . . . . . . . . . . . . 70
Create an Active Directory OU Structure - GUI Configuration . . . . . 70
Create an Active Directory OU Structure - CLI Configuration . . . . . 73
Create Domain User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Create Domain User Accounts - GUI Configuration . . . . . . . . . . . 75
Create Domain User Accounts - CLI Configuration . . . . . . . . . . . 78
Workstation Creation and Domain Join . . . . . . . . . . . . . . . . . . . . . 79
LDAP over SSL for Active Directory . . . . . . . . . . . . . . . . . . . . . . . 82
Domain Controller and Workstation Next Steps . . . . . . . . . . . . . . . . 86
Chapter 4 - Offline Root CA Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Root CA Server Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Optional: Add BitLocker on the Root CA . . . . . . . . . . . . . . . . . 89
Add BitLocker on the Root CA - GUI Installation . . . . . . . . 91
Add BitLocker on the Root CA - CLI Installation . . . . . . . . 96
Optional: Configure Group Policy for BitLocker on the Root CA . . . . 97
Optional: Enable BitLocker on the Root CA . . . . . . . . . . . . . . . 99
Optional: Test BitLocker on the Root CA . . . . . . . . . . . . . . . . 102
Test the BitLocker Recovery Key . . . . . . . . . . . . . . . . . 102
Mount the BitLocker Hard Disk on Another Device . . . . . . . 103
Back Up the BitLocker Recovery Key . . . . . . . . . . . . . . . 104
Optional: Disable Windows Update on the Root CA . . . . . . . . . . 105
Root CA Server Local Policies . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Root CA CAPolicy.inf Installation . . . . . . . . . . . . . . . . . . . . . . . . . 110

viii | Practical Guide to PKI with Windows Server

 Root CA AD CS Role Installation . . . . . . . . . . . . . . . . . . . . . . . . . 111
Root CA AD CS Role Installation - GUI Installation . . . . . . . . . . . 112
Root CA AD CS Role Installation - CLI Installation . . . . . . . . . . . 118
Root CA AD CS Role Configuration . . . . . . . . . . . . . . . . . . . . . . . . 119
Root CA AD CS Role Configuration - GUI Configuration . . . . . . . . 120
Root CA AD CS Role Configuration - CLI Configuration . . . . . . . . 126
Root CA Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Root CA CRL Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Enable Auditing on the Root CA . . . . . . . . . . . . . . . . . . . . . . . . . 132
Root CA CDP and AIA Configuration . . . . . . . . . . . . . . . . . . . . . . . 134
Root CA CDP and AIA Configuration - GUI Configuration . . . . . . . 134
Root CA CDP and AIA Configuration - CLI Configuration . . . . . . . . 139
Root CA Certificate and CRL Export . . . . . . . . . . . . . . . . . . . . . . . 140
Root CA Server Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Root CA Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Chapter 5 - Subordinate CA Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Subordinate CA Server Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Create CNAME Records in DNS . . . . . . . . . . . . . . . . . . . . . . . . . 143
Create CNAME Records in DNS - GUI Configuration . . . . . . . . . . 144
Create CNAME Records in DNS - CLI Configuration . . . . . . . . . . 146
Create CNAME Records in DNS - Validation . . . . . . . . . . . . . . 146
Subordinate CA CAPolicy.inf Installation . . . . . . . . . . . . . . . . . . . . 147
Subordinate CA AD CS Role Installation . . . . . . . . . . . . . . . . . . . . . 148
Subordinate CA AD CS Role Installation - GUI Installation . . . . . . . 149
Subordinate CA AD CS Role Installation - CLI Installation . . . . . . . 157
Subordinate CA AD CS Role Configuration . . . . . . . . . . . . . . . . . . . 158
Subordinate CA AD CS Role Configuration - GUI Configuration . . . . 159
Subordinate CA AD CS Role Configuration - CLI Configuration . . . . 165
Subordinate CA Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Create the CertData Virtual Directory . . . . . . . . . . . . . . . . . . . . . . 168
Create the CertData Virtual Directory - GUI Configuration . . . . . . . 169
Create the CertData Virtual Directory - CLI Configuration . . . . . . . 172
Create the CertData Virtual Directory - Validation . . . . . . . . . . . 172
Enable Double Escaping in IIS . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Subordinate Certificate Creation . . . . . . . . . . . . . . . . . . . . . . . . . 174
Set Maximum Certificate Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Modify the CertEnroll Virtual Directory . . . . . . . . . . . . . . . . . . . . . . 184
Modify the CertEnroll Virtual Directory - GUI Configuration . . . . . . 184
Modify the CertEnroll Virtual Directory - CLI Configuration . . . . . . 186
Modify the CertEnroll Virtual Directory - Validation . . . . . . . . . . . 187
Enable Auditing on the Subordinate CA . . . . . . . . . . . . . . . . . . . . . 188
Subordinate CA CDP and AIA Configuration . . . . . . . . . . . . . . . . . . . 189
Subordinate CA CDP and AIA Configuration - GUI Configuration . . . 189
Subordinate CA CDP and AIA Configuration - CLI Configuration . . . 194
Certification Practice Statement Document . . . . . . . . . . . . . . . . . . . 195
Windows Firewall Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 197

Table of Contents | ix
 Add the Root CA to Active Directory . . . . . . . . . . . . . . . . . . . . . . . 199
Verify PKI Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Subordinate CA Server Restart . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Subordinate CA Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Chapter 6 - Deploy Root and Subordinate Certificates . . . . . . . . . . . . . . . 205
Prepare the Root and Subordinate Certificates . . . . . . . . . . . . . . . . . 206
Deploy the Root and Subordinate Certificates to the Domain . . . . . . . . . 208
Deploy the Root Certificate to the Domain Controller . . . . . . . . . . . . . 214
Internal Certificate File Deployment Folder . . . . . . . . . . . . . . . . . . . 215
Internal Certificate File Deployment Folder - GUI Configuration . . . . 216
Internal Certificate File Deployment Folder - CLI Configuration . . . . 216
Internal Certificate File Deployment Folder - Validation . . . . . . . . 217
Deploy Root and Subordinate Certificates Next Steps . . . . . . . . . . . . . 217
Chapter 7 - Online Responder Role Configuration . . . . . . . . . . . . . . . . . . 219
Add the Online Responder Role . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Add the Online Responder Role - GUI Installation . . . . . . . . . . . 220
Add the Online Responder Role - CLI Installation . . . . . . . . . . . . 221
Enable the Online Responder Role . . . . . . . . . . . . . . . . . . . . . . . . 222
Enable the Online Responder Role - GUI Configuration . . . . . . . . 222
Enable the Online Responder Role - CLI Configuration . . . . . . . . . 225
Enable the Online Responder Role - Validation . . . . . . . . . . . . . 225
Add the OCSP URL to the Subordinate CA . . . . . . . . . . . . . . . . . . . . 226
Add the OCSP URL to the Subordinate CA - GUI Configuration . . . . 226
Add the OCSP URL to the Subordinate CA - CLI Configuration . . . . 228
Configure and Publish the OCSP Response Signing Certificate . . . . . . . . 228
Revocation Configuration for the Online Responder Role . . . . . . . . . . . 233
Enable Auditing on the Online Responder . . . . . . . . . . . . . . . . . . . . 241
Add the OCSP URL to Group Policy . . . . . . . . . . . . . . . . . . . . . . . 244
Verify OCSP Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Test OCSP Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Online Responder Role Limitations . . . . . . . . . . . . . . . . . . . . . . . . 250
Online Responder Role Next Steps . . . . . . . . . . . . . . . . . . . . . . . . 250
Chapter 8 - Private Key Archive and Recovery . . . . . . . . . . . . . . . . . . . . 251
Create the Key Recovery Agent Certificate Template . . . . . . . . . . . . . . 252
Deploy the Key Recovery Agent Certificate . . . . . . . . . . . . . . . . . . . 258
Configure the Certificate Authority for Key Recovery . . . . . . . . . . . . . . 261
Private Key Archive and Recovery Next Steps . . . . . . . . . . . . . . . . . . 263
Chapter 9 - Certificate Template Customization . . . . . . . . . . . . . . . . . . . 265
Active Directory Certificate Templates . . . . . . . . . . . . . . . . . . . . . . 266
User Certificate Template Creation . . . . . . . . . . . . . . . . . . . . . . . . 268
User Certificate Private Key Recovery . . . . . . . . . . . . . . . . . . 270
Computer Certificate Template Creation . . . . . . . . . . . . . . . . . . . . 273
Web Server Certificate Template Creation . . . . . . . . . . . . . . . . . . . . 275
Delete Unnecessary Certificate Templates . . . . . . . . . . . . . . . . . . . 278
Active Directory Certificate Services Web Enrollment . . . . . . . . . . . . . 280
Certificate Template Deployment Next Steps . . . . . . . . . . . . . . . . . . 283

x | Practical Guide to PKI with Windows Server

Chapter 10 - Certificate Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . 285
User Certificate Auto-Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . 286
Computer Certificate Auto-Enrollment . . . . . . . . . . . . . . . . . . . . . . 288
Optional: Deploy Certificates to a Linux Server . . . . . . . . . . . . . . . . . 291
Deploy Certificates to a Linux Server - Server Setup . . . . . . . . . . 291
Deploy Certificates to a Linux Server - CSR Request . . . . . . . . . . 292
Deploy Certificates to a Linux Server - Apache Setup . . . . . . . . . 295
Deploy Certificates to a Linux Server - Nginx Setup . . . . . . . . . . 297
Optional: Deploy Certificates to Android . . . . . . . . . . . . . . . . . . . . . 298
Optional: Deploy Certificates to iOS . . . . . . . . . . . . . . . . . . . . . . . 302
Optional: Deploy Certificates to macOS . . . . . . . . . . . . . . . . . . . . . 308
Certificate Enrollment Next Steps . . . . . . . . . . . . . . . . . . . . . . . . 310
Chapter 11 - AD CS Post-Implementation Tasks . . . . . . . . . . . . . . . . . . . 311
Virtual Floppy Disk Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Root CA Shut Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Renewing the Root CA CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Manually Back Up the PKI Infrastructure . . . . . . . . . . . . . . . . . . . . 314
Active Directory Former Certificate Authorities . . . . . . . . . . . . . . . . . 319
Test Active Directory Certificate Services on your Domain . . . . . . . . . . 322
AD CS Post-Implementation Tasks Next Steps . . . . . . . . . . . . . . . . . 324
Chapter 12 - AD CS Quick Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
AD CS Quick Start - Environment Setup . . . . . . . . . . . . . . . . . . . . . 326
AD CS Quick Start - AD DS Setup . . . . . . . . . . . . . . . . . . . . . . . . . 329
AD DS Setup - AD DS Installation . . . . . . . . . . . . . . . . . . . . . 330
AD DS Setup - AD DS Configuration . . . . . . . . . . . . . . . . . . . 330
AD DS Setup - OU Configuration . . . . . . . . . . . . . . . . . . . . . 331
AD DS Setup - Administrator Configuration . . . . . . . . . . . . . . . 332
AD DS Setup - Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 332
AD CS Quick Start - Root CA Setup . . . . . . . . . . . . . . . . . . . . . . . . 333
Root CA Setup - Local Policies . . . . . . . . . . . . . . . . . . . . . . 333
Root CA Setup - CAPolicy.inf Installation . . . . . . . . . . . . . . . . 334
Root CA Setup - AD CS Role Installation . . . . . . . . . . . . . . . . . 335
Root CA Setup - AD CS Role Configuration . . . . . . . . . . . . . . . 336
Root CA Setup - Root CA Validation . . . . . . . . . . . . . . . . . . . 337
Root CA Setup - Root CA CRL Configuration . . . . . . . . . . . . . . 337
Root CA Setup - CDP and AIA Configuration . . . . . . . . . . . . . . 340
Root CA Setup - Root CA Certificate and CRL Export . . . . . . . . . 341
Root CA Setup - Next Steps . . . . . . . . . . . . . . . . . . . . . . . . 341
AD CS Quick Start - Subordinate CA Setup . . . . . . . . . . . . . . . . . . . 342
Subordinate CA Setup - Create CNAME Records in DNS . . . . . . . . 343
Subordinate CA Setup - CAPolicy.inf Installation . . . . . . . . . . . . 343
Subordinate CA Setup - AD CS Role Installation . . . . . . . . . . . . 344
Subordinate CA Setup - AD CS Role Configuration . . . . . . . . . . . 345
Subordinate CA Setup - Subordinate CA Validation . . . . . . . . . . 346
Subordinate CA Setup - Create the CertData Virtual Directory . . . . 347
Subordinate CA Setup - Enable Double Escaping in IIS . . . . . . . . 348

Table of Contents | xi
 Subordinate CA Setup - Subordinate Certificate Creation . . . . . . . 348
Subordinate CA Setup - Set Maximum Certificate Age . . . . . . . . . 351
Subordinate CA Setup - Modify the CertEnroll Virtual Directory . . . . 351
Subordinate CA Setup - CDP and AIA Configuration . . . . . . . . . . 352
Subordinate CA Setup - CPS Document . . . . . . . . . . . . . . . . . 353
Subordinate CA Setup - Windows Firewall Configuration . . . . . . . 354
Subordinate CA Setup - Add the Root CA to Active Directory . . . . . 355
Subordinate CA Setup - Verify PKI Infrastructure . . . . . . . . . . . . 355
Subordinate CA Setup - Next Steps . . . . . . . . . . . . . . . . . . . 356
AD CS Quick Start - Post-Implementation Tasks . . . . . . . . . . . . . . . . 357
Post-Implementation Tasks - Virtual Floppy Disk Deletion . . . . . . 357
Post-Implementation Tasks - Root CA Shut Down . . . . . . . . . . . 357
AD CS Quick Start - Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Graphical Tools Using Windows Server Tools . . . . . . . . . . . . . . . . . . 367
Graphical Tools Using the Microsoft Management Console . . . . . . . . . . 368
Cmdlets for Managing Windows Server . . . . . . . . . . . . . . . . . . . . . 369
Command Line Tools for Managing Windows Server . . . . . . . . . . . . . 370
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

xii | Practical Guide to PKI with Windows Server

About the Author

Matthew Burr is an IT Professional who has worked in the IT industry for over 12 years in
the Greater Toronto Area. During that time, he has worked in the financial, government,
healthcare, retail, scientific, social media, and software development industries. He
attended Cambrian College in Sudbury, Ontario from 2006 to 2009, where he studied
Computer Networking and Systems Administration.

Matthew is a Network Architect and Network Security expert who has provided his
services to multiple companies during his career. Aside from working in those roles, he
has also worked as a Systems Administrator for networks running both Windows and
Linux. For the last few years, he has also worked on multiple Cloud implementations
using various platforms.

Aside from working in the IT industry for over 12 years at various companies, Matthew
also holds several industry certifications from various vendors, and regularly attends
training courses and conferences to stay current.

Matthew founded Ten Fifteen Solutions (https://tenfifteen.ca/) in early 2016 to better

serve clients and to work on consulting services in the Toronto area.

Matthew wrote this book to demonstrate how to create a PKI using Windows Server as
this is a topic that has become more important in the last few years as security has
become more critical to the daily operations of every company. Matthew has
successfully implemented a PKI for multiple companies while working as an internal
employee and while working on a contractual basis.

Matthew also runs a blog (https://mjcb.io/) where he covers various IT related topics and
hosts other projects that he is working on.

About the Author | xiii

Preface

Who Is This Book For?

The purpose of this book is to create a Certificate Authority using Active Directory
Certificate Services (AD CS) with Microsoft Windows Server. This book offers a
comprehensive step-by-step guide that demonstrates how to successfully create a
Certificate Authority using those technologies.

This book also explains each step, the necessity of that step, and the importance of that
step within the Certificate Authority. The results of this book will create a Certificate
Authority that can issue certificates internally within an organization in a secure manner,
using best practices.

This book is meant for developers, network administrators and systems administrators
who have a basic understanding of Windows Server and Public Key Infrastructures and
need to deploy a Certificate Authority rapidly within their environment for various
purposes. By using the steps provided in this book, there will be a Certificate Authority
framework created that can be customized for whatever requirements are needed in any
environment.

This book is also meant to be used by developers, network administrators and system
administrators who can interpret this guide and modify it for their existing environment.
Simply following this guide will not implement a functioning PKI for your organization,
you will need to modify the steps accordingly to make it function properly. This means
creating different servers, modifying steps for different Active Directory domains,
modifying LDAP settings, modifying file paths, creating different certificates, and other
critical steps as needed.

The contents of this book are presented in a thorough, but easy to follow manner.
Screenshots are provided for important steps for verification purposes and to
demonstrate how the environment should be configured. It should take approximately
ten hours to go through this book from start to finish.

Conventions Used in This Book

There are several text and design conventions that are used to make it easier to
understand the contents of this book. These conventions are also used to understand
what needs to be done to follow the steps in this book.

Some of the conventions are also used to convey additional information that the reader
should be aware of, including potential issues that could arise under certain
circumstances, or additional information on technologies or features that can be
implemented in the future.

Preface | xv
Text Conventions
There are multiple references to running the Command Prompt and PowerShell in an
elevated state. In the context of this book, this means running these applications as an
Administrator. By not running these commands as an Administrator, it may result in
unexpected behaviour as a result which can be difficult to troubleshoot. Depending on
what is being configured, it will either by a local Administrator or a Domain Administrator
account that is needed.

There are multiple text conventions that are used in this book, and all are used for
instructional purposes:

Convention Meaning and Purpose

Menu Commands and Console Trees Menu commands or console trees that need to
be followed are referenced using the > symbol
and bolded. For example, open the File >
New menu, and click the Text Document option
to create the text document needed for the
configuration file.
Bold Text Text that is in bold is used to highlight
important items in a set of instructions. For
example, open the Server Manager console to
find information on a particular server.
Italics Text Text that is in italics is used to reference a URL
that is not used as part of a configuration, and
in some cases is an external link to an outside
resource.
Plus Sign (+) Keyboard shortcuts are indicated using a plus
sign (+) which separates multiple keys. For
example, reading CTRL + ALT + DELETE means
that you need to press the CTRL, ALT and
DELETE keys simultaneously to perform an
action.

Steps are provided in numerical order and should be followed in the correct order to
ensure that the task being performed is setup in the correct manner. Skipping steps or
performing them in the incorrect order can cause issues with setting up the Certificate
Authority in this book, so it is strongly recommended to perform the steps in the correct
order.

Steps that are optional for the Certificate Authority implementation are stated, and not
performing those steps will not cause any issues with the functionality of the Certificate
Authority. Those steps add additional functionality to the Certificate Authority, and those
functions may not be necessary for all environments or organizations.

xvi | Practical Guide to PKI with Windows Server

Information Boxes
There are several types of boxes that appear throughout this book. These boxes are used
to provide additional information or highlight important steps, and each colour
represents several types of information that you will need to know:

Information Box

Anything that appears in an Information Box is provided for reference purposes or

for additional details for a particular topic. The instructions or explanations
provided in these boxes will not affect the deployment of a Certificate Authority in
this book but can also provide additional details on how to configure specific
functions.

Notice Box

Anything that appears in a Notice Box is provided to highlight a potential issue in

the Certificate Authority implementation that could cause issues if not addressed
correctly.

Warning Box

Anything that appears in a Warning Box is provided to highlight a major issue that
may occur if instructions are ignored or not considered.

Configuration File Box

Anything that appears in a Configuration File Box is required for configuring the
roles and features within Windows that is used in this book. The path to the file
that is being configured will be in the Configuration File Box header.

Additionally, there is also an additional box that is used for commands that need to be
inputted through the CLI and used for inputting configuration items in configuration
boxes.

Anything that appears in a CLI Box is meant to be inputted exactly as it appears. This
includes inputs using the Command Prompt, PowerShell, or configuration boxes exactly
as it appears.

These inputs also include all formatting and line breaks, which need to be inputted
exactly as it appears. A CLI box does not have a header, and usually appears during
the configuration of a specific function.

Preface | xvii
Introduction

Goals of This Book

The main goal of this book is to successfully deploy a functioning and secure Two-Tier
Certificate Authority and Public Key Infrastructure (PKI) using Active Directory Certificate
Services (AD CS) with Windows Server. This book provides a complete guide on
implementing a complete PKI with detailed steps, instructions, and background
information.

Creating a properly functioning and secure Certificate Authority is a complicated process

that requires multiple complex steps. There are also validation steps that need to occur
to ensure that there are no errors in the Certificate Authority implementation at certain
key steps. Effort has been made to document every single step that is needed, as
missing even the smallest step or detail can cause issues that are difficult to correct later.

This book will focus on the fictional TFS Labs domain. This environment is basic in
design, and it will easily demonstrate how to build a Two-Tier Certificate Authority using
Active Directory Certificate Services (AD CS) with Windows Server. Steps are provided on
how to create this complete test environment, as well as what needs to be updated for
your implementation to be successful. This book is written in such a way that all steps
provided are incorporated into a complete Certificate Authority, and steps that are
optional are specified.

There are multiple ways to create a virtualization environment for creating a Certificate
Authority for testing purposes, and this book will focus on using the Hyper-V platform to
accomplish this goal. By using Hyper-V over other virtualization platforms, you will not
need to utilize any other third-party software for completing this guide, but that does not
mean that you cannot use other providers. Hyper-V is a Hypervisor platform that was
developed by Microsoft for virtualizing other operating systems in a Windows
environment.

Since all the required tools are provided by Microsoft and are already available in
Windows Server, there is technically no requirement for any third-party software as
absolutely everything is provided. If you have a Windows Server 2019 and a Windows 10
installation source, there is no need for an internet connection at all to complete the
steps in this book. The only thing you will need to complete the steps in this book is a
workstation or server that can run the software with the necessary hardware
requirements.

By using this book as a guide, you will be able to adapt these instructions to your existing
Active Directory domain. It is advised to go through this book at least once to see what
needs to be done for creating a Certificate Authority before attempting to implement it
for your organization. This will ensure that you can see what a functioning Certificate
Authority looks like, and this will allow you to troubleshoot any issues that may arise.

Introduction | xix
What Won’t This Book Cover?
While this book will cover the creation of a PKI using Active Directory Certificate Services,
there are many topics that will not be covered. Creating a working Two-Tier Certificate
Authority with Active Directory Certificate Services is the primary goal of this book, but
there are many applications of this that will not be covered. Among the features that will
not be covered include the following:

• 802.1X authentication
• Smartcard authentication
• Encrypting file systems
• Document and code signing
• Wireless networking
• E-mail signing and encryption
• SSL decryption

Attempting to cover additional features such as the ones that were just listed would be
extremely complicated. These features require considerable planning depending on what
vendors are involved and are beyond the scope of this book. By implementing a proper
PKI using this book, the framework will be established to add features like this in the
future.

What is also missing from this book is the option to perform a completely scripted
version of the PKI installation and configuration. This is not because it is not possible, but
it is difficult to automate many of the configuration steps that are performed in this book.

There are also a few issues with building a Two-Tier PKI using an Offline Root CA with an
unattended setup using PowerShell for automation, as there is no way to easily transmit
files and issue commands remotely on a server that is supposed to be offline. A
workaround to this would be to temporarily enable network connections to the Offline
Root CA during the setup process, but that would defeat the purpose of the security of
the Offline Root CA. Also, some features such as the Online Responder role do not
support CLI options without requiring overly complex steps. Because of these reasons, a
fully automated PKI deployment is not covered in this book.

Before You Start

Before starting with this book there are a few things that you will need to get ready. This
book only requires three virtual machines running Windows Server 2019 and one virtual
machine running Windows 10 Pro. It also requires at least one workstation or server that
can host four virtual machines needed for the TFS Labs Test environment. No additional
third-party software is required, as all necessary features are already available within the
Windows Operating system.

This book uses virtualization software for creating the TFS Labs environment. The
choice of a virtualization platform is up to you, but this book uses the Hyper-V platform
for that virtualization. Hyper-V runs natively on Windows Server 2012 R2, and above and
on any professional version of Windows 10 64-bit.

xx | Practical Guide to PKI with Windows Server

Software Requirements
All servers in this book are created using Windows Server 2019, which is freely available
on the Microsoft website on a trial basis. For the workstation component, Windows 10
Pro is also available on a trial basis on the Microsoft website. There should be no issues
in using Windows Server 2012 R2 or Windows Server 2016 for creating the same
Certificate Authority, the only issue being the Active Directory Functional Level. Earlier
versions of Windows Server are not covered in this book as they are no longer supported
by Microsoft.

AD CS Installation and Configuration Options

As part of creating a functioning PKI using the steps that are in this book, Active
Directory Domain Services (AD DS) and Active Directory Certificate Services (AD CS) will
be configured on three servers running Windows Server 2019. Command line installation
and configuration in the Windows operating system has come a long way since earlier
versions, and it is entirely possible to configure most of the features in Windows without
the GUI. This book will present the option for installing and configuring the needed server
roles using the GUI and CLI whenever possible. Some users are more comfortable with
the CLI configuration as it is easier and faster in most cases, so those options are
presented as well.
A quick start guide is included in this book that demonstrates how to quickly build a PKI
with only the essential components and required steps.

Virtualization Requirements
This book uses Hyper-V as the virtualization platform for creating the TFS Labs
Environment. Hyper-V is available as a role in Windows Server 2019 and as an optional
feature in Windows 10 Pro, so no additional third-party software is required to use and
install it.
For Hyper-V to function correctly, it requires the following features to be available on the
workstation or server (these requirements do not factor in any virtual machines):
• 64-bit Processor with Second Level Address Translation (SLAT)
• CPU support for VM Monitor Mode Extension
• 4 GB Memory
Any modern computer or server will support the necessary virtualization features without
any issues if it was manufactured after 2018. The only exception is computers that are
32-bit only, as those features are not possible.
For Hyper-V to operate correctly on a particular workstation or server, there may be
various settings within the BIOS that would need to be enabled. These settings vary
based on the manufacturer, but there is usually a virtualization option within the BIOS
where those settings are configured. If you are unsure, you should refer to the
manufacturer’s documentation on your system to determine how to enable those
features.

Introduction | xxi
You will require a workstation or server that has at least 16GB of memory to properly
support the four virtual machines that are needed to support the steps provided in this
book. You can allocate less memory to the virtual machines if your system does not have
that amount of memory, but it may affect performance. With Hyper-V you can also utilize
dynamic memory if you would like to, and this would only allocate needed memory for
the virtual machines as it is needed. This should be acceptable for testing purposes but
should be avoided for production deployments.

Supported Virtualization Platforms

The steps that are outlined in this book should work perfectly fine using the
Hyper-V, VirtualBox or VMware platforms for virtualization. If the virtualization
platform that you use supports Windows 10 Pro, Windows Server 2019, virtual
floppy disks, and basic networking that allows for multiple virtual machines to be
connected to each other, the steps in this book should work correctly.

Organization of this Book

This book is organized into twelve chapters to properly break down the deployment and
proper configuration of a Certificate Authority using Active Directory Certificate Services.
There is also a full list of commands that are used in this book, a full glossary of all
important terms, and a complete index. The chapters included in this book are as follows:

Chapter 1 - Public Key Infrastructure

This chapter is an overview of what a Public Key Infrastructure and Certificate Authority
is, as well as how it operates with Windows Server using Active Directory Certificate
Services.

Chapter 2 - Certificate Authority Test Environment

This chapter explains the TFS Labs environment that is being used in this book for
creating the Certificate Authority with Windows Server.

Chapter 3 - Domain Controller and Workstation Setup

This chapter explains how to install an Active Directory Domain Controller and
workstation. This will setup the necessary Active Directory infrastructure for supporting
Active Directory Certificate Services.

Chapter 4 - Offline Root CA Setup

This chapter explains how to setup and secure an Offline Root Certificate Authority using
Windows Server and Active Directory Certificate Services.

xxii | Practical Guide to PKI with Windows Server

Chapter 5 - Subordinate CA Setup

This chapter explains how to setup and secure a Subordinate Certificate Authority that is
capable of issuing, managing, and revoking certificates using Active Directory Certificate
Services.

Chapter 6 - Deploy Root and Subordinate Certificates

This chapter explains how the Root and Subordinate certificates are deployed to an
Active Directory domain using Group Policy.

Chapter 7 - Online Responder Role Configuration

This chapter explains how to enable the Online Responder role Service in Active Directory
Certificate Services, which allows for OCSP to be used in the TFS Labs domain.

Chapter 8 - Private Key Archive and Recovery

This chapter explains how to back up Private Keys for certificates that are issued
internally, and how it can be automated and backed up with Active Directory.

Chapter 9 - Certificate Template Deployment

This chapter explains how to customize Certificate Templates in Active Directory

Certificate Services to ensure that those certificates fit the needs of your organization.

Chapter 10 - Certificate Enrollment

This chapter explains how to deploy Certificate Templates automatically and manually
within an Active Directory domain. It also demonstrates how to deploy certificates to
other platforms such as Linux, iOS, and Android.

Chapter 11 - AD CS Post-Implementation Tasks

This chapter explains any final tasks that need to be completed once the Certificate
Authority has been successfully created and tested, as well as any recurring tasks that
are needed in the future to support it.

Chapter 12 - AD CS Quick Start

This chapter demonstrates how to quickly deploy a basic Two-Tier Certificate Authority
using mostly command line tools, without all features included in this book.

Introduction | xxiii
Chapter 1 - Public Key
Infrastructure Overview

A Public Key Infrastructure (PKI) exists to facilitate the secure transfer of information
between networks and is used primarily to keep sensitive data protected. Information
that is protected includes anything, including e-mail, websites, storage devices and
authentication. Without PKI, the internet, and networks in general would be inherently
insecure as sensitive data would be transmitted in plain text, and all traffic would be open
for anyone to see.

A certificate provides the primary foundation of a PKI and is the most commonly facing
method of interacting with a PKI. Certificates can represent users, workstations, servers,
and other devices. These certificates are issued by a Certificate Authority, which can
manage those certificates. Certificates that are issued by a Certificate Authority are
associated with a public key and private key pair.

The main certificates in a Certificate Authority are the Root certificate and the
Subordinate certificate. In some cases, it may be necessary to revoke a certificate before
it expires, and this is usually performed using a Certificate Revocation List (CRL).

A certificate will typically contain the following information:

• Information on the Certificate Authority that issued the certificate.

• Information on how to determine the revocation status of the certificate as well as
the validity of that certificate.
• Information about the user, workstation or device that holds the private key that
corresponds to the certificate.
• Information on what encryption protocols is being used with the certificate.
• The public key of the certificate, which is used to encrypt data and send it to the
device that holds the private key.

The currently accepted standard for defining a certificate in a Public Key Infrastructure is
with the X.509 standard, which is defined in RFC 5280.

This chapter will briefly cover what a Public Key Infrastructure is and how it applies to
Windows Server and Active Directory Certificate Services. If you already have an
understanding on how a PKI works, you can skip this chapter.

Public Key Infrastructure Overview | 1

What Is a Public Key Infrastructure?
A Public Key Infrastructure (PKI) is a collection of server roles, software, policies, and
procedures that are used to create, distribute, and manage Certificates. The most
common application of PKI that most people are familiar with is securing websites using
SSL, but there are many more applications of a PKI such as:

• Replacing insecure self-signed certificates on internal network devices.

• Increasing security for Remote Desktop services on internal servers.
• Utilizing internal certificates for applications and services.
• Utilizing internal certificates for disk and file system encryption.
• Utilizing internal certificates for SSL decryption on firewalls and proxy devices.
• Issuing internal certificates for VPN services.
• Issuing internal certificates for wireless users and access points.
• Signing code for internal applications.
• Allowing for e-mail encryption and digital signatures.

There are several ways to utilize a Public Key Infrastructure. You have the option of
purchasing certificates from an online Certificate Authority or you can host your own
Certificate Authority internally within your organization. Both solutions have their
advantages and disadvantages, which solution you choose to pursue is dependent on the
needs of your organization and whether you require customization that is not available
through an online Certificate Authority.

The entire basis for PKI is dependent on Public-Private Key Encryption, which depends on
using pairs of public and private keys for the encryption and decryption of data. The
public keys are distributed to whoever needs to send encrypted data, and the private keys
are known only to the destination that needs to decrypt the secure data. The ability to
create, distribute and manage those keys in an effective, automatic, and secure manner
is the entire reason that Certificate Authorities exist.

Due to the open nature of Public Key Infrastructure, Certificate Authorities can be created
using multiple platforms and solutions. The ability to “tier” a Certificate Authority into
specific roles depending on the desired function is an important aspect of creating a
modern PKI.

Certificate Authorities and Public Key Infrastructure Terminologies

The Certificate Authority (CA) and Public Key Infrastructure (PKI) terms are
interchangeable since they are the same thing, with different software
implementations depending on what is used to create those systems. A PKI is the
entire solution for providing secure certificates, and a CA is the individual
components needed to provide those services.

Whether a Certificate Authority is a single system or multiple systems working

together is entirely dependent on the solution that is used to create it.

2 | Practical Guide to PKI with Windows Server

From a cost and overhead perspective of running a Certificate Authority within your
organization, it is really what works best for that environment. It used to be common for
organizations to simply purchase a wildcard certificate for their environment from a
commercial Certificate Authority and just use that for internal services, but that is no
longer a solution that works for several reasons:

• Commercial Certificate Authorities will typically not issue certificates for internal
domains, especially if it is a subdomain within an internal domain. Non-routable
domains are not able to be verified and that is a primary requirement for commercial
Certificate Authorities.
• Commercial Certificate Authorities cannot normally issue custom certificates that
are able to be used for non-standard and custom purposes, especially in a development
environment.
• Commercial Certificate Authorities can be extremely expensive when many certificates
need to be issued. If a specific service requires dozens or hundreds of certificates
to be issued, the cost of purchasing and deploying those certificates can become
extremely expensive.

There is certainly an administrative overhead and associated cost of setting up and

maintaining a PKI in an organization, but the benefits of having a proper PKI are worth the
time and effort in creating one.

Self-Signed Certificates

One of the key benefits to implementing a proper Certificate Authority within your
organization is the ability to eliminate self-signed certificates. A self-signed
certificate is technically free and can be easily setup by a user, but there are many
disadvantages:

• Web browsers do not trust self-signed certificates unless it has been explicitly
added to the list of Trusted Certificates on a workstation. On a single
workstation this is not normally an issue but correcting this on an entire
network can be extremely difficult.
• Modern web browsers show errors that a certificate is self-signed and should
not be trusted. Web browsers alert users to this to keep them safe on a
website that may not be taking their security seriously.
• Some vendors that issue self-signed certificates with network appliances do
not always use the strongest encryption options. There may also be duplicate
certificates in use, which present security risks on devices where security
needs to be a priority.

Adding a Certificate Authority certainly adds overhead and maintenance to an

organization to maintain it, but the benefits to getting rid of self-signed certificates
are worth it from a security perspective and optics from users.

Public Key Infrastructure Overview | 3

 SSL Decryption

SSL decryption is a method of decrypting traffic that is secured with SSL, and this
is done for the purpose of examining all traffic that goes in and out of a network.
When traffic that is secured with SSL traverses a network, the contents of that
traffic is hidden to everyone except for the device that initiated the traffic, and the
destination of the traffic. Details such as the DNS name of the destination is
usually always known, since that is required to facilitate the connection, but that is
usually all that is known. SSL decryption is performed for many reasons, the most
common reasons being:

• Examining the contents of encrypted traffic to search for malicious activity.

• Enforce web filtering on SSL sites.
• Monitor for unwanted uploads and downloads.
• Search downloads and uploads for malware.

SSL decryption is typically performed on firewalls, proxies and in some cases,

dedicated SSL decryption devices. SSL decryption works by placing certificates
on a device and using it to sign SSL traffic on that device. There is always another
copy of the certificate on a device that performs the SSL decryption using same
certificate. Typically, it is best practice to exclude certain sites from SSL
decryption, including government, finance, and healthcare websites.

Active Directory Certificate Services Overview

Active Directory Certificate Services (AD CS) is a server role that has been available in
Windows Server releases since Windows Server 2008. Active Directory Certificate
Services allows for the creation of a Public Key Infrastructure and Certificate Authority in
a Windows environment, with or without the use of Active Directory.
With the Active Directory Certificate Services role, you can issue and manage certificates
for various purposes. Active Directory Certificate Services supports various Certificate
Authority hierarchy configurations and other options depending on the needs of an
organization. Active Directory Certificate Services is a capable and customizable
platform that is well supported.
There are other third-party utilities and vendors that provide the same functionality as
Active Directory Certificate Services. In some cases, additional functionality is also
present in other vendors, but there are several advantages to using Active Directory
Certificate Services within a Windows Server environment:
• Active Directory Certificate Services is available as a role within Windows Server,
which means that it can be added or removed at any time. Since the role is already
provided with Windows Server, there is no additional software required for implementation.
• Active Directory Certificate Services is designed to be scalable and backwards compatible
with earlier versions to allow for easier and faster migration paths to new versions
of the Active Directory Certificate Services role.

4 | Practical Guide to PKI with Windows Server

 • Active Directory Certificate Services offers complex integrations with Active Directory,
which is a large benefit in an organization that utilizes the Windows operating system.
It can get information about users and workstations automatically when issuing and
managing certificates, which saves a considerable amount of time.
• Active Directory Certificate Services is an on-premises solution, which means that it
allows for customizations not always possible through a third-party provider.
• With Active Directory and Group Policy, deploying certificates within an Active Directory
domain is easy and can be automated with minimal effort.
• With Active Directory domains with unsupported top-level domain names, it is extremely
difficult to issue certificates to those domains through a third-party vendor since
there is no way to validate that the domain is valid. Active Directory Certificate Services
supports custom domains that may be present within an Active Directory domain.

Active Directory Certificate Services is a fully featured PKI solution that can be used to
issue certificates for multiple purposes, which can include:

• Digital Signatures
• Encrypting File System
• IPSec
• S/MIME
• Secure LDAP (LDAPS) with Active Directory
• MDM Certificates
• SSL
• VPN Access
• Smartcards
• Wireless Network Access

Active Directory Certificate Services supports several deployment scenarios, and can be
“tiered”, which breaks up a Certificate Authority into multiple servers by adding different
layers to the Certificate Authority. This can be done for to factor in scalability, security
and for custom deployments.

Microsoft Certificate Server

The predecessor to Active Directory Certificate Services was known as Microsoft

Certificate Server. This version was originally released for Windows NT 4.0 Server
Service Pack 3 as an optional feature in 1998. It offered basic and limited
Certificate Authority features to Windows and was not easy to install or manage.
There were subsequent versions of the Microsoft Certificate Server application
released for Windows 2000 Server, Windows Server 2003 and finally for Windows
Server 2003 R2.

When Windows Server 2008 was released, the Microsoft Certificate Server
application was retired in favour of Active Directory Certificate Services, and the
role has continued to be updated since that initial release.

Public Key Infrastructure Overview | 5

Active Directory Certificate Services Roles
Active Directory Certificate Services is split up into six separate roles, which provides
additional options for various deployment scenarios:

Certification Authority - This role is used to issue and manage certificates, with the
ability to create Root and Subordinate Certificate Authorities. Multiple Certificate
Authorities can be linked together and “tiered” to form a complete PKI. Currently the AD
CS role allows for the creation of Certificate Authorities with or without the use of Active
Directory:

• Standalone CA - These are servers that may or may not be members of an Active
Directory domain and can operate without it entirely. A Standalone CA can be used
in an online or offline state and is most often used as a Root Certificate Authority.
• Enterprise CA - These are servers that are a member of an Active Directory domain
and are typically used as a Subordinate or Issuing Certificate Authority. These types
of servers are typically always online and available.

Certificate Enrollment Policy Web Service - The Certificate Enrollment Policy Web
Service role allows users and computers to request and obtain certificates when they are
not members of an Active Directory domain or are located outside of the Active Directory
network. It is used together with the Certificate Enrollment Web Service to issue
certificates.

Certificate Enrollment Web Service - The Certificate Enrollment Web Service role allows
users and computers to enroll and renew certificates when they are not members of an
Active Directory domain or are located outside of the Active Directory network. It is used
together with the Certificate Enrollment Policy Web Service.

Certification Authority Web Enrollment - The Certification Authority Web Enrollment role
adds a simple web interface using Internet Information Services over the HTTPS protocol
that allows users to request and manage certificates as well as retrieve Certificate
Revocation Lists (CRLs).

Network Device Enrollment Service - The Network Device Enrollment Service (NDES) role
gives the AD CS role the ability to issue and manage certificates for network devices
such as switches, routers, and firewalls. These types of devices typically do not have
Active Directory accounts associated with them, so they are not able to automatically
request certificates.

Online Responder - The Online Responder role adds the OCSP functionality to Active
Directory Certificate Services, which allows for rapid revocation of certificates in large
environments.

Even though there are multiple roles available with Active Directory Certificate Services, it
does not necessarily mean that all roles are needed in a particular environment. Certain
roles require a particular type of environment, which means that some environments
would never need to use certain roles at all if that requirement were not needed.

6 | Practical Guide to PKI with Windows Server

 Active Directory Certificate Services roles

Typically, all the Active Directory Certificate Services roles are not used in every
organization. If they are used, they are not installed on the same server. This is to
reduce the complexity of the servers that are used in the PKI, as well as to enable
greater flexibility in complex environments. For a large-scale Active Directory
Certificate Services deployment that utilizes all roles, there would be individual
servers used for each role at a minimum.

Windows Server Roles and Features

Windows Server supports multiple roles and features, which are used to add
additional functionality to a Windows server. These roles and features can be
used to add enhanced functionality to a Windows server, and roles such as Active
Directory Certificate Services and Active Directory Domain Services are among
the significant roles that can be added.

Server roles are typically used to add capabilities to your network, such as AD CS,
AD DS, IIS, DNS or DHCP. Server features are typically used to add capabilities to
the local server itself, such as BitLocker or Hyper-V.

Certificate Authority Hierarchies

When deploying a Certificate Authority and a Public Key Infrastructure, it is typically setup
in a hierarchical deployment, with a Root Certificate Authority at the top, and going all the
way down to the issued certificates.

The Root Certificate Authority signs the certificate for itself, and that certificate is used to
sign any Subordinate certificates that are in the Certificate Authority. In between there
can be multiple Subordinate Certificate Authorities that perform separate functions in the
Certificate Authority. These types of Certificate Authority hierarchies are known as a
One-Tier, Two-Tier and Three-Tier Certificate Authority. All three of these tiers are
supported in Windows Server using Active Directory Certificate Services (AD CS).

This book focuses entirely on a Two-Tier Certificate Authority as it is the most common
Certificate Authority deployment for organizations, as it is the easiest to setup and
support, and is also recommended by Microsoft with Active Directory Certificate
Services. Overviews of the other available Certificate Authority hierarchies are also
provided for reference purposes, should those types of hierarchies be encountered.

The complexity of every Certificate Authority hierarchy increases every time an additional
tier is introduced, or whenever additional servers are added to increase the functionality
of the Certificate Authority. The size of the organization or the requirements of the
Certificate Authority, this amount of technical debt is up to a particular organization to
accept as Certificate Authorities require constant maintenance to operate correctly.

Public Key Infrastructure Overview | 7

One-Tier Certificate Authority
A One-Tier Certificate Authority consists of a single Certificate Authority that is usually
hosted on a single server and represents the most basic way to issue certificates:

Figure 1.4.1: A One-Tier Certificate Authority consists of just one Certificate Authority
server that is used to issue certificates.

This single Certificate Authority is the Root CA as well as the Issuing CA, which means it
is responsible for all roles of the Certificate Authority. This single Certificate Authority
holds all the roles that are necessary for Certificate Authority to manage and issue
certificates.

A One-Tier Certificate Authority is never recommended for a production environment for

multiple reasons:

• Compromising a single CA server will immediately compromise the entire PKI. This
would mean if the Certificate Authority were ever compromised in any way, all certificates
ever issued would need to be re-issued to ensure that the certificates can be trusted
again.
• For large environments, having just a single CA could potentially become a bottleneck
if the CA server is unavailable, or if many certificates need to be issued at a single
time.
• If certificate policy requirements for certificates need to be changed in the future,
having a single CA can make that change extremely difficult, and it can be difficult to
scale out from a single CA server.
• In a production environment, a One-Tier Certificate Authority is a single point of failure
for the entire PKI. This type of CA is not scalable, and if the needs of an organization
change in the future, a single CA can cause serious issues.

There are some instances where a One-Tier Certificate Authority is used, mostly for
one-off applications that require just a single certificate to be issued for things like
application signing or for test environments. These types of scenarios do not require a
robust Certificate Authority to work correctly and are typically only used when there is a
specific need for such a setup.

8 | Practical Guide to PKI with Windows Server

 One-Tier Certificate Authorities and Domain Controllers

Never install a Root Certificate Authority on an Active Directory Domain Controller

in your environment under any circumstances. Even though the server role can
easily be added to an existing Domain Controller, it is not advisable to have the
Active Directory Certificate Services role installed on the same server that is also
a Domain Controller.

This can cause multiple unexpected issues, the most common occurring if a
recovery needs to occur on the Domain Controller. This can cause any issued
certificates within the environment to be broken and invalid. Since the
requirements for running a Certificate Authority are quite low, it is advised to run a
Certificate Authority on a separate server, especially with virtualization.

Two-Tier Certificate Authority

A Two-Tier Certificate Authority consists of an offline Root Certificate Authority and at
least one online Subordinate Issuing Certificate Authority. It is the most common and
most practical way to issue certificates using Active Directory Certificate Services, and is
the primary focus of this book:

Figure 1.4.2: A Two-Tier Certificate Authority consists of at least one Root CA and at least
one Subordinate CA, which is used to issue certificates.

Most organizations utilize a Two-Tier Certificate Authority as it has the best balance
between security and in ease in managing Subordinate Certificate Authorities. Compared
to a One-Tier Certificate Authority, a Two-Tier Certificate Authority has several
advantages:
• The Root Certificate Authority is usually setup and configured as a server that is not
a member of the Active Directory domain and is usually kept in an offline state unless
it is needed. These servers will also have no network connections at any time.

Public Key Infrastructure Overview | 9

 • The Root Certificate Authority can be locked down and hardened separately from the
rest of the servers on the domain, so it can have the strictest security policies applied
to it without becoming an administration issue. Since it is offline and not part of the
domain, any Group Policy Object changes will not affect it.
• An offline Root Certificate Authority can protect the Private Keys for the Root certificate,
so that it is much more difficult to compromise.
• With a separate tier for Subordinate Certificate Authorities, it is much easier to separate
those roles into different servers for different purposes (such as location, operating
systems, applications, etc.) than if it was located on just one server.
• If a Subordinate Certificate Authority is compromised, it can be revoked, and a new
Subordinate certificate can be issued from the Offline Root CA.

A Two-Tier Certificate Authority is the most common Certificate Authority deployment

that you will find. It is a balanced mix between a One-Tier and a Three-Tier Certificate
Authority, and it can be scaled up should it be required.

By introducing a Subordinate Certificate Authority and using an Offline Root CA, the
security of the PKI is increased and allows for more customization of the Certificate
Authority. Microsoft recommends that a Two-Tier Certificate Authority be used wherever
possible with the Active Directory Certificate Services role.

Offline Root Certificate Authority Tasks

When dealing with an Offline Root CA there are tasks that are normally handled
automatically when the server is always online. When a Certificate Authority is
offline, the CDP and AIA records are not automatically updated, and if they expire
it can cause multiple issues with the online Subordinate CA and the entire PKI
under certain circumstances.

It is advised to set calendar reminders on a yearly recurring basis to bring the Root
CA online temporarily to update these records and publish them to the
Subordinate CA. This will ensure that there are no issues with the PKI in your
organization. The time that you set the CRL to expire on the Root CA will also
determine what interval you will need to perform maintenance tasks to keep your
environment updated.

Performing these tasks are not difficult and are relatively easy to do. How to
perform this task is demonstrated in a later chapter.

Three-Tier Certificate Authority

A Three-Tier Certificate Authority consists of an offline Root Certificate Authority, an
Intermediate Certificate Authority (usually offline, but not always) and at least one
Subordinate Issuing Certificate Authority. This represents one of the complex ways to
issue certificates using Active Directory Certificate Services to build a Certificate
Authority.

10 | Practical Guide to PKI with Windows Server

A Three-Tier Certificate Authority can have multiple different configurations, but the
simplest version of this type of hierarchy would look like this:

Figure 1.4.3: A Three-Tier Certificate Authority consists of at least one Root CA, one
Subordinate CA, and at least one Issuing CA. Depending on the size of the Certificate
Authority, there may be other servers involved as well.

This is the most difficult type of Certificate Authority to setup and maintain, but it does
provide the most amount of flexibility and security. It does have many of the same
advantages as a Two-Tier Certificate Authority, but does introduce some other
advantages:

• The ability to revoke Certificate Authorities for only a specific part of the PKI. If there
is an issue with a particular Subordinate CA in the PKI hierarchy, only that server and
certificate would need to be revoked without affecting the entire PKI.
• Additional security by putting more of the Certificate Authority into an offline or inaccessible
state for potential attacks.
• If one of the Issuing Certificate Authorities is compromised, the Offline Root Certificate
Authority does not need to be brought online to replace it, as the other Subordinate
Certificate Authorities would be able to issue a new certificate for that purpose.

A Three-Tier Certificate Authority is most often found in external Certificate Authorities

that are used for securing websites using SSL. While it is more complex than a Two-Tier
Certificate Authority, it does have the most flexibility for organizations that require it. A
Three-Tier Certificate Authority is found internally in large organizations and is usually
maintained by a dedicated team due to the complexity of it. The importance of keeping it
always operating is a mission critical component of the network infrastructure.

Public Key Infrastructure Overview | 11

 Three-Tier Hierarchy for a PKI

Due to the complexity of creating and maintaining a Three-Tier Certificate

Authority, it is strongly recommended to take the necessary time to thoroughly
plan what the PKI will look like and how it will operate. Due to the multiple
Subordinate CA servers that are required to properly make this type of Certificate
Authority operate correctly, and especially if those servers will be offline, it is
important to factor in the availability of those servers when tasks such as
updating the CDP and AIA records need to occur.

Certificate Authority and PKI Terminology

There are a lot of terms that are used when dealing with Certificate Authorities and Public
Key Infrastructures in general, and it is easy to get confused since a lot of those terms
can be interchangeable with Active Directory Certificate Services. When dealing with
Microsoft there are even more terms that are introduced that are also interchangeable as
well. So far in this book, the following Certificate Authority terms have been brought up:
• Root CA
• Intermediate CA
• Enterprise CA
• Issuing CA
• Subordinate CA (SubCA)
The Root CA is self-explanatory as it is always the top of the Certificate Authority or the
PKI depending on which definition you would like to use. If you are using a One-Tier
hierarchy, the Root CA is your entire Certificate Authority, and it handles everything.
An Intermediate CA and a Subordinate CA is the same thing, especially when using that
term in a Microsoft Certificate Authority. An Intermediate CA exists between the Root CA
and Issuing CA servers, and this is a more common term to use in a Three-Tier hierarchy.
A Subordinate CA exists in a Two-Tier hierarchy when there is just a Root CA, and the
Subordinate CA handles the issuing of certificates. From a Microsoft perspective, the
Enterprise CA, Intermediate CA, and Subordinate CA terms are used interchangeably as
they are the same thing.

X.509 Certificates
A certificate is used to link a user, computer, server, or services identity to a public key to
allow for secure transfer of data between those clients using that public key. There are
accepted standards for these certificates to allow for interoperability between various
clients, and the currently accepted standard for certificate is with the X.509 standard, the
latest release being version 3.
Certificates that are issued by a Certificate Authority are structured to meet certain
standards to ensure that they are usable on any device that requires a certificate, and
those standards were established by the Internet Engineering Task Force (IETF).

12 | Practical Guide to PKI with Windows Server

On a high-level, the structure of an X.509 certificate is as follows:

Figure 1.6.1: An X.509 certificate consists of multiple fields that can be used for defining
a certificate and can be customized for various purposes.

The X.509 version 3 certificate supports the following fields by default, some of which
have been supported since X.509 version 1:

• Version Number - This is the version number for the certificate, which is usually V3.
• Serial Number - This is a unique identifier for each certificate that is issued by a
Certificate Authority.
• Signature Algorithm ID - This is the algorithm that was used to sign the certificate.
• Issuer Name - This is the distinguished name of the Certificate Authority that issued
the certificate.
• Validity Period - This is time frame for the validity of the certificate.
– Not Before - The date that the certificate is valid from.
– Not After - The date that the certificate is valid to.
• Subject Name - This is the name of the computer, user, server, or service that the
certificate is issued to.
• Subject Public Key Information - This is the public key information that was used to
create the certificate.
– Public Key Algorithm - This is the algorithm that was used to sign the certificate.
– Subject Public Key - This is the public key of the certificate.
• Issuer Unique Identifier - This is an optional value that is used to make the certificate
unique if used by different entities.
• Subject Unique Identifier - This is an optional value that is used to make it possible
for the same Subject Name to be reused.

Public Key Infrastructure Overview | 13

 • Extensions - These are optional values that can be added to an X.509 version 3
certificate for various purposes.
– Extension Fields - These are additions to the certificates that are used for various
purposes, which is expressed as an OID. Unrecognized extensions are ignored.

In addition to the normal X.509 fields, there are also Extension Fields that are available
for certificates. All extensions are optional, but the most common ones that you will find
on a certificate are:

• Authority Information Access (AIA) - The AIA extension provides one or more URLs
for certificate revocation purposes, including the OCSP URL if it is present.
• CRL Distribution Points (CDP) - The CDP extension provides the URLs or other locations
where a client can retrieve the CRLs for checking if certificates have been revoked.
• Subject Alternative Name - This allows for the inclusion of different information in
the certificate such as a user’s e-mail address or LDAP information. This allows for
alternate names for various purposes, most of which are used for authentication
purposes. This Extension Field can also be referred to as a Unified Communications
Certificate (UCC).
• Certificate Policies - This is used to describe what an organization does to validate
the identity of the Certificate Requestor before a certificate is issued.

You can view the certificate fields by opening any certificate and viewing the details of it:

Figure 1.6.2: The certificate fields of an X.509 certificate being viewed on a Windows
device.

14 | Practical Guide to PKI with Windows Server

There is certainly a lot more to go over on the format of a certificate and how it is
structured, but that is not relevant for the purposes of this book. It is important to know
that these fields are there, and that they are configurable if needed.

Certificate Attributes
There are several attributes that are defined with an X.509 certificate that can be used
within a Certificate Authority, and these attributes can be viewed on every issued
certificate. The subject attribute has several fields as well that can be defined, all of
which are usually configured at the time when a certificate is requested and issued. The
most used subject attributes include:
• C - Country
• ST - State
• L - Locality
• O - Organization Name
• OU - Organization Unit Name
• CN - Common Name
• E - E-mail Address
• SAN - Subject Alternative Name (also known as a UCC certificate)
Depending on the certificate that is being issued, it is up to the user that is requesting the
certificate, or the administrator that is creating a Certificate Template to ensure that the
necessary attributes are specified at the time of creation. Once a certificate is issued,
there is no way to amend or correct a certificate with the updated settings.

SAN Certificates with Modern Web Browsers

There are two ways to define DNS names in an SSL certificate, one is using the CN
attribute and the other using the SAN attribute. The use of the Common Name
attribute has been phased out, as defined in RFC 2818. Certificates that are used
for web servers or for e-mail services most commonly require multiple DNS
records per certificate to allow for all required services to function.

There are a few reasons why the CN attribute has been phased out, mostly
because it is easier to spoof a domain name using the CN attribute. One of the
major web browsers currently in use is Google Chrome, which has enforced the
use of the SAN attribute for DNS names. Since version 65 of Google Chrome, the
use of the CN attribute has been deprecated, and the use of the SAN attribute is
enforced by default. When trying to view a website that only has the CN attribute
set, you will see the following error code:

NET::ERR_CERT_COMMON_NAME_INVALID

This issue is difficult to avoid since most modern web browsers are based on
Google Chrome. The most recent versions of Microsoft Edge, Mozilla Firefox, and
Apple Safari also no longer honour the CN attribute for the same reason.

Public Key Infrastructure Overview | 15

 SAN Certificates with Active Directory Certificate Services

Earlier versions of Active Directory Certificate Services had issues with issuing
SAN certificates, especially when using the Web Enrollment website service. A
workaround to this issue was to issue a command on an Enterprise CA or Issuing
CA to allow for SAN certificates to be issued:

certutil.exe -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Issuing this command can introduce several risks to your Certificate Authority
which could harm users and introduce other security issues to your environment.
This command will allow anyone to add additional information to a certificate
request and potentially impersonate other users or servers in the environment.
Microsoft also recommends not enabling this feature in your Certificate Authority.
It is best practice to maintain the Certificate Templates within the Certificate
Authority to ensure that required features are not only enabled for usage, but also
done in a safe manner.

Certificate Revocation Lists

All certificates that are issued always include an expiration date, and that date usually
varies depending on the type of certificate, or by the Certificate Authority that issues the
certificate. There are some cases where a certificate must be revoked earlier than
expected and that is where a Certificate Revocation List (CRL) comes in. A CRL is used to
centrally manage the list of certificates that have been revoked on that Certificate
Authority and the reason it was revoked. There are a few reasons why a certificate would
need to be revoked earlier than planned:

• Affiliation Changed - This is used when an employee is terminated or suspended.

• Certificate Authority Compromise - This is used when a CA certificate is compromised.
• Certificate Hold - This is used when a certificate needs to be put temporarily on hold.
• Cessation of Operation - This is used when an issued certificate is replaced.
• Key Compromise - This is used when a certificate is known to be stolen or no longer
trusted.
• Remove from CRL - This is used when a CA is removed.
• Superseded - This is used if the legal name of an employee has changed.
• Unspecified - This is used when a certificate is revoked for any other reason.

In Active Directory Certificate Services, there are seven options that are available for
revoking a certificate:

• CA Compromise
• Cease of Operation
• Certificate Hold
• Change of Affiliation
• Key Compromise

16 | Practical Guide to PKI with Windows Server

 • Superseded
• Unspecified
Active Directory Certificate Services supports two types of Certificate Revocation Lists,
which are known as a Base CRL and a Delta CRL:
• A Base CRL contains the serial numbers of all certificates that have been revoked
on a Certificate Authority that are within their expiration time, as well as the reason
they were revoked. The Base CRL is only published on a pre-determined schedule, or
whenever a CA certificate is renewed or published.
• A Delta CRL contains only the serial numbers of all certificates that have been revoked
on a Certificate Authority since the last time that the Base CRL was published. A
Delta CRL is used to provide a timelier update to the Base CRL, which is typically only
published on a pre-determined schedule. All Delta CRL changes are added to the
Base CRL whenever it is updated. The Delta CRL is much smaller than the Base CRL,
so it is much easier to update and send to clients as needed.
There are a few issues with Certificate Revocation Lists, and it mostly applies to how
often they are generated and how quickly they are generated. Whenever a client checks
the Certificate Revocation List, this requires the client to check the complete list and can
create a lot of overhead. If a certificate is revoked after the Base CRL and Delate CRL is
generated, a client can unknowingly accept a certificate that has already been revoked
without being aware of it.
More recently, there are more sophisticated methods and protocols for informing clients
about certificates that have been revoked. To allow for more rapid checking of revoked
certificates, the Online Certificate Status Protocol (OCSP) can be used to check
certificates much more rapidly than with a CRL. Instead of downloading and processing
an entire CRL, the client can individually determine the status of a certificate. By using
OCSP, the client can determine the status of a certificate, the responses being as “good”,
“revoked”, or “unknown”. By using OCSP instead of a CRL, the method is much more
reliable, it is updated constantly and used less overhead. OCSP is fully supported with
Active Directory Certificate Services.

Certificate Types
There are several commonly used filename extensions and formats that are used for
X.509 certificates. Many of these formats are used for different purposes, such as
exporting or importing public and private keys, so you will need to choose the correct
format depending on your needs. The format of the certificate will also vary depending
on its purpose and what application will be utilizing that certificate.
When dealing with the Windows Certificate Store and Active Directory Certificate
Services, there are several formats of certificates that you will primarily be dealing with.
There are several reasons why you would use one format over another, and it depends on
how you intend to use the certificate files. There are several common file extensions and
formats used with X.509 Certificates, but the most common formats in the Windows
operating system are the following:

Public Key Infrastructure Overview | 17

 • DER Encoded Binary X.509 (*.CER)
– This format stores the certificate in the Distinguished Encoding Rules (DER)
format, which stores the certificate in binary format.
– The file extension of the certificate can vary, and be CER, CRT or DER.
• Base-64 Encoded Binary X.509 (*.CER)
– This format stores the certificate in a Base-64 format, which allows you to view
the certificate in ASCII text.
– The file extension of the certificate can vary, and be CER, CRT or DER.
• Cryptographic Message Syntax Standard - PKCS #7 Certificates (*.P7B)
– The P7B format stores the certificate in the Cryptographic Message Syntax
Standard format, which is a binary format.
– When exporting a certificate in this format, there is an option to also include all
the certificates in the certificate chain as well.
– This is the format most used for exporting certificates within Active Directory
Certificate Services.
• Personal Information Exchange - PKCS #12 (*.PFX)
– The PFX format stores the certificate in the Personal Information Exchange
format, which is a binary format.
– This format allows for the export of private keys and allows the certificate to be
encrypted with TripleDES-SHA1 or AES256-SHA256 for added protection.
• Microsoft Serialized Certificate Store (*.SST)
– The SST format is used for storing multiple certificates in a single file for easier
distribution and is a proprietary Microsoft format that is only used in Windows.
– This format is convenient for Certificate Authorities, as it can allow you to distribute
multiple certificates much more rapidly.

The certificate file extension of *.CER is usually interchangeable with *.CRT, which is used
in other operating systems or applications. Certificates in the DER format might
sometimes have the file extension of *.DER and Base-64 formats might also have the file
extension of *.PEM.

Changing the file extension is usually the easiest way to convert between formats, but it
is not always that easy. Depending on the requirements it may require exporting the
certificate in a different format or converting it to the correct format entirely. There are
tools available to do these conversions under certain circumstances.

Exporting Private Keys

Ensure that whenever you export a certificate that includes the private key, you
should always choose a strong password. Even if you are exporting a certificate
for use within your production environment, you use a password that is strong and
secure that can protect the private key if the file is misplaced or deleted.

Using a strong password for private key exports will prevent unnecessary
revocation of certificates when it is known that those certificates have been lost
or compromised in any way.

18 | Practical Guide to PKI with Windows Server

Private Enterprise Numbers
When you are dealing with an internal Certificate Authority you do not really need to worry
about utilizing a properly registered Private Enterprise Number (PEN), but it is something
that is supported with Active Directory Certificate Services should you require it. The
Private Enterprise Number is defined with an OID, which is a unique identifier that is
defined at the time when the Certificate Authority is created. A Private Enterprise Number
is only ever required if you are going to be using your Certificate Authority outside of your
organization or if you use custom applications or certificates that would require this.
Configuring a Private Enterprise Number is beyond the scope of this book, but it only
requires minor modifications to the OID Number that is used in two configuration files at
the time of implementation. In Active Directory Certificate Services, this is in the
CAPolicy.inf file, which is located in the root of the Windows folder.

There are a few available options for assigning a Private Enterprise Number. One of the
easiest methods is to register your organization with the Internet Assigned Numbers
Authority (IANA), and they can provide a valid number for your usage. Applying for a
Private Enterprise Number is easy and can be done free of charge. It does take several
days for the application to be reviewed and approved, so factor that in if you are going to
be using a Private Enterprise Number for a production deployment. To apply for a Private
Enterprise Number, it can be done online at the IANA website:

https://pen.iana.org/pen/PenApplication.page

Private Enterprise Numbers that are issued and managed through the IANA are public
information, and can be freely viewed online at any time at this website address:

http://www.iana.org/assignments/enterprise-numbers

If you do not require a Private Enterprise Number for your organization for whatever
reason, you can use the OID of 1.2.3.4.1455.67.89.5 instead. This OID number is used
within Microsoft’s documentation for Active Directory Certificate Services and there
should be no issues using it within your environment. The only downside to using this
OID is that you may encounter issues with having another organization trust your
certificates if they use the same OID.

For testing purposes this OID is perfectly okay to use, but for production you should
consider using a properly assigned and unique OID. Instructions on how to customize
this are provided in later chapters.

Private Enterprise Number Requirement

If there is even a possibility that you may require a Private Enterprise Number for
your organization in the future, you should strongly consider registering for one
prior to the deployment of your Certificate Authority. Adding a Private Enterprise
Number later to your Certificate Authority is possible, but is complicated and
could cause issues if not done correctly. Adding a Private Enterprise Number to
an existing Certificate Authority is beyond the scope of this book.

Public Key Infrastructure Overview | 19

Why Use an Offline Root CA?
There are multiple reasons to use an Offline Root CA in your environment, and it all
comes down to securing a critical and key part of your infrastructure. It is almost
expected that any Certificate Authority that is created today will have the Root CA in an
always offline state. Unauthorized access to your Certificate Authority can put your
organization at considerable risk and can cause a lot of headaches to fix it, especially if
you depend heavily on a PKI for critical functions in your environment.

The Root CA is critical to your PKI, and you do not want to risk having the Root CA
compromised and having your private keys leaked. This would effectively invalidate every
single certificate in your organization and would require every certificate to be re-issued.
For smaller organizations this may not be a problem, but for large-scale certificate
deployments this can be a time-consuming problem to fix should it ever happen.

The best way to protect the Root CA is to have it always be unavailable and inaccessible.
Access to the Root CA is not needed for day-to-day operations, so having it online at all
times is completely unnecessary. Further to that point, it is not enough to just have it
turned off until needed, it should not be accessible by anyone even when it is temporarily
powered on.

It may be extreme but having a network connection to the Root CA is dangerous, so it is

not uncommon to use mediums such as virtual floppy disks to transfer data between the
Root CA and other servers. It is cumbersome, but this happens so infrequently that it
should not be an issue. Some virtualization platforms allow for copy and paste functions
in virtual machines, but that should be disabled for the Root CA to minimize the attack
surface on it as those are features that could potentially be exploited.

No Network Access vs Network Isolation

There is a difference between having an Offline Root CA that has no access to a

network, and an Offline Root CA that is in contained in an isolated network
segment. The most common and cost-effective way to utilize an Offline Root CA
is to use a virtual machine that has no network adapters attached to it, and have it
powered off until it is needed. Another way to setup an Offline Root CA is to use a
dedicated laptop or workstation that only runs the Offline Root CA, but both
solutions cost money for equipment that is only used at most, once or twice a
year. Physical devices should utilize full disk encryption to ensure that the Root
CA is protected when it is powered off.

Another way to utilize an Offline Root CA is to use an isolated network segment

(either with an inaccessible VLAN or management network), but this is not always
recommended. It is not always possible to block access to these networks, and
an attacker can always find their way into these networks if given enough time to
do so.

20 | Practical Guide to PKI with Windows Server

Windows Certificate Management
Knowing how the operating system manages certificates that are currently issued to it is
important in building and supporting a proper PKI and Certificate Authority. In every client
and server version of the Windows operating system, certificates are stored and
managed by using the Certificate Store, which is used specifically for this purpose. From
this context, a Store is where certificates are located, and this varies based on that
usage. This centralized location provides a complete overview of all certificates that are
installed and available within the operating system.

The Certificate Store can be managed by Administrators by using Active Directory and
Group Policy, which is useful for rapid deployment and management of certificates:

Figure 1.12.1: The Windows Certificate Manager can be used to view all certificates that
are installed on a Windows device.

There are three main Certificate Stores that are used within the Windows operating
system which all have separate purposes:

• Local Computer Store - Stores certificates that are local to the device and available
to all users on the workstation.
• Service Account Store - Stores certificates that are used for Windows services that
are local on the workstation.
• User Account Store - Stores certificates that are used for individual users that utilize
the workstation. These certificates can potentially “follow” users if they use other
workstations in the Active Directory domain.

Public Key Infrastructure Overview | 21

The Local Computer Store and the User Account Store are the most common Certificate
Stores that you are likely to interact with on a Windows device. The Service Account
Certificate Store is used for services or service accounts on the workstation and is
something that you are not likely to have to manage unless there is a specific application
in your environment that requires it.

There are several different folders within these Stores that are used to place certificates
in (this table does not include the Service Account Store):

Windows Certificate Store Name Purpose

Personal The Personal Store contains certificates
that have a private key controlled by the
user or workstation.
Trusted Root Certification Authorities The Trusted Root Certification Authorities
Store contains certificates that belong to
implicitly trusted Certification Authorities.
Enterprise Trust Contains self-signed certificates that are
issued from other organizations.
Intermediate Certification Authorities Contains certificates issued to Subordinate
Certificate Authorities in the certificate
hierarchy.
Active Directory User Object Contains the user object certificate or
certificates published in Active Directory.
Trusted Publishers Contains certificates installed from trusted
Certificate Authorities.
Untrusted Certificates Contains certificates that have been
explicitly identified as untrusted.
Third Party Root Certification Authorities Contains trusted Root Certificates from
Certificate Authorities outside of the
internal PKI hierarchy.

Outside of the scope of this book is the physical locations of certificates within the
Windows operating system. There are locations within the Windows Registry and within
the Certificate Store where certificates are located and can be utilized. Most of the time
these details are not relevant, but for developers or systems administrators these details
become relevant for implementation and troubleshooting purposes.

22 | Practical Guide to PKI with Windows Server

 Windows Certificate Management with MMC

The Certificate Store utilizes the Microsoft Management Console (MMC) for
managing certificates within the Windows operating system. These are several
Snap-ins available with the MMC, which are management features within the
Windows operating system. The MMC is available in all versions of Windows
since Windows 2000.

There are two MMC Management Saved Console (MSC) files available on
Windows which makes it easy to rapidly view certificates:

• certlm.msc - Shows certificates located in the Local Computer Store.

• certmgr.msc - Shows certificates located in the User Account Store.

For the Service Account Certificate Store, this can be viewed by adding the
Certificates Snap-in, and selecting the Service account option when selecting an
available Snap-in.

Aside from using the MMC to manage the Certificate Authority, there is also the
certutil.exe command line utility for managing the Certificate Authority. There are
also additional PowerShell Cmdlets that are available for managing certificates as
well, but not all of these Cmdlets are referenced using this book.

Public Key Infrastructure Overview Next Steps

The next step in this book is to explore and understand the TFS Labs test environment
that is used in this book for creating the TFS Labs Certificate Authority.

This will provide a complete overview of the test environment so that you will understand
what is required, what needs to be done, and how everything will work in a complete
Certificate Authority using Active Directory Certificate Services.

Public Key Infrastructure Overview | 23

Chapter 2 - Certificate Authority
Test Environment

Creating a functioning Certificate Authority requires a lot of planning and work to ensure
that it has been done correctly. The most crucial step that should not be overlooked is
the planning of what a PKI will provide to your organization, and what is required to
support that. This involves several important steps, which requires answering the
following questions before you even begin provisioning servers:

• What servers are required to be created?

• What are the names of the servers that are required?
• What names are going to be used for the Root and Subordinate certificates?
• What is the validity period of the issued certificates?
• Are there any legacy requirements that need to be considered for your environment?

Determining the answers to these questions will determine how the Certificate Authority
will function once it has been created. Planning this out properly is the most crucial part
of the entire PKI implementation, and if any mistakes are made in the planning process or
something is overlooked, correcting the problem later can be extremely difficult.

Even though this book focuses on the fictional TFS Labs domain, the instructions and
guidelines provided in this chapter can be easily adapted to fit with your organization.
Take note of the servers and Certificate Authority details provided in this chapter and
start thinking about how you can apply that to your domain.

This chapter will focus on the test environment that this book will be using for creating a
Certificate Authority with Active Directory Certificate Services.

Certificate Authority Test Environment | 25

Certificate Authority Environment Design and Overview
This book uses a simplified and basic Active Directory environment for demonstration
purposes. This Active Directory domain demonstrates the bare minimum that is required
for Active Directory Certificate Services to operate correctly.

The Active Directory domain that is going to be used in this book is the TFS Labs domain
(corp.tfslabs.com), which is being used by a small IT company that is based in Toronto,
Ontario, Canada.

In total, there are three Windows servers and one Windows workstation that will be used
to build and test the TFS Labs environment:

Figure 2.1.1: The TFS Labs Active Directory domain consists of three servers and one
workstation. This domain represents the bare minimum environment that is required to
demonstrate and test Active Directory Certificate Services.

26 | Practical Guide to PKI with Windows Server

The virtual machines that are being used in this book for the test environment are using
the following specifications:

VM Operating System CPU Memory Disk IP Address

TFS-CA01 Windows Server 2019 2 4096 MB 40 GB 10.100.1.101
TFS-DC01 Windows Server 2019 2 4096 MB 40 GB 10.100.1.100
TFS-ROOT-CA Windows Server 2019 2 4096 MB 40 GB N/A
TFS-WIN10 Windows 10 Pro 21H1 2 4096 MB 40 GB 10.100.1.110

All the virtual machines are Hyper-V Generation 1 virtual machines as they require the
use of virtual floppy disks, which is needed for the transfer of files between the Offline
Root CA and the Subordinate CA. If you are using Hyper-V Generation 1 virtual machines,
you do not need to add a virtual floppy drive at the time of provisioning of the virtual
machine, it is always present by default.

Software Versions

All versions of Windows Server 2019 are using Standard Edition (Desktop
Experience) in this book. There is no difference in the implementation if you use
Windows Server 2019 Datacenter Edition (Desktop Experience) instead. For the
version of Windows 10 Pro, the 21H1 release was used in this book. There should
be no issues with using earlier versions of Windows 10 Pro, but you should
consider using versions that are currently under active support from Microsoft.

For the specific versions of the software that was used for the creation of this
book, they are as follows:

• Windows Server 2019 - Version 1809 (Build 17763.2028)

• Windows 10 Pro - Version 21H1 (Build 19043.1055)
• Microsoft Edge - Version 91.0.864.54 (Official Build - Stable)

Windows Server Core

The version of Windows Server that is used in this book is Windows Server 2019
Standard Edition (Desktop Experience). Windows Server Core is a method of
using Windows Server that removes a considerable part of the user interface to
reduce the attack surface on Windows Server, and most configuration on this type
of server is performed remotely or with command line tools. It is entirely possible
to deploy Active Directory Certificate Services using Windows Server Core and
remotely manage the installation and configuration. It is possible with remote
administration features that are available in Windows Server to manage this type
of environment, but this type of configuration is beyond the scope of this book.

Certificate Authority Test Environment | 27

Here is a breakdown of the servers and workstations that are being used in the TFS Labs
test environment:

• TFS-CA01 is the Subordinate Certificate Authority in the TFS Labs domain. It is an

Enterprise CA that is using the Active Directory Certificate Services role. It is used to
issue all certificates within the domain, except for the Root certificate that is issued
by the Root Certificate Authority that is located on the TFS-ROOT-CA server. It is also
used to handle the OCSP role and primary CRL roles for certificate revocation. It is a
TFS Labs domain member.
• TFS-DC01 is the Domain Controller for the TFS Labs Active Directory domain. It is
also used to allow for automatic distribution of certificates using Group Policy to the
TFS Labs domain. The Active Directory Forest and Domain Functional Levels are set
to Windows Server 2016 Functional Levels.
• TFS-ROOT-CA is the Root Certificate Authority for the TFS Labs domain, which is a
Standalone CA that is using the Active Directory Certificate Services role. It is used to
create the Root certificate and is also used to sign the certificate for the Subordinate
Certificate Authority. It is left in an offline state unless there is an issue with the
Subordinate Certificate Authority or the CRL needs to be updated. It is not a member
of the TFS Labs domain and is technically just a workgroup server. There is also no
additional software or services installed on the server, except for BitLocker, should
that be used. Once the implementation of the Certificate Authority is complete it
can be shut down (but not deleted). This server has no network access to provide
additional security.
• TFS-WIN10 is a workstation that is a member of the TFS Labs domain, and it is used
to ensure that the certificates that are issued by the Certificate Authority is operating
correctly. It is also used to ensure that Group Policy deployment of these certificates
are working correctly.

For networking purposes all devices in this test environment are using the 10.100.1.0/24
network. Since there is only a handful of devices involved, all the IP addresses are set to
static and there is no DHCP server present to automatically distribute IP addresses. In
the test environment, the 10.100.1.0/24 network is the same as a physical network that
is being used for testing purposes, which means this will vary based on your network if
you choose to use the same Hyper-V virtual network configuration.

Active Directory Certificate Services GUI and CLI Installation

The installation and configuration for Active Directory Certificate Services can be
done through the GUI, but there are some steps that require the CLI to complete
the configuration. There are also some steps where the installation or
configuration is performed using the GUI, but the CLI instructions are also
provided as an alternative. Whichever method you use to configure the Certificate
Authority is up to you, but the CLI installation and configuration are typically much
faster to perform.

Now that the virtual machines that are needed for the TFS Labs domain have been
defined, there are several design considerations that will need to be made.

28 | Practical Guide to PKI with Windows Server

Certificate Authority Design Considerations
The focus of this book is to demonstrate the deployment of Active Directory Certificate
Services on the TFS Labs domain as a Two-Tier Certificate Authority. On a high-level, the
following design considerations will be made for this deployment:

• The use of SHA-1 will not be used since it has been deprecated by online Certificate
Authorities and by every vendor since SHA-1 is incredibly insecure. The Certificate
Authority that will be created in this example for TFS Labs will use SHA-2 (SHA256)
by default. It will also use a key length of 4096 bits wherever possible.
• This Certificate Authority deployment will utilize an Offline Root CA for the root of the
Certificate Authority.
• This deployment will utilize a Subordinate CA for issuing certificates to the TFS Labs
domain. This Subordinate CA will always be online and will be used to issue all
certificates to the TFS Labs domain.
• The Root certificate will be valid for 10 years and the Subordinate certificate will be
valid for 5 years. All issued certificates from the Subordinate CA will be valid for only
1 year.
• All files that need to be transferred to and from the Root CA server is done with a
virtual floppy disk through the virtualization platform used for creating it. This virtual
floppy disk will be deleted at the end of the implementation phase to protect the files
that were needed to be transferred as part of the implementation. When needed in
the future, a new virtual floppy disk should be created and then immediately deleted
once it is no longer required.
• For connectivity purposes, CNAME records will be used whenever possible to allow
for the Subordinate CA server to be split up in the future if needed. The Active
Directory Certificate Services role is designed to be easily broken up and reconfigured
should the need arise.
• Server roles will be minimized and only the minimum number of roles required will
be used. It is bad practice to run multiple server roles on the same server that is
running Active Directory Certificate Services. Certificate Authority servers should
never run other server roles, as this increases complexity on the server, and can
introduce issues that are difficult to troubleshoot.
• Certificate Templates will use the highest available compatibility settings whenever
possible and will not work properly on older versions of Windows.
• Auditing is enabled for all available Certificate Authority functions for troubleshooting
and compliance purposes. All auditing logs are stored in the Windows Event Logs.

These design considerations do not factor in any type of legacy applications or services
that may be present in some network environments. It is up to you to determine if these
settings are appropriate for your network, and that is why it is important to fully plan and
thoroughly test the Certificate Authority before putting it into production.

Determining which requirements are needed for the Certificate Authority when it is
deployed in your environment is up to you, and the requirements will always vary based
on the organization.

Certificate Authority Test Environment | 29

Certificate Hierarchy Overview
For the certificates that will be issued for the TFS Labs domain, there will be one Root
certificate and one Subordinate certificate in a Two-Tier Certificate Authority. Here is an
overview of what that certificate hierarchy will look like once it is completed:

Figure 2.3.1: The TFS Labs Certificate Authority is a Two-Tier Certificate Authority
consisting of a Root and Subordinate Certificate Authority.

The certificate structure and associated servers for the TFS Labs domain are as follows:

Certificate Name Certificate Type Validity

TFS Labs Certificate Authority Root Certificate 10 years
TFS Labs Enterprise CA Subordinate Certificate 5 years
N/A Issued Certificate 1 year

The validity period for the certificates in the TFS Labs domain will be set to the following:

• The Root CA certificate is set to expire after 10 years. This certificate is the Root of
the entire PKI for the TFS Labs domain. The validity period of 10 years is perfectly
acceptable for a Root CA, and that server will need to be brought online once every
52 weeks to update the CRL for the Root CA.
• The Subordinate CA certificate is set to expire after 5 years. This certificate is used
to sign all certificates that are issued in the TFS Labs domain. Unlike the Root CA,
it will always be online and available. From an Active Directory Certificate Services
role perspective, it is an Enterprise CA.

30 | Practical Guide to PKI with Windows Server

 • All certificates that are issued from the Subordinate CA is limited to 1 year only for
the validity period. Many vendors, the most recent being Apple, have specifically
restricted SSL lifetimes to 1 year only for security purposes. This forces vendors to
keep their SSL certificates up to date and to make sure that modern security practices
and technologies are being used to protect their users. Most modern web browsers
enforce strict SSL security to keep users safe, so this is the primary reason this is
being done. Even though the TFS Labs Certificate Authority is internal only, it should
still follow best practices.

Once a fully functioning Certificate Authority is deployed on the TFS Labs domain, the
complete Certificate Authority hierarchy for the TFS Labs domain can be seen on the
Subordinate certificate:

Figure 2.1.2: The TFS Labs Certificate Authority and TFS Labs Enterprise CA certificate
can be viewed in the completed certificates for the TFS Labs domain.

By looking at the Subordinate certificate details, the TFS Labs Enterprise CA is a

Subordinate certificate of the TFS Labs Certificate Authority Root certificate. The TFS
Labs Certificate Authority was used to sign the certificate for the TFS Labs Enterprise CA.
The validity period for the Root certificate is set to 10 years, and the validity period for the
Subordinate certificate is set to 5 years as specified above.

Certificate Authority Test Environment | 31

 Certificate Validity Periods

It is up to you and your organization to determine how long certificates should be

valid for. It used to be common to have Root certificates that would have validity
periods of over 20 years, and with that type of setup you did not have to do a lot of
work to maintain those Certificate Authorities. If your organization does not
require interoperability with certain vendors, you are free to have certificate
validity periods for as long as you want, but that could change at any time.

For example, web browser vendors such as Google, Microsoft, Mozilla, and Apple
could force a change to disallow certificates with long validity periods within their
Browsers. This could mean that certificates with long expiration times could
become invalidated at any time, and it usually only requires one vendor to make
the change to get the other vendors to do the same.

AD CS Internal URLs
All the internal URLs that will be in use for the Active Directory Certificate Services role
will point to the TFS-CA01 server and utilize CNAME records. The following URLs will be
in use once the Active Directory Certificate Services implementation has been completed:

Active Directory Certificate Services Role Internal URL

IIS 10.0 HTTP Server Instance http://tfs-ca01.corp.tfslabs.com/
Certificate Practice Statement http://pki.corp.tfslabs.com/cps.html
Root CA Certificate Revocation List http://pki.corp.tfslabs.com/CertData/
Enterprise CA Certificate Revocation List http://pki.corp.tfslabs.com/CertEnroll/
Certificate Internal Download Location http://pki.corp.tfslabs.com/Certificates/
Online Certificate Status Protocol http://ocsp.corp.tfslabs.com/ocsp/
Active Directory Web Enrollment Service https://pki.corp.tfslabs.com/CertSrv/

These URLs will all be needed to properly implement a Certificate Authority using Active
Directory Certificate Services. Even though some of them do not appear to be important,
or in some cases even appear to have anything associated with them, they are needed to
ensure that clients and services that are using the PKI can do so successfully. IIS will be
used for hosting the files for the Certificate Authority in the TFS Labs domain.

Despite there being CNAME records in place to create these URLs for the PKI, they will
still work with the regular FQDN of the TFS-CA01 server.

32 | Practical Guide to PKI with Windows Server

 SSL Enabled Services

SSL is not enabled for many of the websites that a Certificate Authority uses, and
this is mostly to support the deployment and validation of certificates. The one
exception to this is the Active Directory Web Enrollment Service website, since it is
used to securely submit a Certificate Request to the Enterprise CA. The reason
that you cannot always use SSL is because you cannot always assume that the
devices connecting to an SSL website has your Root and Subordinate certificates
on it, and therefore the connection would not be secure anyway.

This is especially true when a device connecting to your internal secure resources
does not yet have the certificates needed for the connection, as is usually the
case for a new device that has connected to the domain.

Public Facing PKI Websites

It is extremely bad practice to ever allow the internal websites for the Active
Directory Certificate Services role to be publicly facing on the internet. Allowing
these websites to be available on the public internet exposes your organization to
many potential security risks, such as potentially leaking information about your
Active Directory information and any certificates that have been issued.

If there is ever a requirement to make the Active Directory Certificate Services role
publicly facing on the internet, there is an issue with the requirements for that type
of deployment. The internal websites for the Active Directory Certificate Services
role should never be publicly facing, and if the request is ever made to allow this,
you should push back on that requirement and deny it.

Active Directory Certificate Services is not meant to be used for issuing

certificates on the public internet, so there is no requirement for the role to be
available in that manner. Users that are external to the network should utilize a
VPN to request and update certificates if they are located outside of the network.

AD CS Important Files
At the end of the Active Directory Certificate Services deployment, there will be several
important file locations on several servers that are needed to host important files needed
to support the Certificate Authority.

AD CS Important Files - TFS-CA01

The TFS-CA01 server is the Subordinate CA as well as an Enterprise CA for the TFS Labs
domain. It is the only part of the Certificate Authority that is always online, so it contains
the needed files for both the Root and Subordinate Certificate Authority, as well as all
web services needed to support both of those functions.

Certificate Authority Test Environment | 33

The important folders that are used for Active Directory Certificate Services located on
the TFS-CA01 server include:

Location Purpose
C:\CertData Contains the Root CA CRL files.
C:\Certificates Contains the Root and Subordinate
certificates for internal web deployment.
C:\CertRecovery Contains any certificate that has been
restored if the private key is lost.
C:\inetpub\wwwroot\cps.html The CPS document that is referenced in
the Root and Subordinate certificates.
C:\Windows\System32\CertLog Contains the log files for the CA.
C:\Windows\System32\CertSrv\CertEnroll Contains the Subordinate CA CRL files.
C:\Windows\System32\CertSrv\en-US Contains the Web Enrollment website
files.
C:\Windows\SystemData\ocsp Contains the files needed for the OCSP
role web service.

Aside from the files and folders that are located on the TFS-CA01 server, there is also an
important location in the Windows Registry that is used to store critical settings needed
for Active Directory Certificate Services:

HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

AD CS Important Files - TFS-DC01

The TFS-DC01 server is the Domain Controller for the TFS Labs domain and is used
primarily to deploy certificates to the domain using Group Policy. The important folders
that are used for Active Directory Certificate Services located on the TFS-DC01 server
include:

Location Purpose
C:\Certificates Contains the Root and Subordinate certificates for Group Policy
deployment.

Since Active Directory Certificate Services is not installed on the TFS-DC01 server, there
is nothing specifically stored in the Windows Registry related to that role. There is
information stored in Active Directory relating to the Certificate Authority since there is an
Enterprise CA in the domain, and this can be viewed using the Active Directory Sites and
Services (dssite.msc) console.

34 | Practical Guide to PKI with Windows Server

AD CS Important Files - TFS-ROOT-CA
The TFS-ROOT-CA server is the Root Certificate Authority for the TFS Labs domain. It is
an Offline CA, so it does not have any network connections. Any files that are needed for
normal operation of the Root Certificate Authority will be hosted on the TFS-CA01 server,
which is an Enterprise CA. The important folders that are used for Active Directory
Certificate Services located on the TFS-ROOT-CA server include:

Location Purpose
C:\RootCA Contains implementation files needed for
the Certificate Authority deployment.
C:\Windows\System32\CertLog Contains the log files for the Root CA.
C:\Windows\System32\CertSrv\CertEnroll Contains the Root CA CRL files which are
updated once per year.

Like the TFS-CA01 server, there is also an important location in the Windows Registry
that is used to store critical settings needed for Active Directory Certificate Services:

HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

AD CS Security Considerations
There are a few security considerations that you should factor in before deploying Active
Directory Certificate Services in your environment, and most of those considerations are
just best practices. This is to ensure that the integrity of your PKI is always maintained,
and that there are no issues in supporting it. The most common security considerations
for Active Directory Certificate Services include:

• Never install any Active Directory Certificate Services roles on a Domain Controller.
• Always install Active Directory Certificate Services roles on dedicated servers. Keeping
AD CS servers more isolated than other servers is beneficial for security purposes.
• Avoid mixing and matching Windows Server versions with Active Directory Certificate
Services. Try and keep all associated AD CS roles on the same operating system
versions and editions whenever possible.
• Ensure that regular backups are kept for Active Directory Certificate Services servers.
Test the backups to ensure that the PKI infrastructure can be successfully restored
if needed.
• Ensure that Active Directory Certificate Services servers are kept up to date.
• Avoid using obsolete or legacy encryption technologies.
• Create specific Active Directory Groups for AD CS administration purposes. Try and
reduce the number of users that have access to those servers to minimize risk to the
PKI infrastructure.
• Avoid auto-enrollment for Certificate Templates that do not require it.
• Keep Offline Root Certificate Authorities in a secure location that cannot be easily
accessed.

Certificate Authority Test Environment | 35

If your network and server environment are secure and everything is configured correctly,
you should not have to worry too much about the security of your Active Directory
Certificate Services deployment. With that said, it is important to understand that a
compromised Certificate Authority is a major issue for an organization, so keeping it
secure is critical for IT staff members and the organization in general.

Certificates can be used for critical infrastructure such as VPN and server authentication,
so if there are security issues with a Certificate Authority, there can be instances when
those critical services are not available to the end user.

Certificate Authority Naming Conventions

It is important to create a proper naming convention for your Certificate Authority and
everything that is associated with the Certificate Authority. Determining the name of the
Certificate Authority is an important first step before you begin provisioning servers, and
it is extremely difficult to change the name of a Certificate Authority after one has been
created.

Some things that you should take into consideration before starting a Certificate
Authority are the following:

• Use descriptive names whenever possible, even if those names can be redundant in
some instances.
• For customizable items, such as a Certificate Template, try and prefix the name of
the Certificate Template so that users are aware that the Certificate Template is for
them and that it is something that they should use instead of the default options that
may still be available within the environment.
• Ensure that the Certificate Authority has the name of your organization in it and is
not something generic that can potentially cause confusion for end users.
• Do not use the default names for the Certificate Authority, as they are not user-friendly
and do not look professional in a production environment. Using default names can
also expose the names of the servers that host the Certificate Authority, which is
not always something that an organization would want for security or compliance
purposes.
• Avoid using server names for important internal links, use CNAME records to make
them more user-friendly whenever possible.
• Only advertise the links to internal Certificate Authority services using CNAME records
whenever possible.

Worrying about how to name a Certificate Authority may not seem important at all, but
ensuring that a proper naming convention is in place will save a lot of trouble later,
especially if things are not setup correctly. Fixing the name of a Certificate Authority after
it has been created it not easy to do, so it is best to just determine the naming convention
before you even provision a server needed for it.

36 | Practical Guide to PKI with Windows Server

Hyper-V Configuration
Hyper-V is a hardware virtualization platform that was created by Microsoft for the
Windows operating system. It is designed to let you create and run virtual machines in an
isolated environment for multiple purposes. It is a native feature in Windows and can be
easily installed and used if the computer supports it.

Figure 2.8.1: Hyper-V Manager as it appears on Windows Server 2019. Listed in the
window are the four virtual machines that are used for this book to demonstrate the TFS
Labs Certificate Authority.

Hyper-V allows you to create virtual hard disks, virtual switches, and all other virtual
devices needed to emulate real Computer Hardware. It is available as a server role in
Windows Server and as an optional feature in some versions of the client version of the
Windows operating system. With Hyper-V, you can do the following:

• Create a private cloud environment for running production or development virtual

machines.
• Use your hardware more effectively by running multiple virtual machines with less
resources.
• Test and develop applications and systems more rapidly without causing issues with
your primary computer.
• Run software that requires older versions of the Windows operating system or other
operating systems.
• Run software in a sandbox, to prevent it from causing issues with other devices.

Certificate Authority Test Environment | 37

The version of Hyper-V that is available in the client versions of Windows is not the same
as the version that is available in Windows Server. It does offer the same base
functionality as the version available on Windows Server, but there are several missing
features that are exclusive to Windows Server. Features that are only available on the
Windows Server version of Hyper-V include:

• Live migration of virtual machines to another Hyper-V server

• Hyper-V Replication
• Virtual Fiber Channel
• SR-IOV Networking
• Shared VHDX files

These limitations that are present in the client version of Hyper-V should not cause
issues for most people as those missing features are mostly used in large-scale
deployments of Hyper-V. These features are especially helpful in Datacentre deployments
of Hyper-V and would not affect users on a regular computer.

If you are already using Hyper-V and do not need any assistance with setting it up, you
can completely skip this section. If you are using another virtualization platform, you can
also skip this section. If you would like to learn how to install and configure Hyper-V on
Windows 10 Pro, you can continue reading the next few sections.

Hyper-V Requirements
Hyper-V is available as an optional feature in certain client versions of Windows. It is
available on the 64-bit versions of Windows 10 Pro, Enterprise, and Education only. It is
also available in Windows 8 and Windows 8.1 (Pro and Enterprise versions). Hyper-V is
not available on any Home Edition of Windows, or any of the versions designed for
low-end devices or non-x86 devices as it is not supported.

From a hardware support perspective, there are also additional requirements for
installing and running Hyper-V:

• 64-bit Processor with Second Level Address Translation (SLAT)

• CPU support for VM Monitor Mode Extension (VT-x on Intel Processors)
• Minimum of 4 GB memory

For memory, 4 GB is the minimum required to install and run Hyper-V, but that is not
enough memory to run all the virtual machines needed to setup the test environment. A
minimum of 16 GB of memory is recommended to properly test all virtual machines.

For Hyper-V to operate correctly, there may be various settings within the BIOS that would
need to be enabled. These settings vary based on the manufacturer, but there is usually a
virtualization section in the computer or server BIOS where those settings are configured.
If you are unsure, you should refer to the manufacturer’s documentation for your system
to determine how to enable the necessary virtualization features.

To quickly determine if your computer can run Hyper-V, there is a built-in utility in
Windows to allow you to check:

38 | Practical Guide to PKI with Windows Server

 1. Click on the Start menu, type in msinfo32.exe and press the Enter key to open the
program.
2. The System Information program will open.
3. In the System Summary window, scroll to the bottom of the page and check that the
following lines are present, and the Value is “Yes”:
• Hyper-V - VM Monitor Mode Extensions
• Hyper-V - Second Level Address Translation Extensions
• Hyper-V - Virtualization Enabled in Firmware
• Hyper-V - Data Execution Prevention

The output of the System Information application should look similar to this:

Figure 2.8.2: The System Information application can be used to view extensive
information on a Windows device. In this screenshot, it is showing the status of Hyper-V.

If all the Hyper-V settings are present and available in the System Summary window, then
you should be able to install and run Hyper-V without any issues.

Multiple Virtualization Platforms

Windows does not always easily support multiple virtualization platforms that are
installed at the same time. For example, Hyper-V and VMware Workstation cannot
always be installed at the same time and work correctly. If there is an issue
getting Hyper-V to operate, ensure that there is no other virtualization platform
installed and in use.

In recent versions of Windows 10 (version 1809 and later), there is a Windows

feature called Virtual Machine Platform that makes it much easier for
virtualization platforms to co-exist on the same Windows installation.

Certificate Authority Test Environment | 39

Hyper-V Installation
If your computer meets the necessary requirements for running Hyper-V, there are several
methods for installing it which are available. Hyper-V can be installed by using the
Windows 10 Control Panel, through PowerShell with a Cmdlet, or through the Deployment
Imaging Servicing and Management (DISM) tool.

Hyper-V is built-in to the versions of Windows that supports it, so there is no need to
download anything to install it as it is already available within the operating system.

Enable Hyper-V using the Control Panel

To install Hyper-V using the Control Panel on a Windows 10 Pro workstation, perform the
following steps:

1. Click on the Start menu, type in appwiz.cpl and press the Enter key to open the
program.
2. In the Program and Features window, click on the Turn Windows features on or off
link in the left side of the window.
3. In the Windows Features window, select all the options under Hyper-V and click the
OK button to continue.

Figure 2.8.3: Hyper-V can be installed on Windows 10 using the Control Panel.

After the command has been executed you will need to restart the computer for the
installation of Hyper-V to be completed.

40 | Practical Guide to PKI with Windows Server

Enable Hyper-V using PowerShell
It is possible to install Hyper-V on a Windows device using PowerShell, which uses the
Enable-WindowsOptionalFeature Cmdlet.

To install Hyper-V using PowerShell, open an elevated PowerShell prompt and run the
following command:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

The output of the command should look similar to this:

Figure 2.8.4: Hyper-V can be installed without the GUI using PowerShell.

After the command has been executed, you will need to restart the computer for the
installation of Hyper-V to be completed.

PowerShell Cmdlets

If there is an issue with the PowerShell command being executed properly, then
you are not running the command as an administrator. The command will also not
work if it is being executed in the Command Prompt. This is because there is no
way to run a Cmdlet from the Command Prompt, so the command will always fail.

PowerShell can be manually started from the Command Prompt if necessary by

running the powershell.exe command, which will switch to PowerShell.

Certificate Authority Test Environment | 41

Enable Hyper-V using DISM
Another method to install Hyper-V is to use the DISM command line tool to add the
Hyper-V feature to the Windows device that is going to be using it.

To install Hyper-V using DISM, open an elevated Command Prompt and run the following
command:

DISM.exe /Online /Enable-Feature /All /FeatureName:Microsoft-Hyper-V

Figure 2.8.5: Hyper-V can be installed using the Command Line using the DISM tool.

After the command has been executed you will need to restart the computer for the
installation of Hyper-V to be completed.

If there is an issue with the command being executed properly, then you are not running
the command as an administrator. The command will also not work if it is being
executed in PowerShell.

Hyper-V Network Setup

Before determining how the virtual machines will connect to the virtual network, you will
need to determine if you are going to want to test the Certificate Authority with external
devices such as an iOS or an Android device.

There are several ways to configure the networking to allow for shared access from the
virtual network to the physical network, and there is a lot of flexibility in virtual networks
to allow for this connection. Since this is just being used for a test environment, setting
up the virtual network is much simpler than in a production environment.

42 | Practical Guide to PKI with Windows Server

There are three types of virtual switches that are available and supported in Hyper-V:

• External Network - This is a virtual switch that binds to a physical network adapter
so that virtual machines can access the network just like a physical device. This is
the most common type of Hyper-V network that is used in a production environment.
• Internal Network - This is a virtual switch that does not connect to the physical
network in any way. Any virtual machine that is connected to that virtual switch will
be able to communicate with other virtual machines that are on the same virtual
switch.
• Private Network - This is a virtual switch that is like an internal virtual switch, except
the host operating system is not able to communicate with the virtual machines on
that virtual switch.

The most common type of Hyper-V network is the External Network. This is the easiest
type of network to setup and offers the most flexibility. The other types of networks are
usually designed and meant for larger scale Datacentre environments with specific
requirements.

Networks in Hyper-V support the addition of VLAN tags to network interfaces to support
more complex networks. In the case of this test environment, that is something that will
not be used. Hyper-V also supports the ability to share the management interface of
Hyper-V with the network adapter that is being used to reduce the number of required
network adapters that are needed. This is especially useful on a desktop computer or
laptop that typically only has one network adapter. Since most users with laptops utilize
wireless networking, it is also compatible with Hyper-V networks and allows for users
with different hardware the ability to use Hyper-V with various configurations.

Hyper-V Default Switch

In the client versions of Windows, Hyper-V will automatically create a virtual

switch at the time of installation. This switch is bridged to the default Ethernet
Adapter using NAT to immediately give virtual machines access to the local
network. It is the same configuration as the external network virtual switch. The
virtual switch will usually show up as vEthernet (Default Switch) in the available
network connections for the computer.

The Hyper-V default switch is also automatically configured to utilize the

management interface and will bridge to multiple adapters as needed. If the
Hyper-V default switch is missing on your computer, it can be easily recreated by
just adding a new external network with shared management enabled on that
network.

Since this book only creates a test environment for demonstrating the setup of a
Certificate Authority, an external network switch is being used. This allows for easy
testing of the Certificate Authority with external devices that are not being created as a
virtual machine, such as an iOS or Android device.

Certificate Authority Test Environment | 43

Hyper-V Virtual Machine Generation
Two generations of virtual machines that are currently available in Hyper-V, Generation 1,
and Generation 2. There are several technical reasons why you would choose to use one
virtual machine generation over another, and that just depends on what requirements are
needed for the virtual machine. Generation 2 virtual machines have been available in
Hyper-V since Windows Server 2012 R2 and are designed for more modern operating
systems. Generation 1 virtual machines are still supported and needed in certain
circumstances and are all used in this book.

There are multiple differences that exist between Generation 1 and Generation 2 virtual
machines, but for the purposes of creating the test environment in this book, Generation
1 virtual machines are required to support the use of a virtual floppy disk.

There are a few scenarios where a Generation 1 virtual machine is needed over a
Generation 2 virtual machine:

• Installing an older operating system that does not support UEFI.

• Installing an older operating system that is only available as 32-bit.
• Migrating to a Hyper-V host machine that does not support Generation 2 virtual machines.
• Support for COM ports, virtual floppy drives, and virtual floppy disks.

For the last point of needing to support virtual floppy disks, all servers and workstations
created in Hyper-V for this book will utilize Generation 1 virtual machines in Hyper-V.
These virtual machines will have a virtual floppy drive available by default, so there is no
need to configure one. No Generation 2 virtual machines are needed at all.

Converting Hyper-V Generations

Microsoft does not officially support a way to convert a Generation 1 virtual

machine to a Generation 2 virtual machine in Hyper-V, and vice versa. Ensure that
when you create a virtual machine in Hyper-V that you create it with the correct
Generation setting as there is no way to easily fix that issue.

There are third-party solutions that may be able to convert between Generation 1
virtual machines and Generation 2 virtual machines in Hyper-V. Those solutions
are beyond the scope of this book and not supported by Microsoft.

Hyper-V Checkpoints
Hyper-V supports Checkpoints, which is also known as Snapshots in other virtualization
platforms. A Checkpoint is a copy of a virtual machine at a particular time, which
captures everything about the virtual machine at that point in time. Hyper-V Checkpoints
are primarily used to revert or undo changes to a virtual machine in case a problem
arises can cause issues. There is the option in Hyper-V to apply multiple Checkpoints to
a virtual machine, which can be useful for testing purposes. Hyper-V Checkpoints are not
an adequate backup solution and should never be used in that manner.

44 | Practical Guide to PKI with Windows Server

There are few things to know about Hyper-V Checkpoints:

• Hyper-V Checkpoints are stored as AVHD or AVHDX files whenever they are used, and
they are stored in the same folder as the Hyper-V hard disks for a virtual machine.
• Hyper-V Checkpoints can be explicitly enabled or disabled for a virtual machine, as
well as set to automatic if needed or required.
• Hyper-V Checkpoints are helpful for testing purposes and can be used to undo changes
to a virtual machine in only a few minutes.

Hyper-V Checkpoints are a useful feature for allowing you to quickly revert to a previous
point in time if you experience an issue with a virtual machine, but they do not replace the
necessity for a proper backup solution.

Hyper-V Checkpoints and Disk Space

One downside to Hyper-V Checkpoints is once you start using them and there are
many of them in use, they can begin to slowly take up a considerable amount of
disk space. When you provision a virtual hard disk, you can specify the size of the
disk and Hyper-V will not allocate more to the disk space if it is used up. However,
with Checkpoints, the AVHD files can grow to whatever size is needed, which can
fill up the entire hard drive or storage location if left unchecked.

Ensure that if you are using a Checkpoint and are finished with it, you should either
delete it or merge in into the main virtual hard disk to prevent the size from getting
out of control, and causing issues with the computer or server that is hosting
Hyper-V.

Hyper-V Virtual Machine Creation

Creating a virtual machine in Hyper-V is not difficult to do and only requires minimal
steps to setup a virtual machine. To create a virtual machine with Hyper-V, perform the
following steps:

1. Open the Hyper-V Manager (virtmgmt.msc).

2. In the Actions pane, click New and select Virtual Machine....
3. The New Virtual Machine Wizard window will appear.
4. On the Before You Begin screen, click the Next button to continue.
5. On the Specify Name and Location screen, enter a name for the virtual machine in
the Name field. Click the Next button to continue.
6. On the Specify Generation screen, select the Generation setting for the virtual machine
(this book only uses Generation 1). Click the Next button to continue.
7. On the Assign Memory screen, set the amount of Startup memory for the virtual
machine. If you would like to only use a set amount of memory for the virtual machine,
unselect the Use Dynamic Memory for this virtual machine option to only use the
amount specified.
8. On the Configure Networking screen, select the network to use in the Connection list
and click Next to continue.

Certificate Authority Test Environment | 45

 9. On the Configure Virtual Hard Disk screen, change the following options:
• Name - Enter the name of the virtual machine.
• Location - Enter the location of the virtual hard disk (usually the Hyper-V default
location).
• Size - Enter the size of the virtual hard disk in GB.
10. On the Installation Options screen, specify where the Operating System installation
source is located. Click the Next button to continue.
11. On the Summary screen, click the Finish button to continue.

Creating a virtual machine in Hyper-V is not difficult to do, and the only real requirement is
managing the resources on the workstation or server that is running Hyper-V. It is
important to ensure that you do not over-provision virtual machines, which can cause
resource issues for the host machine running Hyper-V.

Hyper-V Virtual Machine Connection

When a virtual machine is created using Hyper-V, it is not immediately useful if there is no
method of connecting to that virtual machine to perform any configuration on it. Included
with Hyper-V is an application that enables a connection to the virtual machine, and that
is the Virtual Machine Connection (vmconnect.exe) application, which is also known as
VMConnect. This application can connect to Hyper-V virtual machines either locally or
remotely over the network and connects to the “console” of the virtual machine. This
means that the Virtual Machine Connection works as if you are physically working with
the virtual machine. By default, the keyboard and mouse input are all sent to a virtual
machine when you are interacting with a virtual machine using this application. The
Virtual Machine Connection application is like the Remote Desktop Connection
(mstsc.exe) application that is used to connect over RDP to Windows devices.

When connecting to the Virtual Machine Connection application, you are presented with
this window:

Figure 2.8.6: The Hyper-V VMConnect application supports connections to Hyper-V virtual
machines on the local device or over the network.

46 | Practical Guide to PKI with Windows Server

From here, you can connect to Hyper-V virtual machines that are local to that server, or on
virtual machines that are located on the network. The VMConnect console will appear
like this for a virtual machine that you have connected to:

Figure 2.8.7: The Hyper-V VMConnect application allows you to interact directly with
the virtual machine as if it were a physical machine. Compared to the Remote Desktop
Protocol, this is the equivalent of connecting to the console of the virtual machine.

Aside from simply connecting to a virtual machine, the Virtual Machine Connection
application also offers the following features:

• The ability to start, restart, power off or pause a virtual machine.

• Add disk images to the virtual machines, such as a DVD image (.iso) or a virtual
floppy disk image (.vfd).
• Create and revert Hyper-V Checkpoints.
• Access the settings of the virtual machine.
• Access and manage the shared clipboard for the virtual machine.
• Send custom keyboard commands such as CTRL + ALT + DEL.

Certificate Authority Test Environment | 47

There are also several keyboard shortcuts that are specifically available for the Virtual
Machine Connection application. These keyboard shortcuts do not perform any actions
in the underlying host operating system, and to ensure that you are interacting with the
Virtual Machine Connection application, you may need to press the CTRL + ALT + LEFT
keys before using the following commands:

Keyboard Shortcut Purpose

CTRL + ALT + BREAK Switches from full screen mode back to windowed mode.
CTRL + ALT + LEFT Releases the mouse from the virtual machine.
CTRL + ALT + END Enters CTRL + ALT + DELETE in the virtual machine.
CTRL + O Opens the settings for the virtual machine.
CTRL + S Starts the virtual machine.
CTRL + N Creates a Hyper-V Checkpoint.
CTRL + E Reverts to a Hyper-V Checkpoint.
CTRL + C Performs a screen capture for the virtual machine.

Overall, the Virtual Machine Connection application offers a convenient method of

accessing a virtual machine that is using Hyper-V. If there are issues with a virtual
machine, the Virtual Machine Connection application will allow you to correct any issues
with the virtual machine or make configuration changes to correct any issues with it.

Virtual Machine Connection and Remote Desktop Protocol

There are a few differences between the Virtual Machine Connection application
and the Remote Desktop Connection application that are provided in Windows.
The Remote Desktop Connection application can be more responsive than the
Virtual Machine Connection application and allows actions such as cut and paste
to be performed much easier.

When utilizing Hyper-V, it is easier to use the Remote Desktop Connection

application whenever possible. The only exception is for virtual machines that are
not on the network, such as the Offline Root CA. In that case, you would need to
use the Virtual Machine Connection application to interact with that virtual
machine as it is not available on the network.

Hyper-V Disk Virtual Floppy Disk Management

Part of creating a secure Two-Tier Certificate Authority requires always keeping the Root
Certificate Authority off the network to keep it safe. Because of this, it is not possible to
connect to the network to receive files and transit files. This security concern keeps the
Root Certificate Authority protected from potential issues by removing any threats to it as
it is not able to be reached by conventional means.

48 | Practical Guide to PKI with Windows Server

For transferring the necessary files between the Root CA and the Subordinate CA, there is
the option of using a virtual floppy disk. The size of the files that need to be transferred
with the virtual floppy disk are relatively small (less than 100 KB total), so a virtual floppy
disk is a fast and convenient method of doing this.

To create a virtual floppy disk in Hyper-V, it can be created using the Hyper-V Manager:

1. Open the Hyper-V Manager (virtmgmt.msc).

2. On the Actions pane, click the New button and select Floppy Disk....
3. On the Create Virtual Floppy Disk window, browse to the location where you would
like to save the floppy disk.
4. Input RootCAFiles.vfd as the name for the floppy disk in the File name field and click
the Create button.

The virtual floppy disk will be saved with the .vfd extension by default. It will need to be
formatted the first time that it is used for it to be used properly. To utilize the virtual
floppy disk while using a virtual machine, it can be easily added to a running virtual
machine by performing the following steps:

1. Open the Virtual Machine Connection (vmconnect.exe) window for the virtual machine
that you want to add the virtual floppy disk to.
2. Click on the Media menu, select the Diskette Drive menu and click the Insert Disk...
option.
3. On the Open window, browse to the location where you saved the RootCAFiles.vfd
file and click the Open button.
4. The virtual floppy disk is now added to the virtual machine.

To remove the virtual floppy disk, it only requires a few steps as well (ensure that you do
not have any open files on the virtual floppy disk when you eject it):

1. Open the Virtual Machine Connection (vmconnect.exe) window for the virtual machine
that you want to remove the virtual floppy disk from.
2. Click on the Media menu, select the Diskette Drive menu and click the
Eject RootCAFiles.vfd option.
3. The virtual floppy disk has now been removed from the virtual machine.

Overall, managing virtual floppy disks in Hyper-V is not difficult and is easy to move
between different virtual machines.

Virtual Floppy Disk Deletion

It is advised that after the implementation of the Certificate Authority that the
virtual floppy disk be deleted as it is no longer needed. This will also prevent any
sensitive data that is stored on the virtual floppy disk from being lost. When files
need to be transferred between the Root CA and the Subordinate CA (such as the
CRL when it needs to be renewed), you can just create a new virtual floppy disk for
the task and then delete it when you are finished.

Certificate Authority Test Environment | 49

Certificate Authority Test Environment Next Steps
Now that the TFS Labs test environment has been thoroughly explained and the process
of setting up Hyper-V has been explained, the next step in this book is to create the Active
Directory domain that will be used for the test environment. The Active Directory domain
that will be created will be used for all workstations and servers that are required to
properly test Active Directory Certificate Services.

50 | Practical Guide to PKI with Windows Server

Chapter 3 - Domain Controller and
Workstation Setup

The TFS-DC01 Domain Controller for the TFS Labs domain is setup as a single Domain
Controller in the corp.tfslabs.com Forest. This Active Directory domain will be used for
critical functions in the TFS Labs test environment and is necessary for a proper Active
Directory Certificates Services deployment. It will utilize the Active Directory Domain
Services role that is available in Windows Server.

Aside from being the Domain Controller for the TFS Labs domain, the TFS-DC01 server
will also be responsible for hosting the DNS server and DNS Zone for the TFS Labs
domain. It will also be used for managing Group Policy, which will be used for deploying
certificates. Once the Active Directory Domain Services role has been successfully
installed and configured, the following features will be available on the TFS-DC01 server
for managing Active Directory:

• Active Directory Users and Computers

• DNS Management
• Group Policy Management

These features are all required to properly configure a Certificate Authority using Active
Directory Certificate Services, as well as supporting Active Directory. These features are
available as separate applications, or through the Microsoft Management Console.

This chapter will focus on how to create an Active Directory Domain Controller for the
TFS Labs domain. It will also setup several test user accounts in Active Directory, as well
as setup a Windows 10 workstation that will be used for testing certificate deployment
later in this book.

Domain Controller and Workstation Setup | 51

Domain Controller Server Setup
Provision and configure a new virtual machine called TFS-DC01, and install Windows
Server 2019 Standard (Desktop Experience) in Hyper-V using the following specifications:

• Virtual Machine Generation - 1

• Virtual Processors - 2
• Virtual Memory - 4096 MB
• Virtual Hard Disk - 40 GB
• Virtual Network Adapters - 1

Once the TFS-DC01 virtual machine has been created and the operating system has been
installed, there are a few tasks that need to be completed:

• Set the password for the local administrator account (ensure that you use a complex
password).
• Set the hostname of the server to TFS-DC01. Restart the server to apply the change.

Once the local Administrator account and the hostname have been setup, you will also
need to configure the network settings for the virtual machine:

IP Address 10.100.1.100
Netmask 255.255.255.0
Gateway 10.100.1.1
DNS Server 1 8.8.8.8

Once the network has been setup correctly, you can then proceed to setting up the
TFS-DC01 server as a Domain Controller by installing the Active Directory Domain
Services role.

TFS Labs External DNS Servers

Once the TFS-DC01 server has been successfully promoted to a Domain

Controller, the DNS settings will be automatically updated to utilize the DNS server
that has been added as part of the installation. The TFS-DC01 server will be
added as the first DNS server in the network settings, and the original DNS entry
will be automatically moved to the second DNS server.

If you are having any DNS resolution issues after the Domain Controller
promotion, check the DNS settings on the TFS-DC01 server to ensure that there is
a forwarding DNS server listed.

52 | Practical Guide to PKI with Windows Server

 TFS Labs Domain Administrator Account Password

The local administrator account that is used during the initial setup of the
TFS-DC01 server will become the Domain Administrator account for the TFS Labs
domain once the server has been promoted to a Domain Controller.

Once the Active Directory installation has been completed, the local administrator
account that is on the TFS-DC01 server will become the TFSLABS\Administrator
account, which is the Domain Administrator account for the TFS Labs domain.
This Domain Administrator account will be used for the remainder of the
Certificate Authority implementation, except on the Offline Root CA server.

AD DS Role Installation
The Active Directory Domain Services role needs to be installed on the TFS-DC01 server
prior to configuring the server as a Domain Controller for the TFS Labs domain. The role
can be installed using Server Manager or through the command line with PowerShell, you
can decide which method you would like to use.

AD DS Role Installation - GUI Installation

To perform the Active Directory Domain Services installation using the Server Manager
console, perform the following steps on the TFS-DC01 server:

1. Open the Server Manager console (servermanager.exe), click on the Manage menu,
and then click on Add Roles and Features to start the installation wizard:

Domain Controller and Workstation Setup | 53

 2. On the Before you begin screen, click the Next button to continue:

3. On the Select installation type screen, select the option for Role-based or feature-based
installation and click the Next button to continue:

54 | Practical Guide to PKI with Windows Server

4. On the Select destination server screen, verify that the TFS-DC01 server is selected
and click the Next button to continue:

5. On the Select server roles screen, select the Active Directory Domain Services option:

Domain Controller and Workstation Setup | 55

 6. The installation wizard will ask to install any additional features required for the
Active Directory Domain Services role. Select the option to Include management
tools (if applicable) to install the management tools for the role. Click the Add
Features button to continue:

7. On the Select server roles screen, click the Next button to continue:

56 | Practical Guide to PKI with Windows Server

8. On the Select features screen, click the Next button to continue:

9. On the Active Directory Domain Services screen, click the Next button to continue:

Domain Controller and Workstation Setup | 57

 10. On the Confirm installation selections screen, select the option to Restart the destination
server automatically if required:

11. When prompted with a warning about restarting the server, click the Yes button.
12. On the Confirm installation selections screen, click the Install button to continue:

58 | Practical Guide to PKI with Windows Server

 13. Once the installation is completed, click the Close button:

Once the Active Directory Domain Services role has been installed successfully, you can
now configure the TFS-DC01 server as a Domain Controller for the TFS Labs domain.

AD DS Role Installation - CLI Installation

The Active Directory Domain Services installation can be performed using PowerShell,
which requires much fewer steps to accomplish. This installation will utilize the
Install-WindowsFeature Cmdlet, which can add features to Windows from the command
line.

This Cmdlet only works with PowerShell, so the Command Prompt cannot be used for
this step.

Perform the following steps on the TFS-DC01 server using PowerShell to add the Active
Directory Domain Services role:

1. Open an elevated PowerShell prompt.

2. Run the following command to install the Active Directory Domain Services role and
the necessary Remote Server Administration Tools:

Install-WindowsFeature AD-Domain-Services, RSAT-ADDS

Domain Controller and Workstation Setup | 59

 3. The command will automatically install the Active Directory Domain Services role
and output a Success status of True:

4. Once the installation for Active Directory Domain Services has completed, you can
close the PowerShell prompt.

Once the Active Directory Domain Services role has been installed, you can now
configure the TFS-DC01 server as a Domain Controller for the TFS Labs domain.

AD DS Role Configuration
Once the Active Directory Domain Services role has been installed on the TFS-DC01
server, it will need to be properly configured to become a Domain Controller for the TFS
Labs domain. In the process of configuring the TFS Labs domain, the following Active
Directory Domain settings will be configured on the TFS-DC01 server:

Forest Name corp.tfslabs.com

NetBIOS Domain Name TFSLABS
Forest Functional Level Windows Server 2016
Domain Functional Level Windows Server 2016

The local administrator account password that is currently set on the TFS-DC01 server
will become the Domain Administrator account password once Active Directory has been
setup for the TFS Labs domain.

60 | Practical Guide to PKI with Windows Server

Domain Controller Hostname

Ensure that the hostname for the TFS-DC01 server has been properly set before
going any further. There is no way to change the hostname on a Domain Controller
after it has been promoted, so it must be set correctly prior to being promoted.

Directory Services Restore Mode (DSRM) Password

It is essential that the Directory Services Restore Mode Password is set and
documented if there is a major issue with Active Directory. In the even that a
restore needs to be performed for Active Directory, this password must be used to
regain access to the server. Once the password has been set, it should be
documented in a secure location.

If you already have an existing Active Directory domain, and this password is
unknown, there are methods to reset this password without causing any
production issues or downtime. This is beyond the scope of this book but is
thoroughly documented on Microsoft’s website.

Forest and Domain Modes

The Forest and Domain modes for the TFS Labs domain is set to Windows Server
2016. When using the Install-ADDSForest command there are two parameters
that are used to set the Forest and Domain Modes, DomainMode and ForestMode.

Depending on which Forest and Domain modes you require for your Active
Directory domain, there are a few different options that you can use at the time of
configuration:

• Win2003 - Windows Server 2003

• Win2008 - Windows Server 2008
• Win2008R2 - Windows Server 2008 R2
• Win2012 - Windows Server 2012
• Win2012R2 - Windows Server 2012 R2
• WinThreshold - Windows Server 2016

There is no specific Forest of Domain mode for Windows Server 2019, and the
WinThreshold option represents the latest version that has been available since
Windows Server 2016. With Active Directory, you can always upgrade, or “raise”
the Forest and Domain Functional Levels at any point after installation.

The default option for the Install-ADDSForest Cmdlet is to set the Forest and
Domain to the Windows Server 2008 R2 Functional Level.

Domain Controller and Workstation Setup | 61

The Active Directory Domain Services role can also be configured using Server Manager
or through the command line with PowerShell, you can decide which one you would like
to use. You only need to choose one method for configuring the Active Directory Domain
Services role.

AD DS Role Configuration - GUI Configuration

To perform the Active Directory Domain Services configuration using the Server Manager
console, perform the following steps on the TFS-DC01 server:

1. To begin the configuration of Active Directory Domain Services, open the Server
Manager console (servermanager.exe). You will notice that AD DS now shows up as
being installed on the TFS-DC01 server. Click the Notifications icon in the upper-right
hand corner and click the Promote this server to a domain controller link in the
Post-deployment Configuration box:

62 | Practical Guide to PKI with Windows Server

2. On the Deployment Configuration screen, select the option for Add a new forest. For
the Root domain name, enter corp.tfslabs.com and click Next to continue:

3. On the Domain Controller Options screen, ensure that the Forest functional level
and Domain functional level are both set to Windows Server 2016. Ensure that
the options for Domain Name System (DNS) server and Global Catalog (GC) are
both selected. For the Directory Services Restore Mode (DSRM) password, enter a
complex password in both fields (ensure that you record this password somewhere).
Once completed, click Next to continue:

Domain Controller and Workstation Setup | 63

 4. On the DNS Options screen you can ignore the warning message about DNS Delegation
(this is due to there being no existing DNS Infrastructure at this point) and click Next
to continue:

5. On the Additional Options screen, for the NetBIOS domain name enter TFSLABS and
click Next to continue:

64 | Practical Guide to PKI with Windows Server

6. On the Paths screen, do not modify the default folder paths and click Next to continue:

7. On the Review Options screen, click Next to continue:

Domain Controller and Workstation Setup | 65

 8. On the Prerequisites Check screen you can ignore any warning messages and click
Install to continue:

9. On the Installation screen, Active Directory Domain Services will be configured, no

actions are required:

66 | Practical Guide to PKI with Windows Server

 10. On the Results screen, click the Close button to exit the wizard:

11. The TFS-DC01 server will automatically restart when the configuration has completed.

The TFS-DC01 server should restart automatically to complete the configuration of

Active Directory. Once the Active Directory Domain Services configuration is complete,
you will have a functioning Domain Controller for the TFS Labs domain.

AD DS Role Configuration - CLI Configuration

The Active Directory Domain Services configuration can be performed in much fewer
steps using PowerShell. The following steps will setup the TFS Labs domain in the exact
same way as using the Server Manager console to configure the domain. The
configuration will utilize the Install-ADDSForest Cmdlet, which can configure the Active
Directory Domain Services role from the command line. This Cmdlet only works with
PowerShell, so the Command Prompt cannot be used for this step.

Perform the following steps on the TFS-DC01 server using PowerShell to configure the
Active Directory Domain Services role:

1. Open an elevated PowerShell prompt.

2. Run the following command to import the ADDSDeployment PowerShell module
which is needed to configure Active Directory Domain Services:

Import-Module ADDSDeployment

Domain Controller and Workstation Setup | 67

 3. Run the following command to configure Active Directory Domain Services using
the following configuration settings for Active Directory:

Install-ADDSForest `
-CreateDnsDelegation:$false `
-DatabasePath "C:\Windows\NTDS" `
-DomainMode "WinThreshold" `
-DomainName "corp.tfslabs.com" `
-DomainNetbiosName "TFSLABS" `
-ForestMode "WinThreshold" `
-InstallDns:$true `
-LogPath "C:\Windows\NTDS" `
-NoRebootOnCompletion:$false `
-SysvolPath "C:\Windows\SYSVOL" `
-Force:$true

4. The command will prompt you to set the SafeModeAdministratorPassword, which

is the Directory Services Restore Mode (DSRM) password as specified in the GUI
installation. Enter a complex password for this, and the command will prompt you
to confirm the password before proceeding (ensure that you record this password in
case it is needed in the future):

Directory Services Restore Mode (DSRM) Password

It is essential that the Directory Services Restore Mode Password is set and
documented if there is a major issue with Active Directory. In the even that a
restore needs to be performed for Active Directory, this password must be
used to regain access to the server. Once the password has been set, it
should be documented in a secure location.

68 | Practical Guide to PKI with Windows Server

 5. The Active Directory Domain Services configuration will take several minutes to
complete:

6. The TFS-DC01 server will automatically restart when the configuration has completed.

The TFS-DC01 server should restart automatically to complete the configuration of

Active Directory. Once the Active Directory Domain Services configuration is complete,
you will have a functioning Domain Controller for the TFS Labs domain.

AD DS Role Configuration - Validation

Once the Active Directory Domain Services role has been successfully installed and
configured on the TFS-DC01 server, the Windows login screen will now specify the
domain when logging in. You can use the TFSLABS\Administrator account to login to the
TFS-DC01 server, which will login with the Domain Administrator account.

At this point, the TFS-DC01 server will have the necessary roles and features installed to
properly act as a Domain Controller for the TFS Labs domain.

Once the Active Directory Domain Services role has been successfully configured, you
can proceed to configuring the OU structure for the TFS Labs domain.

Domain Controller and Workstation Setup | 69

Create an Active Directory OU Structure
It is good practice to create a proper Organizational Unit (OU) structure in the TFS Labs
domain prior to adding and users, computers, or servers to the Active Directory domain.
An Organizational Unit is a folder in Active Directory that allows for easier management
of users and computers. An OU also makes it much easier to manage the deployment of
Group Policy Objects and to help keep the domain organized. It also forces
administrators to effectively manage their Active Directory Domain by ensuring that
newly created users, workstations, and servers are put into the correct OU to ensure that
critical policies are being applied where needed.

The OU structure for the TFS Labs domain is not complex, and consists of the following
structure:

• TFS Labs
• TFS Labs\TFS Labs Servers
• TFS Labs\TFS Labs Users
• TFS Labs\TFS Labs Workstations

There are two ways to add the OU structure to the TFS Labs domain, one using the Active
Directory Users and Computers console, or with the command line using PowerShell.

Create an Active Directory OU Structure - GUI Configuration

To create the OU structure using the Active Directory Users and Computers console,
perform the following steps on the TFS-DC01 server:

1. Open the Active Directory Users and Computers console (dsa.msc):

70 | Practical Guide to PKI with Windows Server

2. Click on the corp.tfslabs.com domain in the left side of the window:

3. Right-click on the corp.tfslabs.com domain, select the New option, and select Organizational
Unit:

Domain Controller and Workstation Setup | 71

 4. In the New Object - Organizational Unit window, for the Name, enter TFS Labs.
Ensure that the option to Protect container from accidental deletion is selected and
click the OK button:

5. The TFS Labs OU should now appear in the corp.tfslabs.com domain:

6. Right-click on the TFS Labs OU, go to New, and select Organizational Unit.
7. In the New Object - Organizational Unit window, for the Name, enter TFS Servers.
Ensure that the option to Protect container from accidental deletion is selected and
click OK.
8. Right-click on the TFS Labs OU, go to New, and select Organizational Unit.
9. In the New Object - Organizational Unit window, for the Name, enter TFS Users.
Ensure that the option to Protect container from accidental deletion is selected and
click OK.
10. Right-click on the TFS Labs OU, go to New, and select Organizational Unit.

72 | Practical Guide to PKI with Windows Server

 11. In the New Object - Organizational Unit window, for the Name, enter TFS Workstations.
Ensure that the option to Protect container from accidental deletion is selected and
click OK.
12. There should now be three OUs within the TFS Labs OU:

13. Close the Active Directory Users and Computers console.

Now that there is a basic OU structure in place in the TFS Labs domain, several test user
accounts can now be created that will be used in later chapters for testing purposes.

Create an Active Directory OU Structure - CLI Configuration

To create the OU structure using PowerShell, perform the following steps on the
TFS-DC01 server:

1. Open an elevated PowerShell prompt.

2. Run the following commands to create the OU structure:

New-ADOrganizationalUnit `
-Name "TFS Labs" -Path "DC=corp,DC=tfslabs,DC=com"

New-ADOrganizationalUnit `
-Name "TFS Servers" -Path "OU=TFS Labs,DC=corp,DC=tfslabs,DC=com"

New-ADOrganizationalUnit `
-Name "TFS Users" -Path "OU=TFS Labs,DC=corp,DC=tfslabs,DC=com"

New-ADOrganizationalUnit `
-Name "TFS Workstations" -Path "OU=TFS Labs,DC=corp,DC=tfslabs,DC=com"

3. Close the PowerShell prompt.

Domain Controller and Workstation Setup | 73

The OU structure can be confirmed by opening the Active Directory Users and Computers
console and searching for the TFS Labs OU structure. Now that there is a basic OU
structure in place in the TFS Labs domain, several test user accounts can now be created
that will be used in later chapters for testing purposes.

Domain Controller Default OU

Any Domain Controller in an Active Directory Domain will always be found in the
Domain Controllers OU by default. You should not move any Domain Controllers
from this OU unless the Domain Controller has been demoted and is no longer
being used for Active Directory.

Since the Domain Controllers are in a separate OU from the structure that was just
created, you will need to factor that in when you are applying Group Policy Objects
to those servers.

Create Domain User Accounts

During the setup for the Certificate Authority for the TFS Labs domain, there is only one
Active Directory account that can be used, and that is the Domain Administrator account
that is created by default. For production Active Directory domains, this is typically not
the case as there are regular domain user accounts that are created for day-to-day usage
and for regular users.

Several regular user accounts should be created to test functions of the Active Directory
Certificate Services functionality. This will ensure that user certificates that are being
issued are working correctly, and to test that key archive recovery is working with Active
Directory Certificate Services.

For the purposes of this book, the following three accounts will be created:

User Account E-mail Address

Mary Smith TFSLABS\msmith [email protected]
Michael Brown TFSLABS\mbrown [email protected]
Robert Johnson TFSLABS\rjohnson [email protected]

There are two ways to add user accounts to the TFS Labs domain, one using the Active
Directory Users and Computers console, and the other with the command line using
PowerShell. You only need to create the test accounts using one of those methods, and
you can choose whichever method you would like to use.

74 | Practical Guide to PKI with Windows Server

Create Domain User Accounts - GUI Configuration
To create user accounts using the Active Directory Users and Computers console,
perform the following steps on the TFS-DC01 server:

1. Open the Active Directory Users and Computers console (dsa.msc):

2. Click on the corp.tfslabs.com domain, and then click the arrow to the left of the
domain to expand the domain structure.
3. Expand the TFS Labs OU and select the TFS Users OU:

Domain Controller and Workstation Setup | 75

 4. Right-click on the TFS Users OU, select New, and then select User.
5. On the New Object - User window, enter the details for the user account and click
Next to continue:

6. On the next window, enter a password for the user account. You can uncheck the
option for User must change password at next logon option, as this is not necessary
for testing purposes. Click the Next button to continue:

76 | Practical Guide to PKI with Windows Server

7. On the next window, ensure that the account details look correct and click the Finish
button to continue:

8. Repeat steps 4 to 7 to add the additional user accounts for the TFS Labs domain
until all user accounts have been added:

9. To ensure that there are no issues generating user certificates later in this book, the
e-mail addresses of the users will need to be configured on each account. Right-click
on one of the user accounts and select the Properties option.

Domain Controller and Workstation Setup | 77

 10. On the User Properties window, on the General tab, enter the E-mail address for the
user account. Click the Apply button and then click the OK button. Repeat this step
for all user accounts until the e-mail address is added to all user accounts:

11. Close the Active Directory Users and Computers console.

Create Domain User Accounts - CLI Configuration

To create the user accounts on the TFS-DC01 server using PowerShell, perform the
following steps (modify the command and run it for each account to be created):

1. Open an elevated PowerShell prompt.

2. Run the following command to create a user account (you will be prompted to create
a password for the user account):

New-ADUser `
-Name "Mary Smith" `
-GivenName "Mary" `
-Surname "Smith" `
-SamAccountName "msmith" `
-EmailAddress "[email protected]" `
-Path "OU=TFS Users,OU=TFS Labs,DC=corp,DC=tfslabs,DC=com" `
-AccountPassword (Read-Host -AsSecureString "User Password") `
-ChangePasswordAtLogon $false `
-Enabled $true

3. Close the PowerShell prompt.

78 | Practical Guide to PKI with Windows Server

Before moving on from creating the user accounts for the TFS Labs domain, the Domain
Administrator account should have the e-mail address field set as well. This can be done
by opening the Active Directory Users and Computers console (dsa.msc) and adding the
[email protected] e-mail address. The Domain Administrator account can
be found in the Users OU in the TFS Labs domain (this account is not moved at all in this
book, so it should be found there by default).

Alternatively, the same change can be made from an elevated PowerShell prompt with
the following command:

Set-ADUser `
-Identity Administrator `
-EmailAddress "[email protected]"

Now that the test user accounts have been created, it is now easier to demonstrate that
the certificates issued by the Certificate Authority are working correctly. You can proceed
to setting up the Windows 10 workstation, which these accounts will be able to use for
testing purposes in later chapters.

Active Directory User E-Mail

Ensure that you enter the e-mail addresses for the user accounts correctly,
otherwise there will be issues with the automatic deployment of user certificates
to those accounts in later chapters of this book. Since the issue will be on the
Enterprise CA, the user will not be notified that there is an issue with their account,
they will just receive no user certificate.

Workstation Creation and Domain Join

Provision and configure a new virtual machine called TFS-WIN10 in Hyper-V, and install
Windows 10 Pro or Windows 10 Enterprise using the following specifications:

• Virtual Machine Generation - 1

• Virtual Processors - 2
• Virtual Memory - 4096 MB
• Virtual Hard Disk - 40 GB
• Virtual Network Adapters - 1

Once the TFS-WIN10 virtual machine has been created and the operating system has
been installed, there are a few tasks that need to be completed:

• Set the password for the local Administrator account (ensure that you use a complex
password).
• Set the hostname of the server to TFS-WIN10. Restart the workstation to apply the
change.

Domain Controller and Workstation Setup | 79

Once the local administrator account and the hostname have been setup, you will also
need to configure the network settings for the virtual machine:

IP Address 10.100.1.110
Netmask 255.255.255.0
Gateway 10.100.1.1
DNS Server 1 10.100.1.100

Once the hostname and networking has been setup successfully, you can then proceed
to join the TFS-WIN10 workstation to the TFS Labs domain.

Figure 3.6.1: The TFS-WIN10 workstation once it has been joined to the TFS Labs domain.

80 | Practical Guide to PKI with Windows Server

Once the TFS-WIN10 workstation has been successfully added to the TFS Labs domain,
you should be able to login using one of the domain user accounts created earlier in this
chapter. You can also login with the Domain Administrator account for testing purposes
if you would like to.

The TFS-WIN10 workstation should be moved from the default Computer OU in Active
Directory to one of the dedicated OUs that was created earlier for the TFS Labs domain.
This will facilitate easier application of Group Policy Objects, which are needed for Active
Directory Certificate Services. To move the TFS-WIN10 computer object, perform the
following steps on the TFS-DC01 server:

1. Open the Active Directory Users and Computers console (dsa.msc).

2. Expand the corp.tfslabs.com domain and go to the Computers OU.
3. Right-click on the TFS-WIN10 computer and click on Move....
4. In the Move window, expand the TFS Labs OU and select TFS Workstations and click
OK. If you see a warning message about moving the computer object, click the Yes
button.
5. Close the Active Directory Users and Computers console.

Alternatively, you can also move the TFS-WIN10 computer object by running the following
command from an elevated PowerShell prompt:

Get-ADComputer "TFS-WIN10" | `
Move-ADObject `
-TargetPath "OU=TFS Workstations,OU=TFS Labs,DC=corp,DC=tfslabs,DC=com"

Once the TFS-WIN10 workstation has been moved to the correct OU in Active Directory, it
is ready to be used for testing of the Certificate Authority in the later chapters in this book.

The next section in this book looks at LDAPS with Active Directory, which is used to
encrypt LDAP traffic using certificates. This increases the security of an Active Directory
domain, and other features that rely on LDAP to function. With the use of Active Directory
Certificate Services, this functionality can be easily enabled on an Active Directory
domain.

Windows 10 Pro 32-bit

There are no issues with using Windows 10 Pro 32-bit instead of 64-bit for the
workstation. The 32-bit version of Windows 10 Pro will not affect the functionality
of issuing and managing certificates to that workstation.

The only requirement is that Windows 10 is either the Pro or Enterprise edition,
and that it is only for the requirement that it be able to properly join an Active
Directory domain.

Domain Controller and Workstation Setup | 81

 Hyper-V Remote Connections

You may encounter an issue with connecting to the TFS-WIN10 workstation with
the Hyper-V Virtual Machine Connection when connecting with a regular user
account. This is due to the way that Hyper-V handles connections with the Virtual
Machine Connection application, which is like Remote Desktop. The Virtual
Machine Connection application requires additional permissions to allow for
Domain Users to login correctly. By default, all users in Active Directory are added
to the Domain Users group.

To facilitate testing, that Active Directory group will need to be added to the
TFS-WIN10 workstation to allow for login. Make the following changes to the
TFS-WIN10 workstation to allow for domain user logins:

1. Login to the TFS-WIN10 workstation using the local administrator account.

2. Open the Computer Management console (compmgmt.msc).
3. In the Computer Management console, on the left-hand side, expand Local
Users and Groups, and select Groups.
4. Select Remote Desktop Users, right-click and select Properties.
5. On the General tab, under the Members window, click the Add... button.
6. On the Select Users, Computers, Service Accounts, or Groups window, enter
Domain Users and click the OK button.
7. If prompted, enter the Domain Administrator credentials to authenticate to
the TFS Labs domain.
8. The TFSLABS\Domain Users group should now be listed in the window.
9. Click the OK button to close the window.
10. Restart the TFS-WIN10 workstation to complete the configuration.

At this point, the TFS-WIN10 workstation should be ready for users to login with
the Hyper-V Virtual Machine Connection application. They should also be able to
login using the Remote Desktop application as well if that feature is enabled.

LDAP over SSL for Active Directory

LDAP traffic by default is transmitted over a network in a non-encrypted and unsecured
manner. LDAP over SSL, or LDAPS, is used to secure LDAP traffic to ensure that it is
encrypted. Active Directory supports LDAPS, either through Active Directory Certificate
Services or through a third-party Certificate Authority. LDAPS is not enabled on an Active
Directory level, it is enabled on individual Domain Controllers. Because of this, it is
important to ensure that all Domain Controllers are correctly configured to ensure that
LDAPS operated correctly. A Certificate Authority that was created using Active Directory
Certificate Services makes this take easy to enable in Active Directory.
The requirements for enabling LDAPS for Active Directory are quite simple, assuming
there is already an existing Active Directory Certificate Services deployment in an Active
Directory domain:

82 | Practical Guide to PKI with Windows Server

 • The LDAPS certificate should be in the Local Computer Certificate Store (certlm.msc)
on the Domain Controller, specifically in the Personal Store.
• The certificate must contain the FQDN for the Domain Controller, and this can be
found in either the Common Name (CN) field or the Alternative Name extension.
• The certificate must have the associated private key available on the server.
• The devices on the associated Active Directory domain must contain the complete
certificate chain to ensure that the LDAPS certificate is valid.
• The Enhanced Key Usage extension includes the Server Authentication (1.3.6.1.5.5.7.3.1)
OID in the certificate.
• The certificate uses the Schannel Cryptographic Service Provider (CSP) to generate
the keys for the certificate.

There is no user interface in Active Directory Domain Services for enabling LDAPS.
Installing a valid certificate and meeting the above requirements will permit a Domain
Controller from utilizing LDAP over SSL. The easiest method to enable LDAPS is to use a
computer certificate that is already available in Active Directory Certificate Services and
issue one of those certificates to the Domain Controllers in that environment.

There are multiple third-party utilities that can be used to verify that LDAPS is enabled on
a Domain Controller, but there is a utility available in Windows Server (ldp.exe) that can
quickly verify that LDAPS is enabled. While it is still too early in this book to enable
LDAPS, you can come back to this section after completing the steps in this book to
verify that LDAPS was successfully enabled.

To check the current LDAP settings on a Domain Controller and check if LDAPS is
enabled, perform the following steps on the TFS-DC01 server:

1. Open the Ldp application by running the ldp.exe command from the Run prompt.
2. The Ldp window will appear:

Domain Controller and Workstation Setup | 83

 3. To test LDAP connections, click on the Connection menu and select the Connect...
option.
4. In the Connect window, enter the following details:
• Server - TFS-DC01.corp.tfslabs.com
• Port - 389
• Connectionless - Disabled
• SSL - Disabled
5. The LDAP information for the TFS Labs domain should be displayed in the window,
and the full LDAP entry for the domain (ldap://TFS-DC01.corp.tfslabs.com/DC=corp,
DC=tfslabs,DC=com) should be in the title of the window:

6. To close the current LDAP connection, click on the Connection menu and select the
Disconnect option.
7. To test LDAPS connections, click on the Connection menu and select the Connect...
option.
8. On the Connect window, enter the following details:
• Server - TFS-DC01.corp.tfslabs.com
• Port - 636
• Connectionless - Disabled
• SSL - Enabled

84 | Practical Guide to PKI with Windows Server

 9. The LDAP information for the TFS Labs domain should be displayed in the window,
and the full LDAP entry for the domain (ldaps://TFS-DC01.corp.tfslabs.com/DC=corp,
DC=tfslabs,DC=com) should be in the title of the window:

10. Close the Ldp application.

If you attempt to connect to LDAPS when the Domain Controller is not configured
correctly for it, you will see the following error (or a variation of it):

Figure 3.7.1: The Ldp application will show an error message if there is an issue with
LDAPS.

Domain Controller and Workstation Setup | 85

The purpose of this book is to introduce extra security to an Active Directory domain
using PKI, and not necessarily on enhancing the security of specific Windows Services.
Enabling LDAPS is quite simple once a valid Active Directory Certificate Services
deployment is completed. As of the time of this writing, Microsoft is not enforcing
LDAPS within an Active Directory domain, but that could always change in the future.

Domain Controller and Workstation Next Steps

Now that the TFS Labs Active Directory environment has been successfully setup and
configured, as well as the test workstation, the next step in this book is to create the Root
Certificate Authority. This involves creating the TFS-ROOT-CA server and then creating
the Root Certificate needed for the TFS Labs Certificate Authority. This server will be the
root of the Two-Tier Certificate Authority in Active Directory Certificate Services for the
TFS Labs domain.

86 | Practical Guide to PKI with Windows Server

Chapter 4 - Offline Root CA Setup

The Root Certificate Authority server is setup as a standalone Windows Server and is
never meant to be a member of an Active Directory domain. There are no network
connections to the Root CA server and there never should be in this type of Two-Tier
setup. There are no domain policies being applied to the server, this means that it will
require some local security modifications that are normally handled through Group Policy
from Active Directory. Since there are also no connections to Active Directory, these
changes will need to be applied locally and are specific only to this server. These
modifications only need to be performed once on the server, as those settings will never
be changed and will remain persistent.

Aside from having no network connections to and from the Root Certificate Authority
server, there are also additional security considerations that are in place as well.
BitLocker full disk encryption can be used to secure the server when it is in an offline
state to protect the Root Certificate private keys. This step is optional, but the
instructions are provided for the Root Certificate Authority server to enforce greater
security on the Root CA server when it is in an offline state.

Moving files to and from the Root Certificate Authority server will be accomplished with
the use of a virtual floppy disk. This allows the Offline Root CA to have minimal
interaction with other devices within the environment and removes the requirement to
have a network connection on that server.

This chapter will focus on how to install and configure an Offline Root CA server using
Active Directory Certificate Services.

Offline Root CA Setup | 87

Root CA Server Setup
The Windows Server that will be hosting the Root Certificate Authority requires minimal
resources to operate correctly, as it only performs basic tasks and is not used for
day-to-day activities. It will only to ever be used for issuing any Subordinate certificates
to other TFS Labs Certificate Authority servers and is also used to revoke or add new
Subordinate certificates if necessary. The Root CA will be used to refresh the CRL at
least once a year to keep the PKI working correctly, since the CRL is required for all
components of a PKI. The Root Certificate Authority server will be called TFS-ROOT-CA.

Since there are no active network connections to and from the TFS-ROOT-CA virtual
machine, a virtual floppy disk will need to be created that will be used for transferring
files to and from the TFS-ROOT-CA server. Name the file “RootCAFiles” and store it in a
location that will be available for all virtual machines.

The first time that the virtual floppy disk is inserted into one of the virtual machines it will
need to be formatted with the default settings for it to be usable. Keep this virtual floppy
disk available until the end of the Certificate Authority implementation, when it will be
deleted.

You will need to recreate this virtual floppy disk in the future whenever you need to move
files to and from the TFS-ROOT-CA server. Since this book uses the Hyper-V virtualization
platform for demonstration purposes, this file will be called RootCAFiles.vfd. Instructions
on how to create virtual floppy disk with Hyper-V is provided in an earlier chapter.

Virtualization Shared Features

When provisioning the TFS-ROOT-CA server you should consider disabling all
features that allow for easily copying files to and from that virtual machine. This
feature is a convenient option for moving files to and from the TFS-ROOT-CA
server, but it can compromise the security of the virtual machine. This also
includes the Shared Clipboard feature that is often available in virtual machines
for copying and pasting text between virtual machines.

If you are using Hyper-V this setting can be disabled in the Enhanced Session
Mode settings options. If you are using VMware Workstation, this setting can be
disabled in the Guest Isolation settings. For every other virtualization platform,
there should be a way to disable those features as well.

Even though disabling these features can make dealing with the TFS-ROOT-CA
somewhat cumbersome during the implementation and configuration phase, the
added security features are worth it to protect the Root Certificate Authority. You
will deal with the Offline Root CA so infrequently after it is setup and configured, it
should not be an issue.

88 | Practical Guide to PKI with Windows Server

Provision and configure a new virtual machine called TFS-ROOT-CA and install Windows
Server 2019 Standard (Desktop Experience) in Hyper-V using the following specifications:

• Virtual Machine Generation - 1

• Virtual Processors - 2
• Virtual Memory - 4096 MB
• Virtual Hard Disk - 40 GB
• Virtual Network Adapters - 0

Once the TFS-ROOT-CA virtual machine has been created and the operating system has
been installed, there are a few tasks that need to be completed before proceeding to
configure the Root Certificate Authority:

1. Set the local Administrator account on the TFS-ROOT-CA server to a complex password
that is at least 14 characters in length and store the password securely (the local
Administrator account is renamed to CA-Admin in a later step in this chapter). Ensure
that there are no additional user accounts present on the server (this can be verified in
the Computer Management console (compmgmt.msc)). The Guest account should
already be disabled by default and this account is renamed in a later step to obfuscate
the account.
2. Set the hostname of the server to TFS-ROOT-CA. Restart the server to apply the
change.
3. Set the TFS-ROOT-CA server to be a member of the TFS-CA workgroup. Restart the
server to apply the change.
4. On the root of the C:\ drive create a folder called RootCA (C:\RootCA). This folder will
store the Root certificate, Subordinate certificate, CRL files and any other certificate
files that are needed during the entire Certificate Authority implementation process.
5. Insert the RootCAFiles.vfd virtual floppy disk into the virtual floppy drive on the TFS-ROOT-CA
virtual machine. Format the floppy disk using the default settings using Windows File
Explorer. Eject the virtual floppy disk when the formatting has been completed.

Once the TFS-ROOT-CA server has been setup, you can move onto the optional step of
setting up BitLocker Disk Encryption on the virtual machine. Otherwise, you can continue
with the Active Directory Certificate Services setup if that is not required.

Optional: Add BitLocker on the Root CA

One of the steps that should be taken on the Root CA server before starting the
configuration of Active Directory Certificate Services is to enable and test the BitLocker
feature. BitLocker is a Full Disk Encryption software that is native in Windows Server and
some Windows client versions. BitLocker can encrypt the contents of a server while it is
offline to keep it protected.

Offline Root CA Setup | 89

This step is entirely optional, but there are a few reasons why you should consider using
BitLocker to secure the TFS-ROOT-CA server:

• The information that is stored on the TFS-ROOT-CA server will be secure when the
server is in an offline state. This is important to have since the virtual machine may
be stored elsewhere and this will prevent users from accessing the virtual hard drive.
• BitLocker is a native feature in Windows Server, so there is no cost associated with
using BitLocker since it is part of the operating system. Since BitLocker is a native
feature in Windows Server, there is no concern about using third-party encryption
software that may require additional licensing or fees to use it.
• BitLocker is easily supported with virtualization software.
• BitLocker does not require any additional dependencies to operate and can be used
without any outside software or services.

Using BitLocker to encrypt the TFS-ROOT-CA server is an easy and effective way to
protect the data on that server to ensure that the Root Certificate Authority is secure.

Third-Party Full Disk Encryption Applications

Typically in a production environment there would be a managed Full Disk

Encryption solution in place to manage the unlocking of encrypted disks, as well
as managing recovering keys if there was an issue. It is recommended to avoid
those types of solutions for an Offline Root CA to reduce the need for extra
third-party software on the server, and to avoid the need to connect it to the
network.

BitLocker Encryption Verification

It may seem as though enabling BitLocker should be one of the last tasks
performed in the implementation process, but the reason that it is advisable to
enable and test BitLocker at this stage is to ensure that there are no issues with it.
If you enable BitLocker after creating the Root CA and there is an issue with it, it is
possible that you will not be able to access the Root CA and will need to start the
process again.

If you decide that you would like to use BitLocker to secure the TFS-ROOT-CA server,
perform these steps to add the BitLocker feature to the TFS-ROOT-CA server. It can be
installed using Server Manager or through the command line with PowerShell, you can
decide which one you would like to use. You only need to choose one method for
installing the BitLocker Drive Encryption feature.

90 | Practical Guide to PKI with Windows Server

Add BitLocker on the Root CA - GUI Installation
To perform the BitLocker Drive Encryption installation using the Server Manager console,
perform the following steps on the TFS-ROOT-CA server:
1. Open the Server Manager console (servermanager.exe), click on the Manage menu,
and click on Add Roles and Features to start the installation wizard:

2. On the Before you begin screen, click the Next button to continue:

Offline Root CA Setup | 91

 3. On the Select installation type screen, select the option for Role-based or feature-based
installation and click the Next button to continue:

4. On the Select destination server screen, verify that the TFS-ROOT-CA server is selected
and click the Next button to continue:

92 | Practical Guide to PKI with Windows Server

5. On the Select server roles screen, click the Next button to continue:

6. On the Select features screen, select the BitLocker Drive Encryption feature:

Offline Root CA Setup | 93

 7. The installation wizard will ask to install any additional features required for the
BitLocker Drive Encryption feature. Select the option to Include management tools
(if applicable) to install the management tools for the role. Click the Add Features
button to continue:

8. On the Select features screen, click the Next button to continue:

94 | Practical Guide to PKI with Windows Server

 9. On the Confirm installation selections screen, select the option to Restart the destination
server automatically if required:

10. When prompted with a warning about restarting the server, click the Yes button.
11. On the Confirm installation selections screen, click the Install button to continue:

Offline Root CA Setup | 95

 12. Once the installation is completed, click the Close button:

The TFS-ROOT-CA server should automatically restart once the BitLocker feature has
been installed (restart the server manually if it does not restart automatically). Once
restarted, it will require some additional configuration to the TFS-ROOT-CA server to allow
it to be enabled.

Add BitLocker on the Root CA - CLI Installation

The BitLocker Drive Encryption installation can also be performed using PowerShell,
which requires much fewer steps to accomplish. Perform the following steps on the
TFS-ROOT-CA server:
1. Open an elevated PowerShell prompt.
2. Run the following command to install the BitLocker Drive Encryption role and the
necessary BitLocker Administration Tools:

Install-WindowsFeature BitLocker `
-IncludeAllSubFeature `
-IncludeManagementTools `
-Restart

96 | Practical Guide to PKI with Windows Server

 3. The command will automatically install the BitLocker Drive Encryption role and output
a Success status of True:

4. Once the installation has completed, the TFS-ROOT-CA server will automatically restart.

The TFS-ROOT-CA server should automatically restart once the BitLocker feature has
been installed (restart the server manually if it does not restart automatically). Once
restarted, it will require some additional configuration to the TFS-ROOT-CA server to allow
it to be enabled.

Optional: Configure Group Policy for BitLocker on the Root CA

Once the BitLocker role has been successfully added there are several Local Group Policy
settings that should be changed to allow for enabling a BitLocker startup password and
to allow for the activation of BitLocker without a proper TPM device present.

Offline Root CA Setup | 97

Virtualization platforms do not typically emulate a TPM device, so changes to the Local
Group Policy settings are required to allow for BitLocker to be successfully enabled.
Whenever a TPM module is not available on a device that requires it, you will typically see
an error message like this:

Figure 4.1.2: When there is no valid TPM present on a Windows device, BitLocker by
default will not allow the drive to be encrypted.

To configure the appropriate Local Group Policy settings, perform the following steps on
the TFS-ROOT-CA server:

1. Open the Local Group Policy Editor console (gpedit.msc) on the TFS-ROOT-CA server.
2. Open the Computer Configuration > Administrative Templates > Windows Components
> BitLocker Drive Encryption > Operating System Drives policy settings.
3. Double-click on the Require additional authentication at startup policy setting.
4. Make the following changes to the Policy Setting and apply the settings:
(a) Require additional authentication at startup - Enabled
(b) Allow BitLocker without a compatible TPM (requires a password or a startup
key on a USB flash drive) - Enabled
(c) Configure TPM startup: Allow TPM
(d) Configure TPM startup PIN: Allow startup PIN with TPM
(e) Configure TPM startup key: Allow startup key with TPM
(f) Configure TPM startup key and PIN: Allow startup key and PIN with TPM
5. Close the Local Group Policy Editor window.
6. Restart the TFS-ROOT-CA server to ensure that the Local Group Policy settings have
been successfully applied.

Ensure that the TFS-ROOT-CA server has been restarted before enabling BitLocker on the
server, otherwise the BitLocker setup process will not complete correctly.

98 | Practical Guide to PKI with Windows Server

 Trusted Platform Module

The Trusted Platform Module is a physical chip that is present on most

computers that have been sold in the last 10 years. The purpose of the TPM chip
is to provide a hardware encryption device that is made available to the operating
system. The most common application of the TPM is to allow for full disk
encryption with BitLocker using the Windows operating system.

The issue with requiring TPM by default with BitLocker is that it does not always
work correctly with virtual machines since the TPM is difficult to emulate. This
also means that by relying on a TPM from one device means that portability of the
virtual machine would be affected. It is recommended to just disable the checking
of a TPM when enabling BitLocker.

Modern versions of many virtualization platforms do provide alternatives to make

the TPM emulation easier to accomplish, so this is something to consider as time
goes on.

Optional: Enable BitLocker on the Root CA

Once the BitLocker feature has been added and the Local Group Policy settings have
been completed, BitLocker can now be configured, and the operating system drive can
then be encrypted. As part of the setup of BitLocker, the BitLocker Recovery Key will be
backed up to the virtual floppy disk.

BitLocker Recovery Key

The BitLocker Recovery Key is a unique 48-digit numerical password that is used
to unlock an encrypted BitLocker drive. It is typically only used if the regular
password is not working correctly and will allow you to unlock the drive and
change the password if necessary. Attached to the BitLocker Recovery Key is a
unique 32-digit alphanumeric identifier that allows you to determine if the recovery
key is the correct one for a particular device.

It is important that you do not misplace or lose the BitLocker Recovery Key. There
is absolutely no way to unlock the BitLocker drive without the BitLocker Recovery
Key. If the BitLocker Recovery Key is lost, then the TFS-ROOT-CA server will never
be able to be accessed again. BitLocker does not allow you to save the key to the
same device that has been encrypted, and that is why you typically use removable
media to back up the BitLocker Recovery Key.

Ensuring that you have a working backup of the BitLocker Recovery Key for
encrypted devices is crucial to ensure that you do not encounter issues in the
future.

Offline Root CA Setup | 99

To enable BitLocker, perform the following steps on the TFS-ROOT-CA server:

1. Insert the RootCAFiles.vfd virtual floppy disk on the TFS-ROOT-CA server.

2. Open Windows File Explorer (explorer.exe) and go to This PC. Right-click on the C:\
drive and select the Turn on BitLocker option.
3. On the BitLocker Drive Encryption setup screen click the Next button to continue.
4. On the Preparing your drive for BitLocker screen click the Next button to continue.
5. On the BitLocker Drive Encryption setup screen, click the Next button to continue.
6. On the Choose how to unlock your drive at startup screen, select the option to Enter
a password.
7. On the Create a password to unlock this drive screen, enter the password that you
want to use to unlock the drive at boot up. Make sure that you do not forget this
password as it will require the BitLocker Recovery Key to get back into the TFS-ROOT-CA
virtual machine. Ensure that you use a complex password for this and make it at least
14 characters in length. Click the Next button to continue.
8. On the How do you want to back up your recovery key? screen, select the option to
Save to a file. Save the file to the A:\ Drive (virtual floppy disk). Click the Next button
to continue.
9. Eject the RootCAFiles.vfd virtual floppy disk and then back up the BitLocker Recovery
Key to another device before you continue. This is critical in case there is an issue
with the BitLocker password. You can retrieve the BitLocker Recovery Key using the
TFS-CA01 of TFS-DC01 servers.
10. On the Choose how much of your drive to encrypt screen, select the option to Encrypt
entire drive (slower but best for PCs and drives already in use) and click the Next
button.
11. On the Choose which encryption mode to use screen, select the option for New
encryption mode (best for fixed drives on this devices) and click the Next button
to continue.
12. On the Are you ready to encrypt this drive? screen, ensure that the Run BitLocker
system check box is selected and then click the Continue button, which will close
the window.
13. Restart the TFS-ROOT-CA server when a notification appears stating the encryption
has started. If this notification is missed, restart the server manually:

100 | Practical Guide to PKI with Windows Server

 14. When the server is starting you will be prompted for a password, enter the password
that you set for the drive to ensure that it is working correctly:

15. Login to the TFS-ROOT-CA server, you should receive a notification that the drive
is encrypting. You can also check the status of BitLocker at any time by going to
Windows File Explorer (explorer.exe), then to This PC, right-clicking on the C:\ drive
and selecting the Manage BitLocker option:

Now that BitLocker has been installed and verified to be working correctly, the hard drive
for the Root Certificate Authority server has been successfully secured when it is in an
offline state.

Offline Root CA Setup | 101

Optional: Test BitLocker on the Root CA
There are a few tests that you can perform to ensure that the BitLocker encryption has
been successfully configured on the TFS-ROOT-CA server before going any further. One
test is to ensure that the BitLocker Recovery Key can be successfully used at startup, and
another test is to mount the virtual hard disk for the TFS-ROOT-CA server on another
device to ensure that it can be opened on its own.

BitLocker Encryption and Damaged VHD Files

In the event the virtual hard disk that is encrypted with BitLocker is damaged or
corrupted in any way, there will be no way of retrieving the contents of the
TFS-ROOT-CA server. This is due to the way that BitLocker operates, and regular
disk repair utilities will not work correctly on an encrypted disk. Ensure that you
keep proper backups of the TFS-ROOT-CA server to ensure that the data on that
disk is never lost.

Test the BitLocker Recovery Key

It is simple to test the BitLocker Recovery Key to ensure that it is working correctly, and
only requires a few steps to confirm that it is working correctly:
1. Turn on or restart the TFS-ROOT-CA server.
2. At the BitLocker drive encryption screen, press the ESC key to access the Recovery
Key screen:

3. Input the 48-digit Recovery Key and press Enter to continue.

4. If the BitLocker Recovery Key works correctly, then the boot process will continue,
and you should see the Windows Login Screen.

102 | Practical Guide to PKI with Windows Server

If you are can successfully use the Recovery Key at boot-up and get to the Windows
Login Screen, then you have successfully confirmed that the BitLocker Recovery Key is
working correctly.

Mount the BitLocker Hard Disk on Another Device

It is also possible to mount the virtual hard disk for the Root CA on another compatible
device. This may be required if there is an unrecoverable error in the Windows Server
installation for the Root CA and you need to manually retrieve critical files from the
server. Performing this task requires either another computer running Hyper-V or a
computer that is capable of mounting VHD files. If the test device is on Windows Server,
ensure that the BitLocker feature is added, otherwise this process will not work.

To mount the virtual hard disk on another device using Hyper-V, perform the following
steps:

1. Ensure that the virtual machine that you intend on mounting the virtual hard disk to
is shut down.
2. Open the Hyper-V Manager (virtmgmt.msc) on the device where you want to mount
the virtual hard disk.
3. Select the virtual machine that you want to mount the virtual hard disk to, right-click
on it and select Settings....
4. In the Hardware settings, click on the IDE Controller 0 device, and under the IDE
Controller pane, and click the Add button.
5. For the Virtual hard disk, click the Browse button and select the virtual hard disk you
want to mount.
6. Click the Apply button, and then close the Settings window.
7. Power on the virtual machine that you mounted the virtual hard disk on.
8. Open Windows File Explorer (explorer.exe) and find the virtual hard disk. It should
be assigned a drive letter and have a lock which means it is BitLocker Encrypted.
9. Double-click on the drive and enter the BitLocker password to unlock the virtual hard
disk.

To remove the virtual hard disk, power off the virtual machine and remove it using the
Hyper-V settings. Mounting a virtual hard drive is not something that you would ever
likely need to perform under ordinary circumstances, but it is possible to do should an
extreme situation arise.

Windows 10 VHD Files

It is also possible to mount a virtual hard disk using Windows 10 Pro or Enterprise.
To do this, go to the location where the VHD file is located, right-click, and select
the Mount option and that is all that is needed. For BitLocker VHD files, there will
be an additional option to Unlock the Drive if that drive is encrypted.

Offline Root CA Setup | 103

Back Up the BitLocker Recovery Key
You may need to obtain the BitLocker Recovery Key if you have misplaced it or need to
make a new backup of the key. There are two methods to perform this backup on the
BitLocker device, and this will only work if you are able to successfully login to the device.

The first method will back up the BitLocker Recovery Key through the BitLocker Drive
Encryption Management console. This method requires using a virtual floppy disk, and
you can use the same one as what was provisioned early or provision a new one entirely:

1. Add the RootCAFiles.vfd virtual floppy disk to the TFS-ROOT-CA virtual machine. If
this is a different or new virtual floppy disk, it will need to be formatted first.
2. On the TFS-ROOT-CA server, open Windows File Explorer (explorer.exe).
3. On the left side of the Windows File Explorer window, select This PC.
4. Under Devices and drives, right-click on the C: drive and select Manage BitLocker:

5. Under the Operating system drive, select the Back up your recovery key option.
6. When the BitLocker Drive Encryption (C:) window appears, select the option to Save
to a file.
7. Browse to the A: and click the Save button. You can use the default file name.
8. Click the Finish button to complete the back up of the BitLocker Recovery Key.

104 | Practical Guide to PKI with Windows Server

The second method backs up the BitLocker Recovery Key through the command line
using the manage-bde command, which can be used to manage BitLocker:

1. Add the RootCAFiles.vfd virtual floppy disk to the TFS-ROOT-CA virtual machine.
2. Open an elevated Command Prompt.
3. To back up the BitLocker Recovery Key for the C:\ drive to the A:\ drive, run the
following command:

manage-bde.exe -protectors -get C: > A:\BitLocker-TFS-ROOT-CA.txt

4. The BitLocker ID and password will be backed up to the A:\ drive.

5. Close the Command Prompt window.
6. Eject he RootCAFiles.vfd virtual floppy disk.

Whatever method is used to get the BitLocker Recovery Key, it is important to make sure
that you always have a copy if you need it. Ensure that you keep the BitLocker Recovery
Key stored in a safe place.

Optional: Disable Windows Update on the Root CA

Since the TFS-ROOT-CA server is always in an offline state, there is no way for the server
to ever connect to the Windows Update service and install any updates. This should not
be an issue, since the Offline Root CA server is never connected to a network. It is
possible to manually install critical updates to the server by utilizing offline installers for
the updates and copying them to the virtual machine, but that should not be necessary.
Making changes to the Offline Root CA server should be avoided and installing updates
can sometimes cause unintended consequences that can be difficult to correct.
Performing this configuration change to the Offline Root CA server will not cause any
issues, it will just avoid unnecessary notifications on the server whenever you are logged
in.

There are multiple methods of disabling the Windows Update functionality on a Windows
device, but here are two methods that can be quickly used on the TFS-ROOT-CA server:

• Disable the Windows Update service in the Services console.

• Use the Sconfig utility to disable Windows Update. Sconfig is used to manage Windows
Server functions from the command line.

You only need to perform one of these methods to disable the Windows Update service.
To disable the Windows Update service using the Sconfig utility, perform the following
steps on the TFS-ROOT-CA server:

1. Open an elevated PowerShell prompt.

2. Run the following command to start the Sconfig utility:

sconfig.cmd

Offline Root CA Setup | 105

 3. If you receive a warning message saying No active network adapters found., click
the OK button to continue. You should then see the Server Configuration screen:

4. On the Server Configuration screen, select option 5 and press Enter to configure the
Windows Update Settings.
5. When prompted to configure the Windows Update Settings, select option M and
press Enter to set the option to manual:

106 | Practical Guide to PKI with Windows Server

 6. When the Update Settings message appears, click the OK button.
7. The Windows Update Settings should now be set to Manual:

8. Select option 15 and press Enter to close the Sconfig utility.

9. Close the PowerShell prompt.

To disable the Windows Update service using the Services console, perform the following
steps on the TFS-ROOT-CA server:

1. Open the Services console (services.msc) on the TFS-ROOT-CA server.

2. Search for the Windows Update service. Right-click on the service and select the
Stop option.
3. Search for the Windows Update service. Right-click on the service and select the
Properties option.
4. On the Windows Update Properties (Local Computer) window, click on the General
tab.
5. Go to the Startup type drop-down list and select the Disabled option.
6. Click the OK button to close the window.
7. Close the Services console.

Regardless of which method you use to disable the Windows Update service, performing
this simple action could reduce issues in the future should the TFS-ROOT-CA server ever
be connected to a network.

Once BitLocker has been installed and enabled, and Windows Update has been disabled,
you can proceed to configuring the Local Group Policy settings on the TFS-ROOT-CA
server.

Offline Root CA Setup | 107

Root CA Server Local Policies
Once the TFS-ROOT-CA server has been setup, the Local Group Policy settings and Local
Security Policies can now be configured to increase the security of the local
administrator account. Normally these changes are made with Group Policy on an Active
Directory domain, but since the TFS-ROOT-CA server is not on a domain the changes are
being made locally. The following security settings are being applied to the TFS-ROOT-CA
server:

• Disallow Microsoft accounts from logging into the server.

• Disable the guest account entirely if it is enabled.
• Rename the administrator account to CA-Admin.
• Rename the guest account to administrator.
• Never display the last user that logged in on the server.
• Never display any user that logged in on the server.
• Disable LAN Manager hashes on passwords to increase password security.
• Use only the strongest LAN Manager authentication requests.
• Remember 24 previous passwords and force a password change every 90 days.
• Enforce password complexity with a minimum of 14 characters, and a minimum age
of 14 days.
• Lock out the server after 5 failed login attempts for 30 minutes.

Some of these settings are not necessary since the TFS-ROOT-CA server is never
supposed to have any active network connections to it as there is no network adapter
present on the virtual machine. If the TFS-ROOT-CA server is ever connected to a network,
these settings will help alleviate any potential issues if connections are attempted to it.

Perform the following steps to enable the Local Policy changes to the TFS-ROOT-CA
server:

1. Open the Local Group Policy Editor console (gpedit.msc), confirm the following settings,
and make any changes if necessary:
(a) Modify the Local Computer Policy > Computer Configuration > Windows Settings
> Security Settings > Local Policies > Security Options settings:
i. Accounts: Administrator account status - Enabled
ii. Accounts: Block Microsoft accounts - Users can’t add or log on with Microsoft
Accounts
iii. Accounts: Guest account status - Disabled
iv. Accounts: Rename administrator account - CA-Admin
v. Accounts: Rename guest account - Administrator
vi. Interactive Logon: Don’t display last signed-in - Enabled
vii. Interactive Logon: Don’t display username at sign-in - Enabled
viii. Network security: Do not store LAN Manager hash value on next password
change - Enabled
ix. Network security: LAN Manager authentication level - Send NTLMv2 response
only. Refuse LM & NTLM (click Yes when prompted to confirm the change)
2. Close the Local Group Policy Editor console.

108 | Practical Guide to PKI with Windows Server

 3. Open the Local Security Policy console (secpol.msc), confirm the following settings,
and make any changes if necessary:
(a) Modify the Security Settings > Account Policies > Password Policy settings:
i. Enforce password history - 24 passwords remembered
ii. Maximum password age - 90 days
iii. Minimum password age - 1 days
iv. Minimum password length - 14 characters
v. Password must meet complexity requirements - Enabled
vi. Store passwords using reversible encryption - Disabled
(b) Modify the Security Settings > Account Policies > Account Lockout Policy settings:
i. Account lockout threshold - 5 invalid login attempts (click OK when prompted
to confirm the change)
ii. Account lockout duration - 30 minutes
iii. Reset account lockout counter after - 30 minutes
4. Close the Local Security Policy console.
5. Restart the TFS-ROOT-CA server to apply the updated settings before continuing.

These Local Group Policy and Security Policy settings are required since the
TFS-ROOT-CA server is not a part of an Active Directory domain and therefore would
never receive any polices from a Domain Controller. By default, the policies on Windows
Server are weak when it comes to security settings for password complexity, lockouts,
and password age. By modifying the policies directly on the TFS-ROOT-CA server, you can
ensure that there are adequate protections in place on the server and that they will
always be in place.

With the Local Group Policy and Security Policy settings configured on the TFS-ROOT-CA
server, you can proceed to creating the CAPolicy.inf file. This file is needed to configure
the settings of the Certificate Authority at the time of creation.

Local Administrator Account Changes

After the steps performed in this section have been completed and after the
server has restarted, the local administrator account on the TFS-ROOT-CA server
has been renamed to CA-Admin from Administrator. The path to the administrator
account will still be the same and can only be changed by deleting the profile and
recreating it. Along with the other changes, the username is no longer
remembered on the Windows Login Screen, which means it will need to be
inputted every time that the server is powered on or restarted.

Local Administrator Account Password Expiration

Since the Offline Root CA will only be used at least once a year and with the
password settings that are being applied to this virtual machine, the password to
the local administrator account will need to be reset every single time the
TFS-ROOT-CA virtual machine is powered on.

Offline Root CA Setup | 109

Root CA CAPolicy.inf Installation
The CAPolicy.inf file is used to add configuration details to the Certificate Authority at the
time of creation. Create a file in the C:\Windows folder called CAPolicy.inf (ensure that it
is saved with the correct file extension otherwise these settings will be ignored). Copy the
following contents into this file and make changes as needed to match your organization:

C:\Windows\CAPolicy.inf

[ Version ]
Signature =" $Windows NT$ "

[ PolicyStatementExtension ]
Policies = AllIssuancePolicy , InternalPolicy
Critical = FALSE

; Enables all Certificate Templates .

[ AllIssuancePolicy ]
OID =2.5.29.32.0

[ InternalPolicy ]
OID =1.2.3.4.1455.67.89.5
Notice =" The TFS Labs Certification Authority is internal only ."
URL = http :// pki . corp . tfslabs . com / cps . html

[ Certsrv_Server ]
; Renewal information for the Root CA .
RenewalKeyLength =4096
RenewalValidityPeriod = Years
RenewalValidityPeriodUnits =10

; Disable support for issuing certificates using RSASSA - PSS .

AlternateSignatureAlgorithm =0

; The CRL publication period is the lifetime of the Root CA .

CRLPeriod = Years
CRLPeriodUnits =10

; The option for Delta CRL is disabled since this is a Root CA .

CRLDeltaPeriod = Days
CRLDeltaPeriodUnits =0

Delta CRL with Root Certificate Authorities

A Delta CRL is not normally required for a Root Certificate Authority, especially one
that is offline since it is not normally handling certificate revocations in a PKI. The
Root CA is only ever used to issue a Base CRL when there are Subordinate
Certificate Authorities present. The only certificates that are typically revoked by a
Root CA is a Subordinate certificate, so that would necessitate the deployment of
a new Base CRL instead of a Delta CRL.

110 | Practical Guide to PKI with Windows Server

 OID Number

You can update the OID number in the InternalPolicy section of the CAPolicy.inf
file for your deployment if it is required for your organization. The OID number in
this example is used in Microsoft technical documentation, but it should work for
your organization if it is only ever going to be used internally. If you require a
customized OID number, you can register for a Private Enterprise Number through
the IANA.

If you would like to use your PEN number for the Certificate Authority, modify the
OID line in the InternalPolicy section to OID=1.3.6.1.4.1.X (replace the X with your
PEN number).

Signature Algorithm Support Issues

The AlternateSignatureAlgorithm=0 flag in the CAPolicy.inf file explicitly uses

SHA256 for the algorithm instead of RSASSA-PSS. This can cause issues with
some devices (especially iOS) and by ensuring that it is disabled you should not
have issues with these certificates.

CAPolicy.inf File Name and Locations

Ensure that the CAPolicy.inf file has been properly saved in the C:\Windows folder
(%WINDIR%). Also make sure that the file extension is set to INF and not TXT. A
common mistake is to accidentally save the file as CAPolicy.inf.txt.

If the CAPolicy.inf file is not saved in the correct directory and without the correct
file extension, all settings in the file will be ignored at the time when the Certificate
Authority is created.

Root CA AD CS Role Installation

Once the TFS-ROOT-CA server has been configured properly and the CAPolicy.inf file has
been created, the Active Directory Certificate Services role needs to be installed. The
Active Directory Certificate Services role can be installed using Server Manager or
through the command line with PowerShell, you can decide which one you would like to
use. You only need to choose one method for installing the Active Directory Certificate
Services role.

Offline Root CA Setup | 111

Root CA AD CS Role Installation - GUI Installation
To perform the Active Directory Certificate Services role installation using the Server
Manager console, perform the following steps on the TFS-ROOT-CA server:
1. Open the Server Manager console (servermanager.exe), click on the Manage menu,
and click on Add Roles and Features to start the installation wizard:

2. On the Before you begin screen, click the Next button to continue:

112 | Practical Guide to PKI with Windows Server

3. On the Select installation type screen, select the option for Role-based or feature-based
installation and click Next to continue:

4. On the Select destination server screen, verify that the TFS-ROOT-CA server is selected
and click Next:

Offline Root CA Setup | 113

 5. On the Select server roles screen, select the Active Directory Certificate Services
option:

6. The installation wizard will ask to install any additional Features required for the
Active Directory Certificate Services role. Select the option to Include management
tools (if applicable) to install the management tools for the role. Click the Add
Features button to continue:

114 | Practical Guide to PKI with Windows Server

7. On the Select server roles screen, click the Next button to continue:

8. On the Select features screen, click the Next button to continue:

Offline Root CA Setup | 115

 9. On the Active Directory Certificate Services screen, click the Next button to continue:

10. On the Select role services screen, select the option for Certification Authority and
click the Next button to continue:

116 | Practical Guide to PKI with Windows Server

11. On the Confirm installation selections screen, select the option to Restart the destination
server automatically if required:

12. When prompted with a warning about restarting the server, click the Yes button.
13. On the Confirm installation selections screen, click the Install button to continue:

Offline Root CA Setup | 117

 14. Once the installation is completed, click the Close button:

Once the Active Directory Certificate Services role has been installed, you can then
proceed to configuring the role and creating the Root certificate for the TFS Labs domain.

Root CA AD CS Role Installation - CLI Installation

The Active Directory Certificate Services installation can be performed using PowerShell,
which requires much fewer steps to accomplish. Perform the following steps on the
TFS-ROOT-CA server:

1. Open an elevated PowerShell prompt.

2. Run the following command to install the Active Directory Certificate Services role
and the necessary Administration Tools:

Add-WindowsFeature -Name ADCS-Cert-Authority -IncludeManagementTools

118 | Practical Guide to PKI with Windows Server

 3. The command will automatically install the Active Directory Certificate Services role
and output a Success status of True:

4. Once the installation for Active Directory Certificate Services has completed, you
can close the PowerShell prompt.

Once the Active Directory Certificate Services role has been installed, you can then
proceed to configuring the role and creating the Root certificate for the TFS Labs domain.

Root CA AD CS Role Configuration

Once the Active Directory Certificate Services role has been installed it will need to be
configured to work as the Root Certificate Authority. In the process of configuring the
Active Directory Certificate Services role for the TFS Labs domain, the following Root
Certificate will be created:

Certificate Authority Setup Type Standalone CA

Certificate Authority Type Root CA
Cryptographic Provider RSA#Microsoft Software Key Storage Provider
Key Length 4096 Bits
Signature Hash Algorithm SHA256
CA Common Name TFS Labs Certificate Authority
Validity Period 10 years

Offline Root CA Setup | 119

The Active Directory Certificate Services role can be configured using the Server Manager
or through the command line with PowerShell, you can decide which one you would like to
use. You only need to choose one method for configuring the Active Directory Certificate
Services role. Once the Active Directory Certificate Services role has been configured, all
associated services will be started automatically since it is the Root Certificate Authority.

Root Certificate Validity Period

It is not advised to have the Root certificate and the Subordinate certificate set to
have the same validity period. For example, if both certificates have a 5 year
expiration date, it is possible that the Root certificate will expire before the
Subordinate certificate since it was signed first.

Root CA AD CS Role Configuration - GUI Configuration

To perform the Active Directory Certificate Services role configuration using the Server
Manager console, perform the following steps on the TFS-ROOT-CA server:

1. To begin the configuration of Active Directory Certificate Services on TFS-ROOT-CA,

open the Server Manager console (servermanager.exe). Click the Notifications icon
in the upper-right hand corner and click the Configure Active Directory Certificate
Services on the destination server link in the Post-deployment Configuration box:

120 | Practical Guide to PKI with Windows Server

2. On the Credentials screen, verify that the Administrator credentials are set to
TFS-ROOT-CA\CA-Admin and click Next to continue:

3. On the Role Services screen, select the option for Certification Authority and click
the Next button to continue:

Offline Root CA Setup | 121

 4. On the Setup Type screen, the option for Standalone CA should be selected. The
option for Enterprise CA is not available since this server is not a domain member
server. Click the Next button to continue:

5. On the CA Type screen, ensure that the Root CA option is selected (the Subordinate
CA option will be used later for the Enterprise CA). Click the Next button to continue:

122 | Practical Guide to PKI with Windows Server

6. On the Private Key screen, verify that the Create a new private key option is selected.
Click the Next button to continue:

7. On the Cryptography for CA screen, make the following changes and then click the
Next button to continue:
• Cryptographic Provider: RSA#Microsoft Software Key Storage Provider
• Key Length: 4096
• Hash Algorithm: SHA256

Offline Root CA Setup | 123

 8. On the CA Name screen, set the Common Name (CN) for the CA to TFS Labs Certificate
Authority and click the Next button to continue:

9. On the Validity Period screen, set the validity period to 10 Years and click the Next
button to continue:

124 | Practical Guide to PKI with Windows Server

10. On the CA Database screen, make no changes to the database location and click the
Next button to continue:

11. On the Confirmation screen, verify that the options are correct and click the Configure
button to commit the changes and create the Root certificate:

Offline Root CA Setup | 125

 12. On the Results screen, click the Close button:

At this point the Root certificate for the TFS Labs domain has been created. You can now
validate that the Certificate Authority has been successfully created.

Root CA AD CS Role Configuration - CLI Configuration

The Active Directory Certificate Services configuration can be performed using
PowerShell, which requires much fewer steps to accomplish. Perform the following
steps on the TFS-ROOT-CA server:

1. Open an elevated PowerShell prompt.

2. Run the following command to configure the Active Directory Certificate Services
role and create the Root Certificate:

Install-AdcsCertificationAuthority `
-CAType StandaloneRootCA `
-CACommonName "TFS Labs Certificate Authority" `
-KeyLength 4096 `
-HashAlgorithm SHA256 `
-CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
-ValidityPeriod Years `
-ValidityPeriodUnits 10 `
-DatabaseDirectory $(Join-Path $env:SystemRoot "System32\CertLog") `
-Force

126 | Practical Guide to PKI with Windows Server

 3. The command will automatically configure the Active Directory Certificate Services
role and output an ErrorID status of 0:

4. Once the configuration for Active Directory Certificate Services has completed, you
can close the PowerShell prompt.

Certificate Authority Deployment on an Offline CA

There is an issue with running the Install-AdcsCertificationAuthority command on

a server that does not have an active network connection. When a server that is
running Active Directory Certificate Services performs the configuration of the
role, there are multiple calls to UNC paths that are not accessible. Even though it
is for the local server, the configuration will fail since there are no functioning
network adapters on the server.

The -DatabaseDirectory $(Join-Path $env:SystemRoot ”System32\CertLog”)

option in the Install-AdcsCertificationAuthority command skips the checks for any
network connection and allows the configuration to complete with only local
connections.

At this point the Root Certificate for the TFS Labs domain has been created. You can now
validate that the Certificate Authority has been successfully created.

Offline Root CA Setup | 127

Root CA Validation
At this point there is now a functioning Certificate Authority for the TFS Labs domain.
There are a few configuration items that are needed prior to creating a Subordinate
certificate, and those items include:

• Configuring the Distinguished Name for the TFS Labs domain.

• Configuring the validity period for the Subordinate CA.
• Configuring the CRL renewal for the Root CA.
• Configuring auditing on the Root CA.
• Configuring the CDP and AIA locations for the Root CA.
• Exporting the Root certificate and Root CRL files.

To verify that the Active Directory Certificate Services role has been successfully
configured and the Root certificate was created, you can open the Certification Authority
console (certsrv.msc) on the TFS-ROOT-CA server to check the CA:

Figure 4.6.1: The Certification Authority console is used to manage the CA and
allows administrators to issue and revoke certificates. This console also allows further
customization of the CA.

You can also view the Root certificate and verify that it was created with the correct
values that you setup during the Active Directory Certificate Services configuration:

128 | Practical Guide to PKI with Windows Server

Figure 4.6.2: The TFS Labs Certificate Authority issued the Root certificate to itself, as it
is the root of the PKI.

When the Subordinate CA is created on the TFS-CA01 server, you will be able to validate
that the Offline CA is functioning correctly. The CDP and AIA settings will be displayed,
which still requires customization to fit with the TFS Labs domain. If everything has been
setup correctly for the Root certificate, then you can proceed to configuring the CRL for
the Root CA and specifying the validity period for any signed certificates.

Root CA CRL Configuration

The CRL configuration for the Root CA that is configured in this step is meant to give
greater control over when the CRL expires and needs to be renewed. The time is being
extended to 52 weeks since the CRL does not need to be updated that often on the Root
CA. The changes here also ensures that the Subordinate CA lifetime is extended from 1
year to 5 years.
Also configured is the DSConfigDN settings for the Root Certificate Authority. This is
needed to inform the Root Certificate Authority on the structure of the TFS Labs domain,
since the Root CA has zero visibility to the domain since it is offline.
All the commands in this section are just making changes to the Windows Registry using
the certutil.exe command. You can view the settings for the Certificate Authority by
opening the Windows Registry (regedit.exe), and going to the following location:
HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

Offline Root CA Setup | 129

To configure the CRL settings for the Root Certificate Authority, perform the following
steps on the TFS-ROOT-CA server:

1. Open an elevated PowerShell prompt.

2. To define the Active Directory Configuration Partition Distinguished Name, run the
following command (replace DC=corp,DC=tfslabs,DC=com with the distinguished
name for your domain):

certutil.exe -setreg `
CA\DSConfigDN "CN=Configuration,DC=corp,DC=tfslabs,DC=com"

3. To define the Validity Period Units for all issued certificates by the Root Certificate
Authority, run following commands:

certutil.exe -setreg CA\ValidityPeriodUnits 5

certutil.exe -setreg CA\ValidityPeriod "Years"

4. To define the CRL Period Units and CRL Period, run the following commands:

certutil.exe -setreg CA\CRLPeriodUnits 52

certutil.exe -setreg CA\CRLPeriod "Weeks"

5. To define the CRL Overlap Period Units and CRL Overlap Period, run the following
commands:

certutil.exe -setreg CA\CRLOverlapPeriodUnits 12

certutil.exe -setreg CA\CRLOverlapPeriod "Hours"

6. Restart the Active Directory Certificate Services service to apply the changes:

net stop CertSvc

net start CertSvc

7. Close the PowerShell prompt.

Once the CRL settings have been configured on the Root Certificate Authority, you can
then proceed to configuring auditing on the Root CA.

CRL Renewal Period

As defined in step 4, the CRL Period on the Root Certificate Authority is set to 52
weeks. This means that every 52 weeks you will need to power on the
TFS-ROOT-CA server and renew the CRL. You should set a reminder in your
calendar to perform this task every 50 weeks to ensure that it is renewed in time
and distributed to the rest of the PKI in your environment.

130 | Practical Guide to PKI with Windows Server

Active Directory Configuration Partition Distinguished Name

There are several ways to determine the Active Directory Configuration Partition
Distinguished Name in an Active Directory domain. One of the easiest ways to
determine the correct format of this name can be accomplished in only a few
steps by using the Active Directory Users and Computers console:

1. On the TFS-DC01 Domain Controller, open the Active Directory Users and
Computers console (dsa.msc).
2. Go to the View menu and select Advanced Features.
3. Right-click on corp.tfslabs.com and select Properties.
4. Go to the Attribute Editor tab.
5. Scroll down until you find the distinguishedName Attribute Field and click the
View button. The String Attribute Editor window will appear:

6. Copy the value in the Value field, this is the information needed for later.

7. Close the Active Directory Users and Computers console.

Aside from using the Active Directory Users and Computers console to retrieve
the Active Directory Configuration Partition Distinguished Name, you can also use
the ADSI Edit (Active Directory Service Interface Editor) tool (adsiedit.msc) to
obtain the same result.

Offline Root CA Setup | 131

Enable Auditing on the Root CA
Auditing is not necessary on servers that are running Active Directory Certificate Services
to function correctly, but it is highly recommended for best practices, and in some cases
for compliance purposes. Auditing on these servers will write logs to the Windows Event
Log on the local server under the following circumstances:

• Whenever a certificate is issued.

• Whenever a certificate is revoked.
• Whenever the Certificate Authority configuration is modified.
• Whenever the Certificate Archive Keys are created and retrieved.
• Whenever administrative tasks such as starting and stopping the Active Directory
Certificate Services service is initiated.

To configure auditing on the Root Certificate Authority, perform the following steps on
the TFS-ROOT-CA server:

1. Open an elevated PowerShell prompt on the TFS-ROOT-CA server.

2. Enable the options to audit Success and Failure attempts on the Audit object access
setting in the Local Security Policy by running the following command:

auditpol.exe /set /category:"Object Access" `

/failure:enable /success:enable

3. Enable auditing for all events on the Certificate Authority by running the following
command:

certutil.exe -setreg CA\AuditFilter 127

4. Restart the Active Directory Certificate Services service to apply the changes:

net stop CertSvc

net start CertSvc

5. Close the PowerShell prompt.

You can verify that all auditing options have been enabled by opening the Certification
Authority console (certsrv.msc) and checking the properties of the TFS Labs Certificate
Authority. Once auditing has been enabled on the Root Certificate Authority, you can now
proceed to configuring the CDP and AIA settings on the Root Certificate Authority.

132 | Practical Guide to PKI with Windows Server

Active Directory Certificate Services Auditing

With auditing enabled for Active Directory Certificate Services, events that are
enabled for auditing will be logged to the Windows Event Viewer. These events
can be viewed through the Event Viewer Console (eventvwr.msc):

Opening one of the events will show more details on the Active Directory
Certificate Services details will give further details on that event:

There are 31 Active Directory Certificate Services related events that can be
logged in the Windows Event Viewer with an Event ID between 4868 and 4898.
Events are also logged with a Task Category of Certification Services to allow for
an alternative sorting and filtering method.

Offline Root CA Setup | 133

Root CA CDP and AIA Configuration
Before the Root Certificate Authority can be properly configured, the Certificate
Revocation List needs to be configured on the Root Certificate Authority.
The CRL files that are provided by the Root CA are distributed with the Subordinate CA.
This is because the Root CA is not available on the network, so there is no way for devices
to access the files on the TFS Labs domain. This is accomplished by configuring the CDP
and AIA settings on the Root CA by specifying certain DNS records and pointing them to
the TFS-CA01 server. The Base CRL will be configured and exported as part of this
section, and the Delta CRL will be published on the Subordinate CA in the next chapter.
There are multiple locations where the CDP and AIA locations are used for the Root
Certificate Authority:
• Local file system (used by the TFS-ROOT-CA server)
• LDAP and Active Directory
• HTTP (to the TFS-CA01 server using http://pki.corp.tfslabs.com/CertData/)
The CDP and AIA configuration on the Root Certificate Authority can be performed using
the Certification Authority console or through the command line using PowerShell.

Root CA CDP and AIA Configuration - GUI Configuration

To configure CDP and AIA on the Root Certificate Authority, perform the following steps
using the Certification Authority console on the TFS-ROOT-CA server:
1. Open the Certification Authority console (certsrv.msc) on the TFS-ROOT-CA server:

134 | Practical Guide to PKI with Windows Server

2. Right-click on TFS Labs Certificate Authority server and select Properties:

3. Select the Extensions tab, verify that the CRL Distribution Point (CDP) extension is
selected under the Select extension field, and click the Add button:

Offline Root CA Setup | 135

 4. On the Add Location window, under the Location field, enter the following address
and click the OK button:

http://pki.corp.tfslabs.com/CertData/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

5. On the Extensions tab, verify that the Include in CRLs. Clients use this to find Delta
CRL locations. and Include in the CDP extension of issued certificates options are
selected for the location that was just entered.
6. Select file://<ServerDNSName>/CertEnroll/TFS%20Labs%20Certificate
%20Authority.crl from the list and click the Remove button. Click the Yes button to
confirm that you want to remove the location.
7. On the Extensions tab, verify that under the Selection extension field, the Authority
Information Access (AIA) extension is selected, and click the Add button:

8. On the Add Location window, under the Location field, enter the following address
and click the OK button:

http://pki.corp.tfslabs.com/CertData/<ServerDNSName>_<CaName><CertificateName>.crt

9. On the Extensions tab, verify that the Include in the AIA extension of issued certificates
option is selected for the location that was just entered.
10. Select file://<ServerDNSName>/CertEnroll/<ServerDNSName>_<CaName>
<CertificateName>.crt from the list and click the Remove button. Click the Yes button
to confirm that you want to remove the location.

136 | Practical Guide to PKI with Windows Server

11. Click the OK button to commit the changes.
12. On the Certification Authority window, when prompted to restart Active Directory
Certificate Services, click the Yes button.
13. Verify that the settings are correct by running the following commands in an elevated
PowerShell prompt:

certutil.exe -getreg CA\CRLPublicationURLs

certutil.exe -getreg CA\CACertPublicationURLs

Offline Root CA Setup | 137

 14. In the Certification Authority console, expand the TFS Labs Certificate Authority,
right-click on Revoked Certificates under TFS Labs Certificate Authority and select
All Tasks > Publish:

15. On the Publish CRL window, verify that New CRL is selected and click the OK button:

16. Close the Certification Authority console.

Now that the CRL settings have been successfully configured on the TFS-ROOT-CA server
and the CRL has been published, the CRL and the Root certificate can now be exported
so that the Subordinate CA server can host it for the TFS Labs domain.

138 | Practical Guide to PKI with Windows Server

Root CA CDP and AIA Configuration - CLI Configuration
The CDP and AIA settings can be configured using the command line using PowerShell
with much fewer steps on the TFS-ROOT-CA server:
1. Open an elevated PowerShell prompt.
2. Run the following command to configure the CDP settings for the Root certificate
(execute this command as a single line with no breaks):

certutil.exe -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\

CertSrv\CertEnroll\%3%8%9.crl\n8:ldap:///CN=%7%8,CN=%2,CN=CDP,
CN=Public Key Services,CN=Services,%6%10\n0:http://%1/CertEnroll/
%3%8%9.crl\n6:http://pki.corp.tfslabs.com/CertData/%3%8%9.crl"

3. Run the following command to configure the AIA settings for the Root certificate
(execute this command as a single line) (execute this command as a single line with
no breaks):

certutil.exe -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\

CertSrv\CertEnroll\%1_%3%4.crt\n0:ldap:///CN=%7,CN=AIA,
CN=Public Key Services,CN=Services,%6%11\n0:http://%1/CertEnroll/
%1_%3%4.crt\n2:http://pki.corp.tfslabs.com/CertData/%1_%3%4.crt"

4. Restart the Active Directory Certificate Services service to apply the changes:

net stop CertSvc

net start CertSvc

5. To publish the CRL, run the following command:

certutil.exe -crl

6. Close the elevated PowerShell prompt.

There are two commands that can be run to verify that the CDP and AIA settings were
successfully applied to the Root CA. To verify the CRL settings that were just applied, run
the following command:

certutil.exe -getreg CA\CRLPublicationURLs

To verify the AIA settings that were just applied to the Root CA, run the following
command:

certutil.exe -getreg CA\CACertPublicationURLs

Now that the CRL settings have been successfully configured on the TFS-ROOT-CA server
and the CRL has been published, the CRL and the Root certificate can now be exported
so that the Subordinate CA server can host it for the TFS Labs domain.

Offline Root CA Setup | 139

Root CA Certificate and CRL Export
Exporting the Root certificate and the Root CRL is needed to make it available on the
TFS-CA01 server and for the rest of the TFS Labs domain. The links to these files were
referenced in the Root certificate configuration, so they will need to be copied to the
Subordinate CA server for users to be able to access those files. To copy the Root
certificate and Root CRL files, perform the following steps on the TFS-ROOT-CA server:

1. Copy the contents of the C:\Windows\System32\CertSrv\CertEnroll folder to the

C:\RootCA folder.
2. The following files should be present in the C:\RootCA folder:
• C:\RootCA\TFS Labs Certificate Authority.crl
• C:\RootCA\TFS-ROOT-CA_TFS Labs Certificate Authority.crt
3. Add the RootCAFiles.vfd virtual floppy disk to the TFS-ROOT-CA virtual machine.
4. Copy the contents of the C:\RootCA folder to the A:\ drive.
5. Eject the RootCAFiles.vfd virtual floppy disk.

Once the Root certificate and CRL files have been successfully copied to the virtual
floppy disk, all the initial tasks for the TFS-ROOT-CA server are now complete.

Root CA Server Restart

It is advisable to restart the Root CA server before continuing with any additional
configuration of the TFS Labs Certificate Authority. This will ensure that all changes to
the Root CA have been successfully committed and applied to the TFS Labs domain.

Root CA Next Steps

Now that the Root Certificate Authority and Root certificate have been successfully
created, it is time to create the Subordinate Certificate Authority and the Subordinate
certificate for the TFS Labs domain. The next chapter will outline the process for creating
the Subordinate Certificate Authority server, and how to create the Certificate Request for
the Subordinate certificate.

If you decided to use BitLocker for encrypting the TFS-ROOT-CA server, the BitLocker
Recovery Key should also be located on the RootCAFiles.vfd virtual floppy disk. In the
next chapter when the TFS-CA01 server is provisioned, and the virtual floppy disk is
mounted on that server, you can copy the BitLocker Recovery Key to another device at
that point.

140 | Practical Guide to PKI with Windows Server

Chapter 5 - Subordinate CA Setup

The Subordinate Certificate Authority server is setup as an Active Directory domain

joined Windows Server on the TFS Labs domain. It is meant to always be online and is
used to issue and manage certificates for the TFS Labs domain. The Subordinate
Certificate Authority server will be called TFS-CA01. There are a few terms that are used
for the TFS-CA01 server, the most common being the Subordinate CA (SubCA). It can
also be referred to as an Enterprise CA, and can also be referred to as an Issuing CA.
These terms will be used interchangeably throughout the remainder of this book, but they
are the same thing.

Since the Subordinate CA is being setup on an Active Directory domain, it is necessary to

make changes to the Windows Firewall on that server to ensure that other devices on
that domain can communicate with that server with the correct protocols. It is extremely
bad practice to disable the Windows Firewall on a Windows Server, even when the server
is internal only, so this chapter will also show what changes should be made to the
Windows Firewall to allow for proper communication.

The Root CA that was setup in the previous chapter used BitLocker Full Disk Encryption,
but that step is skipped for this chapter. Since it is assumed that the Subordinate CA will
be a proper member of an Active Directory environment, it is likely that full disk
encryption would be setup differently if it were being used in that environment. If you do
not have a different full disk encryption application in use on your domain, you may want
to consider using BitLocker to enhance the security of the Subordinate CA using the
same instructions as the Root CA.

With the Root Certificate Authority successfully setup, most of the remaining
configuration for the TFS Labs Certificate Authority is performed on the TFS-CA01 server.

This chapter will focus on how to install and configure a Subordinate CA using Active
Directory Certificate Services. There are also steps required to be completed on the
Domain Controller for the TFS Labs domain. The most configuration for the Certificate
Authority will occur in this chapter.

Subordinate CA Setup | 141

Subordinate CA Server Setup
The Windows server that will be hosting the Subordinate Certificate Authority will always
be online and available to the TFS Labs domain. It will be hosting all the certificate files
that are needed for the TFS Labs domain, as well as the Online Responder role that can
be used for rapid certificate revocation. This role will be configured in a later chapter.

Provision and configure a new virtual machine called TFS-CA01 and install Windows
Server 2019 Standard (Desktop Experience) in Hyper-V using the following specifications:

• Virtual Machine Generation - 1

• Virtual Processors - 2
• Virtual Memory - 4096 MB
• Virtual Hard Disk - 40 GB
• Virtual Network Adapters - 1

Once the TFS-CA01 virtual machine has been created and the operating system has been
installed, there are a few tasks that need to be completed:

• Set the local Administrator account on the TFS-CA01 server to a complex password
that is at least 14 characters and store the password securely.
• Set the hostname to TFS-CA01. Restart the server to apply the change.

Once the local Administrator account and the hostname have been setup, you will also
need to configure the network settings for the virtual machine:

IP Address 10.100.1.101
Netmask 255.255.255.0
Gateway 10.100.1.1
DNS Server 1 10.100.1.100

Join the TFS-CA01 server to the TFS Labs domain. Restart the server to apply the change.

The TFS-CA01 server should be moved from the default Computer OU in Active Directory
to one of the dedicated OUs that was created earlier for the TFS Labs domain. This will
facilitate easier application of Group Policy objects, which are needed for Active
Directory Certificate Services. To move the TFS-CA01 computer object, perform the
following steps on the TFS-DC01 server:

1. Open the Active Directory Users and Computers console (dsa.msc) on the TFS-DC01
server.
2. Expand the corp.tfslabs.com domain and go to the Computers OU.
3. Right-click on the TFS-CA01 computer and click on Move....
4. In the Move window, expand the TFS Labs OU and select TFS Servers and click OK. If
you see a warning message about moving the computer object, click the Yes button.
5. Close the Active Directory Users and Computers console.

142 | Practical Guide to PKI with Windows Server

Alternatively, you can also move the TFS-CA01 computer object by running the following
command from an elevated PowerShell prompt on the TFS-DC01 server:

Get-ADComputer "TFS-CA01" | `
Move-ADObject -TargetPath "OU=TFS Servers,OU=TFS Labs,DC=corp,DC=tfslabs,DC=com"

Once the TFS-CA01 server has been successfully joined to the TFS Labs domain, login
with the Domain Administrator account that was created earlier. The Domain
Administrator account will be required for the entire Active Directory Certificate Services
installation and configuration of the TFS-CA01 server. Once the server has been
completely setup and joined to the TFS Labs domain, you can proceed to the next steps
of creating DNS records to support the Active Directory Certificate Services role.

Domain Administrator Account

Ensure that you login as the Domain Administrator on the TFS-CA01 server before
attempting to configure the Active Directory Certificate Services role. If you
attempt to configure this role while logged in as a non-administrator, it will not
allow you to configure the role due to permission errors. The Enterprise CA role in
Active Directory Certificate Services requires an Active Directory account with the
correct permissions since it makes changes to Active Directory. Ensure that you
logon to the TFS-CA01 server using the TFSLABS\Administrator account,
otherwise you will not be able to configure the PKI correctly.

BitLocker Disk Encryption

If you would like to configure BitLocker as the full disk encryption software for the
TFS-CA01 server, you can follow the same steps as the TFS-ROOT-CA server.
Those steps will work the same way on the TFS-CA01 server. You should perform
those steps now and verify it is working correctly before going any further if you
intend to use BitLocker.

Create CNAME Records in DNS

By creating separate CNAME records for the Active Directory Certificate Services role, it
will make it possible to split up the TFS-CA01 server in the future if needed. There are two
DNS records that need to be created in the DNS Zone to support the PKI infrastructure in
the TFS Labs domain. This is the PKI and OCSP DNS records that will be used by clients
to retrieve certificates and perform important lookups for Certificate Revocation.

There are two CNAME records that will need to be created to support the PKI on the TFS
Labs domain:

• OCSP.corp.tfslabs.com
• PKI.corp.tfslabs.com

Subordinate CA Setup | 143

There are two methods for creating CNAME records in DNS using Windows Server, one is
with the DNS Manager console and the other is through the command line with
PowerShell.

Create CNAME Records in DNS - GUI Configuration

On the TFS-DC01 Domain Controller, create the following CNAME records pointing the
TFS-CA01 server using the DNS Manager console:

1. Open the DNS Manager console (dnsmgmt.msc) on the TFS-DC01 server:

2. Under the DNS node, expand the TFS-DC01 server and then expand Forward Lookup
Zones. Select the corp.tfslabs.com Zone:

144 | Practical Guide to PKI with Windows Server

3. Right-click on the corp.tfslabs.com DSN zone and select the option for New Alias
(CNAME)....
4. On the New Resource Record window, in Alias name (uses parent domain if left
blank), enter OCSP as the name. In the Fully qualified domain name (FQDN) field,
enter tfs-ca01.corp.tfslabs.com. and then click OK to add the CNAME record:

5. Right-click on the corp.tfslabs.com DNS Zone and select the option for New Alias
(CNAME)....
6. On the New Resource Record window, in Alias name (uses parent domain if left
blank), enter PKI as the name. In the Fully qualified domain name (FQDN) field, enter
tfs-ca01.corp.tfslabs.com. and then click OK to add the CNAME record.
7. Verify that the two CNAME records have been added to the DNS Zone and point to
the TFS-CA01 server:

8. Close the DNS Manager console.

Subordinate CA Setup | 145

Once the DNS records have been created, you can proceed to creating the CAPolicy.inf
file that is needed to create the Subordinate Certificate.

Create CNAME Records in DNS - CLI Configuration

Alternatively, you can also add the DNS records through the command line using
PowerShell on the TFS-DC01 server:

1. Open an elevated PowerShell prompt.

2. Enter the following command to create a CNAME record for OCSP.corp.tfslabs.com:

Add-DnsServerResourceRecordCName `
-Name "OCSP" `
-HostNameAlias "TFS-CA01.corp.tfslabs.com" `
-ZoneName "corp.tfslabs.com"

3. Enter the following command to create a CNAME record for PKI.corp.tfslabs.com:

Add-DnsServerResourceRecordCName `
-Name "PKI" `
-HostNameAlias "TFS-CA01.corp.tfslabs.com" `
-ZoneName "corp.tfslabs.com"

4. Close the PowerShell prompt.

Once the DNS records have been created, you can proceed to creating the CAPolicy.inf
file that is needed to create the Subordinate certificate.

Create CNAME Records in DNS - Validation

Once the CNAME records have been created, you can test that the records have been
created correctly by opening a Command Prompt and pinging the FQDN entries that were
just created in the previous steps. The addresses should resolve to the correct hostname
and IP address, which both point to the TFS-CA01 server.

If the ping fails with a timeout, but still resolves to the correct IP address for the
TFS-CA01 server, that does not necessarily mean that there is an issue. If the Windows
Firewall is blocking ping requests, then the ping responses will fail. A later step in this
chapter will correct any issues with ping requests.

Once the DNS records have been created and validated, you can proceed to creating the
CAPolicy.inf file that is needed to create the Subordinate certificate.

146 | Practical Guide to PKI with Windows Server

Subordinate CA CAPolicy.inf Installation
The CAPolicy.inf file is used to add configuration details to the Certificate Authority at the
time of creation. On the TFS-CA01 server, create a file in the C:\Windows folder called
CAPolicy.inf (ensure that it is saved with the correct file extension otherwise these
settings will be ignored). Copy the following contents into this file:

C:\Windows\CAPolicy.inf

[ Version ]
Signature =" $Windows NT$ "

[ PolicyStatementExtension ]
Policies = AllIssuancePolicy , InternalPolicy
Critical = FALSE

; Enables all Certificate Templates .

[ AllIssuancePolicy ]
OID =2.5.29.32.0

[ InternalPolicy ]
OID =1.2.3.4.1455.67.89.5
Notice =" The TFS Labs Certification Authority is internal only ."
URL = http :// pki . corp . tfslabs . com / cps . html

[ Certsrv_Server ]
; Renewal information for the Subordinate CA .
RenewalKeyLength =4096
RenewalValidityPeriod = Years
RenewalValidityPeriodUnits =5

; Disable support for issuing certificates using RSASSA - PSS .

AlternateSignatureAlgorithm =0

; Load all certificate templates by default .

LoadDefaultTemplates =1

Delta CRL with Subordinate Certificate Authorities

A Delta CRL is not normally required for a Root Certificate Authority, especially one
that is offline since it is not normally handling certificate revocations in a PKI. The
Root CA is only ever used to issue a Base CRL when there are Subordinate
Certificate Authorities. The only certificates that are typically revoked by a Root
CA is a Subordinate certificate, so that would necessitate the deployment of a
new Base CRL instead of a Delta CRL.

Since this is a Subordinate CA that is always online and used for handling all
regular Certificate Authority tasks, a Delta CRL is needed to revoke certificates
much more frequently. A Delta CRL can also be used in parallel with OCSP, which
is configured in a later chapter of this book.

Subordinate CA Setup | 147

 OID Number

You can update the OID number in the InternalPolicy section of the CAPolicy.inf
file for your deployment if it is required for your organization. The OID number in
this example is used in Microsoft technical documentation, but it should work for
your organization if it is only ever going to be used internally. If you require a
customized OID number, you can register for a Private Enterprise Number through
the IANA.

If you used a particular OID for the Root certificate, ensure that you use the same
OID here as well otherwise the PKI will likely have issues.

If you would like to use your PEN number for the Certificate Authority, modify the
OID line in the InternalPolicy section to OID=1.3.6.1.4.1.X (replace the X with your
PEN number).

Signature Algorithm Support Issues

The AlternateSignatureAlgorithm=0 flag in the CAPolicy.inf file explicitly uses

SHA256 for the algorithm instead of RSASSA-PSS. This can cause issues with
some devices (especially iOS) and by ensuring that it is disabled you should not
have issues with these certificates.

CAPolicy.inf File Name and Locations

Ensure that the CAPolicy.inf file has been properly saved in the C:\Windows folder
(%WINDIR%). Also make sure that the file extension is set to INF and not TXT. A
common mistake is to accidentally save the file as CAPolicy.inf.txt.

If the CAPolicy.inf file is not saved in the correct directory and without the correct
file extension, all settings in the file will be ignored at the time when the Certificate
Authority is created.

Subordinate CA AD CS Role Installation

Once the TFS-CA01 server has been installed and configured properly, the Active
Directory Certificate Services role needs to be installed. As part of the installation
process, the Internet Information Services role will also be installed to manage the
Certificate Authority Web Enrollment role. It can be installed using Server Manager or
through the command line with PowerShell, you can decide which one you would like to
use. You only need to choose one method for installing the Active Directory Certificate
Services role.

148 | Practical Guide to PKI with Windows Server

Subordinate CA AD CS Role Installation - GUI Installation
To install the Active Directory Certificate Services role using the Server Manager console,
perform the following steps:
1. Open the Server Manager console (servermanager.exe), click on the Manage menu,
and click on Add Roles and Features to start the installation wizard:

2. On the Before You Begin screen, click the Next button to continue:

Subordinate CA Setup | 149

 3. On the Installation Type screen, select the option for Role-based or feature-based
installation and click the Next button to continue:

4. On the Server Selection screen, verify that the TFS-CA01.corp.tfslabs.com server is

selected and click Next to continue:

150 | Practical Guide to PKI with Windows Server

5. On the Server Roles screen, select the Active Directory Certificate Services option:

6. The installation wizard will ask to install any additional features required for the
Active Directory Certificate Services role. Select the option to Include management
tools (if applicable) to install the management tools for the role. Click the Add
Features button to continue:

Subordinate CA Setup | 151

 7. On the Server Roles screen, click the Next button to continue:

8. On the Features screen, click the Next button to continue:

152 | Practical Guide to PKI with Windows Server

 9. On the Active Directory Certificate Services screen, click the Next button to continue:

10. On the Select role services screen, select the option for Certification Authority and
Certificate Authority Web Enrollment:

Subordinate CA Setup | 153

 11. The installation wizard will ask to install any additional features required for Certification
Authority Web Enrollment. Select the option to Include management tools (if applicable)
to install the management tools for the role. Click the Add Features button to continue:

12. On the Select role services screen, click Next to continue:

154 | Practical Guide to PKI with Windows Server

13. On the Web Server Role (IIS) screen, click the Next button to continue:

14. On the Select role services screen, click the Next button to continue:

Subordinate CA Setup | 155

 15. On the Confirm installation selections screen, select the option to Restart the destination
server automatically if required:

16. When prompted with a warning about restarting the server, click the Yes button.
17. On the Confirm installation selections screen, click the Install button to continue:

156 | Practical Guide to PKI with Windows Server

 18. Once the installation is completed, click the Close button:

Once the Active Directory Certificate Services role has been installed, you can then
proceed to configuring the role and creating the Subordinate Certificate for the TFS Labs
domain.

Subordinate CA AD CS Role Installation - CLI Installation

The Active Directory Certificate Services role installation can be performed using
PowerShell, which requires much fewer steps to accomplish:

1. Open an elevated PowerShell prompt.

2. Run the following command to install the Active Directory Certificate Services role,
the Certification Authority Web Enrollment role, and the necessary Administration
Tools:

Add-WindowsFeature `
-Name ADCS-Cert-Authority, ADCS-Web-Enrollment, Web-Mgmt-Service `
-IncludeManagementTools

Subordinate CA Setup | 157

 3. The command will automatically install the Active Directory Certificate Services role
and output a Success status of True:

4. Once the installation for Active Directory Certificate Services has completed, you
can close the PowerShell prompt.

Once the Active Directory Certificate Services role has been installed, you can then
proceed to configuring the role and creating the Subordinate certificate for the TFS Labs
domain.

Subordinate CA AD CS Role Configuration

Once the Active Directory Certificate Services role has been added, it will need to be
properly configured as the Subordinate Certificate Authority. In the process of
configuring the Active Directory Certificate Services role for the TFS Labs domain, the
following Subordinate certificate be configured:

Certificate Authority Setup Type Enterprise CA

Certificate Authority Type Subordinate CA
Cryptographic Provider RSA#Microsoft Software Key Storage Provider
Key Length 4096 Bits
Signature Hash Algorithm SHA256
CA Common Name TFS Labs Enterprise CA
Validity Period 5 years

158 | Practical Guide to PKI with Windows Server

The Active Directory Certificate Services role can be configured using the Server Manager
or through the command line with PowerShell, you can decide which one you would like
to use. You only need to choose one method for configuring the Active Directory
Certificate Services role.

Subordinate CA AD CS Role Configuration - GUI Configuration

To perform the Active Directory Certificate Services role configuration using the Server
Manager console, perform the following steps:

1. To begin the configuration of Active Directory Certificate Services, open the Server
Manager console (servermanager.exe). Click the Notifications icon in the upper-right
hand corner and click the Configure Active Directory Certificate Services on the
destination server link in the Post-deployment Configuration box:

Subordinate CA Setup | 159

 2. On the Credentials screen, verify that the Administrator credentials are set to a Domain
Administrator account and click the Next button to continue. If you do not use a
Domain Administrator account, then the installation will not allow you to install the
Active Directory Certificate Services service correctly:

3. On the Role Services screen, select the options for Certification Authority and Certification
Authority Web Enrollment and click Next to continue:

160 | Practical Guide to PKI with Windows Server

4. On the Setup Type screen, select the option for Enterprise CA and click the Next
button to continue:

5. On the CA Type screen, ensure that the Subordinate CA option is selected and click
the Next button to continue:

Subordinate CA Setup | 161

 6. On the Private Key screen, verify that the Create a new private key option is selected.
This is because this a new CA installation and the Private Key is not being restored
from a previous server. Click the Next button to continue:

7. On the Cryptography for CA screen, make the following changes and then click the
Next button to continue:
• Cryptographic Provider: RSA#Microsoft Software Key Storage Provider
• Key Length: 4096
• Hash Algorithm: SHA256

162 | Practical Guide to PKI with Windows Server

8. On the CA Name screen, set the Common Name (CN) for the CA to TFS Labs Enterprise
CA and click the Next button to continue:

9. On the Certificate Request screen, accept the default location for saving the Certificate
Request file. It will be saved as C:\TFS-CA01.corp.tfslabs.com_corp-TFS-CA01-CA.req.
Click the Next button to continue:

Subordinate CA Setup | 163

 10. On the CA Database screen, make no changes to the database location and click the
Next button to continue:

11. On the Confirmation screen, verify that the options are correct and click the Configure
button to commit the changes:

164 | Practical Guide to PKI with Windows Server

 12. On the Results screen, click the Close button:

At this point the Subordinate Certificate Authority for the TFS Labs domain has been
created, but the Subordinate certificate needs to be issued. You can now validate that the
Certificate Authority has been successfully created.

Subordinate CA AD CS Role Configuration - CLI Configuration

The Active Directory Certificate Services role configuration can be performed using
PowerShell, which requires much fewer steps to accomplish:

1. Open an elevated PowerShell prompt.

2. Run the following command to configure the Active Directory Certificate Services
role and create the Subordinate Certificate Authority:

Install-AdcsCertificationAuthority `
-CAType EnterpriseSubordinateCA `
-CACommonName "TFS Labs Enterprise CA" `
-KeyLength 4096 `
-HashAlgorithm SHA256 `
-CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
-Force

Subordinate CA Setup | 165

 3. The command will automatically configure the Active Directory Certificate Services
role and output a Success status of True:

4. Run the following command to configure the Certification Authority Web Enrollment
role:

Install-AdcsWebEnrollment -Force

5. The command will automatically configure the Certification Authority Web Enrollment
role and output an ErrorID status of 0:

166 | Practical Guide to PKI with Windows Server

 6. Once the configuration for Active Directory Certificate Services has completed, you
can close the PowerShell prompt.

At this point the Subordinate Certificate Authority for the TFS Labs domain has been
created, but the Subordinate certificate needs to be issued. You can now validate that the
Certificate Authority has been successfully created before configuring the Subordinate
certificate.

Subordinate CA Validation
The Subordinate Certificate Authority for the TFS Labs domain has been created, so there
is now an Enterprise CA available which can be validated. The Certificate Request for the
Subordinate certificate has been created, which means it will need to be submitted to the
Root Certificate Authority to complete the request. Until this CSR is submitted and
completed, the Enterprise CA will not function correctly as there is no valid certificate
present yet.

Even though the Active Directory Certificate Services role was configured, it is not
currently running as there is no valid certificate present. If you open the Certification
Authority console (certsrv.msc) on the TFS-CA01 server, you will see that it is setup, but
the service is not running:

Figure 5.6.1: The Certification Authority console is used to manage the CA and
allows administrators to issue and revoke certificates. This console also allows further
customization of the CA.

Subordinate CA Setup | 167

Once the Certificate Request file has been successfully generated, it will need to be
copied to the RootCAFiles.vfd virtual floppy disk since the Root CA on TFS-ROOT-CA
needs the request file to issue the Subordinate certificate. To copy the Certificate
Request file, perform the following steps:

1. Add the RootCAFiles.vfd virtual floppy disk to the TFS-CA01 virtual machine.
2. Browse to the C:\ drive and copy the TFS-CA01.corp.tfslabs.com_corp-TFS-CA01-CA.req
to the A:\ drive.
3. Eject the RootCAFiles.vfd virtual floppy disk.

Once the Certificate Request has been successfully copied to the virtual floppy disk, you
can proceed to creating the CertData directory in IIS on the TFS-CA01 server.

Create the CertData Virtual Directory

On the TFS-CA01 server, create a folder that will be used to host important certificate
files (such as the Root certificate and the CRL files) for the users, workstations, and
servers in the TFS Labs domain. These are the necessary files from the Offline Root
Certificate Authority, which requires these files to be available for users. It can be created
by performing the following steps:

1. Add the RootCAFiles.vfd virtual floppy disk to the TFS-CA01 virtual machine.
2. On the root of the C:\ drive, create a folder called CertData (C:\CertData).
3. Open the A:\ drive and copy the TFS Labs Certificate Authority.crl and TFS-ROOT-CA_TFS
Labs Certificate Authority.crt files to the C:\CertData folder.
4. Eject the RootCAFiles.vfd virtual floppy disk.

There are two methods for creating the CertData virtual directory on the TFS-CA01 server,
one using the IIS Manager and the other using the command line. Only one method for
creating the CertData folder is needed, you can choose whatever method to create the
virtual directory since the result will be the same.

Root Certificate Authority Files

The Root Certificate Authority is an Offline CA, which means that files such as the
Root certificate and the Root CRL files are not available. As part of maintaining a
healthy PKI, it is necessary that the Root CA files are made available to users,
workstations, and other devices. The CDP and AIA files for the Root CA were
configured on the Root CA in the previous chapter.

Since the TFS-ROOT-CA server is offline and the TFS-CA01 server is online, the
TFS-CA01 server can be used to host the necessary Root CA files. When the CRL
files for the Root CA are updated, those files will need to be copied to this folder
as well to ensure that the PKI remains up to date. Steps on how to perform this
are provided in a later chapter.

168 | Practical Guide to PKI with Windows Server

Create the CertData Virtual Directory - GUI Configuration
To add the CertData directory to IIS, perform the following steps on the TFS-CA01 server
using the Internet Information Services (IIS) Manager:

1. Open the Internet Information Services (IIS) Manager (inetmgr.exe) console:

2. On the Connections pane, expand TFS-CA01, and then expand Sites:

Subordinate CA Setup | 169

 3. Right-click on Default Web Site and select Add Virtual Directory:

4. On Add Virtual Directory screen, in Alias, enter CertData. For the Physical path, enter
C:\CertData and then click OK.
5. In the Connections screen, under the Default Web Site, ensure the CertData virtual
directory is selected:

170 | Practical Guide to PKI with Windows Server

 6. In the CertData Home pane, double-click on Directory Browsing:

7. In the Actions pane on the right-side of the windows, click Enable:

8. Close the Internet Information Services (IIS) Manager console.

Once the directory and the directory browsing option has been enabled on the CertData
directory, double escaping can now be enabled in IIS.

Subordinate CA Setup | 171

Create the CertData Virtual Directory - CLI Configuration
Alternatively, you can create the CertData virtual directory using the command line
instead of using the Internet Information Services (IIS) Manager:

1. Open an elevated Command Prompt.

2. Change to the correct directory by entering the following command:

cd C:\Windows\System32\inetsrv\

3. Run the following command to create the CertData virtual directory in IIS:

appcmd.exe add vdir /app.name:"Default Web Site/" ^

/path:/CertData /physicalPath:C:\CertData

4. Run the following command to enable Directory Browsing on the CertData virtual
directory:

appcmd.exe set config "Default Web Site/CertData" ^

/section:directoryBrowse /enabled:true

5. Close the Command Prompt.

Once the directory and the directory browsing option has been enabled on the CertData
directory, double escaping can now be enabled in IIS.

Create the CertData Virtual Directory - Validation

Once the CertData directory is created, you can test that the directory is accessible by
opening a web browser on the TFS-CA01 server. Open the following address in a web
browser on the TFS-CA01 server (the address specified below is a CNAME record to that
server):

http://pki.corp.tfslabs.com/CertData/

The contents of the CertData folder should be displayed in the browser, and the Root
certificate and Root CRL files should be listed.

Once the directory and the directory browsing option has been enabled on the CertData
directory, double escaping can now be enabled in IIS.

Enable Double Escaping in IIS

On the TFS-CA01 server, enable double escaping within Internet Information Services to
allow for proper CRL publication on the TFS Labs domain. This applies specifically to the
Delta CRL which requires this functionality. The Delta CRL has a plus (+) symbol in the
name, and this can cause issues with some versions of IIS.

172 | Practical Guide to PKI with Windows Server

To enable double escaping in IIS, perform the following steps on the TFS-CA01 server:

1. Open an elevated Command Prompt.

2. Change to the correct directory by entering the following command:

cd C:\Windows\System32\inetsrv\

3. Enter the following command to apply the change to IIS:

appcmd.exe set config "Default Web Site" ^

/section:system.webServer/Security/requestFiltering ^
-allowDoubleEscaping:True

4. Restart IIS service by entering the iisreset.exe command:

5. Close the Command Prompt.

After enabling double escaping in IIS, it will now be possible to distribute the Delta CRL
files in the TFS Labs domain.

Double Escaping Validation

If double escaping is not enabled correctly then there will be issues with deploying
the Delta CRL and with validation of the PKI. This issue will occur since the Delta
CRL files are not able to be accessed over HTTP, and that is the way that they are
distributed with the Enterprise CA in this book. If an issue arises with accessing
the Delta CRL files, it is easy to correct by checking IIS to verify that double
escaping is enabled.

Subordinate CA Setup | 173

Subordinate Certificate Creation
Once the Subordinate CA has been configured and the Certificate Request successfully
generated, it is now time to complete the Subordinate CA certificate by using the
TFS-ROOT-CA server.

Creating the Subordinate certificate requires multiple steps using both the Root CA
server and the Subordinate CA server. These steps are not complicated, but they must be
completed in the correct order and none of the steps can be skipped. The workflow for
creating the Subordinate certificate is as follows:

• Insert the virtual floppy disk on the TFS-ROOT-CA server.

• Submit the CSR for the Subordinate CA to the Root CA.
• Export the Subordinate certificate from the Root CA.
• Copy the Subordinate certificate to the virtual floppy disk.
• Insert the virtual floppy disk on the TFS-CA01 server.
• Install the Subordinate certificate on the Subordinate CA.
• Start Active Directory Certificate Services on the TFS-CA01 server.

To create the Subordinate CA certificate, perform the following steps on the TFS-CA01
and TFS-ROOT-CA servers:

1. Add the RootCAFiles.vfd virtual floppy disk to the TFS-ROOT-CA virtual machine.
2. Copy the A:\TFS-CA01.corp.tfslabs.com_corp-TFS-CA01-CA.req file to the C:\RootCA
folder.
3. On the TFS-ROOT-CA server open Certification Authority console (certsrv.msc).
4. Right-click on the TFS Labs Certificate Authority server, select All Tasks and click
on Submit new request...:

174 | Practical Guide to PKI with Windows Server

5. On the Open Request File window, browse to the C:\RootCA folder and select the
TFS-CA01.corp.tfslabs.com_corp-TFS-CA01-CA.req file that was copied from TFS-CA01.
Click the Open button to continue:

6. Once the Certificate Request has been submitted to the Root Certificate Authority,
go to the Pending Requests folder in the TFS Labs Certificate Authority to see the
pending Certificate Request. It should be identified as Request ID 2:

Subordinate CA Setup | 175

 7. To issue the Subordinate certificate, right-click on the Request ID 2, select All Tasks
and click on Issue:

8. Once the certificate has been issued, go to the Issued Certificates folder to see the
certificate. It is still identified as Request ID 2:

176 | Practical Guide to PKI with Windows Server

 9. Double-click on the Request ID 2 certificate to open the Certificate properties window:

10. Go to the Details tab and click on the Copy to File... button:

Subordinate CA Setup | 177

 11. On the first screen of the Certificate Export Wizard, click the Next button to continue:

12. On the Export File Format screen, select the Cryptographic Message Syntax Standard
- PKCS #7 Certificate (.P7B) format. Select the option to Include all certificates in
the certification path if possible and click the Next button:

178 | Practical Guide to PKI with Windows Server

13. On the File to Export screen, enter C:\RootCA\TFS Labs Enterprise CA.p7b as the
file name and click Next to continue:

14. On the Completing the Certificate Export Wizard screen, click the Finish button to
complete the wizard:

Subordinate CA Setup | 179

 15. On the Certificate Export Wizard prompt, click the OK button to continue.
16. Copy the C:\RootCA\TFS Labs Enterprise CA.p7b file to the A:\ drive.
17. Eject the RootCAFiles.vfd virtual floppy disk.
18. On the TFS-CA01 server insert the RootCAFiles.vfd virtual floppy disk. Copy the
A:\TFS Labs Enterprise CA.p7b file to root of the C:\ drive.
19. On the TFS-CA01 server, open the Certification Authority console (certsrv.msc):

20. Right-click on the TFS Labs Enterprise CA server, go to All Tasks and select the option
to Install CA Certificate...:

180 | Practical Guide to PKI with Windows Server

21. On the Select file to complete CA installation window, browse to the C:\ drive, select
the TFS Labs Enterprise CA.p7b file and click Open:

22. If you receive a warning message about installing an untrusted Root certificate, click
the OK button. The error is due to the Root certificate being untrusted and should be
referenced by the CERT_E_UNTRUSTEDROOT error message.
23. If there were no errors in installing the certificate, right-click on the TFS Labs Enterprise
CA server, select the All Tasks option, and click the Start Service option:

Subordinate CA Setup | 181

 24. The Subordinate Certificate has now been installed successfully, and the Subordinate
Certificate Authority is now running.

25. Eject the RootCAFiles.vfd virtual floppy disk.

You can also view the Subordinate certificate and verify that it was created with the
correct values that you setup during the configuration:

Figure 5.9.1: The TFS Labs Enterprise CA is signed by the TFS Labs Certificate Authority,
with a 5 year validity period.

182 | Practical Guide to PKI with Windows Server

If there were no issues with creating the Subordinate certificate, you can delete the
following files from the TFS-CA01 server as they are no longer needed:

• C:\TFS-CA01.corp.tfslabs.com_corp-TFS-CA01-CA.req
• C:\TFS Labs Enterprise CA.p7b

These files should be deleted as they should not remain on a server that has active
network connections for security purposes. Those files can remain on the TFS-ROOT-CA
server as it is offline, and the files cannot be accessed.

There may be instances where the installation and configuration of the Subordinate
certificate may fail for several reasons (if the Subordinate certificate was successfully
issued, skip this step). This may occur when the Subordinate CA has issues with the
Root CA CRL configuration, which is offline at the time of issuance of the Subordinate
certificate. To correct this issue when you are attempting to issue or start the services on
the Subordinate CA, run the following command in an elevated PowerShell prompt:

certutil.exe –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

Once the command is issued, the Active Directory Certificate Services role will need to be
restarted. Run the following commands to restart the service:

net stop CertSvc

net start CertSvc

You can proceed to setting the maximum age for any certificate that is issued by the
Certificate Authority in the next section.

Set Maximum Certificate Age

All certificates that will be issued by the Subordinate CA will only be valid for 1 year, and
the setting can be forced so that a Certificate Template does not attempt to sign a
certificate for a longer period of time.

To configure the maximum certificate age for the Subordinate CA, run the following
commands on the TFS-CA01 server:

1. To define the maximum age of any certificate that the Subordinate CA is capable of
issuing, run the following commands from an elevated PowerShell prompt:

certutil.exe -setreg CA\ValidityPeriodUnits 1

certutil.exe -setreg CA\ValidityPeriod "Years"

2. Restart the Active Directory Certificate Services service to apply the configuration:

net stop CertSvc

net start CertSvc

Subordinate CA Setup | 183

 3. Close the PowerShell prompt.
Once the maximum age for certificates has been configured on the Subordinate
Certificate Authority, you can proceed to modifying the CertEnroll virtual directory
settings, which is used for certificate deployment.

Modify the CertEnroll Virtual Directory

Before the Subordinate CA CDP and AIA Configuration can be added to the Subordinate
certificate, the CertEnroll folder in IIS will need to have directory browsing enabled to
allow for proper certificate file distribution. This setting is not enabled by default when
the directory is created during the Active Directory Certificate Services configuration.
This requirement is similar to the CertData virtual directory that was created earlier, and
that if access to the CertEnroll directory is restricted, there will be issues with accessing
the Base CRL and Delta CRL files. This can cause issues with validating the overall status
of the PKI, and users will not be able to access the necessary CRL information.
There are two methods for modifying the CertEnroll virtual directory on the TFS-CA01
server, one using the IIS Manager and the other using the command line. Only one
method for modifying the CertEnroll folder is needed.

Modify the CertEnroll Virtual Directory - GUI Configuration

To modify the CertEnroll directory in IIS, perform the following steps on the TFS-CA01
server using the Internet Information Services (IIS) Manager:
1. Open the Internet Information Services (IIS) Manager (inetmgr.exe) console:

184 | Practical Guide to PKI with Windows Server

2. On the Connections pane, expand TFS-CA01, then expand Sites and expand Default
Web Site:

3. In the Connections pane, under the Default Web Site, ensure the CertEnroll virtual
directory is selected:

Subordinate CA Setup | 185

 4. In the CertEnroll pane, double-click on Directory Browsing.
5. In Actions pane click Enable:

6. Close the Internet Information Services (IIS) Manager console.

Once the directory browsing option has been enabled on the CertEnroll directory, you can
then proceed to configuring auditing on the Subordinate CA.

Modify the CertEnroll Virtual Directory - CLI Configuration

Alternatively, you can enable directory browsing on the CertEnroll virtual directory using
the command line instead of using the Internet Information Services (IIS) Manager:
1. Open an elevated Command prompt.
2. Change to the correct directory by entering the following command:

cd C:\Windows\System32\inetsrv\

3. Run the following command to enable Directory Browsing on the CertEnroll virtual
directory:

appcmd.exe set config "Default Web Site/CertEnroll" ^

/section:directoryBrowse /enabled:true

4. Close the Command prompt.

Once the directory browsing option has been enabled on the CertEnroll directory, you can
then proceed to configuring auditing on the Subordinate CA.

186 | Practical Guide to PKI with Windows Server

Modify the CertEnroll Virtual Directory - Validation
You can test that the CertEnroll directory is accessible by opening the web browser on the
TFS-CA01 server. Open the following address in a web browser on the TFS-CA01 server:

http://pki.corp.tfslabs.com/CertEnroll/

The contents of the CertEnroll folder should be displayed in the browser:

Figure 5.11.1: The CertEnroll folder contains the Subordinate CA certificate as well as the
Subordinate CRL files. This includes the Base CRL and Delta CRL files.

To ensure that double escaping has been correctly enabled on the IIS server, you should
be able to download all files that are listed in the CertEnroll directory. If the files are not
able to be downloaded, especially the TFS Labs Enterprise CA+.crl file, that means that
double escaping was not correctly enabled on the IIS server.

Unlike the Root CA certificate and CRL files, the contents of the CertEnroll folder are
automatically updated whenever there are updates to it through Active Directory
Certificate Services. There is no need to manually update the contents of the CertEnroll
folder, as it is completely managed through Active Directory Certificate Services
whenever a certificate needs to be revoked.

Subordinate CA Setup | 187

Enable Auditing on the Subordinate CA
Auditing is not necessary on servers that are running Active Directory Certificate Services
to function correctly, but it is highly recommended for best practices, and in some cases
for compliance purposes. Auditing on these servers will write logs to the Windows Event
Log on the local server under the following circumstances:

• Whenever a certificate is issued.

• Whenever a certificate is revoked.
• Whenever the Certificate Authority configuration is modified.
• Whenever the Certificate Archive Keys are created and retrieved.
• Whenever administrative tasks such as starting and stopping the Active Directory
Certificate Services service is initiated.

To configure auditing on the Subordinate Certificate Authority, perform the following

steps on the TFS-CA01 server:

1. Open an elevated PowerShell prompt on the TFS-CA01 server.

2. Enable the options to audit Success and Failure attempts on the Audit object access
setting in the Local Security Policy by running the following command:

auditpol.exe /set /category:"Object Access" `

/failure:enable /success:enable

3. Enable auditing for all events on the Certificate Authority by running the following
command:

certutil.exe -setreg CA\AuditFilter 127

4. Restart the Active Directory Certificate Services service to apply the changes:

net stop CertSvc

net start CertSvc

5. Close the PowerShell prompt.

Once auditing has been enabled on the Subordinate Certificate Authority, you can now
proceed to configuring the CDP and AIA on the Subordinate CA.

Active Directory Certificate Services Auditing

With auditing enabled for Active Directory Certificate Services, events that are
enabled for auditing will be logged to the Windows Event Viewer. These events
can be viewed through the Event Viewer Console (eventvwr.msc).

There are 31 Active Directory Certificate Services related events that can be
logged in the Windows Event Viewer with an Event ID between 4868 and 4898.

188 | Practical Guide to PKI with Windows Server

Subordinate CA CDP and AIA Configuration
Before the Subordinate Certificate Authority can be properly configured, the Certificate
Revocation List needs to be configured on the Subordinate Certificate Authority.

The CRL files that are provided by the Root CA are distributed with the Subordinate CA.
This is because the Root CA is not available on the network since it is always offline, so
there is no way for clients to access the files needed for the TFS Labs domain. This is not
needed as the Subordinate CA is always online and managed, so those workarounds are
not required.

There are multiple locations where the CDP and AIA locations are used for the
Subordinate Certificate Authority:

• Local file system (used by the TFS-CA01 server)

• LDAP and Active Directory
• HTTP (to the TFS-CA01 server using http://pki.corp.tfslabs.com/CertEnroll/)

The CDP and AIA configuration on the Subordinate Certificate Authority can be performed
using the Certification Authority console or through the command line using PowerShell.

Subordinate CA CDP and AIA Configuration - GUI Configuration

To configure CDP and AIA on the Subordinate Certificate Authority using the Certification
Authority console, perform the following steps on the TFS-CA01 server:

1. Open the Certification Authority console (certsrv.msc) on the TFS-CA01 server:

Subordinate CA Setup | 189

 2. Right-click on TFS Labs Enterprise CA server and select Properties:

3. Select the Extensions tab, verify that the CRL Distribution Point (CDP) extension is
selected under the Select extension field, and click the Add button:

190 | Practical Guide to PKI with Windows Server

 4. On the Add Location window, under the Location field, enter the following address
and click the OK button:

http://pki.corp.tfslabs.com/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

5. On the Extensions tab, verify that the Include in CRLs. Clients use this to find Delta
CRL locations. and Include in the CDP extension of issued certificates options are
selected for the location that was just entered.
6. Select the file://<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix>
<DeltaCRLAllowed>.crl list item and click the Remove button. Click the Yes button
to confirm that you want to remove the location.
7. On the Extensions tab, verify that under the Selection extension field, the Authority
Information Access (AIA) extension is selected, and click the Add button:

8. On the Add Location window, under the Location field, enter the following address
and click the OK button:

http://pki.corp.tfslabs.com/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt

9. On the Extensions tab, verify that the Include in the AIA extension of issued certificates
option is selected for the location that was just entered.
10. Select file://<ServerDNSName>/CertEnroll/<ServerDNSName>_<CaName>
<CertificateName>.crt from the list and click the Remove button. Click the Yes button
to confirm that you want to remove the location.

Subordinate CA Setup | 191

 11. Click the OK button to commit the changes.
12. On the Certification Authority window, when prompted to restart Active Directory
Certificate Services, click the Yes button.
13. Verify that the settings are correct by running the following commands in an elevated
PowerShell prompt:

certutil.exe -getreg CA\CRLPublicationURLs

certutil.exe -getreg CA\CACertPublicationURLs

192 | Practical Guide to PKI with Windows Server

 14. In the Certification Authority Console, expand the TFS Labs Enterprise CA, right-click
on Revoked Certificates under TFS Labs Enterprise CA and select All Tasks > Publish:

15. On the Publish CRL window, verify that New CRL is selected and click the OK button:

16. Close the Certification Authority console.

Once the CRL settings for the Subordinate CA have been configured, you can proceed to
configuring the CPS document for the TFS Labs domain.

Subordinate CA Setup | 193

Subordinate CA CDP and AIA Configuration - CLI Configuration
To configure CDP and AIA on the Subordinate Certificate Authority using PowerShell,
perform the following steps on the TFS-CA01 server:

1. Open an elevated PowerShell prompt.

2. Run the following command to configure the CDP settings for the Subordinate Certificate
(execute this command as a single line with no breaks):

certutil.exe -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\

CertSrv\CertEnroll\%3%8%9.crl\n79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=
Public Key Services,CN=Services,%6%10\n0:http://%1/CertEnroll/%3%8%9.crl\
n6:http://pki.corp.tfslabs.com/CertEnroll/%3%8%9.crl"

3. Run the following command to configure the AIA settings for the Subordinate Certificate
(execute this command as a single line with no breaks):

certutil.exe -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\

CertSrv\CertEnroll\%1_%3%4.crt\n3:ldap:///CN=%7,CN=AIA,
CN=Public Key Services,CN=Services,%6%11\n0:http://%1/CertEnroll/
%1_%3%4.crt\n2:http://pki.corp.tfslabs.com/CertEnroll/%1_%3%4.crt"

4. Restart the Active Directory Certificate Services service to apply the changes:

net stop CertSvc

net start CertSvc

5. To publish the CRL, run the following command:

certutil.exe -crl

6. Close the elevated PowerShell Prompt.

There are two commands that can be run to verify that the CDP and AIA settings were
successfully applied to the Subordinate CA. To verify the CRL settings that were just
applied, run the following command:

certutil.exe -getreg CA\CRLPublicationURLs

To verify the AIA settings that were just applied to the Subordinate CA, run the following
command:

certutil.exe -getreg CA\CACertPublicationURLs

Once the CRL settings for the Subordinate CA have been configured, you can proceed to
configuring the CPS document for the TFS Labs domain.

194 | Practical Guide to PKI with Windows Server

Certification Practice Statement Document
At the time of the Active Directory Certificate Services role configuration for the
Certificate Authority, the CAPolicy.inf files specified the location for a Certification
Practice Statement (CPS). The CPS is a document that is available to users who are
using the Certificate Authority to inform them of important policies regarding the
Certificate Authority.

The CPS document varies for every organization, so a placeholder will be put in place
which can be updated later to ensure that the Certificate Authority meets any compliance
standards that may be required. This is especially important in industries with strict
requirements (such as financial services), so having a CPS in place from day one can
alleviate a lot of issues in the future. There are several important items that should be
defined in a CPS document, and the IETF has published RFC 3647 which is used to set
the standards for a Certificate Policy Statement.

At the time of creation of the TFS Labs Certificate Authority on both the Root CA and the
Subordinate CA, the path to the CPS document was set. This path will be displayed
whenever any certificate that was issued by the TFS Labs Certificate Authority is
displayed. In the future, should a more detailed CPS document be required, this can be
remapped with IIS to go to another location.

To create the CPS document, perform the following steps on the TFS-CA01 server:

1. On the TFS-CA01 server, open Windows File Explorer (explorer.exe), then go to This
PC and then go to the C:\.
2. Open the C:\inetpub\wwwroot folder.
3. Create a file named cps.html (ensure the file extension is correct).
4. Copy the following text into the cps.html file, save it and close the file:

C:\inetpub\wwwroot\cps.html

<! DOCTYPE html >

< html >
< head >
< meta charset =" utf -8" >
< title > TFS Labs Certification Practice Statement </ title >
</ head >
< body >

<h1 > TFS Labs Certification Practice Statement </ h1 >

<p > The TFS Labs Certification Authority is internal only . </p >

<p > All issued certificates are for internal usage only . </p >

</ body >

</ html >

5. Close Windows File Explorer.

Subordinate CA Setup | 195

You can test that the CPS document is accessible by opening the web browser on the
TFS-CA01 server. Open the following address in a web browser on the TFS-CA01 server:

http://pki.corp.tfslabs.com/cps.html

The CPS placeholder document should be displayed in the web browser:

Figure 5.14.1: The CPS placeholder document can be modified at any time in the future
to fit the needs of an organization. This placeholder can be accessed through every
certificate that is issued by the TFS Labs Certificate Authority.

You can also get to the document by checking the certificate properties for any
Certificate issued by the TFS Labs Certificate Authority. If you open any certificate that
was issued by the TFS Labs Certificate Authority, there is a button called Issuer
Statement, which will provide a direct link to the CPS document. In the future, should you
want to use a different URL for accessing the CPS document, you can simply setup a
redirect within IIS to handle the request.

If there is an issue with the CPS document, it will not affect the normal operation of a
Certificate Authority. Keeping the CPS accessible and up to date should be a priority, as
users are able to access it so it should always be available.

Once the CPS document has been created, you can proceed to configuring the Windows
Firewall on the TFS-CA01 server.

196 | Practical Guide to PKI with Windows Server

Windows Firewall Configuration
The Windows Firewall is always enabled in Windows Server by default. To allow for the
necessary access to the TFS-CA01 server, there are several firewall rules that need to be
enabled to allow for connections to the server. There are a few ports that are used for
Active Directory Certificate Services on the TFS-CA01 server that need to be open for
everything to work correctly.

The correct firewall rules should be automatically enabled when the Active Directory
Certificate Services role is configured, but they should be checked to ensure that they are
opened before proceeding. Quickly validating the firewall rules now can save a lot of time
later should there be an issue with the Certificate Authority.

There are three firewall rules that need to be enabled on the TFS-CA01 server for Active
Directory Certificate Services to function correctly:

Firewall Rule Name Port Profile

File and Printer Sharing (Echo Request - ICMPv4-In) ICMP All
World Wide Web Services (HTTP Traffic-In) TCP/80 All
World Wide Web Services (HTTPS Traffic-In) TCP/443 All

To check if the firewall rules are enabled on the TFS-CA01 server, perform the following
steps:

1. Open the Windows Defender Firewall with Advanced Security console (wf.msc) on
the TFS-CA01 server:

Subordinate CA Setup | 197

 2. Under the Windows Defender Firewall with Advanced Security on Local Computer,
click on Inbound Rules.

3. For each of the firewall rules listed above, perform the following steps:
(a) Right-click on the firewall rule and select the Properties option to open the Rule
Properties window.
(b) On the General tab, select the option for Enabled.
(c) On the Advanced tab, ensure that the options for Domain, Private and Public
are selected.
(d) Click on the Apply button to apply the changes and then click the OK button to
close the window.
4. Close the Windows Defender Firewall with Advanced Security console.

Once the Windows Firewall has been correctly configured, you can proceed to adding the
Root CA to Active Directory.

Disabling the Windows Firewall

It is extremely bad practice to disable the Windows Firewall, even within an

internal network. Disabling the Windows Firewall will increase the attack surface
on any server, and for best practices you should leave the Windows Firewall
enabled. Never assume that because a server is internal with no externally facing
ports that is completely safe from threats.

If you are using a third-party firewall solution for the server, then it is possible for
the Windows Firewall to be automatically disabled as a result. If there is a
software firewall enabled on your servers, then you are following best practices.

198 | Practical Guide to PKI with Windows Server

Add the Root CA to Active Directory
Since the TFS-ROOT-CA server is an Offline CA and there are no network connections
from Active Directory to that server, Active Directory is not aware that there is another
Certificate Authority in the TFS Labs domain. It is aware that there is a Standalone CA in
the Certificate Authority hierarchy, but that is all that it knows. The Enterprise CA
automatically adds itself to Active Directory when it is configured, but there is a manual
step that is required to add the Root Certificate Authority to Active Directory.

This step will ensure that workstations that are a member of the TFS Labs domain will
trust the Root Certificate Authority. Devices that are not a part of the Active Directory
domain will still need to have the Root certificate installed for it to be trusted.

The Root certificate and CRL are already located on the TFS-CA01 server and can be
found in the C:\CertData folder. This reduces the amount of configuration that is required
to add the Root CA to Active Directory.

To add the Root CA and Root CRL to the TFS Labs domain, perform the following steps
on the TFS-CA01 server:

1. Open an elevated PowerShell prompt on the TFS-CA01 server.

2. Run the following command to add the TFS Labs Certificate Authority to Active
Directory:

certutil.exe -dspublish `
-f "C:\CertData\TFS-ROOT-CA_TFS Labs Certificate Authority.crt" RootCA

Subordinate CA Setup | 199

 3. Run the following command to add the Root CA to the Certificate Store in Active
Directory:

certutil.exe –addstore `
–f root "C:\CertData\TFS-ROOT-CA_TFS Labs Certificate Authority.crt"

4. Run the following command to add the Root CRL to the Certificate Store in Active
Directory:

certutil.exe –addstore `
–f root "C:\CertData\TFS Labs Certificate Authority.crl"

5. Close the PowerShell prompt.

200 | Practical Guide to PKI with Windows Server

To verify that the Root CA was successfully added to Active Directory, you can check the
status on the TFS-DC01 server:

1. Open the Active Directory Sites and Services (dssite.msc) console on the TFS-DC01
server.
2. Ensure that the Active Directory Sites and Services node is selected, click on the
View menu and select the Show Services Node option.
3. Expand the Active Directory Sites and Services > Services > Public Key Services
node.
4. Open the CDP > RootCA folder to find the CRL:

5. Open the Certification Authorities folder to find the Root CA:

6. Close the Active Directory Sites and Services console.

Subordinate CA Setup | 201

Now that the Root CA has been added to Active Directory, you can proceed to verifying
the PKI infrastructure on the TFS Labs domain.

Verify PKI Infrastructure

Before continuing with the deployment of the Root and Intermediate certificates to the
TFS Labs domain and the OCSP role configuration, it is important to verify that there are
no issues with the Active Directory Certificate Services role on the TFS-CA01 server.
There is a tool available for Active Directory Certificate Services called Enterprise PKI,
which is used to validate a PKI in Windows Server. It conveniently lists all the certificates
and Certificate Revocation Lists that are part of the PKI and specifies whether they are
valid or not.
There are still additional items to be configured for the TFS Labs Certificate Authority, but
checking the overall status of the PKI at this stage can determine if there are any obvious
issues with the Certificate Authority. It will quickly determine if there are issues with the
CDP and AIA configurations, as well as the CRL files that have been published. At this
point in the overall configuration of the PKI, issues like this are much easier to correct
before more complex configurations are introduced.
Fixing these issues in a PKI that is already in production can be extremely difficult, as it
could result in downtime for the Certificate Authority.
To validate the PKI configuration for the TFS Labs Certificate Authority, perform the
following steps on the TFS-CA01 server:
1. On the TFS-CA01 server, open the Enterprise PKI console (pkiview.msc).
2. On the default window for the Enterprise PKI console, it should state that the status
of the TFS Labs Certificate Authority (V0.0) server is OK:

202 | Practical Guide to PKI with Windows Server

3. Under the Enterprise PKI node, click on the TFS Labs Certificate Authority (V0.0)
server. Check that the status of the CA Certificate, AIA Location #1 and CDP Location
#1 have the status of OK:

4. Under the Enterprise PKI node, click on the TFS Labs Enterprise CA (V0.0) server.
Check that the status of the CA Certificate, DeltaCRL Locations, AIA Locations and
CDP Locations have the status of OK:

5. Close the Enterprise PKI console.

Subordinate CA Setup | 203

If there are no issues with the PKI infrastructure configuration on the TFS Labs domain,
then the initial deployment of the TFS Labs Certificate Authority is now complete. With
an Enterprise CA, the TFS Labs Enterprise CA certificate should start to automatically
deploy to all Active Directory devices in the TFS Labs domain.

Subordinate CA Server Restart

It is advisable to restart the Enterprise CA server before continuing with any additional
configuration of the TFS Labs Certificate Authority. This will ensure that all changes to
the Enterprise CA have been successfully committed and applied to the TFS Labs
domain.

Subordinate CA Next Steps

Now that the Subordinate certificate has been successfully created, it is now time to
deploy the Root and Subordinate certificates within the TFS Labs domain. The next
chapter will demonstrate how to use Group Policy to automatically deploy the certificates
to the TFS Labs domain.

204 | Practical Guide to PKI with Windows Server

Chapter 6 - Deploy Root and
Subordinate Certificates

Once the Root and Subordinate certificates have been created, those certificates will
need to be deployed to the TFS Labs domain for those certificates to be utilized. With an
Enterprise CA running with Active Directory Certificate Services, any Subordinate
certificates will automatically deploy to any server or workstation within the Active
Directory domain.

Since the TFS Labs Certificate Authority uses an Offline CA, this means that the Root
certificate will not be automatically deployed to the domain, since there is no network
connection on that server and it is not an Enterprise CA. Fortunately, deploying the Root
certificate is a trivial process since the use of Group Policy makes certificate deployment
easy to perform in Active Directory.

The Group Policy Objects that are created in this chapter will be used in later steps for
certificate auto-enrollment and for deploying the OCSP settings to the TFS Labs domain.

This chapter will focus on the deployment of the Root and Subordinate certificates to the
TFS Labs domain. This deployment will be automatic using Group Policy which will allow
for rapid deployment to domain servers and workstations.

Deploy Root and Subordinate Certificates | 205

Prepare the Root and Subordinate Certificates
The easiest method to deploy the certificates to your organization is to use Group Policy
to deploy the certificates automatically to your workstations and servers in the TFS Labs
domain.

As a result of the deployment that has been completed so far, the Root and Subordinate
certificates for the TFS Labs domain are already located on the TFS-CA01 server in two
different folders:

• Root certificate - C:\CertData\

– TFS-ROOT-CA_TFS Labs Certificate Authority.crt
• Subordinate certificate - C:\Windows\System32\certsrv\CertEnroll\
– TFS-CA01.corp.tfslabs.com_TFS Labs Enterprise CA.crt

Both certificates are DER encoded and are available for usage immediately. They can be
installed through Active Directory, either manually by users or automatically by Group
Policy. To get the two certificate files ready for distribution on the TFS Labs domain,
perform the following steps on the TFS-CA01 and TFS-DC01 servers:

1. On the C:\ drive on the TFS-CA01 server, create a folder called Certificates
(C:\Certificates).
2. On the TFS-CA01 server, copy the C:\CertData\TFS-ROOT-CA_TFS Labs Certificate
Authority.crt file to the (C:\Certificates) folder.
3. On the TFS-CA01 server, copy the C:\Windows\System32\certsrv\CertEnroll\TFS-CA01.
corp.tfslabs.com_TFS Labs Enterprise CA.crt file to the (C:\Certificates) folder.
4. Rename the certificate files to the following on the TFS-CA01 server in the
(C:\Certificates) folder:
• TFS-ROOT-CA_TFS Labs Certificate Authority.crt file to TFS Labs Certificate
Authority.crt
• TFS-CA01.corp.tfslabs.com_TFS Labs Enterprise CA.crt file to TFS Labs Enterprise
CA.crt
5. On the C:\ drive on the TFS-DC01 server, create a folder called Certificates
(C:\Certificates).
6. Copy the contents of the C:\Certificates folder on the TFS-CA01 server to the
C:\Certificates on the TFS-DC01 server.

Once the certificates have been successfully renamed and copied, you can inspect them
to ensure that there are no issues with either of the certificates:

206 | Practical Guide to PKI with Windows Server

Root Certificate - TFS Labs Certificate Authority

Subordinate Certificate - TFS Labs Enterprise CA

Deploy Root and Subordinate Certificates | 207

After the Root and Subordinate certificates have been successfully copied and renamed,
they can now be deployed to the TFS Labs domain using Group Policy.

Converting Certificate Types

The certificates that are currently being deployed to the TFS Labs domain are in
the DER Encoded format, but what if you want to deploy them in the Base-64
Encoded format? You have the option of exporting those certificates in that
format, but there is a faster method to convert certificates using the certutil.exe
utility.

To convert from DER Encoded format to Base-64 Encoded format, run the
following command:

certutil.exe -encode der-certificate.cer base64-certificate.cer

To convert from Base-64 Encoded format to DER Encoded format, run the
following command:

certutil.exe -decode base64-certificate.cer der-certificate.cer

There should not be any issues with converting between certificate formats using
the certutil.exe utility. If you convert from one format to another, and then back
again, the certificate contents and file sizes will be identical.

Deploy the Root and Subordinate Certificates to the Domain

For the deployment of the Root and Subordinate certificates to the TFS Labs domain, it
will be applied to the root of TFS Labs OU in the TFS Labs Active Directory domain that
was created earlier. This is to ensure that best practices are being applied for Group
Policy in an Active Directory domain.

There are default Group Policy Objects available in an Active Directory domain, but it is
advised to create your own for your specific purposes and not modify the Default Domain
Policy. This way you have complete control over the Group Policy Objects that are being
assigned to the domain.

If you are using Active Directory Certificate Services in an Active Directory domain, you
will find that the Subordinate certificate is already deployed to all the workstations and
servers in the domain since the Subordinate CA is an Enterprise CA.

To deploy the Root and Subordinate certificates using Group Policy, perform the
following steps on the TFS-DC01 server:

208 | Practical Guide to PKI with Windows Server

1. Open the Group Policy Management console (gpmc.msc) on the TFS-DC01 server:

2. In the Group Policy Management console tree, expand Forest: corp.tfslabs.com,

then expand Domains, then expand the corp.tfslabs.com domain and then select
the TFS Labs OU:

Deploy Root and Subordinate Certificates | 209

 3. Right-click on the TFS Labs OU and select the option for Create a GPO in this domain,
and Link it here...:

4. On the New GPO window, under the Name, enter TFS Labs Certificates and click the
OK button.
5. Under the TFS Labs OU, the TFS Labs Certificates OU will now be listed:

210 | Practical Guide to PKI with Windows Server

6. Right-click on the TFS Labs Certificates GPO and select the Edit option:

7. The Group Policy Management Editor window for the TFS Labs Certificates GPO
should open:

Deploy Root and Subordinate Certificates | 211

 8. In the Group Policy Management Editor window, open the Computer Configuration
> Policies > Windows Settings > Security Settings > Public Key Policies node:

9. Right-click on the Trusted Root Certification Authorities folder and select the Import...
option:
(a) On the Welcome to the Certificate Import Wizard window, click the Next button
to continue.
(b) On the File to Import window, enter C:\Certificates\TFS Labs Certificate Authority.crt
as the File name and click the Next button to continue.
(c) On the Certificate Store window, ensure that the Trusted Root Certification
Authorities store is selected and click the Next button to continue.
(d) On the Completing the Certificate Import Wizard screen, click the Finish button.
(e) On the Certificate Import Wizard prompt, click the OK button to complete the
import of the Root certificate.
10. Right-click on the Intermediate Certification Authorities folder and select the Import...
option:
(a) On the Welcome to the Certificate Import Wizard window, click the Next button
to continue.
(b) On the File to Import window, enter C:\Certificates\TFS Labs Enterprise CA.crt
as the File name and click the Next button to continue.
(c) On the Certificate Store window, ensure that the Intermediate Certification Authorities
store is selected and click the Next button to continue.
(d) On the Completing the Certificate Import Wizard screen, click the Finish button.
(e) On the Certificate Import Wizard prompt, click the OK button to complete the
import of the Subordinate certificate.
11. Close the Group Policy Management console.

212 | Practical Guide to PKI with Windows Server

Once the Root and Subordinate certificates have been added to Group Policy, it will now
be automatically applied to the workstations and servers in the TFS Labs domain. It may
take some time for the Group Policy Object to be applied to the workstations and servers
in the TFS Labs domain, but if you want to test it immediately, open a Command Prompt
on any Windows device on the TFS Labs domain and run the following command:

gpupdate.exe /force

You can check the Local Machine Certificate Store on any workstation or server in the
TFS Labs domain to ensure that both certificates are present on those devices.

Duplicate Certificates

When deploying certificates to the domain using Group Policy it is entirely

possible that you will see duplicate certificates in the Certificate Store. This is due
to the way that Windows manages the Certificate Store and the way that it
displays certificates. Normally it pulls the certificates stored on the device and
puts all that information into the Certificate Store.

Root Certificate Deployment

Ensure that in a production network the certificates folder that is created on the
Domain Controller is present on all Domain Controllers. Group Policy will require
access to this folder and the contents of it, and if it is missing on a Domain
Controller the Root certificate will not be deployed correctly.

Default Domain Policy GPO

The TFS Labs Certificates GPO was created to prevent modifications to the
Default Domain Policy GPO, which is created at the time of any Active Directory
domain creation. It is bad practice to add anything to the Default Domain Policy,
as this GPO should only be used for essential account policies (such as
passwords and account lockouts), and it is applied to the root of the entire Active
Directory domain. The Default Domain Policy is applied to the root of the Active
Directory domain to ensure that all users and computers receive the policy.

Creating Group Policy Objects and applying them to specific OUs is preferred, as it
ensures that you as the Administrator are aware of everything that is being
applied to your Active Directory domain. It ensures that you are also correctly
targeting your Group Policy Objects to the correct users and workstations.

Once the new Group Policy Object has been created, you can proceed to deploying the
Root certificate to the TFS-CA01 Domain Controller.

Deploy Root and Subordinate Certificates | 213

Deploy the Root Certificate to the Domain Controller
As part of deploying the Root and Subordinate certificates to the TFS Labs domain, there
is an exception for any of the Domain Controllers that are present in the Active Directory
domain. By default, all Domain Controllers are placed in their own OU when they are
promoted to a Domain Controller. An Enterprise CA will automatically deploy the
Subordinate certificate to all devices in an Active Directory domain, but not the Root
certificate. Since the TFS-ROOT-CA server is offline, there is no way to automatically
deploy the certificate to the domain. There are two options to deploy the Root certificate
to the Domain Controllers:
• Automatic deployment of the certificate with Group Policy.
• Manual installation of the certificate on each Domain Controller.
The option that you choose is entirely up to you, and if the Root certificate is properly
deployed to the Domain Controllers you should not have any issues. To deploy the Root
certificate to the Domain Controllers using Group Policy, perform the following steps on
the TFS-DC01 server:
1. Open the Group Policy Management console (gpmc.msc) on the TFS-DC01 server.
2. In the Group Policy Management console tree, expand Forest: corp.tfslabs.com,
then expand Domains, then expand the corp.tfslabs.com domain and then select
the Domain Controllers OU.
3. Right-click on the Domain Controllers OU and select the option for Link an Existing
GPO....
4. On the Select GPO window, select the TFS Labs Certificates GPO and click the OK
button.
To deploy the Root certificate to the Domain Controllers manually, perform the following
steps on the TFS-DC01 server:
1. Open Windows File Explorer (explorer.exe) on the TFS-DC01 server.
2. Go to This PC and open the C:\ drive.
3. Open the Certificates folder, right-click on TFS Labs Certificate Authority.crt and
select the Install Certificate option.
4. On the Welcome to the Certificate Import Wizard window, ensure that Store Location
is set to Local Machine and click the Next button to continue.
5. On the Certificate Store window, select the option for Certificate store and click the
Browse... button.
6. On the Select Certificate Store window, select the Trust Root Certification Authorities
Store, and click the OK button.
7. On the Certificate Store window, click the Next button.
8. On the Completing the Certificate Import Wizard window, click the Finish button.
9. On the Certificate Import Wizard prompt, click the OK button to complete the import
of the certificate.
Once the Root certificate has been deployed to the TFS-DC01 server, the certificate chain
on that server will be complete. At this point, the TFS-DC01 server will be enabled for
LDAPS as it now has valid certificates to accommodate that feature.

214 | Practical Guide to PKI with Windows Server

 Default Domain Controllers Policy GPO

It is best practice to never modify the Default Domain Controller Policy as this
policy contains important security information for the Domain Controllers. These
settings are critical to ensure that proper audit, security, and user settings are
correctly applied, and if modified incorrectly can cause login failures within an
Active Directory domain.

Because of the importance of the Default Domain Controllers Policy, and changes
that you intend to make to a Domain Controller should always be done in a
separate Group Policy Object.

Internal Certificate File Deployment Folder

It is possible for you to have non-Windows clients in your network that may require
access to the Root and Subordinate certificates for the TFS Labs domain. A common
scenario is Linux servers that are running a web server that requires SSL and will need
the Root and Subordinate certificates to apply their web certificates correctly. Another
scenario is with iOS and Android devices that require the certificates to access internal
services. Typically, these devices will receive the certificates using a Mobile Device
Management solution, but that is not always available in some organizations. A folder on
the TFS-CA01 server was created earlier that can be used for this purpose.

This step is entirely optional, and not completing it does not affect the deployment of
Active Directory Certificate Services.

If you would like to create an internal website for deploying the Root and Subordinate
certificates for the TFS Labs domain, all that is needed is to add a new virtual directory in
IIS. This configuration can be completed using the IIS Manager or with the command line.

MDM Solutions

In most organizations with extensive mobile device deployments, it is typical to

have an MDM solution in place to manage tasks such as certificate deployment.
In this case, the domain is too small to warrant such a solution, so it is being
performed manually. The reason that a dedicated folder on the Subordinate CA
was created earlier was to facilitate such scenarios where an MDM solution was
not available.

Certificate Private Keys

Ensure that any certificates that are included in this folder do not include any
private keys. If you accidentally include the private keys in these certificates, you
will compromise the integrity of your Certificate Authority. If you accidentally
publish a certificate with the private key, you should strongly consider revoking it.

Deploy Root and Subordinate Certificates | 215

Internal Certificate File Deployment Folder - GUI Configuration
To create the virtual directory using Internet Information Services (IIS), perform the
following steps on the TFS-CA01 server:

1. Open the Internet Information Services (IIS) Manager (inetmgr.exe) console on the
TFS-CA01 server.
2. On the Connections pane, expand TFS-CA01, then expand Sites and then select
Default Web Site.
3. Right-click on Default Web Site and select Add Virtual Directory....
4. On the Add Virtual Directory window, in the Alias field, enter Certificates. For the
Physical path, enter C:\Certificates and then click OK.
5. In the Connections pane, under the Default Web Site, ensure the Certificates virtual
directory is selected.
6. In the Certificates Home pane, double-click on Directory Browsing.
7. In the Actions pane, click the Enable button.
8. Close the Internet Information Services (IIS) Manager console.

Once the certificates virtual directory has been successfully configured, you can move on
to validate the virtual directory.

Internal Certificate File Deployment Folder - CLI Configuration

Alternatively, you can create the certificates virtual directory using the command line
instead of using the Internet Information Services (IIS) Manager:

1. Open an elevated Command prompt on the TFS-CA01 server.

2. Change to the correct directory by entering the following command:

cd C:\Windows\System32\inetsrv\

3. Run the following command to create the CertData virtual directory in IIS:

appcmd.exe add vdir /app.name:"Default Web Site/" ^

/path:/Certificates /physicalPath:C:\Certificates

4. Run the following command to enable Directory Browsing on the CertData Virtual
Directory:

appcmd.exe set config "Default Web Site/Certificates" ^

/section:directoryBrowse /enabled:true

5. Close the Command prompt.

Once the certificates virtual directory has been successfully configured, you can move on
to validate the virtual directory.

216 | Practical Guide to PKI with Windows Server

Internal Certificate File Deployment Folder - Validation
You can test that the Certificates virtual directory is accessible by opening the web
browser on the TFS-CA01 server. Open the following address in a web browser on the
TFS-CA01 server:

http://pki.corp.tfslabs.com/Certificates/

The contents of the Certificates folder should be displayed in the browser:

Figure 6.4.1: The Certificates folder contains the Root and Subordinate certificates in a
format that can be easily deployed across multiple platforms.

Once the virtual directory has been successfully configured and tested, you can move on
to the next chapter.

Deploy Root and Subordinate Certificates Next Steps

Now that the Root and Subordinate certificates have been deployed within the Active
Directory domain, the framework is now in place to setup OCSP for revoking certificates
and to deploy more complex Certificate Templates to the TFS Labs domain.

Deploy Root and Subordinate Certificates | 217

Chapter 7 - Online Responder Role
Configuration

The ability to issue and manage certificates is the primary purpose of a Certificate
Authority, but if the integrity of any of those certificates is ever compromised then it is up
to an administrator to revoke those certificates since they can no longer be trusted.
Typically, a Certificate Revocation List is used to revoke certificates, but a CRL is not
always updated often enough. The Online Certificate Status Protocol is a service that is
available that speeds up the revocation of certificates and reduces overhead on the CRL.
In Active Directory Certificate Services, this feature is implemented as the Online
Responder role.

For large environments using Active Directory Certificate Services, the Online Responder
role is convenient because it allows for rapid revocation of certificates. In smaller
environments the Online Responder role is not always needed, so this chapter is optional
if you do not believe it is required for your organization. Fortunately, the Online
Responder role can be added to Active Directory Certificate Services at any time in the
future should it be required.

This chapter will focus on installing and configuring the Online Responder role within
Active Directory Certificate Services. The OCSP feature simplifies the revocation of
certificates and makes it much faster to revoke a certificate that should no longer be
trusted.

Online Responder Role Configuration | 219

Add the Online Responder Role
The Online Responder role is a component of Active Directory Certificate Services that
can be added as an additional feature within that role. It can be added using Server
Manager or through the command line with PowerShell, you can decide which one you
would like to use. You only need to choose one method for adding the Online Responder
role on the TFS-CA01.

Add the Online Responder Role - GUI Installation

To add the Online Responder role on the TFS-CA01 server using the Server Manager
console, perform the following steps:

1. Open the Server Manager console (servermanager.exe), click on the Manage menu,
and click on Add Roles and Features to start the installation wizard:

2. On the Before You Begin screen, click the Next button to continue.
3. On the Installation Type screen, select the option for Role-based or feature-based
installation and click the Next button to continue.
4. On the Server Selection screen, verify that the TFS-CA01.corp.tfslabs.com server is
selected and click Next to continue.

220 | Practical Guide to PKI with Windows Server

 5. On the Server Roles screen, expand the Active Directory Certificate Services option
and select the Online Responder role:

6. The installation wizard will ask to install any additional features required for the
Active Directory Certificate Services role. Select the option to Include management
tools (if applicable) to install the management tools for the role. Click the Add
Features button to continue.
7. On the Server Roles screen, click the Next button to continue.
8. On the Features screen, click the Next button to continue.
9. On the Confirm installation selections screen, select the option to Restart the destination
server automatically if required.
10. When prompted with a warning about restarting the server, click the Yes button.
11. On the Confirm installation selections screen, click the Install button to continue.
12. Once the installation is completed, click the Close button.
Once the Online Responder role has been added to the TFS-CA01 server, you can proceed
to enabling it for the TFS Labs domain.

Add the Online Responder Role - CLI Installation

The Online Responder role can be added using PowerShell, which requires much fewer
steps to accomplish. Perform the following steps on the TFS-CA01 server:
1. Open an elevated PowerShell prompt.
2. Run the following command to add the Online Responder role and the required
Management Tools:

Add-WindowsFeature Adcs-Online-Cert, RSAT-Online-Responder

Online Responder Role Configuration | 221

 3. Once the Online Responder role has been added, you can close the PowerShell prompt.

Once the Online Responder role has been added to the TFS-CA01 server, you can proceed
to enabling it for the TFS Labs domain.

Enable the Online Responder Role

Once the Online Responder role has been added to the TFS-CA01 server, it will need to be
enabled before it can be configured. It can be enabled using Server Manager or through
the command line with PowerShell, you can decide which one you would like to use. You
only need to choose one method for enabling the Online Responder role.

Enable the Online Responder Role - GUI Configuration

To enable the Online Responder role on the TFS-CA01 server using the Server Manager
console, perform the following steps:

1. To begin the configuration of the Online Responder Service, open the Server Manager
console (servermanager.exe). Click the Notifications icon in the upper-right hand
corner and click the Configure Active Directory Certificate Services on the destination
server link in the Post-deployment Configuration box:

222 | Practical Guide to PKI with Windows Server

2. On the Credentials screen, verify that the Administrator credentials are set to a Domain
Administrator account and click the Next button to continue. If you do not use a
Domain Administrator account, then the installation will not allow you to install the
Online Responder Role correctly:

3. On the Role Services screen, select the option for Online Responder and click Next
to continue:

Online Responder Role Configuration | 223

 4. On the Confirmation screen, click on the Configure button to continue:

5. Once the installation is completed, click the Close button:

Once the Online Responder role has been enabled on the TFS-CA01 server, you can
proceed to adding the OCSP URL to the Subordinate CA.

224 | Practical Guide to PKI with Windows Server

Enable the Online Responder Role - CLI Configuration
The Online Responder role can be enabled using PowerShell, which requires much fewer
steps to accomplish:

1. Open an elevated PowerShell prompt.

2. Run the following command to enable the Online Responder role:

Install-AdcsOnlineResponder -Force

3. Once the Online Responder role has been enabled, you can close the PowerShell
prompt.

Once the Online Responder role has been enabled on the TFS-CA01 server, you can
proceed to adding the OCSP URL to the Subordinate CA.

Enable the Online Responder Role - Validation

Once the Online Responder role has been enabled, verify that the OCSP folder is present
in the IIS Manager console.

To do this, open the Internet Information Services (IIS) Manager console and expand the
TFS-CA01 > Sites > Default Web Site folder. The ocsp folder should be listed as one of
the available directories:

Online Responder Role Configuration | 225

If the OCSP folder is not present for whatever reason, run the following command in an
elevated PowerShell prompt to create it manually:

certutil.exe -vocsproot

The IIS service will need to be restarted afterwards if this command is run to apply the
changes. You can restart IIS by running the following command in an elevated
PowerShell prompt:

iisreset.exe

Once the Online Responder role has been enabled on the TFS-CA01 server, you can
proceed to adding the OCSP URL to the Subordinate CA.

Add the OCSP URL to the Subordinate CA

Once the Online Responder role has been installed, you will need to add the OCSP URL to
the AIA settings for the Subordinate CA. This can be configured using the Certification
Authority console or through the command line using PowerShell.

Add the OCSP URL to the Subordinate CA - GUI Configuration

The URL for OCSP can be added to the Subordinate CA certificate by performing the
following steps using the Certification Authority console on the TFS-CA01 server:
1. Open the Certification Authority console (certsrv.msc) on the TFS-CA01 server:

226 | Practical Guide to PKI with Windows Server

 2. In the console tree, right-click on TFS Labs Enterprise CA, and then select Properties.
3. On the TFS Labs Enterprise CA Properties window, click on the Extensions tab.
4. On the Extensions tab, under Select extension, select Authority Information Access
(AIA), and then click Add... button.
5. On the Add Location window, enter http://ocsp.corp.tfslabs.com/ocsp in the Location
field and then click the OK button.
6. With the http://ocsp.corp.tfslabs.com/ocsp location selected, check the Include in
the online certificate status protocol (OCSP) extension option and then click the OK
button (ensure that the Include in the AIA extension of issued certificates option is
not selected):

7. When prompted by the Certification Authority dialog box to restart Active Directory
Certificate Services, click Yes.
8. Close the Certification Authority console.

Once the OCSP URL has been added to the Subordinate CA, you can proceed to
configuring and publishing the OCSP Response Signing Certificate.

Online Responder Role Configuration | 227

Add the OCSP URL to the Subordinate CA - CLI Configuration
The URL for OCSP can be added to the Subordinate CA certificate by performing the
following steps using PowerShell on the TFS-CA01 server:

1. Open an elevated PowerShell prompt.

2. Run the following command to add the OCSP URL to the AIA configuration on the
TFS Labs Enterprise CA (execute this command as a single line with no breaks):

certutil.exe -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\

CertSrv\CertEnroll\%1_%3%4.crt\n3:ldap:///CN=%7,CN=AIA,
CN=Public Key Services,CN=Services,%6%11\n0:http://%1/CertEnroll/
%1_%3%4.crt\n2:http://pki.corp.tfslabs.com/CertEnroll/%1_%3%4.crt\n
32:http://ocsp.corp.tfslabs.com/ocsp"

3. Restart the Active Directory Certificate Services service to apply the changes:

net stop CertSvc

net start CertSvc

4. Once the Online Responder role has been configured, you can close the PowerShell
prompt.

Once the OCSP URL has been added to the Subordinate CA, you can proceed to
configuring and publishing the OCSP Response Signing Certificate.

Configure and Publish the OCSP Response Signing Certificate

The OCSP Response Signing certificate will be used by the Online Responder role to
manage the OCSP services for the organization. In Active Directory Certificate Services,
all Certificate Templates are stored in and managed by Active Directory.

To configure the OCSP Response Signing Certificate, perform the following steps on the
TFS-CA01 server:

228 | Practical Guide to PKI with Windows Server

1. Open the Certification Authority console (certsrv.msc) on the TFS-CA01 server:

2. Ensure that the TFS Labs Enterprise CA server is expanded in the console tree.
3. Right-click on the Certificate Templates folder and then click Manage:

Online Responder Role Configuration | 229

 4. The Certificate Templates console window will open and display the current Certificate
Templates that are stored in Active Directory.
5. In the main window, right-click on the OCSP Response Signing template and then
click Duplicate Template:

6. The Properties of New Template window will open for the Duplicated Certificate.
7. On the Compatibility tab, make the following changes in the Compatibility Settings
pane:
• Certification Authority - Windows Server 2016
• Certificate recipient - Windows 10 / Windows Server 2016
8. When the Resulting changes window appears, click the OK button to continue.
9. On the General tab, change the name of the Certificate Template from Copy of OCSP
Response Signing to TFS Labs OCSP Response Signing. The Validity period and
Renewal period times can remain at the default values.
10. On the Cryptography tab, make the following changes for the Cryptography settings:
• Provider Category - Key Storage Provider
• Algorithm name - RSA
• Minimum key size - 4096
• Request hash - SHA256
11. On the Security tab, select Authenticated Users and enable the Enroll permission.
12. On the Security tab, add the TFS-CA01 server and enable the Read and Enroll permissions.

230 | Practical Guide to PKI with Windows Server

 Security Permissions for Server Objects

There are a few extra steps required for adding server and computer objects
to the security settings as those objects are not searchable by default. To be
able to add a server object, perform the following steps to be able to search
for those objects:

(a) On the Security tab, click the Add... button.

(b) In the Select Users, Computers, Service Accounts, or Groups window,
click the Object Types... button.
(c) In the Object Types window, select the option for Computers and click
the OK button.
(d) In the Enter the object names to select field, enter TFS-CA01 and click
the Check Names button.
(e) Click the OK button to finish adding the server object.

13. Click OK to close the Properties of New Template window.

14. In the Certificate Templates console, the TFS Labs OCSP Response Signing Certificate
Template should be listed:

15. Close the Certificate Templates console.

Online Responder Role Configuration | 231

 16. In the Certification Authority console, right-click Certificate Templates, then select
New > Certificate Template to Issue:

17. In the Enable Certificate Templates window, select the TFS Labs OCSP Response
Signing Certificate Template and then click OK:

232 | Practical Guide to PKI with Windows Server

 18. In the Certificate Templates folder, the TFS Labs OCSP Response Signing Certificate
Template should now be listed:

19. Close the Certification Authority console.

Once the OCSP Response Signing certificate has been created and issued, you can
proceed to the revocation configuration on the TFS-CA01 server.

Revocation Configuration for the Online Responder Role

Once the OCSP Response Signing certificate has been configured for the TFS Labs
domain, the Online Responder role can now be configured on the TFS-CA01 server.

To perform the revocation configuration for the TFS Labs domain, complete the following
steps on the TFS-CA01 server:

Online Responder Role Configuration | 233

 1. Open the Online Responder Management console (ocsp.msc) on the TFS-CA01 server:

2. Right-click on Revocation Configuration and then click Add Revocation Configuration:

234 | Practical Guide to PKI with Windows Server

3. On the Getting started with adding a revocation configuration screen, click Next to
continue:

4. On the Name the Revocation Configuration screen, enter TFS Labs Enterprise CA
OCSP in the Name field, and then click Next to continue:

Online Responder Role Configuration | 235

 5. On the Select CA Certificate Location screen, ensure that Select a certificate for an
Existing enterprise CA is selected, then click Next to continue:

6. On the Choose CA Certificates screen, ensure that Browse CA certificates published

in Active Directory is selected, and then click Browse:

236 | Practical Guide to PKI with Windows Server

7. On the Select Certification Authority dialog box, ensure that TFS Labs Enterprise CA
is selected, and then click OK:

8. On the Choose CA Certificates screen, click the Next button to continue:

Online Responder Role Configuration | 237

 9. On the Select Signing Certificate screen, use the default options and then click Next
to continue. The TFS Labs OCSP Response Signing certificate should be selected
as the default option:

10. On the Revocation Provider screen, click the Provider... button:

238 | Practical Guide to PKI with Windows Server

11. On the Revocation Provider Properties window, for the LDAP location in the Base
CRLs pane, clear the Refresh CRLs based on their validity periods option. In the
Update CRLs at this refresh interval (min) field, enter 15 as the value:

12. On the Revocation Provider Properties window, for the HTTP location in the Base
CRLs pane, clear the Refresh CRLs based on their validity periods option. In the
Update CRLs at this refresh interval (min) field, enter 15 as the value, and then click
OK to close the window:

Online Responder Role Configuration | 239

 13. Click Finish to close the window and complete the configuration.
14. In the Online Responder Management console, expand the Array Configuration node
and then click on TFS-CA01.corp.tfslabs.com. Review the Revocation Configuration
Status in the middle pane to ensure there is a valid OCSP Response Signing certificate
present and the status reports as OK:

15. Click on the View Signing Certificate link to view the OCSP Certificate. Click OK to
close the Certificate:

240 | Practical Guide to PKI with Windows Server

 16. Close the Online Responder Management console.

Once the revocation configuration has been completed for the Online Responder role, you
can proceed to configure auditing for the Online Responder role.

Enable Auditing on the Online Responder

Auditing is not necessary on servers that are running the Online Responder role to
function correctly, but it is highly recommended for best practices, and in some cases for
compliance purposes. Auditing on these servers will write to the Windows Event Log on
the local server under the following circumstances:

• When the Online Responder configuration, or associated security settings is changed.

• When a request is made to the Online Responder.
• Whenever administrative tasks such as starting and stopping the Online Responder
service is initiated.

To configure auditing for the Online Responder role, perform the following steps:

1. Open the Online Responder Management console (ocsp.msc) on the TFS-CA01 server:

2. In the Actions Pane, select the Responder Properties option.

Online Responder Role Configuration | 241

 3. In the Online Responder Properties window, click on the Audit tab:

4. On the Audit tab, select all the auditing options and click the OK button:

5. Close the Online Responder Management console.

6. Restart the Active Directory Certificate Services Service to apply the changes.

Once auditing has been enabled for the Online Responder role, you can proceed to adding
the OCSP URL to Group Policy.

242 | Practical Guide to PKI with Windows Server

Online Responder Service Auditing

With auditing enabled for the Online Responder Service, events that are enabled
for auditing will be logged to the Windows Event Viewer. These events can be
viewed through the Event Viewer console (eventvwr.msc):

Opening one of the events will show more details on the Online Responder Service
details will give further details on that event:

There are 8 Online Responder Service events that can be logged in the Windows
Event Viewer with an Event ID between 5120 and 5127. Events are also logged
with a Task Category of Certification Services to allow for an alternative sorting
and filtering method.

Online Responder Role Configuration | 243

Add the OCSP URL to Group Policy
Once the Online Responder role has been installed, the URL for OCSP can now be added
to the Subordinate CA certificate in Group Policy to ensure that it is being deployed to the
organization. To add the OCSP URL to Group Policy, perform the following steps on the
TFS-DC01 server:
1. Open the Group Policy Management console (gpmc.msc) on the TFS-DC01 server:

2. In the Group Policy Management console tree, expand Forest: corp.tfslabs.com,

then expand Domains, then expand the corp.tfslabs.com domain and then expand
the TFS Labs OU.
3. Right-click on the TFS Labs Certificates GPO and select the Edit... option.
4. In the Group Policy Management Editor window, open the Computer Configuration
> Policies > Windows Settings > Security Settings > Public Key Policies node:

244 | Practical Guide to PKI with Windows Server

 5. Open the Intermediate Certification Authorities folder, right-click on the TFS Labs
Enterprise CA certificate and select Properties:

6. In the TFS Labs Enterprise CA properties window, click on the OCSP tab and in the
text field to the right of the Add URL button, enter http://ocsp.corp.tfslabs.com/ocsp
and click the Add URL button. Click the OK button to close the window:

7. Close the Group Policy Management console.

8. Restart the Active Directory Certificate Services service to apply the changes.

Once the OCSP URL has been added to Group Policy, allow up to 1 hour for the OCSP URL
to be deployed to the entire Active Directory domain. You can now proceed to validating
the OCSP configuration on the TFS-CA01 server.

Online Responder Role Configuration | 245

Verify OCSP Status
Once the Online Responder role has been configured, you can now verify if it is working
correctly within the PKI infrastructure for the TFS Labs domain. This can be done by
checking the Enterprise PKI console on the TFS-CA01 server:

1. On the TFS-CA01 server, open the Enterprise PKI console (pkiview.msc).

2. Under the Enterprise PKI node, click on the TFS Labs Certificate Authority server,
and then click on the TFS Labs Enterprise CA server and check that the status of
OCSP is OK:

3. Close the Enterprise PKI console.

If the OCSP Location in the Enterprise PKI console is showing an error, then the issue is
most likely with the CA Exchange Certificate in the Certificate Authority. That particular
certificate does not know about OCSP since it was generated before the Online
Responder role was configured, so it will need to be recreated for it to be valid.
Fortunately, this is not a major issue, and this task can be performed without causing any
issues with the Certificate Authority.

246 | Practical Guide to PKI with Windows Server

If there is an issue with the OCSP Location due to an issue with the CA Exchange
Certificate, the error would look like this while viewing the Enterprise PKI console for the
Subordinate CA:

Figure 7.8.1: The OCSP Location is invalid since the Online Responder role was added
after several certificates were created. This can be corrected by revoking a certificate and
recreating it, as the new certificate will be aware of the OCSP Location.

To fix the error with the OCSP Location, perform the following steps:

1. Open the Certification Authority console (certsrv.msc) on the TFS-CA01 server.

2. Expand the TFS Labs Enterprise CA server in the console tree.
3. Under the Issued Certificates folder, look for a certificate using the CA Exchange
(CAExchange) Template.
4. Right-click on the Certificate and select the All Tasks > Revoke Certificate option.
5. On the Certificate Revocation window, leave the Reason code as Unspecified and
click the Yes button to revoke the Certificate.
6. Open an elevated PowerShell prompt and run the following command request a new
certificate:

certutil.exe -cainfo xchg

Online Responder Role Configuration | 247

 7. On the TFS-CA01 server, open the Enterprise PKI console (pkiview.msc). Under the
Enterprise PKI node, click on the TFS Labs Certificate Authority, and then click on
the TFS Labs Enterprise CA server. The status of OCSP should be OK:

8. Close the Enterprise PKI console.

Once the OCSP status has been verified and there are no errors, you can proceed to
checking the OCSP connectivity.

Test OCSP Connectivity

To verify that the Online Responder role can communicate properly with devices on the
TFS Labs domain, a certificate will need to be exported and analyzed through the URL
Retrieval Tool. At the same time, the Enterprise CA and CRLs locations can also be
verified. This can be easily accomplished on the TFS-CA01 server by performing the
following steps:

1. On the TFS-CA01 server, export the TFS Labs Enterprise CA certificate as a DER
Encoded Binary to the root of the C:\ drive (C:\TFS Labs Enterprise CA.cer).
2. Run the following command in an elevated PowerShell prompt to launch the URL
Retrieval Tool, and load the certificate to be checked:

certutil.exe -URL "C:\TFS Labs Enterprise CA.cer"

248 | Practical Guide to PKI with Windows Server

3. The URL Retrieval Tool window will open with the C:\TFS Labs Enterprise CA.cer
already loaded:

4. In the Retrieve pane, select the option for Certs (from AIA) and then click the Retrieve
button. The results that are returned should include the Enterprise CA locations with
a Verified status:

5. In the Retrieve pane, select the option for CRLs (from CDP) and then click the Retrieve
button. The results that are returned should include the Base CRL and Delta CRL
locations with a Verified status:

Online Responder Role Configuration | 249

 6. In the Retrieve pane, select the option for OCSP (from AIA) and then click the Retrieve
button. The result returned should be (0.0) http://ocsp.corp.tfslabs.com/ocsp with
a Verified status:

7. Close the URL Retrieval Tool window.

OCSP Status Results

This step may not return a result immediately and that is nothing to be concerned
about. If you run this test and nothing is returned in the results, you may want to
run this test later using the TFS-WIN10 workstation once the Active Directory
Certificate Services deployment has been completed. If the previous test of
verifying OCSP connectivity was successful, then there are no issues with OCSP.

Online Responder Role Limitations

The Online Responder role does have some limitations and potential issues when it is
used within an environment that you should be aware of. There have been several
documented cases in the last few years where a misconfigured OCSP server caused
several issues with application providers, so you should be aware that the OCSP role can
cause issues. It is important to maintain the OCSP role to ensure that there are no issues
with any services that are provided by your organization. Having a misconfigured OCSP
server can cause several unintended consequences, so always ensure that the server
holding the Online Responder role is healthy and functioning properly.

Online Responder Role Next Steps

Now that the Online Responder role has been installed and configured, the next step is to
configure the Certificate Authority for Private Key Archival.

250 | Practical Guide to PKI with Windows Server

Chapter 8 - Private Key Archive
and Recovery

With the use of certificates and a PKI in an Active Directory domain, a lot of enhanced
functionality can be utilized that depends on a valid PKI. This functionality relies on the
public and private keys always being available and ensuring the integrity of those keys.

An important thing to factor in with certificates is to ensure that the private keys are
backed up correctly, which most users would not understand how to do. Fortunately, this
is a straightforward process to automate and can be performed natively with no
third-party software or utilities required in Windows Server.

This chapter will focus on the setup and deployment of the Certificate Templates needed
to enable Private Key Archival. This will allow for the recovery of the private keys for a
user if their private key is lost for whatever reasons.

Private Key Archive and Recovery | 251

Create the Key Recovery Agent Certificate Template
The Key Recovery Agent feature of Active Directory Certificate Services allows for the
archival of private keys that are generated by the Certificate Authority. This is important if
a certificate is deleted and needs to be restored. There is a Certificate Template needed
to activate the required features, and that can be completed by performing these steps:
1. Open the Certification Authority console (certsrv.msc) on the TFS-CA01 server:

2. Expand the TFS Labs Enterprise CA server in the console tree.

3. Right-click on Certificate Templates and then click Manage. The Certificate Templates
console will open and display the Certificate Templates stored in Active Directory:

252 | Practical Guide to PKI with Windows Server

4. In the details pane, right-click on the Key Recovery Agent Template and then click
Duplicate Template:

5. The Properties of New Template window will open for the Duplicated Certificate.
6. On the Compatibility tab, make the following changes in the Compatibility Settings
pane (when the Resulting changes windows appears, click the OK button to continue):
• Certification Authority - Windows Server 2016
• Certificate recipient - Windows 10 / Windows Server 2016

Private Key Archive and Recovery | 253

 7. On the Properties of New Template window, click on the General tab. Change the
name of the template from Copy of Key Recovery Agent to TFS Labs Key Recovery
Agent. Ensure that the Validity Period is set to 1 year. Also ensure that the option
to Publish certificate in Active Directory is selected:

8. On the Issuance Requirements tab, un-check the option for CA certificate manager
approval:

254 | Practical Guide to PKI with Windows Server

 9. On the Cryptography tab, make the following changes for the Cryptography settings:
• Provider Category - Key Storage Provider
• Algorithm name - RSA
• Minimum key size - 4096
• Request hash - SHA256

10. On the Security tab, verify that Authenticated Users group only has the Read permission
enabled:

Private Key Archive and Recovery | 255

 11. On the Security tab, select the Domain Admins group and enable the Read, Write and
Enroll permissions:

12. On the Security tab, select the Enterprise Admins group and enable the Read, Write
and Enroll permissions:

13. Click the OK button to close the Properties of New Template window.
14. Close the Certificate Templates console window.

256 | Practical Guide to PKI with Windows Server

 15. In Certification Authority console, right-click on the Certificate Templates folder,
then select New and then select Certificate Template to Issue.
16. On the Enable Certificate Templates window, select TFS Labs Key Recovery Agent
and then click OK:

17. The TFS Labs Key Recovery Agent Certificate Template should now appear in the
Certificate Templates folder:

18. Close the Certification Authority console.

Once the Key Recovery Agent Certificate Template has been created, you can proceed to
issuing the certificate to the Domain Administrator account.

Private Key Archive and Recovery | 257

Deploy the Key Recovery Agent Certificate
Once the Key Recovery Agent Certificate Template has been created it, can now be
requested for the Domain Administrator account. To request a Key Recovery Agent
certificate, perform the following steps on the TFS-CA01 server:

1. On the TFS-CA01 server, open the Certificates console (certmgr.msc) for the Current
User Account, which should be the Domain Administrator account:

2. Right-click on the Personal folder and select the All Tasks > Request New Certificate
option:

258 | Practical Guide to PKI with Windows Server

3. On the Before You Begin screen, click the Next button to continue:

4. On the Select Certificate Enrollment Policy screen, the Active Directory Enrollment
Policy will be automatically selected. Click the Next button to continue:

Private Key Archive and Recovery | 259

 5. On the Request Certificates screen, check the box beside the TFS Labs Key Recovery
Agent Certificate and click the Enroll button:

6. On the Certificate Installation Results screen, click the Finish button.

7. In the Certificates console, expand the Personal folder and expand the Certificates
folder. The new Key Recovery Agent certificate should be listed in the issued Certificates
for the TFSLABS\Administrator user:

8. Close the Certificates console.

Once the Key Recovery Agent certificate has been issued for the Domain Administrator
account, you can proceed to configuring the Certificate Authority to use Key Recovery.

260 | Practical Guide to PKI with Windows Server

 Alternate Account for Key Recovery

It is not advised to setup the Domain Administrator account for the Key Recovery
Agent for large organizations. It is better to use a dedicated account for Key
Recovery if the task of restoring certificates has been delegated to other users in
the organization.

Adding additional or dedicated accounts also allows for better delegation to other
members of the IT department and removes extra tasks that must be run as the
Domain Administrator account.

Configure the Certificate Authority for Key Recovery

The option to archive keys that are generated by the Subordinate CA will need to be
explicitly activated for it work correctly for key recovery to work correctly. This can be
configured on the TFS-CA01 server by performing the following steps:

1. Open the Certification Authority console (certsrv.msc) on the TFS-CA01 server.

2. Right-click on the TFS Labs Enterprise CA server and select the Properties option.
3. In the TFS Labs Enterprise CA Properties window, click on the Recovery Agents tab:

Private Key Archive and Recovery | 261

 4. On the Recovery Agents tab, select the option to Archive the Key. Leave the Number
of recovery agents to use number set to 1:

5. On the Recovery Agents tab, under the Key recovery agent certificates pane, click the
Add... button and select the Key Recovery Agent Certificate that was just requested
by clicking the OK button:

262 | Practical Guide to PKI with Windows Server

 6. On the Recovery Agents tab, the Key recovery agent certificates pane should now
list the Key Recovery Agent Certificate (the status will be shown as Not loaded until
the Active Directory Certificate Services service is restarted):

7. Click the OK button. When prompted to restart Active Directory Certificate Services,
click the Yes button.
8. Close the Certification Authority console.

Once the Certificate Authority has been configured to allow for key recovery, Certificate
Templates can now be created to allow for the automatic back up of private keys.

Private Key Archive and Recovery Next Steps

Now that the Private Key Archival and Recovery has been completed, you can now move
on and configure custom Certificate Templates for the TFS Labs domain.

Private Key Archive and Recovery | 263

Chapter 9 - Certificate Template
Customization

Active Directory Certificate Services provides multiple default Certificate Templates that
are available for use within your Active Directory domain. Most of these default
Certificate Templates are completely adequate and would work well in most
organizations, but they can sometimes require some additional customization from the
default settings.

By creating custom Certificate Templates for your Active Directory domain, you are
ensuring that the security settings for those certificates are correct and that the correct
servers can manage certificates. There are also additional Certificate Templates present
by default which can be deleted.

This chapter will focus on the modification and deployment of various Certificate
Templates for Active Directory Certificate Services. There will also be a focus on how to
modify those Certificate Templates to follow the best security practices as well and
modifying them to work with automatic deployment.

Certificate Template Customization | 265

Active Directory Certificate Templates
Active Directory Certificate Services provides over 30 Certificate Templates which are
available for use within your environment (the highlighted Certificate Templates below
will be configured later in this chapter). These are the Certificate Templates that are
available by default with Windows Server 2019:

Administrator IPSec
Authenticated Session IPSec (Offline request)
Basic EFS Kerberos Authentication
CA Exchange Key Recovery Agent
CEP Encryption OCSP Response Signing
Code Signing RAS and IAS Server
Computer Root Certification Authority
Cross Certification Authority Router (Offline request)
Directory Email Replication Smartcard Logon
Domain Controller Smartcard User
Domain Controller Authentication Subordinate Certification Authority
EFS Recovery Agent Trust List Signing
Enrollment Agent User
Enrollment Agent (Computer) User Signature Only
Exchange Enrollment Agent Web Server
Exchange Signature Only Workstation Authentication
Exchange User

These Certificate Templates are available for usage and can be customized to fit the
needs of your organization. Certificate Templates are be published in Active Directory,
which allows for greater ease of Certificate Deployment within an organization. There are
a few best practices that should be followed when dealing with Certificate Templates:
• You should always duplicate existing Certificate Templates that you intend to use
and then modify the duplicate Certificate Template accordingly. Some of the default
Certificate Templates can be modified without duplicating them, but this is not a
recommended way to modify Certificate Templates.
• Always use descriptive names for the Certificate Templates to ensure that you know
that it is a Certificate Template that was duplicated. If the name is too similar to the
default Certificate Template, it can be easy to confuse which Certificate Templates
are default and which ones are duplicated.

266 | Practical Guide to PKI with Windows Server

 • You should always confirm the security settings when configuring a Certificate Template.
Ensure that you are assigning the correct permissions to the Certificate Template and
that the intended behaviour will be correct once it has been published.
• When publishing a Certificate Template to Active Directory, ensure that you are allowing
the correct users or groups to have access to that Certificate Template. Do not allow
anyone in your organization to request a certificate if they should not be allowed to.
• For important Certificates Templates, do not allow them to enroll automatically. Important
certificates should require an administrator to issue them to ensure they are valid.
• Only ever publish the Certificate Templates that you intend to use within your environment.
Never publish Certificate Templates if you have no intention of using them.
• When you no longer require a Certificate Template, delete it from the list of issued
Certificate Templates. Never keep Certificate Templates available to be issued if they
are obsolete.

For the TFS Labs domain, the following Certificate Templates will be created and
published so that they can be utilized by users, workstations, and servers:

Certificate Template Name Security Options

TFS Labs User Certificate TFS-CA01 (Read, Enroll)
Domain Users (Read, Enroll, Autoenroll)
TFS Labs Computer Certificate TFS-CA01 (Read, Enroll)
Domain Computers (Read, Enroll, Autoenroll)
TFS Labs Web Server Certificate TFS-CA01 (Read, Enroll)
Domain Admins (Read, Enroll, Autoenroll)

These Certificate Templates will be used to issue certificates to the TFS Labs domain.
Some of these certificates will be issued automatically using Group Policy, and the other
certificates can be requested by users as needed. The procedure for creating these
Certificate Templates is mostly the same, and only requires slight modifications from the
default settings.

When working with Certificate Templates there are several compatibility settings that you
will need to factor in depending on your environment. In Active Directory Certificate
Services there are two types of compatibility settings that can be modified, and that is
the Certificate Authority and the Certificate Recipient settings.

For the Certificate Authority options, there are six options for what the minimum level of
support is:

• Windows Server 2003

• Windows Server 2008
• Windows Server 2008 R2
• Windows Server 2012
• Windows Server 2012 R2
• Windows Server 2016

Certificate Template Customization | 267

For the Certificate Recipients options, there are six options for what the minimum level of
support is:

• Windows XP / Server 2003

• Windows Vista / Server 2008
• Windows 7 / Server 2008 R2
• Windows 8 / Windows Server 2012
• Windows 8.1 / Windows Server 2012 R2
• Windows 10 / Windows Server 2016

Typically, it is best practice to support the previous operating system to ensure that you
experience no issues within the environment. For example, if your environment is
primarily using Windows Server 2016 and Windows 10, you should choose Windows
Server 2012 R2 and Windows 8.1 to ensure the greatest compatibility in the network.
Since this book only focuses on the latest versions of Windows and is just for
demonstration purposes, only the highest compatibility settings are used.

User Certificate Template Creation

The purpose of the User Certificate Template is primarily to provide signature and
encryption capabilities on a user level that is not necessarily tied to a particular
workstation. Some of the main uses of a User Certificate Template include:

• File encryption
• E-mail signing
• 802.1X authentication
• VPN authentication

Since User Certificates are used for critical purposes that can effectively lock a user out
of important data, it is strongly advised that these certificates utilize the Key Recovery
Agent that was setup in the previous chapter.

To create the User Certificate Template, which can be automatically issued later and
enrolled, perform the following steps on the TFS-CA01 server:

1. Open the Certification Authority console (certsrv.msc) on the TFS-CA01 server.

2. Expand the TFS Labs Enterprise CA console tree and select the Certificate Templates
folder.
3. Right-click on the Certificate Templates and select the Manage option.
4. In the Certificate Templates window, right-click on the User Template and then click
Duplicate Template.
5. The Properties of New Template window will open for the Duplicated Certificate.
6. On the Compatibility tab, make the following changes in the Compatibility Settings
pane (when the Resulting changes window appears, click the OK button to continue):
• Certification Authority - Windows Server 2016
• Certificate recipient - Windows 10 / Windows Server 2016

268 | Practical Guide to PKI with Windows Server

 7. On the Properties of New Template window, click on the General tab. Make the
following changes to the Certificate Template if needed:
• Template display name - TFS Labs User Certificate
• Validity period - 1 Year
• Renewal period - 6 Weeks
• Publish certificate in Active Directory - Enabled
• Do not automatically reenroll if a duplicate certificate exists - Enabled
8. On the Request Handling tab, make the following changes for the request handling
settings (if prompted, click OK to continue):
• Purpose - Signature and encryption
• Include symmetric algorithms allowed by the subject - Enabled
• Archive subject’s encryption private key - Enabled
• Allow private key to be exported - Enabled
• Renew with the same key - Enabled
9. On the Cryptography tab, make the following changes for the Cryptography settings:
• Provider Category - Key Storage Provider
• Algorithm name - RSA
• Minimum key size - 4096
• Request hash - SHA256
10. On the Security tab, click the Add... button, and then add the TFS-CA01 server.
Assign the Read and the Enroll permissions.

Security Permissions for Server Objects

There are a few extra steps required for adding server and computer objects
to the security settings as those objects are not searchable by default. To be
able to add a server object, perform the following steps to be able to search
for those objects:

(a) On the Security tab, click the Add... button.

(b) In the Select Users, Computers, Service Accounts, or Groups window,
click the Object Types... button.
(c) In the Object Types window, select the option for Computers and click
the OK button.
(d) In the Enter the object names to select field, enter TFS-CA01 and click
the Check Names button.
(e) Click the OK button to finish adding the server object.

11. On the Security tab, select the Domain Users group and assign the Read, Enroll and
Autoenroll permissions.
12. Click the OK button to close the Properties of New Template window.
13. Close the Certificate Templates console window.
14. In the Certification Authority console, right-click on Certificate Templates, then select
New and then select Certificate Template to Issue.
15. In the Enable Certificate Templates dialog box, click TFS Labs User Certificate and
then click OK.

Certificate Template Customization | 269

 16. The TFS Labs User Certificate should now be listed in the available Certificates for
the TFS Labs domain.
17. Close the Certification Authority console.

The User Certificate is now ready to be utilized on the TFS Labs domain and can be
requested manually by users or enrolled automatically if that option is enabled.

User Certificate Template Limitations

Ensure that the user has their e-mail address entered into their user account
details in Active Directory, otherwise this certificate will not deploy correctly to the
user account. If you are missing the e-mail address in the Active Directory user
object, you will receive errors while attempting to issue the certificate:

Once the e-mail address is entered for the affected user accounts, the certificate
should then be able to be issued correctly by re-requesting the certificate.

User Certificate Private Key Recovery

It is entirely possible that a user will lose their private key at some point after it has been
issued, and it not necessarily their fault. The private key can be lost when a user’s
workstation is replaced or re-imaged, and it is not always backed up prior to this.

Most of the time, a user could just request a new User certificate from the Certificate
Authority, but that could cause the following issues when existing items have been
attached to that private key:

270 | Practical Guide to PKI with Windows Server

 • Encrypted files could become inaccessible.
• Encrypted e-mail could be lost.
• VPN authentication could be interrupted.

By setting up private key archive and private key recovery in the previous chapter,
Certificate Templates that are configured with the archive option will have their private
keys automatically archived. It is a straightforward process to recover a private key
should it ever need to be restored.

In this example, the private key for the Mary Smith user account that was created in an
earlier chapter will be retrieved from the private key archive by performing the following
steps on the TFS-CA01 server:

1. On the root of the C:\ drive, create a folder called CertRecovery (C:\CertRecovery).
2. On the TFS-CA01 server open Certification Authority console (certsrv.msc).
3. Expand the TFS Labs Enterprise CA console tree and select the Issued Certificates
folder.
4. Find the User Certificate that you are trying to recover the Private Key from
(TFSLABS\msmith), right-click on it and select Open.
5. On the Certificate window, go to the Details tab.
6. Find the Serial number field, which contains the 38-digit alphanumeric serial number
for the certificate:

7. Open an elevated PowerShell prompt on the TFS-CA01 server.

8. Change to the C:\CertRecovery Directory.

Certificate Template Customization | 271

 9. Run the following command to retrieve the certificate (insert the correct serial number
and the outputted file name):

certutil.exe -getkey 3c0000000946c30a9587d470b9000000000009 msmith

10. Run the following command to recover the private key for the certificate (insert the
file name with a .PFX extension). You will also be prompted to enter a password
which will be used to import the certificate:

certutil.exe -recoverkey .\msmith msmith.pfx

272 | Practical Guide to PKI with Windows Server

 11. Once the certificate has been exported, you can close the PowerShell prompt.

The outputted PFX file will contain the public and private keys for the user’s certificate, as
well as the Root and Subordinate certificates. A user can install the certificate in the
Personal Store for their user account to make their private key available again for usage.

User Private Key

Ensure that you keep the outputted certificate safe and secure as it contains the
public and private key for the user account that was recovered. If possible, try and
avoid sending the recovered certificate through e-mail and use more secure
manners for transmission.

Computer Certificate Template Creation

The purpose of the Computer Certificate Template is like the User Certificate Template,
but it is primarily used to provide authentication capabilities to the workstation. Some of
the main uses of a Computer Certificate Template include:

• Full disk encryption

• 802.1X authentication
• Pre-logon VPN authentication
• Authentication for MDM or workstation management

The Computer Certificate Template typically works independently of the User Certificate
Template, and the user on a particular workstation is usually unaware that it is being
used. There are some features within the Windows operating system which work without
requiring any information or input from the user, and this is usually the case with Active
Directory domains with advanced security or authentication features.

To create the Computer Certificate Template, which can be automatically issued later
and enrolled using Group Policy, perform the following steps on the TFS-CA01 server:

1. Open the Certification Authority console (certsrv.msc) on the TFS-CA01 server.

2. Expand the TFS Labs Enterprise CA console tree and select the Certificate Templates
folder.
3. Right-click on the Certificate Templates and select the Manage option.
4. In the Certificate Templates window, right-click on the Computer Template and then
click Duplicate Template.
5. The Properties of New Template window will open for the Duplicated Certificate.
6. On the Compatibility tab, make the following changes in the Compatibility Settings
pane (when the Resulting changes window appears, click the OK button to continue):
• Certification Authority - Windows Server 2016
• Certificate recipient - Windows 10 / Windows Server 2016

Certificate Template Customization | 273

 7. On the Properties of New Template window, click on the General tab. Make the
following changes to the Certificate Template if needed:
• Template display name - TFS Labs Computer Certificate
• Validity period - 1 Year
• Renewal period - 6 Weeks
• Publish certificate in Active Directory - Enabled
• Do not automatically reenroll if a duplicate certificate exists - Disabled
8. On the Request Handling tab, make the following changes for the request handling
settings:
• Purpose - Signature and encryption
9. On the Cryptography tab, make the following changes for the Cryptography settings:
• Provider Category - Key Storage Provider
• Algorithm name - RSA
• Minimum key size - 4096
• Request hash - SHA256
10. On the Security tab, click the Add... button, and then add the TFS-CA01 server.
Assign the Read and the Enroll permissions.

Security Permissions for Server Objects

There are a few extra steps required for adding server and computer objects
to the security settings as those objects are not searchable by default. To be
able to add a server object, perform the following steps to be able to search
for those objects:

(a) On the Security tab, click the Add... button.

(b) In the Select Users, Computers, Service Accounts, or Groups window,
click the Object Types... button.
(c) In the Object Types window, select the option for Computers and click
the OK button.
(d) In the Enter the object names to select field, enter TFS-CA01 and click
the Check Names button.
(e) Click the OK button to finish adding the server object.

11. On the Security tab, select the Domain Computers group and assign the Read, Enroll
and Autoenroll permissions.
12. Click the OK button to close the Properties of New Template window.
13. Close the Certificate Templates console window.
14. In the Certification Authority console, right-click on Certificate Templates, then select
New and then select Certificate Template to Issue.
15. In the Enable Certificate Templates dialog box, click TFS Labs Computer Certificate
and then click OK.

274 | Practical Guide to PKI with Windows Server

 16. The TFS Labs Computer Certificate should now be listed in the available certificates
for the TFS Labs domain:

17. Close the Certification Authority console.

The Computer Certificate is now ready to be utilized on the TFS Labs domain, and can be
requested manually by users, or enrolled automatically.

Web Server Certificate Template Creation

The Web Server Certificate Template only requires minor changes to make it easily
deployable in the TFS Labs domain, and most of those changes are related to the
security settings of the Certificate Template. This Certificate Template will be available
on the Active Directory Certificate Services Web Enrollment website, which will allow
users to submit a Certificate Request to the Enterprise CA to have it issued.

The settings for a Web Server Certificate Template are slightly different from the
previously configured certificates, and this is due to those certificates being used
primarily in a Windows environment. A web server certificate requires less strict settings
to maximize the compatibility between the most devices where the website will be used,
and which web browsers are used. Some settings are intentionally relaxed to ensure the
maximum compatibility with other devices that may be using the certificate.

The Web Server Certificate Template will be used to enable SSL on the IIS server that is
being used for the Active Directory Certificate Services Web Enrollment role.

Certificate Template Customization | 275

To create the Web Server Certificate Template, perform the following steps on the
TFS-CA01 server:

1. Open the Certification Authority console (certsrv.msc) on the TFS-CA01 server.

2. Expand the TFS Labs Enterprise CA console tree and select the Certificate Templates
folder.
3. Right-click on the Certificate Templates and select the Manage option.
4. In the Certificate Templates window, right-click on the Web Server Template and
then click Duplicate Template.
5. The Properties of New Template window will open for the Duplicated Certificate.
6. On the Compatibility tab, make the following changes in the Compatibility Settings
pane (when the Resulting changes window appears, click the OK button to continue):
• Certification Authority - Windows Server 2016
• Certificate recipient - Windows 7 / Windows Server 2008 R2
7. On the Properties of New Template window, click on the General tab. Make the
following changes to the Certificate Template if needed:
• Template display name - TFS Labs Web Server Certificate
• Validity period - 1 Year
• Renewal period - 6 Weeks
• Publish certificate in Active Directory - Disabled
• Do not automatically reenroll if a duplicate certificate exists in Active Directory
- Disabled
8. On the Request Handling tab, make these changes for the request handling settings:
• Purpose - Signature and encryption
9. On the Cryptography tab, make the following changes for the Cryptography settings:
• Provider Category - Legacy Cryptographic Service Provider
• Algorithm name - Determined by CSP
• Minimum key size - 2048
10. On the Security tab, click the Add... button, and then add the TFS-CA01 server.
Assign the Read and the Enroll permissions.

Security Permissions for Server Objects

There are a few extra steps required for adding server and computer objects
to the security settings as those objects are not searchable by default. To be
able to add a server object, perform the following steps to be able to search
for those objects:

(a) On the Security tab, click the Add... button.

(b) In the Select Users, Computers, Service Accounts, or Groups window,
click the Object Types... button.
(c) In the Object Types window, select the option for Computers and click
the OK button.
(d) In the Enter the object names to select field, enter TFS-CA01 and click
the Check Names button.
(e) Click the OK button to finish adding the server object.

276 | Practical Guide to PKI with Windows Server

 11. On the Security tab, select the Domain Admins group and assign the Read, Write,
Enroll and Autoenroll permissions.
12. Click the OK button to close the Properties of New Template window.
13. Close the Certificate Templates console window.
14. In the Certification Authority console, right-click on Certificate Templates, then select
New and then select Certificate Template to Issue.
15. In the Enable Certificate Templates dialog box, click TFS Labs Web Server Certificate
and then click OK.
16. The TFS Labs Web Server Certificate should now be listed in the available certificates
for the TFS Labs domain:

17. Close the Certification Authority console.

The Web Server Certificate Template is now ready to be utilized on the TFS Labs domain
and can be requested by authenticated users.

Web Server Certificate Template Account Permissions

In this example, the Domain Admins security group is the only group of users that
can request a Web Server certificate. Depending on how your environment is
setup, you may add additional groups to the security settings to allow for easier
access to issue that certificate. For example, an Active Directory group could be
added for web developers, to allow them access to request a Web Server
certificate, without requiring an administrator to assist them in that task.

Certificate Template Customization | 277

Delete Unnecessary Certificate Templates
There are several Certificate Templates that are present in the Certificate Templates
folder that should be removed prior to a Certificate Authority going into production.
These Certificate Templates are not necessarily needed as they were included by default
with Active Directory Certificate Services and may not be needed for all Active Directory
environments.

For example, the Subordinate Certification Authority Certificate Template should never be
available on a production Certificate Authority since it can potentially cause security
issues. Other Certificate Templates provide some overlap with the customized
Certificate Templates that were previously configured and can cause support issues
should users utilize the incorrect Certificate Templates.

The Certificate Templates that were present at the beginning of the TFS Labs Certificate
Authority deployment and at the end of the deployment are listed below (optional
Certificate Templates are also listed):

Certificate Template AD CS Default TFS Labs Domain Optional

Administrator Yes Yes N/A
Basic EFS Yes No N/A
Computer Yes No N/A
Directory E-mail Replication Yes Yes N/A
Domain Controller Yes Yes N/A
Domain Controller Authentication Yes Yes N/A
EFS Recovery Agent Yes No N/A
Kerberos Authentication Yes Yes N/A
User Yes No N/A
Web Server Yes No N/A
Subordinate Certification Authority Yes No N/A
TFS Labs Computer Certificate No Yes No
TFS Labs Key Recovery Agent No Yes No
TFS Labs OCSP Response Signing No Yes No
TFS Labs User Certificate No Yes No
TFS Labs Web Server Certificate No Yes Yes

278 | Practical Guide to PKI with Windows Server

Some of the default Certificate Templates, such as Domain Controller or Kerberos
Authentication, should not be modified unless you have a good reason to make
modifications. These Certificate Templates are needed for secure information exchange
between workstations and servers to Domain Controllers, so they must be present for
that functionality to operate correctly.

To remove the unnecessary Certificate Templates that are present in the TFS Labs
domain, perform the following steps on the TFS-CA01 server:

1. Open the Certification Authority console (certsrv.msc) on the TFS-CA01 server.

2. Expand the TFS Labs Enterprise CA console tree and select the Certificate Templates
folder.
3. Right-click on the following Certificate Templates and select the Delete option (if
they exist). When prompted in the Disable certificate templates dialog box, select
the Yes option.
• Basic EFS
• Computer
• EFS Recovery Agent
• Subordinate Certification Authority
• User
• Web Server
4. The deleted Certificate Templates should no longer be listed in the available certificates
for the TFS Labs domain, and the TFS Labs Certificate Templates that have been
created should all be listed:

5. Close the Certification Authority console.

Certificate Template Customization | 279

Once the unnecessary Certificate Templates have been removed, there are no longer any
additional changes needed to be made to the Certificate Templates on the TFS Labs
domain.
Unnecessary Certificate Templates

It does not affect the operation of the Certificate Authority to keep extra
Certificate Templates available, but you should consider removing Certificate
Templates that you do not intend to support. This can reduce complexity of the
Certificate Authority and make it easier for upgrades in the future.

Active Directory Certificate Services Web Enrollment

Active Directory Certificate Services Web Enrollment is a feature that allows
authenticated users in the organization the ability to submit Certificate Requests and
download the completed certificates. It also gives the option of downloading the
Certificate Authority certificate chain and the CRL files. By default, any user that is a
member of the Domain Admins group can login and request certificates, but additional
groups can be added if needed (and is recommended in a production environment). The
Active Directory Certificate Services Web Enrollment website can be accessed by going
to the following URL on the TFS Labs domain:
http://pki.corp.tfslabs.com/CertSrv/
The only issue is that SSL should be enabled on this site to enhance the security for it, so
an SSL certificate will be needed for it. Fortunately, the Certificate Authority is now able
to issue certificates and a proper certificate can now be requested and applied to this
site. Since there are multiple sites linked to the TFS-CA01 server, a SAN certificate is
needed to add the other names to the certificate:
• TFS-CA01.corp.tfslabs.com
• OCSP.corp.tfslabs.com
• PKI.corp.tfslabs.com
To add a certificate to the TFS-CA01 server to allow for SSL encryption, perform the
following steps:
1. Open the Certificates console (certlm.msc) on the TFS-CA01 server, which lists the
certificates on the Local Computer Account.
2. Open the Certificates > Personal > Certificates store.
3. Right-click on the Certificates folder, go to All Tasks and select the Request New
Certificate... option.
4. On the Before You Begin screen, click the Next button to continue.
5. On the Select Certificate Enrollment Policy screen, the Active Directory Enrollment
Policy option should be pre-selected. Click the Next button to continue.
6. On the Request Certificates screen, select the TFS Labs Web Server Certificate and
click the More information is required to enroll for this certificate. Click here to
configure settings link below it.

280 | Practical Guide to PKI with Windows Server

 7. On the Certificate Properties window, you will be able to enter the details for the
certificate.
8. On the Subject tab, add the following details for the Subject name. Select the Type,
enter the Value and click the Add > button to add the fields to the certificate:
• Common name - TFS-CA01.corp.tfslabs.com
• Country - CA
• Email - [email protected]
• Locality - Toronto
• Organization - TFS Labs
• Organizational Unit - IT
• State - Ontario
9. On the Subject tab, add the following details for the Alternative name. Select the
Type, enter the Value and click the Add > button to add the fields to the certificate:
• DNS - OCSP.corp.tfslabs.com
• DNS - PKI.corp.tfslabs.com
10. On the General tab, set the Friendly name to TFS-CA01.corp.tfslabs.com.
11. Click the OK button to close Certificate Properties window.
12. On the Request Certificates screen, click the Enroll button to continue.
13. On the Certificate Installation Results screen, click the Finish button to close the
wizard.
14. The new certificate should now be listed in the Certificates > Personal > Certificates
store and should be labelled TFS-CA01.corp.tfslabs.com.
15. Close the Certificates console.

Once the SSL certificate has been created, it will need to be applied to the IIS website to
ensure that it is used, and to ensure that SSL is enforced on the Active Directory
Certificate Services Web Enrollment website. Perform the following steps on the
TFS-CA01 server:

1. Open the Internet Information Services (IIS) Manager (inetmgr.exe) console on the
TFS-CA01 server.
2. In the Connections pane, select the TFS-CA01 server and expand Sites.
3. Select the Default Web Site and in the Actions pane, select Bindings....
4. In the Site Bindings window, click the Add... button.
5. On the Add Site Binding window, use the following settings and then click the OK
button:
• Type: https
• IP Address: All Unassigned
• Port: 443
• SSL Certificate: TFS-CA01.corp.tfslabs.com
6. Click the Close button to close the Site Binding window.
7. Expand Default Web Site and select the CertSrv folder.
8. In the /CertSrv Home pane, double-click on the SSL Settings icon.
9. In the SSL Settings window, select the option for Require SSL and then click the
Apply button in the Actions pane.
10. Close the Internet Information Services (IIS) Manager console.

Certificate Template Customization | 281

To ensure that the changes to the SSL settings were applied correctly to the TFS-CA01
server, restart the Internet Information Services service. You can do this by opening an
elevated PowerShell prompt and running the following command:

iisreset.exe

You can easily and quickly verify that SSL is working correctly on the Active Directory
Certificate Services Web Enrollment website by opening the Active Directory Certificate
Services Web Enrollment (https://pki.corp.tfslabs.com/CertSrv/) website (you can login
with a Domain Administrator account to test it).
The Active Directory Certificate Services Web Enrollment website should now be properly
secured with SSL:

Since there is a SAN certificate in use, the https://tfs-ca01.corp.tfslabs.com/CertSrv/ and

https://ocsp.corp.tfslabs.com/CertSrv/ links will also work for accessing the website
should you choose to use that URL instead. If you attempt to go to the site without
specifying HTTPS in the URL, the connection will not be successful.
Once the Active Directory Certificate Services Web Enrollment website is working
correctly with SSL, you can use the site for purposes such as requesting a web server
certificate for a Linux server running Apache or Nginx. Depending on the needs of your
organization, you can also add custom Certificate Templates that users can request from
the Active Directory Certificate Services Web Enrollment website.

282 | Practical Guide to PKI with Windows Server

 Active Directory Certificate Services Web Enrollment Alternate URLs

Since there are CNAME records that are in place for accessing services on the
Subordinate CA, there are several URLs that are not available since there are no
SSL certificates in place for those CNAME records. To allow for proper SSL
access to URLs such as https://pki.corp.tfslabs.com/, you would need to ensure
that a proper SAN certificate has been issued to the TFS-CA01 server. Without a
proper SAN certificate in place, those URLs will not be secured properly.

Certificate Template Deployment Next Steps

Now that the default Certificate Templates have been modified from the default settings
and customized for the TFS Labs domain, they can now be configured for automatic
deployment using Group Policy.

Certificate Template Customization | 283

Chapter 10 - Certificate Enrollment

It is easy to request and issue certificates using Active Directory Certificate Services, but
the ability to rapidly deploy certificates within a domain is critical in large organizations.
Most users do not understand how a PKI works so it would be a large burden on them to
have them manually go through the process of requesting certificates on their own.
Fortunately, with Active Directory and Group Policy, it is easy to automatically deploy
certificates with no interaction required by any users.

This chapter will focus on the automatic deployment of certificates within an Active
Directory domain using Group Policy. This will reduce the amount of time and effort
required in deploying certificates to large numbers of users and workstations. This
chapter will also demonstrate how to install the TFS Labs certificates on Linux servers,
iOS devices, Android devices and macOS workstations.

Certificate Enrollment | 285

User Certificate Auto-Enrollment
Enabling the user certificate auto-enrollment feature will allow users within the TFS Labs
domain the ability to automatically receive a certificate from Active Directory Certificate
Services. This certificate will be the TFS Labs User Certificate that was created in the
previous chapter. This enrollment will occur when Group Policy on the device is refreshed
or when the user logs in. To enable this functionality, perform the following steps on the
TFS-DC01 server:

1. Open the Group Policy Management console (gpmc.msc) on the TFS-DC01 server:

2. In the Group Policy Management console tree, expand Forest: corp.tfslabs.com,

then expand Domains, then expand the corp.tfslabs.com domain and then select
the TFS Labs OU:

286 | Practical Guide to PKI with Windows Server

3. Right-click on the TFS Labs Certificates GPO and select the Edit... option.
4. In the Group Policy Management Editor window, open the User Configuration > Policies
> Windows Settings > Security Settings > Public Key Policies node:

5. Right-click on the Certificate Services Client - Certificate Enrollment Policy object

and select the Properties option.
6. In the Certificate Services Client - Certificate Enrollment Policy window, change the
Configuration Model option to Enabled. Click the OK button to close the window:

7. Right-click on the Certificate Services Client - Auto-Enrollment object and select the
Properties option.

Certificate Enrollment | 287

 8. In the Certificate Services Client - Auto-Enrollment window, change the Configuration
Model option to Enabled. Select the options for Renew expired certificates, update
pending certificates, and remove revoked certificates and Update certificate that
use certificate templates options. Click the OK button to close the window:

9. Close the Group Policy Management Editor window.

You can confirm that the auto-enrollment of the TFS Labs User Certificate is working
correctly by logging in on the TFS-WIN10 workstation and checking the Certificate Store
after Group Policy has taken enough time to update. The TFS Labs User Certificate can
be viewed by opening the Local User Certificate Store (certmgr.msc) on the TFS-WIN10
workstation. The TFS Labs User Certificate can be found in the Personal Store.

Group Policy Propagation Time

Once the auto-enrollment options have been added to Group Policy for the User
Certificate, allow up to 1 hour for the update to be propagated in the entire Active
Directory Forest.

Computer Certificate Auto-Enrollment

Enabling the computer auto-enrollment feature will allow workstations and servers within
the TFS Labs domain the ability to automatically receive a certificate from Active
Directory Certificate Services. This certificate will be the TFS Labs Computer Certificate
that was created in the previous chapter. This will occur when Group Policy on the device
is refreshed or when the computer is started. To enable this functionality, perform the
following steps on the TFS-DC01 server:

288 | Practical Guide to PKI with Windows Server

1. Open the Group Policy Management console (gpmc.msc) on the TFS-DC01 server.
2. In the Group Policy Management console tree, expand Forest: corp.tfslabs.com,
then expand Domains, then expand the corp.tfslabs.com domain and then select
the TFS Labs OU.
3. Right-click on the TFS Labs Certificates GPO and select the Edit... option.
4. In the Group Policy Management Editor window, open the Computer Configuration
> Policies > Windows Settings > Security Settings > Public Key Policies node:

5. Right-click on the Certificate Services Client - Certificate Enrollment Policy object

and select the Properties option.
6. In the Certificate Services Client - Certificate Enrollment Policy window, change the
Configuration Model option to Enabled. Click the OK button to close the window:

Certificate Enrollment | 289

 7. Right-click on the Certificate Services Client - Auto-Enrollment object and select the
Properties option.
8. In the Certificate Services Client - Auto-Enrollment window, change the Configuration
Model option to Enabled. Select the options for Renew expired certificates, update
pending certificates, and remove revoked certificates and Update certificate that
use certificate templates options. Click the OK button to close the window:

9. Close the Group Policy Management Editor window.

You can confirm that the auto-enrollment of the TFS Labs Computer Certificate is
working correctly by logging in on the TFS-WIN10 workstation and checking the
Certificate Store after Group Policy has taken enough time to update. The TFS Labs
Computer Certificate can be viewed by opening the Local Machine Certificate Store
(certlm.msc) on the TFS-WIN10 workstation. The TFS Labs Computer Certificate can be
found in the Personal Store.

Group Policy Propagation Time

Once the auto-enrollment options have been added to Group Policy for the
Computer Certificate, allow up to 1 hour for the updates to be propagated in the
entire Active Directory Forest.

Additional sections in this chapter detail the process in creating and using an SSL
certificate for Linux with a certificate that was issued from Active Directory Certificate
Services. There are also sections on deploying the Root and Subordinate certificates to
Android, iOS, and macOS. If these scenarios are not required, you can proceed to the next
chapter.

290 | Practical Guide to PKI with Windows Server

Optional: Deploy Certificates to a Linux Server
In this example, a certificate will be requested from the Active Directory Certificate
Services Web Enrollment website for use with the Apache web server and Nginx web
server running on a Linux server. To request the SSL certificate, OpenSSL will be used to
create the CSR Request that will be submitted to the Enterprise CA. The certificate will
then be applied to both web servers to demonstrate how each is configured.

If you do not use Linux in your environment or are not planning to use it, you can skip this
section.

Deploy Certificates to a Linux Server - Server Setup

In this example, a new virtual machine called TFS-LINUX-WWW was provisioned, and
Ubuntu Server 20.04.2 LTS was installed in Hyper-V using the following hardware
specifications:

• Virtual Machine Generation - 1

• Virtual Processors - 2
• Virtual Memory - 4096 MB
• Virtual Hard Disk - 40 GB
• Virtual Network Adapters - 1

The network settings for the TFS-LINUX-WWW virtual machine are as follows:

IP Address 10.100.1.120
Netmask 255.255.255.0
Gateway 10.100.1.1
DNS Server 1 10.100.1.100

For the DNS settings, there is one A record and one CNAME record that was created in
the TFS Labs DNS Zone to support the virtual machine and to facilitate testing of the
issued SSL certificate:

• A record - TFS-LINUX-WWW.corp.tfslabs.com
• CNAME record - WWW.corp.tfslabs.com

The TFS-LINUX-WWW server will resolve to the https://tfs-linux-www.corp.tfslabs.com/

and https://www.corp.tfslabs.com/ addresses, so a SAN or a UCC certificate will be
required for the TFS-LINUX-WWW server to accommodate that requirement. This
functionality is available with Active Directory Certificate Services and can be added to
the CSR request.

In the next step, you will create the CSR request for the Linux server containing the two
DNS entries needed for the SSL certificate.

Certificate Enrollment | 291

Deploy Certificates to a Linux Server - CSR Request
Creating a CSR on the TFS-LINUX-WWW server is not difficult, and only requires minimal
configuration tasks to be completed. Since this is a Linux server, there is no way to
automatically submit a request to the Certificate Authority, so the Active Directory
Certificate Services Web Enrollment website will be used to submit the CSR and
download the issued certificate.

To create the CSR and submit the request, perform the following steps on the
TFS-LINUX-WWW and TFS-CA01 servers:

1. On the TFS-LINUX-WWW server, create a folder in the /etc/ssl directory called

TFS-WWW-LINUX (/etc/ssl/TFS-LINUX-WWW). This folder will be used to store the
SSL files for the TFS-LINUX-WWW server.
2. Go to the /etc/ssl/TFS-LINUX-WWW directory.
3. Create a file to store the CSR request information called tfs-linux-www.cnf and copy
the contents below into the file:

/etc/ssl/TFS-LINUX-WWW/tfs-linux-www.cnf

[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext

[ req_distinguished_name ]
commonName = TFS - LINUX - WWW . corp . tfslabs . com
countryName = CA
stateOrProvinceName = Ontario
localityName = Toronto
organizationName = TFS Labs
organizationalUnitName = IT
emailAddress = administrator@corp . tfslabs . com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS .1 = TFS - LINUX - WWW . corp . tfslabs . com
DNS .2 = WWW . corp . tfslabs . com

4. Run the following command to create the CSR file and the private key for the
TFS-LINUX-WWW server:

openssl req \
-out tfs-linux-www.csr \
-newkey rsa:2048 \
-nodes \
-keyout tfs-linux-www.key \
-config tfs-linux-www.cnf

292 | Practical Guide to PKI with Windows Server

5. Copy the tfs-linux-www.csr file to the TFS-CA01 server.
6. On the TFS-CA01 server, open the Active Directory Certificate Services Web Enrollment
website https://pki.corp.tfslabs.com/CertSrv/ (if prompted, login with the Domain
Administrator account):

7. To submit the CSR, click on the Request a certificate link which is listed under Select
a task.
8. On the Advanced Certificate Request page, click on the Submit a certificate request
by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by
using a base-64-encoded PKCS #7 file link to continue:

Certificate Enrollment | 293

 9. On the Submit a Certificate Request or Renewal Request page, copy the contents of
the tfs-linux-www.csr file into the Saved Request box. Under the Certificate Template
list, select the TFS Labs Web Server Certificate template. Click the Submit > button
to continue:

10. On the Certificate Issued page, select the option for Base 64 encoded and download
both the Certificate and Certificate Chain files. These files should be saved as certnew.cer
and certnew.p7b:

11. Close the Active Directory Certificate Services Web Enrollment website.
12. Copy the certnew.cer and certnew.p7b files to the TFS-LINUX-WWW server and place
them in the /etc/ssl/TFS-LINUX-WWW folder.

294 | Practical Guide to PKI with Windows Server

 13. Go to the /etc/ssl/TFS-LINUX-WWW directory.
14. Convert the Certificate Chain file to the correct format by running the following command:

openssl pkcs7 -print_certs -in certnew.p7b -out tfs-labs-ca

15. Rename the Certificate file to the correct name by running the following command:

cp certnew.cer tfs-linux-www.cer

16. There should now be the following files located in the /etc/ssl/TFS-LINUX-WWW
directory:
• certnew.cer
• certnew.p7b
• tfs-labs-ca
• tfs-linux-www.cer
• tfs-linux-www.cnf
• tfs-linux-www.csr
• tfs-linux-www.key

Once the SSL certificate has been installed on the TFS-LINUX-WWW server, the Apache or
Nginx web servers can be configured to use it.

Deploy Certificates to a Linux Server - Apache Setup

To enable SSL on Apache on the default website, perform the following steps on the
TFS-LINUX-WWW server:

1. Install the Apache web server using the following command:

sudo apt-get install apache2

2. Enable the SSL module in Apache by running the following command.

sudo a2enmod ssl

3. Modify the SSL settings for the default website by editing the configuration file that
is provided with Apache (/etc/apache2/sites-available/default-ssl.conf):

/etc/apache2/sites-available/default-ssl.conf

ServerName TFS - LINUX - WWW . corp . tfslabs . com

SSLCertificateFile / etc / ssl / TFS - LINUX - WWW / tfs - linux - www . cer
SSLCertificateKeyFile / etc / ssl / TFS - LINUX - WWW / tfs - linux - www . key
SSLCertificateChainFile / etc / ssl / TFS - LINUX - WWW / tfs - labs - ca

Certificate Enrollment | 295

 4. Run the following command to enable SSL:

sudo a2ensite default-ssl.conf

5. Run the following command to restart the Apache service.

sudo service apache2 restart

6. Run the following command to enable the Apache service to start when the server is
booted:

sudo systemctl enable apache2

7. If there were no errors with the Apache service, the configuration is now complete.
If there were no issues with configuring SSL on Apache, you can test that SSL is working
by going to the following website:
http://tfs-linux-www.corp.tfslabs.com/
The Apache placeholder document should be displayed in the web browser:

Figure 10.3.1: The Apache test website is installed by default on an Ubuntu server. The A
record for the TFS-CA01 server is being used to access the page.

296 | Practical Guide to PKI with Windows Server

Since the certificate for the TFS-LINUX-WWW server was setup using a SAN certificate,
the website can also be reached using the CNAME record as well:

http://www.corp.tfslabs.com/

Once the Apache service has been confirmed to be working correctly with SSL, there are
no additional steps to complete.

Deploy Certificates to a Linux Server - Nginx Setup

Adding the SSL certificate to the Nginx web server is trivial to do, and only requires
modifying one configuration file to enable SSL. To enable SSL on Nginx on the default
website, perform the following steps on the TFS-LINUX-WWW server:

1. Install the Nginx web server using the following command:

sudo apt-get install nginx

2. Edit the /etc/nginx/sites-available/default file and make following changes. Add or

edit the configuration file for these configuration items:

/etc/nginx/sites-available/default

listen 443 ssl default_server ;

listen [::]:443 ssl default_server ;

ssl_certificate / etc / ssl / TFS - LINUX - WWW / tfs - linux - www . cer ;
ssl_certificate_key / etc / ssl / TFS - LINUX - WWW / tfs - linux - www . key ;

3. Run the following command to restart the Nginx service.

sudo service nginx restart

4. Run the following command to enable the Nginx service to start when the server is
booted:

sudo systemctl enable nginx

5. If there were no errors with the Nginx service, the configuration is now complete.

If there were no issues with configuring SSL on Nginx, you can test that SSL is working by
going to the following website:

http://tfs-linux-www.corp.tfslabs.com/

Certificate Enrollment | 297

The Nginx placeholder document should be displayed in the web browser:

Figure 10.3.3: The Nginx test website is installed by default on an Ubuntu server. The A
record for the TFS-CA01 server is being used to access the page.

Since the certificate for the TFS-LINUX-WWW server was setup using a SAN certificate,
the website can also be reached using the CNAME record as well:

http://www.corp.tfslabs.com/

Once the Nginx service has been confirmed to be working correctly with SSL, there are no
additional steps to complete.

Optional: Deploy Certificates to Android

Since the Root and Subordinate certificates have been setup for deployment in an earlier
chapter, you can now test that they work correctly on an Android device. To test the Root
and Subordinate certificates correctly, you will need to install the two certificates on the
Android device. Once the certificates have been installed, you can go to any of the
internal websites that have already been secured with HTTPS for verification.

If you do not have an Android device for testing or require this functionality, you can skip
this section.

298 | Practical Guide to PKI with Windows Server

To install and test the Root and Subordinate certificates on an Android device, perform
the following steps:

1. On the Android device, open the http://pki.corp.tfslabs.com/ website in Chrome.

This is to ensure that you can access the TFS-CA01 server on the device:

2. In Chrome, open the http://pki.corp.tfslabs.com/Certficates/ website. This website

contains the Root and Subordinate certificates that can be downloaded and installed:

3. Click on the link for the TFS Labs Certificate Authority.crt. You will be prompted to
enter your password to continue.

Certificate Enrollment | 299

 4. On the Name the certificate page, enter the Certificate name of TFS Labs Certificate
Authority. For the Credential use selection, ensure that VPN and apps is selected.
Click the OK button to continue:

5. In Chrome, open the http://pki.corp.tfslabs.com/Certficates/ website.

6. Click on the link for the TFS Labs Enterprise CA.crt and enter your password.
7. On the Name the certificate page, enter the Certificate name of TFS Labs Enterprise
CA. For the Credential use selection, ensure that VPN and apps is selected. Click the
OK button to continue.
8. To confirm that the Root and Subordinate certificates are installed and working, in
Chrome, open the https://pki.corp.tfslabs.com/ website. The website should now
be encrypted using SSL:

300 | Practical Guide to PKI with Windows Server

 9. If you click on the Lock icon in the address bar, you will see that the website is
encrypted using the TFS Labs Enterprise CA:

10. To view the Root and Subordinate certificates that are located on the Android device,
open the Settings app, and go to Security > Encryption & credentials > Trusted
credentials > User. The two certificates should be listed:

11. If there were no issues with the certificates on the Android device, the configuration
is now complete.

Once the Root and Subordinate certificates have been verified to be installed on the
Android device, the TFS Labs domain certificates are verified to be working correctly.

Certificate Enrollment | 301

Optional: Deploy Certificates to iOS
Since the Root and Subordinate certificates have been setup for deployment in an earlier
chapter, you can now test that they work correctly on an iOS device. To test the Root and
Subordinate certificates correctly, you will need to install the two certificates on the iOS
device. Once the certificates have been installed, you can go to any of the internal
websites that have already been secured with HTTPS for verification.

If you do not have an iOS device for testing or require this functionality, you can skip this
section.

To install and test the Root and Subordinate certificates on an iOS device, perform the
following steps:

1. On the iOS device, open the http://pki.corp.tfslabs.com/ website in Safari. This is to

ensure that you can access the TFS-CA01 server on the device:

302 | Practical Guide to PKI with Windows Server

2. In Safari, open the http://pki.corp.tfslabs.com/Certficates/ website. This website
contains the Root and Subordinate certificates that can be downloaded and installed:

3. Click on the link for the TFS Labs Certificate Authority.crt. You will get a prompt
stating, This website is trying to download a configuration profile. Do you want to
allow this?. Click the Allow button to continue. The Profile Downloaded prompt will
appear, click the Close button to continue.

Certificate Enrollment | 303

 4. Open the Settings app on your iOS device and select the Profile Downloaded menu
option. A prompt should appear with the Install Profile options for the TFS Labs
Certificate Authority. Click the Install button. You may be prompted to enter your
credentials. On the Warning prompt, click the Install button twice to continue. Click
Done to finish the installation:

304 | Practical Guide to PKI with Windows Server

5. Go to Settings > General > About > Certificate Trust Settings. Under Enable Full
Trust For Root Certificates, enable the TFS Labs Certificate Authority certificate. A
prompt for enabling a Root Certificate will appear, click Continue to complete the
certificate trust:

6. In Safari, open the http://pki.corp.tfslabs.com/Certficates/ website. This website

contains the Root and Subordinate certificates that can be downloaded and installed.
7. Click on the link for the TFS Labs Enterprise CA.crt. You will get a prompt stating,
This website is trying to download a configuration profile. Do you want to allow
this?. Click the Allow button to continue. The Profile Downloaded prompt will appear,
click the Close button to continue.
8. Open the Settings app on your iOS device and select the Profile Downloaded menu
option. A prompt should appear with the Install Profile options for the TFS Labs
Enterprise CA. Click the Install button. You may be prompted to enter your credentials.
On the Warning prompt, click the Install button twice to continue. Click Done to finish
the installation.

Certificate Enrollment | 305

 9. Go to Settings > General > About > Certificate Trust Settings. Under Enable Full Trust
For Root Certificates, ensure that the option for the TFS Labs Certificate Authority
certificate is still enabled.
10. To confirm that the Root and Subordinate certificates are installed and working on
the iOS device, in Safari, open the https://pki.corp.tfslabs.com/ website. The default
IIS website should now be encrypted using SSL:

306 | Practical Guide to PKI with Windows Server

 11. To verify that the two certificates have been successfully installed on the iOS device,
you can confirm it by going to Settings > General > Profiles and checking that the
certificates are present:

12. If there were no issues with the certificates on the iOS device, the configuration is
now complete.

Once the Root and Subordinate certificates have been verified to be installed on the iOS
device, the TFS Labs domain certificates are verified to be working correctly.

Certificate Enrollment | 307

Optional: Deploy Certificates to macOS
Since the Root and Subordinate certificates have been setup for deployment in an earlier
chapter, you can now test that they work correctly on a macOS device. To test the Root
and Subordinate certificates correctly, you will need to install the two certificates on the
macOS device. Once the certificates have been installed, you can go to any of the internal
websites that have already been secured with HTTPS for verification. Unlike the Windows
operating system, macOS uses the local Keychain to store certificates.

If you do not have a macOS device for testing or require this functionality, you can skip
this section.

1. On the macOS device, open the http://pki.corp.tfslabs.com/ website in Safari. This

is to ensure that you can access the TFS-CA01 server on the device:

2. In Safari, open the http://pki.corp.tfslabs.com/Certficates/ website. This website

contains the Root and Subordinate certificates that can be downloaded and installed:

308 | Practical Guide to PKI with Windows Server

3. Download the TFS Labs Certificate Authority.crt and TFS Labs Enterprise CA.crt
files.
4. Open the Keychain Access app by going to Finder > Applications > Utilities > Keychain
Access.
5. Select System in the System Keychains on the left side of the window.
6. Click on the File menu and select the Import Items option to import a certificate
file into the System keychain. Select the TFS Labs Enterprise CA.crt certificate and
click the Open button to continue. You will be prompted for a password to install the
certificate.
7. The TFS Labs Certificate Authority certificate should been shown with a red X, which
means that it is not trusted in the operating system. To enable trust for the certificate,
double-click on the TFS Labs Certificate Authority certificate. Under the Trust setting,
change the setting for When using this certificate to Always Trust. You will be
prompted for a password to trust the certificate.
8. Click on the File menu and select the Import Items option to import a certificate file
into the System keychain. Select the TFS Labs Certificate Authority.crt certificate
and click the Open button to continue. You will be prompted for a password to install
the certificate.
9. The TFS Labs Certificate Authority certificate should be shown with a red X, which
means that it is not trusted in the operating system. To enable trust for the certificate,
double-click on the TFS Labs Enterprise CA certificate. Under the Trust setting,
change the setting for When using this certificate to Always Trust. You will be
prompted for a password to trust the certificate.

Certificate Enrollment | 309

 10. To confirm that the Root and Subordinate certificates are installed and working, in
Safari, open the https://pki.corp.tfslabs.com/ website. The website should now be
encrypted using SSL:

11. To verify that the two certificates have been successfully installed on the macOS
device, you can confirm it by going Finder > Applications > Utilities > Keychain Access
and checking that the certificates are present.
12. If there were no issues with the certificates on the macOS device, the configuration
is now complete.

Once the Root and Subordinate certificates have been verified to be working on the
macOS device, the TFS Labs domain certificates are verified to be working correctly.

Certificate Enrollment Next Steps

Now that certificate auto-enrollment has been completed and certificates are being
automatically generated and deployed within the Active Directory domain, the Certificate
Authority is now functionally complete. There are a few housekeeping tasks left to
complete, but at this point the Certificate Authority is functionally complete.

310 | Practical Guide to PKI with Windows Server

Chapter 11 - AD CS
Post-Implementation Tasks

If you have been following the steps in this book correctly and have made it this far, you
should now have a complete and working Certificate Authority using Active Directory
Certificate Services. There are a few minor steps remaining to complete the setup, and
that is cleaning up files created during the implementation process and shutting down
the TFS-ROOT-CA server.

This chapter will focus on finalizing the setup of the Certificate Authority and what needs
to be done as an administrator to maintain Active Directory Certificate Services in the
future. It will also outline some suggested steps that can be taken to test Active Directory
Certificate Services within your existing environment.

AD CS Post-Implementation Tasks | 311

Virtual Floppy Disk Deletion
Once the Certificate Authority has been successfully implemented, completed, and
tested, the virtual floppy disk should be deleted as it is no longer required. The virtual
floppy disk contains important files that are not needed after the implementation, and by
keeping the virtual floppy disk can introduce an unnecessary security risk.

Prior to deleting the virtual floppy disk, if there are any BitLocker Recovery Keys, they
should be backed up. Should the virtual floppy disk be required in the future, specifically
for updating the Root CA CRL files, it can be easily recreated for that purpose.

Root CA Shut Down

Once the Certificate Authority has been successfully implemented, the Root CA can be
powered off as it is no longer needed once the Subordinate CA is online and operating
correctly. For security purposes it is important to keep the Root CA offline and protected.
The TFS-ROOT-CA virtual machine will need to be powered on at least once every 52
weeks to update the Base CRL.

Ensure that you do not delete this virtual machine. If you delete this virtual machine, it
will break your entire PKI and there will be no way of recovering from it.

Renewing the Root CA CRL

The only major task that you should need to perform on your PKI Infrastructure is that
you will need to renew the Base CRL from the Root CA at least once a year. Once the
implementation is completed you should setup a yearly recurring task to make sure this
task is not forgotten. You should put in a recurring task in your calendar every 50 weeks
to ensure that you renew the CRL in time. Renewing a CRL before it expires is perfectly
fine and will not affect the operation of a Certificate Authority.

Since the Root CA is an Offline CA, renewing the CRL file is the only time you will turn on
the TFS-ROOT-CA server as there is no other tasks that are needed to be performed on
the server.

To renew the CRL on the Root Certificate Authority, perform the following steps on the
TFS-ROOT-CA server:

1. Open the Certification Authority console (certsrv.msc) on the TFS-ROOT-CA server.

2. In the Certification Authority console, expand the TFS Labs Certificate Authority,
right-click on Revoked Certificates under TFS Labs Certificate Authority and select
All Tasks > Publish.
3. On the Publish CRL window, verify that New CRL is selected and click the OK button.
4. Close the Certification Authority console.

312 | Practical Guide to PKI with Windows Server

Alternatively, you can renew the CRL much faster by using PowerShell instead of the
Certification Authority console:

1. Open an elevated PowerShell prompt on the TFS-ROOT-CA server.

2. To publish the CRL, run the following command:

certutil.exe -crl

3. Close the elevated PowerShell prompt.

Once the CRL file has been renewed, use a virtual floppy disk to copy the file to the
TFS-CA01 server. You will need to create a virtual floppy disk to move the file, which will
also need to be formatted before it can be used. To copy the CRL file to the TFS-CA01
server, perform the following steps on the TFS-ROOT-CA server:

1. Add the virtual floppy disk to the TFS-ROOT-CA virtual machine. Format the virtual
floppy disk if necessary.
2. Copy the C:\Windows\System32\CertSrv\CertEnroll\TFS Labs Certificate Authority.crl
file to the C:\RootCA folder. Overwrite the existing file that is already in that directory.
3. Copy the C:\RootCA\TFS Labs Certificate Authority.crl file to the A:\ drive.
4. Eject the virtual floppy disk.

Once the CRL file has been copied from the Root CA server, it can then be placed on the
TFS-CA01 server so that it can be utilized:

1. Add the virtual floppy disk to the TFS-ROOT-CA virtual machine.

2. Copy the A:\TFS Labs Certificate Authority.crl file to the C:\CertData folder. Overwrite
the existing file that is already in that directory.
3. Eject the virtual floppy disk.

Now that the CRL file has been copied to the TFS-CA01 server, the virtual floppy disk can
be deleted as it is no longer required.

The final task is to publish the renewed Root CA CRL to Active Directory. This can be
completed by running the following command from an elevated PowerShell prompt on
the TFS-CA01 server:

certutil.exe –addstore `
–f root "C:\CertData\TFS Labs Certificate Authority.crl"

Renewing the Root CA CRL file is a trivial process, the most difficult step is ensuring that
you do not forget to renew the CRL. Not renewing the CRL can cause issues with the
entire PKI and renewing it before it expires can save a lot of trouble.

AD CS Post-Implementation Tasks | 313

Manually Back Up the PKI Infrastructure
When a Certificate Authority is deployed in a production environment, it is usually backed
up as part of the regular backups that are maintained by your organization. Like other
components of Windows Server, it is possible to manually create a backup of a
Certificate Authority without requiring any third-party tools. Since the Certificate Authority
for TFS Labs is a Two-Tier Certificate Authority, this means both servers would need to
be backed up to ensure that the Certificate Authority would function correctly if it needed
to be restored in this manner. You have the option of using the native Windows Server
Backup tool that is included with Windows Server to back up the entire server, or you can
use the tools within the Certificate Authority to just back up the Certificate Authority.

To manually back up just the Certificate Authority files using tools already available on
the server, perform the following steps on the TFS-CA01 server:

1. On the TFS-CA01 server, create a folder called CA-Backup (C:\CA-Backup) on the

root of the C:\ drive.
2. Open the Certification Authority console (certsrv.msc) on the TFS-CA01 server.
3. Right-click on TFS Labs Enterprise CA server, select the All Tasks option, and select
Back up CA...:

314 | Practical Guide to PKI with Windows Server

4. On the Welcome to the Certification Authority Backup Wizard window, click the Next
button to continue.

5. On the Items to Back Up window, select the following options and click the Next
button to continue:
• Private key and CA certificate - Enabled
• Certificate database and certificate database log - Enabled
• Back up to this location - C:\CA-Backup

AD CS Post-Implementation Tasks | 315

 6. On the Select a Password window, enter a complex password in both fields and click
the Next button to continue:

7. On the Completing the Certification Authority Backup Wizard window, click the Finish
button to close the wizard:

8. On the TFS-CA01 server, open the Registry Editor (regedit.exe).

9. Browse to the HKLM\SYSTEM\CurrentControlSet\Services\CertSvc Registry Key.

316 | Practical Guide to PKI with Windows Server

10. Right-click on the CertSvc Registry Key and select the Export option:

11. On the Export Registry File window, select the C:\CA-Backup folder, enter TFS Labs
Enterprise CA.reg in the File name field, and click the Save button to continue:

AD CS Post-Implementation Tasks | 317

 12. Close the Registry Editor.
13. If you browse to the C:\CA-Backup folder, it should list the files that have been backed
up:

At this point, the Certificate Authority has now been manually backed up. To backup any
other Certificate Authority servers in the environment, perform the same steps on those
servers.

Certificate Authority Backup Files

Ensure that the files that have been backed up from the Certificate Authority are
kept in a safe location. Even though the files are saved with a password, they
should not be left in a location where they could be obtained by an attacker.

Certificate Authority Backups

Just like every important infrastructure server in your environment, you must
ensure that the Root and Subordinate Certificate Authority servers are backed up
regularly and can be restored successfully. If there is an issue with backups and
the Root CA is lost, then the PKI for your environment is effectively broken forever,
and the only way to fix it is to create a new PKI and then re-issue all certificates.

318 | Practical Guide to PKI with Windows Server

Active Directory Former Certificate Authorities
Before attempting to implement a Certificate Authority in your Active Directory domain,
one important thing that you should check for prior to implementation is if there are
former Certificate Authorities present in the domain. It is entirely possible that someone
at some point in the past implemented a Certificate Authority on an older version of
Active Directory Certificate Services that is no longer compatible with the domain. It is
also possible that the Certificate Authority stopped being maintained at some point and
there are remnants of it in Active Directory. Regardless of how or why the former
Certificate Authority is present on the domain, it should be safely removed prior to putting
a new Certificate Authority in production. The process of removing a former Certificate
Authority is beyond the scope of this book, but Microsoft does provide excellent
documentation on how to do this properly.

There are several ways that a former Certificate Authority can cause issues with a new
Active Directory Certificate Services deployment:

• Cause conflicts with the CDP and AIA settings.

• Cause issues with Enterprise CA deployments.
• Cause issues with Certificate Templates that are stored in Active Directory.

The first step should be to check Active Directory to see if there was a former Certificate
Authority in your domain. On any of the Domain Controllers in your domain, perform the
following steps:

1. Open the Active Directory Sites and Services (dssite.msc) console on a Domain
Controller in your domain:

AD CS Post-Implementation Tasks | 319

 2. Ensure that the Active Directory Sites and Services node is selected, click on the
View menu and select the Show Services Node option:

3. Expand the Active Directory Sites and Services > Services > Public Key Services
node:

320 | Practical Guide to PKI with Windows Server

 4. There are three nodes to check to verify that there was not previously an Enterprise
CA or Root CA present on the domain:
• AIA
• CDP
• Certification Authorities
5. If there was previously an Enterprise CA or Root CA present on the domain, any
of those nodes will contain references to servers that hosted the Active Directory
Certificate Services role. You can then check those servers to determine if they are
still in use.
6. Close the Active Directory Sites and Services console.

There is an alternative method to checking Active Directory for former Certificate

Authorities by using the command line:

certutil.exe -dump

The output will display all known Enterprise CA servers that are configured in Active
Directory:

Figure 11.5.1: The certutil.exe tool will list the Enterprise CA servers that are registered
within Active Directory.

AD CS Post-Implementation Tasks | 321

You can also check Group Policy on the domain to see if there are any Group Policy
Objects that are being used to deploy certificates. You can also check the Certificate
Store on servers and workstations to see if there are any certificates in the Trusted Root
Certification Authorities or Intermediate Certification Authority Stores that would have
come from an Enterprise CA. Typically, these certificates are easy to find because the
Root Certificate is usually missing since it is not deployed automatically by the Enterprise
CA.

It is important to check if there are former Certificate Authorities in your domain prior to
attempting to deploy a new one. Removing former Certificate Authorities is easier before
adding a new one to the environment, and leaving an old Certificate Authority in place can
cause unexpected issues later that are not immediately apparent with a new Active
Directory Certificate Services deployment. By performing this simple check, you can save
yourself a lot of time and troubleshooting later.

Test Active Directory Certificate Services on your Domain

There are a few ways to test an Active Directory Certificate Services deployment on an
existing Active Directory domain without making changes to the production network.
Since Active Directory Certificate Services make changes to Active Directory, it is good
practice to test the deployment prior to putting it into production. All you need for testing
purposes is a Domain Controller that is a member of your Active Directory Domain. This
is not difficult to do, and there are a few options for an existing Active Directory domain:

• Clone an existing Domain Controller to a new virtual machine.

• Provision a new Domain Controller in a virtual machine and allow all Active Directory
data to synchronize with it.

Regardless of which method you choose to use for getting a Domain Controller for your
existing Active Directory domain, ensure that you perform the following steps prior to
attempting to deploy Active Directory Certificate Services:

• Place the Domain Controller on a network segment that has no connections to your
production network.
• Update the DNS records on the Domain Controller to allow it to handle its own DNS
resolution.
• If the Domain Controller does not have all FSMO roles available, seize those roles to
ensure that all FSMO roles are on that Domain Controller.

Once the Domain Controller has been properly isolated and setup for proper
authentication and DNS resolution, you can then proceed to testing the deployment of
Active Directory Certificate Services on your domain. This book used the TFS Labs
domain as an example, and you can easily modify the deployment steps to fit with your
Active Directory domain.

322 | Practical Guide to PKI with Windows Server

For example, if you were using the MJCB Active Directory domain, the Active Directory
environment might look like this:

Figure 11.6.1: The MJCB Active Directory domain consists of three servers and one
workstation.

The certificate hierarchy for the MJCB domain might look like this:

Figure 11.6.2: The MJCB Certificate Authority hierarchy is a Two-Tier Certificate Authority
consisting of a Root and Subordinate CA.

AD CS Post-Implementation Tasks | 323

Testing the deployment of Active Directory Certificate Services in a controlled manner is
strongly recommended prior to putting it into production. Active Directory domains that
have been in production for extended periods of time tend to accumulate technical
issues as they are upgraded and migrated over time. Testing the deployment of Active
Directory Certificate Services in a controlled manner on a copy of a Domain Controller is
something that you should seriously consider doing prior to deploying it in production.

AD CS Post-Implementation Tasks Next Steps

At this point you should now have a completely functioning Certificate Authority using
Active Directory Certificate Services and there are no additional steps to complete.

You should make it a habit to occasionally check the Certification Authority and the
Enterprise PKI console on the TFS-CA01 server. You should verify that there are no
certificates in a pending state and that the Certificate Authority is always healthy.

324 | Practical Guide to PKI with Windows Server

Chapter 12 - AD CS Quick Start

This chapter will focus on quickly deploying a Two-Tier Certificate Authority using Active
Directory Certificate Services. This chapter will use a subset of the instructions that were
provided in the previous chapters of this book. This chapter uses a simplified and basic
Active Directory environment for demonstration purposes, which represents the bare
minimum that is required for Active Directory Certificate Services to operate correctly. To
make the deployment of Active Directory Certificate Services faster, all configurations will
be done using the CLI instead of the GUI, whenever possible.

This chapter is optional, and if you have already completed the Certificate Authority using
the steps in previous chapters, you can skip this chapter as it is not needed.

There are several items that are intentionally omitted from this chapter to make the
deployment faster, and those items include:

• Group Policy and Security Policy changes to the Root CA server.

• BitLocker encryption of the Root CA server.
• Auditing in Active Directory Certificate Services.
• A Windows 10 workstation for testing purposes.
• Deployment of certificates using Group Policy.
• Online Responder role deployment and configuration.
• Private key archival and recovery.
• Certificate Template customization.
• Certificate enrollment options.

Even though this chapter focuses on quickly deploying a Certificate Authority using
Active Directory Certificate Services using all available CLI commands, it does not offer
an automated or scripted method of setting it up in that manner.

This chapter will focus on setting up a basic Two-Tier Certificate Authority, with the
option to add any additional features to the Certificate Authority at any given time after it
has been created.

AD CS Quick Start | 325

AD CS Quick Start - Environment Setup
The Active Directory domain that is going to be used in this chapter is the TFS Labs
domain (corp.tfslabs.com), which is being used by a small IT Company that is based in
Toronto, Ontario, Canada. In total, there are three Windows servers that will be used to
build and test the TFS Labs environment:

Figure 12.1.1: The TFS Labs Active Directory domain consists of three servers and one
workstation. This domain represents the bare minimum environment required to test
Active Directory Certificate Services.

The virtual machines that are being used in this chapter for the test environment are
using the following specifications:

VM Operating System CPU Memory Disk IP Address

TFS-CA01 Windows Server 2019 2 4096 MB 40 GB 10.100.1.101
TFS-DC01 Windows Server 2019 2 4096 MB 40 GB 10.100.1.100
TFS-ROOT-CA Windows Server 2019 2 4096 MB 40 GB N/A

326 | Practical Guide to PKI with Windows Server

Here is a breakdown of the servers and workstations that are being used in the TFS Labs
test environment:
• TFS-CA01 is the Subordinate Certificate Authority in the TFS Labs domain. It is an
Enterprise CA that is using the Active Directory Certificate Services role. It is used to
issue all certificates within the domain, except for the Root certificate that is issued
by the Root Certificate Authority that is located on the TFS-ROOT-CA server. It is also
used to handle CRL distribution that is needed for certificate revocation. It is a TFS
Labs domain member server.
• TFS-DC01 is the Domain Controller for the TFS Labs Active Directory domain. The
Active Directory Forest and Domain Functional Levels are set to Windows Server
2016 Functional Levels.
• TFS-ROOT-CA is the Root Certificate Authority for the TFS Labs domain, which is a
Standalone CA that is using the Active Directory Certificate Services role. It is used to
create the Root certificate and is also used to sign the certificate for the Subordinate
Certificate Authority. It is left in an offline state unless there is an issue with the
Subordinate Certificate Authority or the CRL needs to be updated, which occurs at
least once a year. It is not a member of the TFS Labs domain and is technically just a
workgroup server. Once the implementation of the Certificate Authority is complete,
this server can be shut down, but not deleted. This server has no network access.
For networking purposes all devices in this test environment are using the 10.100.1.0/24
network. Since there is only a handful of devices involved, all the IP addresses are set to
static and there is no DHCP server present to automatically distribute IP addresses.
For the certificates that will be issued for the TFS Labs domain, there will be one Root
and one Subordinate certificate in a Two-Tier Certificate Authority. Here is an overview of
what that certificate hierarchy will look like:

Figure 12.1.2: The TFS Labs Certificate Authority is a Two-Tier Certificate Authority
consisting of a Root and Subordinate Certificate Authority.

AD CS Quick Start | 327

The certificate structure and associated servers for TFS Labs will be as follows:

Certificate Name Certificate Type Validity

TFS Labs Certificate Authority Root Certificate 10 years
TFS Labs Enterprise CA Subordinate Certificate 5 years
N/A Issued Certificate 1 year

Now that the TFS Labs domain has been explained, including the required virtual
machines and the format of the certificate structure, you can proceed to provisioning the
Domain Controller for the TFS Labs domain.

328 | Practical Guide to PKI with Windows Server

AD CS Quick Start - AD DS Setup
Provision and configure a new virtual machine called TFS-DC01, and install Windows
Server 2019 Standard (Desktop Experience) using the following specifications:

• Virtual Machine Generation - 1

• Virtual Processors - 2
• Virtual Memory - 4096 MB
• Virtual Hard Disk - 40 GB
• Virtual Network Adapters - 1

Once the TFS-DC01 virtual machine has been created and the operating system has been
installed, there are a few tasks that need to be completed:

• Set the password for the local administrator account (ensure that you use a complex
password).
• Set the hostname of the server to TFS-DC01. Restart the server to apply the change.

Once the local Administrator account and the hostname have been setup, you will also
need to configure the network settings for the virtual machine:

IP Address 10.100.1.100
Netmask 255.255.255.0
Gateway 10.100.1.1
DNS Server 1 8.8.8.8

Once the network has been setup correctly, you can then proceed to setting up the
TFS-DC01 server as a Domain Controller.

TFS Labs External DNS Servers

Once the TFS-DC01 server has been successfully promoted to a Domain

Controller, the DNS settings will be automatically updated to utilize the DNS server
that has been added as part of the installation. The TFS-DC01 server will be
added as the first DNS server in the network settings, and the original DNS entry
will be automatically moved to the second DNS server.

If you are having any DNS resolution issues after the Domain Controller
promotion, check the DNS settings on the TFS-DC01 server to ensure that there is
a forwarding DNS server listed.

AD CS Quick Start | 329

 TFS Labs Domain Administrator Account Password

The password that is set for the local administrator account during the initial
setup of the TFS-DC01 server will become the password for the Domain
Administrator account for the TFS Labs domain once the server has been
promoted to a Domain Controller. Ensure that this is a strong password since it is
going to be the most privileged account in the TFS Labs domain.

Once the Active Directory installation has been completed, the local administrator
account that is on the TFS-DC01 server will become the TFSLABS\Administrator
account, which is the Domain Administrator account for the TFS Labs domain.
This Domain Administrator account will be used for the remainder of the
Certificate Authority implementation, except for any configurations made on the
Offline Root CA server.

AD DS Setup - AD DS Installation
To install the Active Directory Domain Services role on the TFS-DC01 server, perform the
following steps:
1. Open an elevated PowerShell prompt.
2. Run the following command to install the Active Directory Domain Services role and
the necessary Remote Server Administration Tools:

Install-WindowsFeature AD-Domain-Services, RSAT-ADDS

3. The command will automatically install the Active Directory Domain Services role
and output a Success status of True.
4. Once the installation for Active Directory Domain Services has completed, you can
close the PowerShell prompt.
Once the Active Directory Domain Services role has been installed on the TFS-DC01
server, you can proceed to configuring the role to create the Domain Controller.

AD DS Setup - AD DS Configuration
Once the Active Directory Domain Services role has been installed on the TFS-DC01
server, it will need to be properly configured to become a Domain Controller for the TFS
Labs domain. In the process of configuring the TFS Labs domain, the following Active
Directory Domain settings will be configured on the TFS-DC01 server:

Forest Name corp.tfslabs.com

NetBIOS Domain Name TFSLABS
Forest Functional Level Windows Server 2016
Domain Functional Level Windows Server 2016

330 | Practical Guide to PKI with Windows Server

To configure the TFS-DC01 server as a Domain Controller for the TFS Labs domain,
perform the following steps:

1. Open an elevated PowerShell prompt.

2. Run the following command to import the ADDSDeployment PowerShell module
which is needed to configure Active Directory Domain Services:

Import-Module ADDSDeployment

3. Run the following command to configure Active Directory Domain Services:

Install-ADDSForest `
-CreateDnsDelegation:$false `
-DatabasePath "C:\Windows\NTDS" `
-DomainMode "WinThreshold" `
-DomainName "corp.tfslabs.com" `
-DomainNetbiosName "TFSLABS" `
-ForestMode "WinThreshold" `
-InstallDns:$true `
-LogPath "C:\Windows\NTDS" `
-NoRebootOnCompletion:$false `
-SysvolPath "C:\Windows\SYSVOL" `
-Force:$true

4. The command will prompt you to set the SafeModeAdministratorPassword, which is

the Directory Services Restore Mode (DSRM) password. Enter a complex password
for this, and the command will prompt you to confirm the password before proceeding
(ensure that you record this password in case it is needed).
5. The Active Directory Domain Services configuration will take several minutes to
complete.
6. The TFS-DC01 server will automatically restart when the configuration has completed.

Once the TFS-DC01 server has restarted, there is now a functioning Domain Controller of
the TFS Labs domain.

AD DS Setup - OU Configuration
It is optional to create an OU structure for organizing the objects in the Active Directory
domain, so creating one is your choice. The OU structure for the TFS Labs domain is not
complex, and consists of the following structure:

• TFS Labs
• TFS Labs\TFS Labs Servers
• TFS Labs\TFS Labs Users
• TFS Labs\TFS Labs Workstations

AD CS Quick Start | 331

To create a basic OU structure using PowerShell, perform the following steps on the
TFS-DC01 server:

1. Open an elevated PowerShell prompt.

2. Run the following commands to create the OU structure:

New-ADOrganizationalUnit `
-Name "TFS Labs" `
-Path "DC=corp,DC=tfslabs,DC=com"

New-ADOrganizationalUnit `
-Name "TFS Servers" `
-Path "OU=TFS Labs,DC=corp,DC=tfslabs,DC=com"

New-ADOrganizationalUnit `
-Name "TFS Users" `
-Path "OU=TFS Labs,DC=corp,DC=tfslabs,DC=com"

New-ADOrganizationalUnit `
-Name "TFS Workstations" `
-Path "OU=TFS Labs,DC=corp,DC=tfslabs,DC=com"

3. Close the PowerShell prompt.

Once the OU structure has been created for the TFS Labs domain, the Domain
Administrator account needs to have the e-mail address field set.

AD DS Setup - Administrator Configuration

Before moving on from setting up the TFS Labs domain, the Domain Administrator
account should have the e-mail address field set as well. The Domain Administrator
account can be found in the Users OU in the TFS Labs domain (this account is not moved
at all in this chapter, so it should be found there by default). The change can be made
from an elevated PowerShell prompt with the following command:

Set-ADUser `
-Identity Administrator `
-EmailAddress "[email protected]"

Now that the e-mail field has been set for the Domain Administrator account, there
should be no problems in issuing certificates for that account.

AD DS Setup - Next Steps

With the Domain Controller for the TFS Labs domain setup and working correctly, you can
now proceed to setting up the Root Certificate Authority.

332 | Practical Guide to PKI with Windows Server

AD CS Quick Start - Root CA Setup
Provision and configure a new virtual machine called TFS-ROOT-CA and install Windows
Server 2019 Standard (Desktop Experience) using the following specifications:

• Virtual Machine Generation - 1

• Virtual Processors - 2
• Virtual Memory - 4096 MB
• Virtual Hard Disk - 40 GB
• Virtual Network Adapters - 0

Once the TFS-ROOT-CA virtual machine has been created and the operating system has
been installed, there are a few tasks that need to be completed before proceeding to
configure the Root Certificate Authority:

1. Set the local Administrator account on the TFS-ROOT-CA server to a complex password
that is at least 14 characters and store the password securely. Ensure that there
are no additional user accounts present on the server (this can be verified in the
Computer Management console (compmgmt.msc)). The Guest account should already
be disabled by default and is renamed in a later step to obfuscate the account.
2. Set the hostname of the server to TFS-ROOT-CA. Restart the server to apply the
change.
3. Set the TFS-ROOT-CA server to be a member of the TFS-CA workgroup. Restart the
server to apply the change.
4. On the root of the C:\ drive create a folder called RootCA (C:\RootCA). This folder will
store the Root certificate, Subordinate certificate, CRL files and any other certificate
files that are needed during the entire Certificate Authority implementation process.
5. Create a virtual floppy disk named RootCAFiles.vfd and then insert the RootCAFiles.vfd
virtual floppy disk into the virtual floppy drive. Format the floppy disk using the
default settings using Windows File Explorer. Eject the virtual floppy disk when the
formatting has been completed.

Root CA Setup - Local Policies

Once the TFS-ROOT-CA server has been setup, the Local Group Policy settings and Local
Security Policies can now be configured to increase the security of the local
administrator account on the server. Normally these changes are made with Group Policy
on an Active Directory domain, but since the TFS-ROOT-CA server is not on a domain the
changes need to be made locally.

If these policy changes are required, the steps are thoroughly documented in an earlier
chapter, otherwise you can proceed to configuring the CAPolicy.inf file for the Root CA.

AD CS Quick Start | 333

Root CA Setup - CAPolicy.inf Installation
The CAPolicy.inf file is used to add configuration details to the Certificate Authority at the
time of creation. Create a file in the C:\Windows folder called CAPolicy.inf (ensure that it
is saved with the correct file extension otherwise these settings will be ignored). Copy the
following contents into this file and make changes as needed to match your organization:

C:\Windows\CAPolicy.inf

[ Version ]
Signature =" $Windows NT$ "

[ PolicyStatementExtension ]
Policies = AllIssuancePolicy , InternalPolicy
Critical = FALSE

; Enables all Certificate Templates .

[ AllIssuancePolicy ]
OID =2.5.29.32.0

[ InternalPolicy ]
OID =1.2.3.4.1455.67.89.5
Notice =" The TFS Labs Certification Authority is internal only ."
URL = http :// pki . corp . tfslabs . com / cps . html

[ Certsrv_Server ]
; Renewal information for the Root CA .
RenewalKeyLength =4096
RenewalValidityPeriod = Years
RenewalValidityPeriodUnits =10

; Disable support for issuing certificates using RSASSA - PSS .

AlternateSignatureAlgorithm =0

; The CRL publication period is the lifetime of the Root CA .

CRLPeriod = Years
CRLPeriodUnits =10

; The option for Delta CRL is disabled since this is a Root CA .

CRLDeltaPeriod = Days
CRLDeltaPeriodUnits =0

Delta CRL with Root Certificate Authorities

A Delta CRL is not normally required for a Root Certificate Authority, especially one
that is offline since it is not normally handling certificate revocations in a PKI. The
Root CA is only ever used to issue a Base CRL when there are Subordinate
Certificate Authorities. The only certificates that are typically revoked by a Root
CA is a Subordinate CA, so that would necessitate the deployment of a new Base
CRL instead of a Delta CRL.

334 | Practical Guide to PKI with Windows Server

 OID Number

You can update the OID number in the InternalPolicy section of the CAPolicy.inf
file for your deployment if it is required for your organization. The OID number in
this example is used in Microsoft technical documentation, but it should work for
your organization if it is only ever going to be used internally. If you require a
customized OID number, you can register for a Private Enterprise Number through
the IANA.

If you would like to use your PEN number for the Certificate Authority, modify the
OID line in the InternalPolicy section to OID=1.3.6.1.4.1.X (replace the X with your
PEN number).

CAPolicy.inf File Name and Locations

Ensure that the CAPolicy.inf file has been properly saved in the C:\Windows folder
(%WINDIR%). Also make sure that the file extension is set to INF and not TXT. A
common mistake is to accidentally save the file as CAPolicy.inf.txt.

If the CAPolicy.inf file is not saved in the correct directory and without the correct
file extension, all settings in the file will be ignored at the time when the Certificate
Authority is created.

Root CA Setup - AD CS Role Installation

The Active Directory Certificate Services installation can be performed using PowerShell
by running the following steps on the TFS-ROOT-CA server:

1. Open an elevated PowerShell prompt.

2. Run the following command to install the Active Directory Certificate Services role
and the necessary Administration Tools:

Add-WindowsFeature -Name ADCS-Cert-Authority -IncludeManagementTools

3. The command will automatically install the Active Directory Certificate Services role
and output a Success status of True.
4. Once the installation for Active Directory Certificate Services has completed, you
can close the PowerShell prompt.

Once the Active Directory Certificate Services role has been installed, you can then
proceed to configuring the role and creating the Root certificate for the TFS Labs domain.

AD CS Quick Start | 335

Root CA Setup - AD CS Role Configuration
Once the Active Directory Certificate Services role has been installed it will need to be
configured to work as the Root Certificate Authority. In the process of configuring the
Active Directory Certificate Services role for the TFS Labs domain, the following Root
Certificate will be created:

Certificate Authority Setup Type Standalone CA

Certificate Authority Type Root CA
Cryptographic Provider RSA#Microsoft Software Key Storage Provider
Key Length 4096 Bits
Signature Hash Algorithm SHA256
CA Common Name TFS Labs Certificate Authority
Validity Period 10 years

During the configuration of Active Directory Certificate Services, the option to create a
new private key for the Root Certificate Authority is presented. This is because this a new
CA installation and the private key is not being restored from a previous server and this is
the Root of the PKI. The private key for the Root certificate will reside on the
TFS-ROOT-CA server.

The Active Directory Certificate Services configuration can be performed using

PowerShell by running the following steps on the TFS-ROOT-CA server:

1. Open an elevated PowerShell prompt.

2. Run the following command to configure the Active Directory Certificate Services
role and create the Root Certificate:

Install-AdcsCertificationAuthority `
-CAType StandaloneRootCA `
-CACommonName "TFS Labs Certificate Authority" `
-KeyLength 4096 `
-HashAlgorithm SHA256 `
-CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
-ValidityPeriod Years `
-ValidityPeriodUnits 10 `
-DatabaseDirectory $(Join-Path $env:SystemRoot "System32\CertLog") `
-Force

3. The command will automatically configure the Active Directory Certificate Services
role and output an ErrorID status of 0.
4. Once the configuration for Active Directory Certificate Services has completed, you
can close the PowerShell prompt.

At this point the Root Certificate for the TFS Labs domain has been created. You can now
validate that the Certificate Authority has been successfully created.

336 | Practical Guide to PKI with Windows Server

Root CA Setup - Root CA Validation
To verify that the Active Directory Certificate Services role has been successfully
configured and the Root certificate was created, you can open the Certification Authority
console (certsrv.msc) on the TFS-ROOT-CA server to check the CA.

You can also view the Root certificate and verify that it was created with the correct
values that you setup during the Active Directory Certificate Services configuration:

Figure 12.3.1: The TFS Labs Certificate Authority issued the certificate to itself, as it is the
root of the PKI.

When the Subordinate CA is created on the TFS-CA01 server, you will be able to validate
that the Offline CA is functioning correctly. If everything has been setup correctly for the
Root certificate, then you can proceed to configuring the CRL for the Root CA and
specifying the validity period for any signed certificates.

Root CA Setup - Root CA CRL Configuration

The CRL configuration for the Root CA is configured in this step to give greater control
over when the CRL expires and needs to be renewed. The time is being extended to 52
weeks since the CRL does not need to be updated that often on the Root CA. The changes
here also ensures that the Subordinate CA lifetime is extended from 1 year to 5 years.

AD CS Quick Start | 337

All the commands in this section are just making changes to the Windows Registry using
the certutil.exe command. You can view the settings for the Certificate Authority by
opening the Windows Registry (regedit.exe) and going to the following location:

HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

To configure the CRL settings on the Root Certificate Authority, perform the following
steps on the TFS-ROOT-CA server:

1. Open an elevated PowerShell prompt.

2. To define the Active Directory Configuration Partition Distinguished Name, run the
following command (replace DC=corp,DC=tfslabs,DC=com with the distinguished
name for your domain):

certutil.exe -setreg `
CA\DSConfigDN "CN=Configuration,DC=corp,DC=tfslabs,DC=com"

3. To define the Validity Period Units for all issued certificates by the Root Certificate
Authority, run following commands:

certutil.exe -setreg CA\ValidityPeriodUnits 5

certutil.exe -setreg CA\ValidityPeriod "Years"

4. To define the CRL Period Units and CRL Period, run the following commands:

certutil.exe -setreg CA\CRLPeriodUnits 52

certutil.exe -setreg CA\CRLPeriod "Weeks"

5. To define the CRL Overlap Period Units and CRL Overlap Period, run the following
commands:

certutil.exe -setreg CA\CRLOverlapPeriodUnits 12

certutil.exe -setreg CA\CRLOverlapPeriod "Hours"

6. Restart the Active Directory Certificate Services service to apply the changes:

net stop CertSvc

net start CertSvc

7. Close the PowerShell prompt.

Once the CRL settings have been configured on the Root Certificate Authority, you can
then proceed to configuring auditing on the Root CA.

338 | Practical Guide to PKI with Windows Server

Active Directory Configuration Partition Distinguished Name

There are several ways to determine the Active Directory Configuration Partition
Distinguished Name in an Active Directory domain. One of the easiest ways to
determine the correct format of this name can be accomplished it in only a few
steps by using the Active Directory Users and Computers console:

1. On the TFS-DC01 Domain Controller, open the Active Directory Users and
Computers console (dsa.msc).
2. Go to the View menu and select Advanced Features.
3. Right-click on corp.tfslabs.com, which is the root of the Domain, and select
Properties.
4. Go to the Attribute Editor tab.
5. Scroll down until you find the distinguishedName Attribute Field and click the
View button. The String Attribute Editor window will appear:

6. Copy the value in the Value field, this is the information needed for later:

7. Close the Active Directory Users and Computers console.

Aside from using the Active Directory Users and Computers console to retrieve
the Active Directory Configuration Partition Distinguished Name, you can also use
the ADSI Edit (Active Directory Service Interface Editor) tool (adsiedit.msc) to
obtain the same result.

AD CS Quick Start | 339

Root CA Setup - CDP and AIA Configuration
The CRL files that are provided by the Root CA are distributed with the Subordinate CA.
This is because the Root CA is not available on the network, so there is no way for devices
to access the files on the TFS Labs domain. This is accomplished by configuring the CDP
and AIA settings on the Root CA by specifying certain DNS records and pointing them to
the TFS-CA01 server. The Base CRL will be configured and exported as part of this
section, and the Delta CRL will be published on the Subordinate CA in the next chapter.
There are multiple locations where the CDP and AIA locations are used for the Root
Certificate Authority:
• Local file system (used by the TFS-ROOT-CA server)
• LDAP and Active Directory
• HTTP (to the TFS-CA01 server using http://pki.corp.tfslabs.com/)
The CDP and AIA settings can be configured using the command line using PowerShell
on the TFS-ROOT-CA server:
1. Open an elevated PowerShell prompt.
2. Run the following command to configure the CDP settings for the Root certificate
(execute this command as a single line with no breaks):

certutil.exe -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\

CertSrv\CertEnroll\%3%8%9.crl\n8:ldap:///CN=%7%8,CN=%2,CN=CDP,
CN=Public Key Services,CN=Services,%6%10\n0:http://%1/CertEnroll/
%3%8%9.crl\n6:http://pki.corp.tfslabs.com/CertData/%3%8%9.crl"

3. Run the following command to configure the AIA settings for the Root certificate
(execute this command as a single line with no breaks):

certutil.exe -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\

CertSrv\CertEnroll\%1_%3%4.crt\n0:ldap:///CN=%7,CN=AIA,
CN=Public Key Services,CN=Services,%6%11\n0:http://%1/CertEnroll/
%1_%3%4.crt\n2:http://pki.corp.tfslabs.com/CertData/%1_%3%4.crt"

4. Restart the Active Directory Certificate Services service to apply the changes:

net stop CertSvc

net start CertSvc

5. To publish the CRL, run the following command:

certutil.exe -crl

6. Close the elevated PowerShell prompt.

Now that the CRL settings have been successfully configured on the TFS-ROOT-CA server
and the CRL has been published, the CRL and the Root certificate can now be exported
so that the Subordinate CA server can host it for the TFS Labs domain.

340 | Practical Guide to PKI with Windows Server

Root CA Setup - Root CA Certificate and CRL Export
Exporting the Root certificate and the Root CRL is needed to make it available on the
TFS-CA01 server and for the rest of the TFS Labs domain. The links to these files were
referenced in the Root certificate configuration, so they will need to be copied to the
Subordinate CA server for users to be able to access these files. To copy the Root
certificate and Root CRL files, perform the following steps on the TFS-ROOT-CA server:

1. Copy the contents of the C:\Windows\System32\CertSrv\CertEnroll folder to the

C:\RootCA folder.
2. The following files should be present in the C:\RootCA folder:
• C:\RootCA\TFS Labs Certificate Authority.crl
• C:\RootCA\TFS-ROOT-CA_TFS Labs Certificate Authority.crt
3. Add the RootCAFiles.vfd virtual floppy disk to the TFS-ROOT-CA virtual machine.
4. Copy the contents of the C:\RootCA folder to the A:\ drive.
5. Eject the RootCAFiles.vfd virtual floppy disk.

Once the Root certificate and CRL files have been successfully copied to the virtual
floppy disk, all the initial tasks for the TFS-ROOT-CA server are now complete.

Root CA Setup - Next Steps

With the Root Certificate Authority for the TFS Labs domain setup and working correctly,
you can now proceed to setting up the Subordinate Certificate Authority.

AD CS Quick Start | 341

AD CS Quick Start - Subordinate CA Setup
Provision and configure a new virtual machine called TFS-CA01 and install Windows
Server 2019 Standard (Desktop Experience) using the following specifications:

• Virtual Machine Generation - 1

• Virtual Processors - 2
• Virtual Memory - 4096 MB
• Virtual Hard Disk - 40 GB
• Virtual Network Adapters - 1

Once the TFS-CA01 virtual machine has been created and the operating system has been
installed, there are a few tasks that need to be completed:

• Set the local Administrator account on the TFS-CA01 server to a complex password
that is at least 14 characters and store the password securely.
• Set the hostname to TFS-CA01. Restart the server to apply the change.

Once the local Administrator account and the hostname have been setup, you will also
need to configure the network settings for the virtual machine:

IP Address 10.100.1.101
Netmask 255.255.255.0
Gateway 10.100.1.1
DNS Server 1 10.100.1.100

Join the TFS-CA01 server to the TFS Labs domain. Restart the server to apply the change.

The TFS-CA01 server should be moved from the default Computer OU in Active Directory
to one of the dedicated OUs that was created earlier for the TFS Labs domain. This will
facilitate easier application of Group Policy objects, which are needed for Active
Directory Certificate Services should you choose to add them in the future. To move the
TFS-CA01 computer object, run the following command from an elevated PowerShell
prompt on the TFS-DC01 server:

Get-ADComputer "TFS-CA01" | `
Move-ADObject -TargetPath "OU=TFS Servers,OU=TFS Labs,DC=corp,DC=tfslabs,DC=com"

Once the TFS-CA01 server has been successfully joined to the TFS Labs domain, login
with the Domain Administrator account that was created earlier. The Domain
Administrator account will be required for the entire Active Directory Certificate Services
installation and configuration of the TFS-CA01 server. Once the server has been
completely setup and joined to the TFS Labs domain, you can proceed to the next steps
on creating DNS records to support the Active Directory Certificate Services role.

342 | Practical Guide to PKI with Windows Server

Subordinate CA Setup - Create CNAME Records in DNS
There is one DNS record that needs to be created in the DNS Zone to support the PKI
infrastructure in the TFS Labs domain, and that is the PKI.corp.tfslabs.com CNAME
record. This DNS record can be added by performing the following steps:

1. Open an elevated PowerShell prompt on the TFS-DC01 server.

2. Enter the following command to create a CNAME record for PKI.corp.tfslabs.com:

Add-DnsServerResourceRecordCName `
-Name "PKI" -HostNameAlias "TFS-CA01.corp.tfslabs.com" -ZoneName "corp.tfslabs.com"

3. Close the PowerShell prompt.

Once the DNS record has been created, you can proceed to creating the CAPolicy.inf file
that is needed to create the Subordinate certificate.

Subordinate CA Setup - CAPolicy.inf Installation

On the TFS-CA01 server, create a file in the C:\Windows folder called CAPolicy.inf. Copy
the following contents into this file:

C:\Windows\CAPolicy.inf

[ Version ]
Signature =" $Windows NT$ "

[ PolicyStatementExtension ]
Policies = AllIssuancePolicy , InternalPolicy
Critical = FALSE

; Enables all Certificate Templates .

[ AllIssuancePolicy ]
OID =2.5.29.32.0

[ InternalPolicy ]
OID =1.2.3.4.1455.67.89.5
Notice =" The TFS Labs Certification Authority is internal only ."
URL = http :// pki . corp . tfslabs . com / cps . html

[ Certsrv_Server ]
; Renewal information for the Subordinate CA .
RenewalKeyLength =4096
RenewalValidityPeriod = Years
RenewalValidityPeriodUnits =5

; Disable support for issuing certificates using RSASSA - PSS .

AlternateSignatureAlgorithm =0

; Load all certificate templates by default .

LoadDefaultTemplates =1

AD CS Quick Start | 343

 OID Number

You can update the OID number in the InternalPolicy section of the CAPolicy.inf
file for your deployment if it is required for your Organization. The OID number in
this example is used in Microsoft technical documentation, but it should work for
your organization if it is only ever going to be used internally. If you require a
customized OID number, you can register for a Private Enterprise Number through
the IANA.

If you used a particular OID for the Root certificate, ensure that you use the same
OID here as well.

If you would like to use your PEN number for the Certificate Authority, modify the
OID line in the InternalPolicy section to OID=1.3.6.1.4.1.X (replace the X with your
PEN number).

CAPolicy.inf File Name and Locations

Ensure that the CAPolicy.inf file has been properly saved in the C:\Windows folder
(%WINDIR%). Also make sure that the file extension is set to INF and not TXT. A
common mistake is to accidentally save the file as CAPolicy.inf.txt.

If the CAPolicy.inf file is not saved in the correct directory and without the correct
file extension, all settings in the file will be ignored at the time when the Certificate
Authority is created.

Subordinate CA Setup - AD CS Role Installation

The Active Directory Certificate Services installation can be performed using PowerShell
by running the following steps on the TFS-CA01 server:

1. Open an elevated PowerShell prompt.

2. Run the following command to install the Active Directory Certificate Services role,
as well as the Certification Authority Web Enrollment role, and the necessary
Administration Tools:

Add-WindowsFeature `
-Name ADCS-Cert-Authority, ADCS-Web-Enrollment, Web-Mgmt-Service `
-IncludeManagementTools

3. The command will automatically install the Active Directory Certificate Services role
and output a Success status of True.
4. Once the installation for Active Directory Certificate Services has completed, you
can close the PowerShell prompt.

344 | Practical Guide to PKI with Windows Server

Once the Active Directory Certificate Services role has been installed, you can then
proceed to configuring the role and creating the Subordinate certificate for the TFS Labs
domain.

Subordinate CA Setup - AD CS Role Configuration

Once the Active Directory Certificate Services role has been added, it will need to be
properly configured as the Subordinate Certificate Authority. In the process of
configuring the Active Directory Certificate Services role for the TFS Labs domain, the
following Subordinate Certificate be configured:

Certificate Authority Setup Type Enterprise CA

Certificate Authority Type Subordinate CA
Cryptographic Provider RSA#Microsoft Software Key Storage Provider
Key Length 4096 Bits
Signature Hash Algorithm SHA256
CA Common Name TFS Labs Enterprise CA
Validity Period 5 years

The Active Directory Certificate Services configuration can be performed using

PowerShell by running the following steps on the TFS-CA01 server:

1. Open an elevated PowerShell prompt.

2. Run the following command to configure the Active Directory Certificate Services
role and create the Subordinate Certificate Authority:

Install-AdcsCertificationAuthority `
-CAType EnterpriseSubordinateCA `
-CACommonName "TFS Labs Enterprise CA" `
-KeyLength 4096 `
-HashAlgorithm SHA256 `
-CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
-Force

3. The command will automatically configure the Active Directory Certificate Services
role and output a Success status of True.
4. Run the following command to configure the Certification Authority Web Enrollment
role:

Install-AdcsWebEnrollment -Force

5. The command will automatically configure the Certification Authority Web Enrollment
role and output an ErrorID status of 0.

AD CS Quick Start | 345

 6. Once the configuration for Active Directory Certificate Services has completed, you
can close the PowerShell prompt.

At this point the Subordinate Certificate Authority for the TFS Labs domain has been
created, but the Subordinate certificate needs to be issued. You can now validate that the
Certificate Authority has been successfully created.

Subordinate CA Setup - Subordinate CA Validation

At this point the Subordinate Certificate Authority for the TFS Labs domain has been
created, so there is now an Enterprise CA available. The Certificate Request for the
Subordinate certificate has been created, which means it will need to be submitted to the
Root Certificate Authority to complete the request. Until this CSR is submitted and
completed, the Enterprise CA will not function correctly.

Even though the Active Directory Certificate Services role was configured, it is not
currently running as there is no valid certificate present. If you open the Certification
Authority console (certsrv.msc), you will see that it is setup, but the service is not running:

Figure 12.4.1: The Certification Authority console is used to manage the CA and
allows administrators to issue and revoke certificates. This console also allows further
customization of the CA.

Once the Certificate Request file has been successfully generated, it will need to be
copied to the RootCAFiles.vfd virtual floppy disk since the Root CA on TFS-ROOT-CA
needs the request file to issue the Subordinate Certificate.

346 | Practical Guide to PKI with Windows Server

To copy the Certificate Request file from the TFS-CA01 server to the TFS-ROOT-CA server,
perform the following steps:

1. Add the RootCAFiles.vfd virtual floppy disk to the TFS-CA01 virtual machine.
2. Browse to the C:\ drive and copy the TFS-CA01.corp.tfslabs.com_corp-TFS-CA01-CA.req
to the A:\ drive.
3. Eject the RootCAFiles.vfd virtual floppy disk.

Once the Certificate Request has been successfully copied to the virtual floppy disk, you
can proceed to creating the CertData directory in IIS on the TFS-CA01 server.

Subordinate CA Setup - Create the CertData Virtual Directory

On the TFS-CA01 server, create a folder that will be used to host important certificate
files such as the Root certificate and the CRL files) for the users, workstations, and
servers in the TFS Labs domain. These are the necessary files from the Offline Root
Certificate Authority, which requires these files to be available for users. It can be created
by performing the following steps:

1. Add the RootCAFiles.vfd virtual floppy disk to the TFS-CA01 virtual machine.
2. On the root of the C:\ drive, create a folder called CertData (C:\CertData).
3. Open the A:\ drive and copy the TFS Labs Certificate Authority.crl and TFS-ROOT-CA_TFS
Labs Certificate Authority.crt files to the C:\CertData folder.
4. Eject the RootCAFiles.vfd virtual floppy disk.

You can create the CertData virtual directory using the command line instead of using the
Internet Information Services (IIS) Manager:

1. Open an elevated Command Prompt.

2. Change to the correct directory by entering the following command:

cd C:\Windows\System32\inetsrv\

3. Run the following command to create the CertData virtual directory in IIS:

appcmd.exe add vdir /app.name:"Default Web Site/" ^

/path:/CertData /physicalPath:C:\CertData

4. Run the following command to enable Directory Browsing on the CertData virtual
directory:

appcmd.exe set config "Default Web Site/CertData" ^

/section:directoryBrowse /enabled:true

5. Close the Command Prompt.

Once the directory and the directory browsing option has been enabled on the CertData
directory, double escaping can now be enabled in IIS.

AD CS Quick Start | 347

Subordinate CA Setup - Enable Double Escaping in IIS
On the TFS-CA01 server, enable double escaping within Internet Information Services to
allow for proper CRL publication on the TFS Labs domain. This applies specifically to the
Delta CRLs which require this functionality. The Delta CRL has a plus (+) symbol in the
name, and this can cause issues with some versions of IIS.

To enable double escaping in IIS, perform the following steps on the TFS-CA01 server:

1. Open an elevated Command Prompt.

2. Change to the correct directory by entering the following command:

cd C:\Windows\System32\inetsrv\

3. Enter the following command to apply the change to IIS:

appcmd.exe set config "Default Web Site" ^

/section:system.webServer/Security/requestFiltering ^
-allowDoubleEscaping:True

4. Restart IIS service by entering the iisreset.exe command.

5. Close the Command Prompt.

After enabling double escaping in IIS, it will now be possible to distribute the Delta CRL
files in the TFS Labs domain.

Subordinate CA Setup - Subordinate Certificate Creation

Once the Subordinate CA has been configured and the Certificate Request successfully
generated, it is now time to complete the Subordinate CA certificate by using the
TFS-ROOT-CA server.

Creating the Subordinate certificate requires multiple steps using both the Root CA
server and the Subordinate CA server. These steps are not complicated, but they must be
completed in the correct order and none of the steps can be skipped.

The workflow for creating the Subordinate certificate on the TFS-CA01 and TFS-ROOT-CA
servers is as follows:

• Insert the virtual floppy disk on the TFS-ROOT-CA server.

• Submit the CSR for the Subordinate CA to the Root CA.
• Export the Subordinate certificate from the Root CA.
• Copy the Subordinate certificate to the virtual floppy disk.
• Insert the virtual floppy disk on the TFS-CA01 server.
• Install the Subordinate certificate on the Subordinate CA.
• Start Active Directory Certificate Services on the TFS-CA01 server.

348 | Practical Guide to PKI with Windows Server

To create the Subordinate CA certificate, perform the following steps on the TFS-CA01
and TFS-ROOT-CA servers:
1. Add the RootCAFiles.vfd virtual floppy disk to the TFS-ROOT-CA virtual machine.
2. Copy the A:\TFS-CA01.corp.tfslabs.com_corp-TFS-CA01-CA.req file to the C:\RootCA
folder.
3. On the TFS-ROOT-CA server open Certification Authority console (certsrv.msc).
4. Right-click on the TFS Labs Certificate Authority server, select All Tasks and click
on Submit new request....
5. On the Open Request File window, browse to the C:\RootCA folder and select the
TFS-CA01.corp.tfslabs.com_corp-TFS-CA01-CA.req file that was copied from TFS-CA01.
Click the Open button to continue.
6. Once the Certificate Request has been submitted to the Root Certificate Authority,
go to the Pending Requests folder in the TFS Labs Certificate Authority to see the
pending Certificate Request. It should be identified as Request ID 2, the first request
being the self-signed Root certificate which has already been issued by this Certificate
Authority (not shown).
7. To issue the Subordinate certificate, right-click on the Request ID 2, select All Tasks
and click on Issue.
8. Go to the Issued Certificates folder to see the issued Subordinate certificate.
9. Double-click on the Request ID 2 certificate to open the Certificate properties window.
10. Go to the Details tab and click on the Copy to File... button.
11. On the first screen of the Certificate Export Wizard, click the Next button to continue.
12. On the Export File Format screen, select the Cryptographic Message Syntax Standard
- PKCS #7 Certificate (.P7B) format. Select the option to Include all certificates in
the certification path if possible and click the Next button.
13. On the File to Export screen, enter C:\RootCA\TFS Labs Enterprise CA.p7b as the
file name and click Next to continue.
14. On the Completing the Certificate Export Wizard screen, click the Finish button to
complete the wizard.
15. On the Certificate Export Wizard prompt, click the OK button to continue.
16. Copy the C:\RootCA\TFS Labs Enterprise CA.p7b file to the A:\ drive.
17. Eject the RootCAFiles.vfd virtual floppy disk.
18. On the TFS-CA01 server insert the RootCAFiles.vfd virtual floppy disk. Copy the
A:\TFS Labs Enterprise CA.p7b file to root of the C:\ drive.
19. On the TFS-CA01 server, open the Certification Authority console (certsrv.msc).
20. Right-click on the TFS Labs Enterprise CA server, go to All Tasks and select the option
to Install CA Certificate....
21. On the Select file to complete CA installation window, browse to the C:\ drive, select
the TFS Labs Enterprise CA.p7b file and click Open.
22. If you receive a warning message about installing an untrusted Root certificate, click
the OK button.
23. If there were no errors in installing the certificate, right-click on the TFS Labs Enterprise
CA server, select the All Tasks option, and click the Start Service option.
24. The Subordinate Certificate has now been installed successfully, and the Subordinate
Certificate Authority is now running.
25. Eject the RootCAFiles.vfd virtual floppy disk.

AD CS Quick Start | 349

You can also view the Subordinate certificate and verify that it was created with the
correct values that you setup during the configuration:

Figure 12.4.2: The TFS Labs Enterprise CA is signed by the TFS Labs Certificate Authority,
with a 5 year validity period.

If there were no issues with creating the Subordinate certificate, delete the following files
from the TFS-CA01 server as they are no longer needed:

• C:\TFS-CA01.corp.tfslabs.com_corp-TFS-CA01-CA.req
• C:\TFS Labs Enterprise CA.p7b

There may be instances where the installation and configuration of the Subordinate
certificate may fail for several reasons (if the Subordinate certificate was successfully
issued, skip this step). This may occur when the Subordinate CA has issues with the
Root CA CRL configuration, which is offline at the time of issuance of the Subordinate
certificate. To correct this issue when you are attempting to issue the Subordinate CA,
run the following command in an elevated PowerShell prompt:

certutil.exe –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

Once the command is issued, the Active Directory Certificate Services role will need to be
restarted. Run the following commands to restart the service:

net stop CertSvc

net start CertSvc

350 | Practical Guide to PKI with Windows Server

These files should be deleted as they should not remain on a server that has active
network connections for security purposes. Those files can remain on the TFS-ROOT-CA
server as it is offline, and the files cannot be accessed. You can proceed to setting the
maximum age for any certificate that is issued by the Certificate Authority in the next
section.

Subordinate CA Setup - Set Maximum Certificate Age

All certificates that will be created by the Subordinate CA will only be valid for 1 year, and
the setting can be forced so that a Certificate Template does not attempt to sign a
certificate for a longer period.

To configure the maximum certificate age for the Subordinate CA, run the following
commands on the TFS-CA01 server:

1. To define the maximum age of any certificate that the Subordinate CA is capable of
issuing, run the following commands from an elevated PowerShell prompt:

certutil.exe -setreg CA\ValidityPeriodUnits 1

certutil.exe -setreg CA\ValidityPeriod "Years"

2. Restart the Active Directory Certificate Services service to apply the configuration:

net stop CertSvc

net start CertSvc

3. Close the PowerShell prompt.

Once the maximum age for certificates has been specified on the Certificate Authority,
you can proceed to modifying the CertEnroll virtual directory settings, which is used for
certificate deployment.

Subordinate CA Setup - Modify the CertEnroll Virtual Directory

Alternatively, you can enable directory browsing on the CertEnroll virtual directory using
the command line instead of using the Internet Information Services (IIS) Manager:

1. Open an elevated Command prompt.

2. Change to the correct directory by entering the following command:

cd C:\Windows\System32\inetsrv\

3. Run the following command to enable Directory Browsing on the CertEnroll virtual
directory:

appcmd.exe set config "Default Web Site/CertEnroll" ^

/section:directoryBrowse /enabled:true

AD CS Quick Start | 351

 4. Close the Command prompt.

Once the directory browsing option has been enabled on the CertEnroll directory, you can
now proceed to configuring CDP and AIA on the Subordinate CA.

Subordinate CA Setup - CDP and AIA Configuration

Before the Subordinate Certificate Authority can be properly configured, the Certificate
Revocation List needs to be configured on the Subordinate Certificate Authority.

The CRL files that are provided by the Root CA are distributed with the Subordinate CA.
This is because the Root CA is not available on the network since it is always offline, so
there is no way for clients to access the files needed for the TFS Labs domain. This is
accomplished by configuring CDP and AIA on the Subordinate CA.

There are multiple locations where the CDP and AIA locations are used for the
Subordinate Certificate Authority:

• Local file system (used by the TFS-CA01 server)

• LDAP and Active Directory
• HTTP (to the TFS-CA01 server using http://pki.corp.tfslabs.com/)

The CDP and AIA configuration on the Subordinate Certificate Authority can be performed
using the Certification Authority console or through the command line using PowerShell.

To configure CDP and AIA on the Subordinate Certificate Authority using PowerShell,
perform the following steps on the TFS-CA01 server:

1. Open an elevated PowerShell prompt.

2. Run the following command to configure the CDP settings for the Subordinate Certificate
(execute this command as a single line with no breaks):

certutil.exe -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\

CertSrv\CertEnroll\%3%8%9.crl\n79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=
Public Key Services,CN=Services,%6%10\n0:http://%1/CertEnroll/%3%8%9.crl\
n6:http://pki.corp.tfslabs.com/CertEnroll/%3%8%9.crl"

3. Run the following command to configure the AIA settings for the Subordinate Certificate
(execute this command as a single line with no breaks):

certutil.exe -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\

CertSrv\CertEnroll\%1_%3%4.crt\n3:ldap:///CN=%7,CN=AIA,
CN=Public Key Services,CN=Services,%6%11\n0:http://%1/CertEnroll/
%1_%3%4.crt\n2:http://pki.corp.tfslabs.com/CertEnroll/%1_%3%4.crt"

4. Restart the Active Directory Certificate Services service to apply the changes:

net stop CertSvc

net start CertSvc

352 | Practical Guide to PKI with Windows Server

 5. To publish the CRL, run the following command:

certutil.exe -crl

6. Close the elevated PowerShell Prompt.

Once the CRL settings for the Subordinate CA have been configured, you can proceed to
configuring the CPS document.

Subordinate CA Setup - CPS Document

At the time of the Active Directory Certificate Services role configuration for the
Certificate Authority, the CAPolicy.inf files specified the location for a Certification
Practice Statement (CPS). The CPS is a document that is available to users who are
using the Certificate Authority to inform them of important policies regarding the
Certificate Authority. The CPS varies for every organization, so a placeholder will be put
in place which can be updated later to ensure that the Certificate Authority meets any
compliance standards that may be required. This is especially important in industries
with strict requirements (such as financial services), so having a CPS in place from day
one can alleviate a lot of issues in the future.

To create the CPS document, perform the following steps on the TFS-CA01 server:

1. On the TFS-CA01 server, open Windows File Explorer (explorer.exe), then go to This
PC and then go to the C:\.
2. Open the C:\inetpub\wwwroot folder.
3. Create a file named cps.html (ensure the file extension is correct).
4. Copy the following text into the cps.html file, save it and close the file:

C:\inetpub\wwwroot\cps.html

<! DOCTYPE html >

< html >
< head >
< meta charset =" utf -8" >
< title > TFS Labs Certification Practice Statement </ title >
</ head >
< body >

<h1 > TFS Labs Certification Practice Statement </ h1 >

<p > The TFS Labs Certification Authority is internal only . </p >

<p > All issued certificates are for internal usage only . </p >

</ body >

</ html >

5. Close Windows File Explorer.

AD CS Quick Start | 353

You can test that the CPS document is accessible by opening the web browser on the
TFS-CA01 server. Open the following address in a web browser on the TFS-CA01 server:

http://pki.corp.tfslabs.com/cps.html

Once the CPS document has been created, you can proceed to configuring the Windows
Firewall for the TFS-CA01 server.

Subordinate CA Setup - Windows Firewall Configuration

Disabling the Windows Firewall is extremely bad practice and can cause unexpected
issues with the TFS-CA01 server if is not enabled. Active Directory Certificate Services
utilizes HTTP and HTTPS connections to distribute and manage files needed to support
the Certificate Authority. This includes all the certificate files and CRL files that need to
be distributed to users and workstations. For anything that is handled through Group
Policy or LDAP, that is handled through the TFS-DC01 server which is the Domain
Controller for the TFS Labs domain.

There are three firewall rules that need to be enabled on the TFS-CA01 server for Active
Directory Certificate Services to function correctly:

Firewall Rule Name Port Profile

File and Printer Sharing (Echo Request - ICMPv4-In) ICMP All
World Wide Web Services (HTTP Traffic-In) TCP/80 All
World Wide Web Services (HTTPS Traffic-In) TCP/443 All

To check if the firewall rules are enabled on the TFS-CA01 server, perform the following
steps:

1. Open the Windows Defender Firewall with Advanced Security console (wf.msc) on
the TFS-CA01 server.
2. Under the Windows Defender Firewall with Advanced Security on Local Computer,
click on Inbound Rules.
3. For each of the firewall rules listed above, perform the following steps:
(a) Right-click on the firewall rule and select the Properties option to open the Rule
Properties window.
(b) On the General tab, select the option for Enabled.
(c) On the Advanced tab, ensure that the options for Domain, Private and Public
are selected.
(d) Click on the Apply button to apply the changes and then click the OK button to
close the window.
4. Close the Windows Defender Firewall with Advanced Security console.

Once the Windows Firewall has been correctly configured on the TFS-CA01 server, you
can proceed to verifying the PKI infrastructure for the TFS Labs domain.

354 | Practical Guide to PKI with Windows Server

Subordinate CA Setup - Add the Root CA to Active Directory
Since the TFS-ROOT-CA server is an Offline CA and there are no network connections
from Active Directory to that server, Active Directory is not aware that there is another
Certificate Authority in the TFS Labs domain. The Enterprise CA automatically adds itself
to Active Directory when it is configured, so there is a manual step that is required to add
the Root Certificate Authority to Active Directory. The Root certificate and CRL are
already located on the TFS-CA01 server and can be found in the C:\CertData folder. To
add the Root CA and Root CRL to the TFS Labs domain, perform the following steps on
the TFS-CA01 server:

1. Open an elevated PowerShell prompt.

2. Run the following command to add the TFS Labs Certificate Authority to Active
Directory:

certutil.exe -dspublish `
-f "C:\CertData\TFS-ROOT-CA_TFS Labs Certificate Authority.crt" RootCA

3. Run the following command to add the Root CA to the Certificate Store in Active
Directory:

certutil.exe –addstore `
–f root "C:\CertData\TFS-ROOT-CA_TFS Labs Certificate Authority.crt"

4. Run the following command to add the Root CRL to the Certificate Store in Active
Directory:

certutil.exe –addstore `
–f root "C:\CertData\TFS Labs Certificate Authority.crl"

5. Close the PowerShell prompt.

Now that the Root CA has been added to Active Directory, you can proceed to verifying
the PKI infrastructure on the TFS Labs domain.

Subordinate CA Setup - Verify PKI Infrastructure

There is a tool available for Active Directory Certificate Services called Enterprise PKI,
which is used to validate a PKI in Windows Server. It conveniently lists all the certificates
and Certificate Revocation Lists that are part of the PKI and specifies whether they are
valid or not.

To validate the PKI configuration for the TFS Labs domain, perform the following steps
on the TFS-CA01 server:

1. On the TFS-CA01 server, open the Enterprise PKI console (pkiview.msc).

2. On the default window for the Enterprise PKI console, it should state that the status
of the TFS Labs Certificate Authority (V0.0) server is OK.

AD CS Quick Start | 355

 3. Under the Enterprise PKI node, click on the TFS Labs Certificate Authority (V0.0)
server. Check that the status of the CA Certificate, AIA Location #1 and CDP Location
#1 have the status of OK:

4. Under the Enterprise PKI node, click on the TFS Labs Enterprise CA (V0.0) server.
Check that the status of the CA Certificate, DeltaCRL Locations, AIA Locations and
CDP Locations have the status of OK:

5. Close the Enterprise PKI console.

If there are no issues with the PKI infrastructure configuration, then the initial deployment
of the TFS Labs Certificate Authority is now complete. With an Enterprise CA, the TFS
Labs Enterprise CA certificate should start to automatically deploy to all Active Directory
devices.

Subordinate CA Setup - Next Steps

With the Subordinate Certificate Authority for the TFS Labs domain setup and working
correctly, there are no further steps to complete.

356 | Practical Guide to PKI with Windows Server

AD CS Quick Start - Post-Implementation Tasks
Post-Implementation Tasks - Virtual Floppy Disk Deletion
Once the Certificate Authority has been successfully implemented, completed, and
tested, the virtual floppy disk should be deleted as it is no longer required. The virtual
floppy disk contains important files that are not needed after the implementation, and by
keeping the virtual floppy disk can introduce an unnecessary security risk.

Prior to deleting the virtual floppy disk, if there are any BitLocker Recovery Keys, they
should be backed up. Should the virtual floppy disk be required in the future, specifically
for updating the Root CA CRL files, it can be easily recreated for that purpose.

Post-Implementation Tasks - Root CA Shut Down

Once the Certificate Authority has been successfully implemented, the Root CA can be
powered off as it is no longer needed once the Subordinate CA is online and operating
correctly. For security purposes it is important to keep the Root CA offline and protected.
The TFS-ROOT-CA virtual machine will need to be powered on at least once every 52
weeks to update the Base CRL.

Ensure that you do not delete this virtual machine. If you delete this virtual machine, it
will break your entire PKI and there will be no way of recovering from it.

AD CS Quick Start - Next Steps

Once the quick start steps for the Certificate Authority have been completed, you have
the option to go through the previous chapters in this book and add additional
functionality, as well as further customizations. The major items that are missing from
the quick start steps include the Online Responder role configuration, Certificate
Template customization and auto-enrollment of certificates in the TFS Labs domain.
These items can be added at any time should they be required.

AD CS Quick Start | 357

Glossary of Terms

802.1X 802.1X is an open standard that is used for securing ports on

a network. It provides authentication capabilities to devices
that are connecting to a network.

A Record An A record is a type of DNS record that returns a 32-bit IPv4

address and is commonly used to map a hostname to an IP
address.
Active Directory Active Directory is a directory service application developed
by Microsoft for managing, authenticating, and authorizing
access to a domain.
AD CS Active Directory Certificate Services is a server role
available in Windows Server that allows for the creation
and management of a Certificate Authority.
AD DS Active Directory Domain Services is a server role available
in Windows Server that allows for the creation of a Domain
Controller. This allows for creating an Active Directory domain
or adding onto an existing one.
AIA Authority Information Access is a feature in a Certificate
Authority that publishes CRL information and the OCSP URL
for issued certificates.
Apache The Apache HTTP Server is an open-source web server
platform that is available on multiple operating systems.

Base CRL A Base CRL is a large list of certificates that have been revoked
previously by the Certificate Authority. It is a large file that
is updated infrequently and is tied to the Delta CRL as it
incorporates those revocations.
BDE BitLocker Drive Encryption is a full disk encryption application
developed and maintained by Microsoft for the Windows
operating system.

Glossary of Terms | 359

C

CDP A CRL Distribution Point is where clients can download a CRL

to check the revocation status of certificates for a Certificate
Authority.
Certificate Authority A Certificate Authority is an entity that issues and manages
certificates.
CLI A Command Line Interface is a method of interacting with a
computer that relies on only inputting commands with text.
Cmdlet A Cmdlet is a special type of command used with PowerShell
which are useful for automation tasks within Windows.
CNAME Record A Canonical Name record is a resource record for DNS that
maps one DNS entry to another one. This allows for multiple
DNS records for a single A record.
CRL A Certificate Revocation List is a list of certificates that have
been revoked before they are set to expire on their own. This
occurs when a certificate is compromised or can no longer be
trusted.
CSR A Certificate Signing Request is a digital application for a
certificate. A CSR is received by a Certificate Authority and if
approved, is issued back to the applicant as a valid certificate.

Delta CRL A Delta CRL is a small list of certificates that have been
revoked since the last time a Base CRL was published.
DISM Deployment Imaging Servicing and Management is a
command line tool that is used to mount and update
Windows images. It can also be used to add or remove
Windows features as needed.
DER Distinguished Encoding Rules is a certificate format that is in
Binary Format.
DNS The Domain Name System is a hierarchical naming system for
devices that are connected to a private network or the public
internet. It is critical for an Active Directory environment and
is usually installed on a Domain Controller using the Active
Directory integrated DNS feature. DNS relies on UDP port 53
for communication.
DNS Zone A DNS Zone is a domain space that holds all records for a
particular domain.

360 | Practical Guide to PKI with Windows Server

E

Enterprise CA An Enterprise CA is a server that is a member of an Active

Directory domain and is typically used as a Subordinate or
Issuing Certificate Authority. An Enterprise CA will have the
AD CS role installed and configured on it.

Firewall A Firewall is a network security device that is used to control

access to and from a network, as well as other functions such
as Malware detection, and other malicious activity.
FDE Full Disk Encryption is a method of encryption used on hard
drives and other devices that fully encrypts the contents when
the device is not in use.
FQDN A Fully Qualified Domain Name is the complete domain name
for a specific host on a network.
FSMO The Flexible Single Master Operation are several roles within
Active Directory (Schema Master, Domain Naming Master,
RID Master, PDC Emulator and Infrastructure Master) that are
responsible for critical AD DS functions. FSMO roles can
be installed on a single or multiple Domain Controllers in an
Active Directory domain.
Functional Level Functional Levels are used to determine what capabilities
an Active Directory domain has available to it. There are
Forest and Domain Functional Levels that provide different
capabilities to a domain. Raising a Functional Level can
add additional functionality to an Active Directory domain
depending on which version is used.

GPO A Group Policy Object is a set of Group Policy configurations

that can be applied in multiple ways to an Active Directory
domain.
Group Policy Group Policy is a feature in Windows Server that allows
for the centralized management of Windows Settings within
an Active Directory domain. It is also available locally on
Windows if Active Directory is unavailable.
GUI A Graphical User Interface is an interface that allows
interaction with an operating system using buttons, icons, and
windows.

Glossary of Terms | 361

H

HTTP The Hypertext Transfer Protocol is an application layer

protocol that is used on the internet for communication with
webpages. All information that is transferred is in plain text
and is not encrypted, and it typically uses TCP port 80. It was
first defined in RFC 1945.
HTTPS Hypertext Transfer Protocol Secure is an extension of HTTP
that utilizes certificates to allow for secure transfer of
information over the internet, and typically uses TCP port 443.
Hyper-V Hyper-V is a Hypervisor that can run virtual machines on
modern versions of Windows 64-bit operating systems.
Hyper-V was developed by Microsoft and is a feature that is
available for free with certain versions of Windows.
Hypervisor A Hypervisor is computer software that can emulate the
hardware of a physical computer to allow for multiple
operating systems to be run on the same physical hardware.

IANA The Internet Assigned Numbers Authority is responsible for

assigning and managing all public IP addresses, Root Zone
management and Private Enterprise Numbers.
ICMP The Internet Control Message Protocol is a network protocol
that can be used to determine if network devices are reachable
on a network, and if there are any issues with connectivity.
IETF The Internet Engineering Task Force is an organization that
develops and maintains internet standards.
IIS Internet Information Services is a web server platform that is
available for the Windows platform.

LAN Manager LAN Manager is an obsolete networking technology and

associated protocols that was used by Microsoft in early
versions of Windows NT.
LDAP The Lightweight Directory Access Protocol is an open protocol
that is used for accessing a directory service such as Active
Directory. LDAP typically operates on TCP port 389.
LDAPS Lightweight Directory Access Protocol over SSL is a secure
form of LDAP that typically operates on TCP port 636.

362 | Practical Guide to PKI with Windows Server

M

MDM Mobile Device Management is a platform that is used to

manage mobile devices such a phones or tablets and ensure
that they meet necessary compliance standards. An MDM
can also be used to automatically distribute files and policies
to mobile devices.
MMC The Microsoft Management Console is a component of
Windows that allows a single application the ability to manage
and monitor the operating system using modules, called
Snap-ins.

NAT Network Address Translation is a method of mapping an IP

address into another by changing the network address while
the traffic is in transit. In practice, this allows for one WAN IP
address to be mapped to multiple internal LAN IP addresses,
or for one WAN IP address to be mapped to one internal LAN
IP address for things like web servers.
NDES The Network Device Enrollment Service allows network
devices such as routers or switches without proper Active
Directory credentials to receive proper certificates in a
network.
Nginx Nginx is an open-source web server platform that is available
for multiple operating systems.

OCSP The Online Certificate Status Protocol is a protocol that is

used to determine the revocation status of a certificate. It is
like a CRL in nature but is updated more frequently.
Offline CA An Offline Certificate Authority is a Certificate Authority that
is not connected to a network and can only sign certificates
manually.
OID An Object Identifier is an identification method used to
uniquely name an object or attribute.
OU An Organizational Unit is a container in an Active Directory
domain that is used to store objects based on their usage.
It can be linked with Group Policy to enforce settings or
push software to those objects, whether they be users or
computers.

Glossary of Terms | 363

P

P7B P7B is a PKCS #7 signed certificate that is stored in the

Cryptographic Message Syntax Standard format, which is a
binary format.
PEN A Private Enterprise Number is a unique identifier that is
maintained by the IANA in a public registry that can be used
with an OID. A PEN number is free to acquire and use within
an organization.
PFX PFX is a PKCS #12 signed certificate that is stored in the
Personal Information Exchange format, which is a binary
format. This format is very commonly used on the Windows
operating system and with IIS.
PKI A Public Key Infrastructure is a set of roles and services that
are needed to create and manage certificates using public key
encryption.
PowerShell PowerShell is a framework that provides a command line
interface that is maintained by Microsoft. Administrative
tasks are performed using Cmdlets, which simplify complex
tasks.
Private Key In Cryptography, a private key is the key that is known only to
the owner that is used to decrypt data that is signed using the
public key.
Public Key In Cryptography, a public key is the key that is known to others
that is used to digitally sign data, to be decrypted using the
private key.

RDP Remote Desktop Protocol is a method of remotely connecting

to a Windows device over the network. Typically uses TCP
port 3389.
RFC Request for Comments is a publication that is used to develop
standards for the internet.
Root CA A Root Certificate Authority is the top of a Certificate Authority
and is used to sign all Subordinate certificates for a PKI
hierarchy.
RSA Rivest–Shamir–Adleman is a public key encryption system
that is widely used for the secure transmission of data over
networks.

364 | Practical Guide to PKI with Windows Server

S

S/MIME Secure/Multipurpose Internet Mail Extensions is a method of

encrypting and decrypting e-mails using digital signatures.
SAN Subject Alternative Name is a type of certificate that allows for
multiple DNS names to be used on a single certificate. Also
known as a UCC certificate.
SSL Secure Socket Layers is a method of public key encryption
that is most used on the World Wide Web. Websites that are
encrypted with SSL typically use HTTPS as the protocol for
transmitting and receiving data. TLS is the successor to SSL.
Subordinate CA A Subordinate CA is a Certificate Authority that is certified
by another Certificate Authority, which is most often a Root
Certificate Authority.

TCP The Transmission Control Protocol is a transport protocol that

is used to ensure a reliable transmission of packets over a
network.
TCP/IP The Transmission Control Protocol/Internet Protocol is a
network protocol that is primarily used on the internet and on
internal networks.
TLS Transport Layer Security is the successor to SSL that supports
greater encryption capabilities.
TPM A Trusted Platform Module is a standard for providing secure
cryptographic functions to a computer through dedicated
hardware on the device.

UCC A Unified Communications Certificate is a type of certificate

that allows for multiple DNS names to be used on a single
certificate. Also known as a SAN certificate.
UDP The User Datagram Protocol is a type of network protocol
that is used mostly in scenarios where loss is more generally
accepted, but with the benefit of higher transfer speeds.
URL A Uniform Resource Locator is a reference to a resource on a
network that uses DNS. It can also be referred to as a Uniform
Resource Identifier (URI).

Glossary of Terms | 365

V

VFD A Virtual Floppy Disk is a virtual disk format that is used

by Microsoft to emulate 1.44 MB floppy disks. They are
compatible with all versions of Hyper-V and several other
virtualization platforms.
VHD A Virtual Hard Disk is a virtual disk format that is used by
Microsoft to emulate a hard disk of varying sizes up to 2 TB. It
can contain disk partitions and file systems that can be used
by an operating system used for virtualization.
VHDX A Virtual Hard Disk format that is used by Microsoft that is an
enhanced version of a VHD that can support up to 64 TB of
storage capacity. It also allows for enhanced capabilities with
recent versions of Hyper-V.
Virtual Machine A virtual machine is an emulation of a computer system and
is most used to run multiple operating systems on a single
computer.
VPN A Virtual Private Network is an encrypted connection between
networks that is used to securely transmit information.

Wildcard Certificate A Wildcard Certificate is a certificate that is applied to a

domain and all associated subdomains. A wildcard certificate
is usually specified using an asterisk before the domain name
(*.tfslabs.com).
Workgroup A Workgroup is a collection of computers that are on the
same network that can share files and resources without a
centralized authentication system such as Active Directory or
other LDAP providers.

X.509 This is an open standard that is used in defining public

key certificates and several other associated protocols and
features needed for supporting certificates.

366 | Practical Guide to PKI with Windows Server

Commands Index

The following commands were used in this book for installing and configuring Active
Directory Domain Services and Active Directory Certificate Services, as well as various
other required components that are needed to support a Certificate Authority.
Many of the commands used in this book are shortcuts to graphical tools that are already
available within the Windows operating system, some are shortcuts to the Microsoft
Management Console, some are custom PowerShell Cmdlets that are required for
installation and configuration and the rest are legacy command line tools.

Graphical Tools Using Windows Server Tools

Command Purpose
appwiz.cpl Programs and Features is a Control Panel application that
allows for the installation, modification, and removal of
applications on a Windows device.
explorer.exe Windows File Explorer is used to manage local and remote file
systems.
inetmgr.exe Internet Information Services (IIS) Manager is used to manage
IIS services on a Windows server.
ldp.exe Ldp is a Graphical Interface for connecting to LDAP directories
for troubleshooting purposes.
mmc.exe Microsoft Management Console is a modular framework for
accessing management features within the Windows operating
system using Snap-ins.
msinfo32.exe System Information provides information on the local system,
such as hardware, driver, and software versions.
mstsc.exe Remote Desktop Connection provides a method or connecting
to Windows devices using the RDP protocol.
servermanager.exe Server Manager is a management console used in Windows
Server that provides access to all roles and features on
Windows Server.
regedit.exe Registry Editor provides a graphical interface for managing the
Windows Registry.
vmconnect.exe Virtual Machine Connection provides a graphical interface for
managing Hyper-V virtual machines. This tool can manage
local and remote Hyper-V virtual machines.

Commands Index | 367

Graphical Tools Using the Microsoft Management Console

MMC Console Purpose

adsiedit.msc ADSI Edit is a tool that is used to connect to and edit Active
Directory objects.
certlm.msc Certificate Store (local machine) allows management of
certificates that are assigned to a workstation.
certmgr.msc Certificate Store (current user) allows management of
certificates that are assigned to a user.
certsrv.msc Certification Authority provides an interface to issue, revoke and
manage certificates for AD CS.
compmgmt.msc Computer Management provides a single view for tools,
storage, and services on a Windows workstation or server.
dnsmgmt.msc DNS Manager is used to manage DNS Zones that are standalone
or integrated with AD DS.
dsa.msc Active Directory Users and Computers is used to manage AD DS
groups, users, workstations, and servers.
dssite.msc Active Directory Sites and Services is used to manage AD
Replication as well as AD service nodes.
eventvwr.msc Event Viewer provides an interface for viewing and searching for
events that are stored in Windows.
gpedit.msc Local Group Policy Editor allows for management of Group
Policy settings on a local Windows computer.
gpmc.msc Group Policy Management allows for the creation and
management of Group Policy Objects for Active Directory.
ocsp.msc Online Responder is used to manage the OCSP settings for
Active Directory Certificate Services.
pkiview.msc Enterprise PKI provides an interface for viewing the overall
status of an Enterprise CA in AD CS.
secpol.msc Local Security Policy provides an interface for viewing and
modifying security policies.
services.msc Services provides an interface for viewing services, and
provides the ability to start, stop or restart them.
virtmgmt.msc Hyper-V Manager is used to manage Hyper-V virtual machines
on a local or remote server.
wf.msc Windows Defender Firewall is used to manage the advanced
settings for the Windows firewall.

368 | Practical Guide to PKI with Windows Server

Cmdlets for Managing Windows Server

Cmdlet Purpose
Add-DnsServerResourceRecordCName This Cmdlet is used to add DNS records to
a DNS Zone, specifically CNAME records.
Add-WindowsFeature This Cmdlet is used to add optional
features to a Windows workstation or
server.
Enable-WindowsOptionalFeature This Cmdlet is used to enable optional
features to a Windows workstation or
server.
Get-ADComputer This Cmdlet is used to search for and
retrieve computer objects within Active
Directory.
Import-Module This Cmdlet is used to import a specific set
of Cmdlets into a PowerShell session which
are not present by default.
Install-AdcsCertificationAuthority This Cmdlet is used to install and configure
an AD CS Certificate Authority once the AD
CS role has been installed.
Install-AdcsWebEnrollment This Cmdlet is used to install and configure
the AD CS Web Enrollment role for AD CS,
plus any additional required features.
Install-AdcsOnlineResponder This Cmdlet is used to install and configure
the AD CS Online Responder role for AD CS.
Install-ADDSForest This Cmdlet is used to install and configure
an AD DS Forest once the AD DS role has
been installed.
Install-WindowsFeature This Cmdlet is used to enable optional
features to a Windows workstation or
server.
Move-ADObject This Cmdlet is used to move objects within
Active Directory.
New-ADOrganizationalUnit This Cmdlet is used to add Organizational
Units to Active Directory.
New-ADUser This Cmdlet is used to add users to Active
Directory.
Set-ADUser This Cmdlet is used to modify user
properties in Active Directory.

Commands Index | 369

Command Line Tools for Managing Windows Server

CLI Command Purpose

appcmd.exe AppCmd.exe is a command line tool for managing IIS 7 and
above.
auditpol.exe Auditpol.exe is a command line tool for managing audit policies
on a Windows workstation or server.
certutil.exe Certutil.exe is a command line tool used for managing
certificates and configuration tasks for AD CS.
dism.exe DISM.exe is a command line tool for managing Windows
images, as well as adding and removing features to an existing
system.
gpupdate.exe Gpupdate.exe is a command line tool for managing Group
Policy settings on a Windows workstation or server, most often
used to refresh GPO.
iisreset.exe IISReset.exe is a command that is used to manage IIS services
from the command line.
manage-bde.exe Manage-bde.exe is a command line tool used for managing
BitLocker on a Windows workstation or server.
net Net is a command that manages all network tasks on a
Windows workstation or server.
sconfig.cmd Sconfig is a command line tool that is used for managing basic
Windows Server functions.

370 | Practical Guide to PKI with Windows Server

Index

Symbols CSR 14, 16, 33, 140, 163, 167, 168, 174,
802.1X xx, 268, 273 275, 280, 291, 292, 346, 348

A D
AD CS xix, 1, 4, 7, 12, 16, 23, 51, 89, 141, Delta CRL 17, 110, 134, 136, 147, 172,
205, 219, 265, 311, 325 184, 191, 249, 334, 340, 348
AD DS 7, 51, 53, 60, 69, 108, 330, 333 DER 18, 206
AIA 10, 12, 14, 128, 129, 132, 134, 139, DHCP 7, 28, 327
168, 184, 188, 194, 202, 226, DNS 4, 7, 15, 51, 52, 134, 143, 322, 329,
319, 340, 352 340, 343
Android xxiii, 42, 43, 215, 285, 290, 298 DNS Zone 51, 143, 145, 291, 343
Apache 282, 291, 295 Domain Controller xxii, 9, 28, 34, 51, 52,
Apple Safari 15, 32, 302 59, 60, 67, 74, 85, 109, 141, 144,
AVHD 45 213, 214, 279, 319, 322, 327,
AVHDX 45 330, 332, 354

E
B
EFS xx, 5
Base CRL 17, 110, 134, 147, 184, 239,
Enterprise CA 12, 28, 79, 122, 141, 167,
249, 312, 334, 340, 357
205, 248, 275, 291, 319, 327,
Base-64 18
346
BIOS xxi, 38
BitLocker 7, 28, 87, 89, 141, 143 F
FQDN 32, 83, 146
C FSMO 322
CDP 10, 12, 14, 128, 129, 132, 134, 139, Functional Level xxi, 28, 61, 327
168, 184, 188, 194, 202, 319,
340, 352 G
Certificate 1 Google Chrome 15, 32
Certificate Authority xv, 1, 51, 311 GPO 74, 81, 205, 208, 213, 244, 287, 289,
Certificate Store 17, 21, 23, 83, 200, 213, 322
288, 290, 322, 355 Group Policy xxiii, 28, 51, 70, 87, 98, 108,
Cmdlet 23, 40, 41, 59, 61, 67, 367 142, 204, 206, 208, 244, 267,
CNAME 29, 32, 36, 143, 283, 291, 297, 273, 283, 285, 288, 322, 333,
298, 343 342, 354
CPS 34, 195, 353
CRL 1, 6, 10, 14, 16, 17, 28, 30, 88, 128, H
129, 134, 140, 143, 168, 172, HTTP 134, 173, 189, 340, 354
189, 199, 202, 219, 248, 280, HTTPS 6, 282, 298, 302, 308, 354
312, 337, 341, 347, 348, 352, Hyper-V xix, xxi, xxii, 7, 37, 52, 79, 88, 89,
355, 357 142, 291

Index | 371
Hypervisor xix, 362 R
RFC 1, 15, 195
I Root CA xx, 8, 9, 12, 20, 29, 49, 53, 87,
IANA 19, 111, 148, 335, 344 109, 128, 130, 140, 141, 168,
IETF 12, 195 189, 199, 312, 313, 318, 325,
IIS 6, 7, 32, 148, 172, 184, 187, 195, 215, 333, 355
306, 348 RSA 119, 158, 336, 345
Intermediate CA 10, 12
iOS xxiii, 42, 43, 111, 148, 215, 285, 290, S
302, 306 S/MIME 5
IPSec 5 SAN 15, 280, 283, 291, 297, 298
Issuing CA 8, 12, 141 SSL xx, 2, 5, 11, 15, 31, 33, 215, 280, 283,
291
L SST 18
LDAP 14, 82, 134, 189, 239, 340, 352, Subordinate CA xxiii, 9, 12, 29, 49, 128,
354 139, 141, 147, 205, 208, 215,
LDAPS 5, 82, 86, 214 224, 227, 228, 261, 283, 312,
Linux xxiii, 215, 282, 285, 291 334
M
T
macOS 285, 290, 308, 310
TPM 97, 99
MDM 5, 215, 273
Microsoft Edge 15, 27, 32
U
MMC 23, 51, 367
Ubuntu 291, 296, 298
Mozilla Firefox 15, 32
UCC 14, 15, 291
N
Nginx 282, 291, 295, 297 V
VFD 47, 49
O VHD 103
OCSP xx, 6, 14, 17, 28, 142, 143, 147, VHDX 38
202, 205, 217, 219, 228 VirtualBox xxii
OID 14, 19, 111, 148, 335, 344 VLAN 20, 43
OpenSSL 291 VMware xxii, 39, 88
Organizational Unit 70, 73, 74, 208 VPN 2, 5, 268, 273

P W
P7B 18, 178, 349 Windows Server xix, 1, 4, 7, 26, 27, 51,
PEN 19, 111, 148, 335, 344 87, 141
PFX 18, 273
PKI xv, xix, xxii, 1, 5, 110, 143, 147, 168, X
184, 251, 334 X.509 1, 12, 15, 17

372 | Practical Guide to PKI with Windows Server