Building and extending the internal PKI Damir Dizdarevic Logosoft d.o.o. Sarajevo http://dizdarevic.ba/ddamirblog @ddamirMVP

Agenda General PKI concepts Key points for building an internal PKI hierarchy Extending an Internal PKI

General PKI concepts

PKI Trust Models Root CA Intermediate CA Intermediate CA Subordinate CA Subordinate CA User & Computer Certificates User & Computer Certificates

PKI & CA Components Digital Certificates Registration Authorities Contains Identity and Verification info Issued Via a Certificate Authority Think of it as a Passport Trusted Entity that Issues Certificates Registration Authorities Verifies Identity for Certificate Requests Certificate Revocation List (CRL) CRLs are Maintained by the CA & List All Certificates that Have been Revoked.

Digital Certificates Based on X.509 / PKIX / PKCS standards Fields Version Serial number CA’s signature Validity Subject’s public key Extensions CDP/AIA locations Standard Private / proprietary Critical or non-critical

Certificate Authority Certification Authority CA is a trusted third party that issues identity certificates Public Key Certificate Registration Authority Structure of Certificates Trusted Organization Can be internal or external to the organization GoDaddy, Entrust, VeriSign Certification Revocation Lists Can be provided by Browser

Active Directory Certificate Services Security Group Policy Applied Group Policy distribution Certificate Publication, Notification mapping to User Accounts, Computers etc. Domain Admin Certificate services KDC / Domain Controller Active Directory Domain Logon Process Smartcard Logon Process Domain User Domain Client

AD CS in Windows Server 2012 CA CA Web Enrollment Online Responder 7: Deploying and Managing AD CS Firewall Enrollment Linux Proxy Windows 7 or newer Policy CA CA Web Enrollment Introduce Active Directory Certificate Services (AD CS) and explain the purpose of each role service. Spend some time describing the role services that are new to Windows Server 2008 R2 and Windows Server 2012. Online Responder Network Device Enrollment Service Certificate Enrollment Web Service Certificate Enrollment Policy Web Service

Digital Signatures Ensures Integrity, Authentication, Non-Repudiation Sender Creates Message Digest and Signs Using Private key Receiver Decrypts Message Digest Using the Linked Public Key Receiver Performs the Same Hash Function and Should Get the Same Value Protects Users from Potentially Malicious Websites Including Fake Social Networking Sites However Digital Signatures Do Not Confirm Identity

Key points for building an internal PKI hierarchy

Public or Private CA? External public CAs: Internal private CAs: Are trusted by many external clients, such as web browsers and operating systems Are slower compared to internal CAs Have higher cost Internal private CAs: Require greater administration than external public CAs Cost less than external public CAs and provide greater control over certificate management Are not trusted by external clients by default Offer advantages such as customized templates and autoenrollment

Stand-Alone vs. Enterprise Cas? 10969B Stand-Alone vs. Enterprise Cas? 7: Deploying and Managing AD CS Stand-alone CAs Enterprise CAs Must be used if any CA (root/intermediate/policy) is offline because a stand-alone CA is not joined to an AD DS domain Requires the use of AD DS and stores information in AD DS Can use Group Policy to propagate certificates to the trusted root CA certificate store Users must provide identifying information and specify the type of certificate Publishes user certificates and CRLs to AD DS Does not support certificate templates Issues certificates based on a certificate template All certificate requests are kept pending until administrator approval Supports autoenrollment for issuing certificates Discuss the following: Stand-alone and enterprise CAs, and their differences. CAs that issue certificates to clients over the Internet. A root CA typically is configured as a stand-alone CA. Mention that business requirements often dictate the types of CAs that students might use. For example, autoenrollment requires an enterprise CA.

Options for Implementing CA Hierarchies 10969B Options for Implementing CA Hierarchies 7: Deploying and Managing AD CS Root CA Policy CAs Issuing CA Issuing CAs Policy CA Policy CA Usage Two-Tier Hierarchy Cross-Certification Trust Highlight various usage scenarios for CAs. This should help students understand the typical scenarios that are found in an enterprise environment. Contrast these scenarios with a typical usage scenario in a small environment, such as a single-server PKI. Make sure that students understand that a single CA does not represent a CA hierarchy, although it is still a fully functional PKI.

Deploying a Root CA – key points 10969B Deploying a Root CA – key points 7: Deploying and Managing AD CS Computer name and domain membership cannot change When you plan private key configuration, consider the following: CSP Key character length with a default of 2,048 The hash algorithm that is used to sign certificates issued by a CA When you plan a root CA, consider the following: Name and configuration Certificate database and log location Validity period CDP locations (especially if RootCA will be offline) Describe the key points related to considerations for installing a root CA. When discussing the private key configuration, mention that any provider that contains a number sign (#) in its name is a Cryptography Next Generation (CNG) provider. CNG, which was first introduced in Windows Vista, is enhanced in Windows Server 2008 and Windows Server 2012. The CNG application programming interface (API) is the long-term replacement for the CryptoAPI of previous versions of the Windows operating system.

Deploying a Subordinate CA - scenarios 7: Deploying and Managing AD CS Root Subordinate RAS EFS S/MIME Certificate Uses Load Balancing India Canada USA Locations Employee Contractor Partner Discuss the scenarios for deploying a subordinate CA. Ask students if they have PKI deployed in their environments and whether they are using root CAs only, or if they have deployed subordinate CAs also. Organizational Divisions

10969B CDPs and AIA Locations 7: Deploying and Managing AD CS The AIA specifies where to retrieve the CA's certificate The CDP specifies from where the CRL for a CA can be retrieved Publication locations for AIA and CDP: AD DS Web servers FTP servers File servers Ensure that you properly configure CRL and AIA locations for offline and stand-alone CAs Ensure that the CRL for an offline root CA does not expire This is an important topic. Make sure that you spend enough time explaining the importance of the authority information access (AIA) and certificate revocation list distribution point (CDP) locations. Use the offline root CA as an example. Discuss the publication points and when to use each one of them.

Key Archival and Recovery 10969B Key Archival and Recovery 8: Deploying and Managing Certificates Private keys can get lost when: A user profile is deleted An operating system is reinstalled A disk is corrupted A computer is lost or stolen It is critical that you archive private keys for certificates that are used for encryption The KRA is needed for key recovery Key archival must be configured on the CA and on the certificate template Key recovery is a two-phase process: Key retrieval Key recovery The KRA certificate must be protected This is a very important topic. Make sure that students understand why it is important to back up private keys. Also, make sure that they understand which certificates are critical for archiving and which are not. Explain how key archival works and what the Key Recovery Agent (KRA) is. Then, explain how key recovery works and what security precautions students should take for the KRA certificate. Carefully read all the content from the Workbook and use it in your instruction.

Establishing CA Security You can establish role based administration for CA hierarchy by defining the following roles: CA Administrator Certificate Manager Backup Operator Auditor Enrollees You can assign the following permissions on the CA level: Read Issue and Manage Certificates Manage CA Request Certificates Certificate Managers can be restricted to a template

Certificate Policies A certificate is not interchangeable for different uses CA defines certificate policies to identify uses for certificates Some certificates may require higher level authentication (High Assurance SSL)

Managing CA Hierarchy For monitoring and maintenance of a CA hierarchy, you can use PKIView and CA auditing With PKIView, you can: Access and manage AD DS PKI-related containers Monitor CAs and their health state Check the status of CA certificates Check the status of AIA locations Check the status of CRLs Check the status of CDPs Evaluate the state of the Online Responder CA auditing provides logging for various events that happen on the CA

Extending an Internal PKI

CA Policy and Exit Modules 10969B CA Policy and Exit Modules 7: Deploying and Managing AD CS The policy module determines the action that is performed after the certificate request is received The exit module determines what happens with a certificate after it is issued Each CA is configured with default policy and exit modules FIM 2010 R2 CM deploys custom policy and exit modules The exit module can send email or publish a certificate to a file system You have to use certutil to specify these settings, as they are not available in the CA the administrator console Define policy and exit modules on the CA. Most students probably will not be familiar with these settings, as they are used rarely. Use Microsoft Forefront Identity Manager (FIM) Certificate Management to provide real-life examples of custom policy and exit modules. Spend some time explaining how to configure default exit modules to perform some tasks.

FIM CM Benefits Centralized Enrollment Agent (EA) and Key Recovery Agent (KRA) Improved overall process workflow Detailed auditing and reporting Support for extended self-service scenarios PIN unblocks with user’s credentials Self-servicing Integration with Active Directory and PKI

Certificate Management – smart cards related tasks Enroll Duplicate Renew Revoke Disable Suspend Temporary cards Online/Offline Unblock Online Update

Certificate Management with FIM What you should keep in mind? Permissions on Service Connection Point Permissions on Profile Templates Permissions on AD DS objects Workflow design Permissions on CA and Certificate Templates Certificates on FIM CM agents accounts

How Does Smart Card Authentication Work? 10969B 8: Deploying and Managing Certificates How Does Smart Card Authentication Work? Smart cards can be used for: Interactive logon to AD DS Client authentication, if you use a certificate that matches an account Remote logon Interactive logon steps: Logon request goes to the LSA, which is forwarded to the Kerberos package KDC verifies the certificate KDC verifies the digital signature on the authentication service KDC performs an AD DS query to locate the user account KDC generates a random encryption key to encrypt the TGT KDC signs the reply with its private key and sends it to the user You can use smart cards for offline logon In this topic, you should explain how smart cards are used for authentication. First, describe the types of authentication that are performed with smart cards. After that, use the steps provided on the slide with content from the Workbook to describe how interactive logon works with smart cards. At the end, explain how offline logon works with smart cards.

Consider usage of virtual smart cards A smart card infrastructure might be expensive Windows Server 2012 AD CS introduces Virtual Smart Cards Virtual Smart Cards use the capabilities of the TPM chip No cost for buying smart cards and smart card readers Computer acts like a smart card Private keys are protected by the cryptographic capabilities of the TPM