Successfully reported this slideshow.
Your SlideShare is downloading. ×

EC PKI Training on-prem and cloud-based PKI

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 65 Ad

EC PKI Training on-prem and cloud-based PKI

This presentation is an overview of the PKI training Encryption Consulting LLC provides.
In this training program, you will learn PKI from scratch including MS PKI and cloud-based PKI options.

Get more details on our website www.encryptionconsulting.com

This presentation is an overview of the PKI training Encryption Consulting LLC provides.
In this training program, you will learn PKI from scratch including MS PKI and cloud-based PKI options.

Get more details on our website www.encryptionconsulting.com

Advertisement
Advertisement

More Related Content

Slideshows for you (19)

Similar to EC PKI Training on-prem and cloud-based PKI (20)

Advertisement

Recently uploaded (20)

EC PKI Training on-prem and cloud-based PKI

  1. 1. Windows Server 2019 Active Directory Certificate Services (ADCS) PRESENTED BY Puneet Singh Principal
  2. 2. 2 This module will give you a detailed introduction about basic Cryptography  Introduction to Cryptography  Symmetric Encryption  Asymmetric Encryption  Hash Functions and Digital Signatures  Introduction to HSM  Introduction to PKI  Certificates  Module Review Module01 Introduction to PKI
  3. 3. 3 Brief summary of module 1 : The below mentioned topics will be covered in this module Introduction to Cryptography  What is Cryptography ? – Detailed definition of cryptography – History of Cryptography  Goals of Cryptography – Confidentiality, Data Integrity, Non-repudiation, Authentication  Binary mathematical operation  Symmetric Encryption in detail  Asymmetric Encryption in detail  Symmetric and Asymmetric algorithm – details about each algorithm – symmetric Vs. Asymmetric algorithm – hybrid Encryption  Hash functions and Digital Signature – Overview of Hash Algorithm – Characteristics of Digital signature – Singing and verification process of hashing Summary of Module 01 Introduction to PKI
  4. 4. 4 Brief summary of module 1 : The below mentioned topics will be covered in this module Introduction to HSM (Hardware Security Module)  What is HSM ? – Detailed definition of HSM – Why do we use HSM? – Benefits of HSM – Overview of HSM and PKI integration Introduction to PKI (Public Key Infrastructure)  What is PKI ? – Goals of PKI – Detailed description of each PKI components – Common uses of PKI – Overview of HSM and PKI integration  Certificate Authority – Description of certificate authority – Overview of CA Hierarchy – Certificate Authority designs – Why hierarchy is important – Overview of Two-tier hierarchy – Overview of CP/CPS Summary of Module 01 Introduction to PKI – cont’d
  5. 5. 5 Brief summary of module 1 : The below mentioned topics will be covered in this module Certificates  What is a digital certificate? – Common contents of a X.509 certificates – Windows certificate stores – Detailed description of OIDs (Object identifiers) Module Review Q&A Summary of Module01 Introduction to PKI - cont’d
  6. 6. Asymmetric Encryption NOTE: We are providing an overview of the above-mentioned topic from module 1, which will be discussed in the training sessions
  7. 7. Asymmetric Cryptography- Overview  Asymmetric encryption increases the security of the encryption process by utilizing two separate, but mathematically related keys known as a public key and a private key: • Public Key: Can and should be distributed • Private Key: Must remain secret  Asymmetric encryption is also called as “Public Key Encryption“  Personal Key Storage • Keyring (OpenPGP), Personal Security Environment (PSE) (S/MIME) • Collection of public and private keys
  8. 8. Asymmetric Encryption  The data sender obtains the recipient’s public key.  The plaintext data is passed through an asymmetric encryption algorithm, using the recipient’s public key as the encryption key. The encryption algorithm creates the encrypted ciphertext.  The ciphertext is sent or made available to the recipient  Messages encrypted with Bob‘s public key can only be decrypted using Bob‘s private key
  9. 9. Asymmetric Algorithms – RSA  Developed by Rivest, Shamir and Adleman in 1978  Most famous key algorithm and well researched  Strength in today’s inefficiency to factories into prime numbers  This algorithm can be used for encrypting/decrypting and signing data  The security of the RSA algorithm can be increased by using longer key lengths, such as 1,024 bits or more—the longer the key length, however, the slower the encryption or signing process.
  10. 10. Asymmetric Algorithms- ECC  Elliptic Curve Cryptosystem (ECC)  Discovered in 1985 by Neal Koblitz and Victor Miller  Can be used for Digital signatures, key distribution, encryption  More efficient than other algorithms Used in devices with limited processing power  Does not require longer key to provide higher protection  160-bit elliptic curve prime is said to provide the same level of security as a 1536-bit RSA key
  11. 11. 11 Module 02: Certificate Revocation and Chain Building This module will give you a vital understanding of  Certificate Verification and Chain Building  Designing and Configuring Certificate Distribution point (CDP)  Revocation Cache  Online Certificate Status Protocol (OCSP)  Certificate Revocation Lists (CRLs) • Functionality • Design considerations • How to deal with revocation cache  Troubleshooting
  12. 12. 12 Brief summary of module 2 : The below mentioned topics will be covered in this module Certificate Verification and Chain Building  Certificate Verification – Detailed description of certificate verification (certificate discovery, path validation, Revocation checking, certificate validity check)  Root CA Trust configuration – Chain validation – Overview of AKI ( Authority Key Identifier) and SKI (Subject Key Identifier)  Revocation Checking – What is CRL ( certificate revocation list)? – CRL Extensions – CRL overlap period – Delta CRL  Designing and configurating CDP location – Understanding LDAP CDP configuration – Understanding HTTP CDP confirmation (Advantage and disadvantage) – CRL Configuration (LDAP Vs. HTTP) – Revocation strategy Summary of Module 02: Certificate Revocation and Chain Building
  13. 13. 13 Brief summary of module 2 : The below mentioned topics will be covered in this module Certificate Verification and Chain Building  Revocation cache – Disk cache – Memory cache  Online certificate status protocol (OCSP) – Overview of OCSP – Detailed description of OCSP mechanism  Troubleshooting – Revocation issues – Certificate Path validation events Module Review Q &A Summary of Module 02: Certificate Revocation and Chain Building- cont’d
  14. 14. Online Certificate Status Protocol (OCSP) NOTE: We are providing an overview of the above-mentioned topic from module 2, which will be discussed in the training sessions
  15. 15. 15 The Pillars of Certificate Verification Certificate Discovery The issuing CA certificate and all CA certificates up to the root CA certificate are collected Path Validation CA certificate chain is validated until a self- signed root certificate is reached Revocation Checking CRL OCSP Certificate Validity Check Content Format Critical extensions Policy validation Trusted Root CA check Signature check Time validity Building the Certificate Chain
  16. 16. 16 OCSP in a Nutshell  OCSP client searches for locally cached time-valid OCSP response from prior query  OCSP client sends HTTP request to OCSP responder for certificate status providing the certificate serial # of interest  OCSP responder replies with a signed response that includes the revocation status of the certificate based on its cached knowledge from the CRL issued by the CA  OCSP client validates the signature of the response prior to accepting and caching the response: • Valid response cached for remaining duration of OCSP responder cached CRL
  17. 17. 1717 OCSP Mechanics
  18. 18. 18 Module 03: Deploy a Two- Tier PKI Hierarchy  In this module, you will learn: • Two-tier CA Hierarchy • Define CAPolicy.inf for root Certification Authority (CA) and subordinate CA • Active Directory Certificate Services (AD CS) PowerShell cmdlets • Install and configure offline root CA • Publish root CA certificate and CRL to CDP and AIA URLs • Install and configure subordinate CA • Post-install health checks • CA Security
  19. 19. 19 Brief summary of module 3 : The below mentioned topics will be covered in this module Deploy Two-tier CA Hierarchy  Define CAPolicy.inf File  Certificate Template Management Deploy Standalone and Offline Root CA  Install and Configure Offline Root CA  Root CA Post-install Configuration  Understanding LDAP and HTTP CDP Configuration  Understanding LDAP and HTTP AIA Configuration  Configure Root CA Auditing Deploy Subordinate Issuing CA  Install and Configure online Subordinate CA  Post Installation Configuration Module 03: Deploy a Two- Tier PKI Hierarchy- cont’d
  20. 20. 20 Brief summary of module 3 : The below mentioned topics will be covered in this module Validate initial PKI deployment health Setup CA Web Enrollment Proxy for FabrikamIssuingCA Certification Authority Security  Certification Authority's Risk Exposure  Where are the CA’s private keys stored?  Features provided by a Hardware Security Module (HSM)  Risk Exposure due to CA Backup  Overview of Offline Certification Authorities  Certification Authority Hardening Recommendations  How to secure remote management tasks  Enable and configure windows firewall  Define Windows-based CA administrative roles  Define multi-factor authentication for a CA management  Configure security audit policy Module Review Q&A Module 03: Deploy a Two- Tier PKI Hierarchy - cont’d
  21. 21. Understanding LDAP CDP Configuration NOTE: We are providing a detailed overview of the above-mentioned topic from module 3, which will be discussed in the training sessions
  22. 22. Understanding LDAP CDP Configuration Default LDAP CDP: 10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10  Specifies publishing details (see table below)  10 means that the following checkboxes are enabled: Note: This setting will disclose LDAP information in the CRL 22
  23. 23. Understanding LDAP CDP Configuration (continued) Default LDAP CDP: 10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10 • CN=%2 specifies a subcontainer in AD (see table next page) • CN=%2 stands for „SERVERSHORTNAME“ and results in something like ldap:///CN=FabrikamRootCA,CN=ADCSCA01,CN=CDP,CN=Public%20K ey%20Services,CN=Services,CN=Configuration,DC=Fabrikam,DC= com?certificateRevocationList?base?objectClass=cRLDistribu tionPoint We will remove the SERVERSHORTNAME, resulting in 10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10 23
  24. 24. LDAP CDPs – the AD Sites and Services View  The CRL is an attribute of the cRLDistributionPoint object in AD  By default, the CRL object is stored in a sub container named by the computer name 24
  25. 25. Understanding HTTP AIA Configuration Default HTTP AIA: 2:http://%1/CertData/%1_%3%4.crt Defines which checkboxes are enabled: Stands for SERVERFQDN and results in http://ADCSCA01/CertData/ADCSCA01_FabrikamRootCA.crt We will replace respectively remove the CA’s computername’s FQDN which results in: 2:http://pki.fabrikam.com/CertData/%3%4.crt 25
  26. 26. CDP and AIA Interaction Root CA cert: CDP = empty AIA = empty 1 2Root CA Configuration: CDP=http://pki.fabrikam.com/Certdata/FabrikamRootCA.crl AIA =http://pki.fabrikam.com/Certdata/FabrikamRootCA.cer Sub CA cert: CDP=http://pki.fabrikam.com/Certdata/FabrikamRootCA.crl AIA =http://pki.fabrikam.com/Certdata/FabrikamRootCA.cer 3 Sub CA Configuration: CDP=http://pki.fabrikam.com/Certdata/FabrikamIssuingCA.crl AIA =http://pki.fabrikam.com/Certdata/FabrikamIssuingCA.cer 4 End-Entity cert: CDP=http://pki.fabrikam.com/Ce rtdata/FabrikamIssuingCA.crl AIA =http://pki.fabrikam.com/Certda ta/FabrikamIssuingCA.cer 5 26 2
  27. 27. 27 Module 04: Certificate Templates and Enrollment Methods  This module covers the purpose of certificate templates. Configuration and management will be explained in addition to different enrollment methods.  This module will give you an overview of: • Certificate Templates • Template Versions • Configuration of Templates • Enrollment methods • Revocation Cache  How templates can be created and modified  How certificates can be enrolled
  28. 28. 28 Brief summary of module 4 : The below mentioned topics will be covered in this module Certificate Template Terminology  Definition of Certificate Template – Standalone CA Vs. Enterprise CA – How to map Templates to the AD Object – What are the Template Versions – Overview of Template Management – Define Template Settings Enrollment Methods  Several ways to enroll certificates – Manual enrollment, auto enrollment , offline certificate enrollment – Enrollment using command line – Autoenrollment group-policy settings – Enrollment agent – Enrollment Strategy Lab: Configuring Templates and Enrollment Module Review Q& A Module 04: Certificate Templates and Enrollment Methods - cont’d
  29. 29. Template Versions NOTE: We are providing an overview of the above-mentioned topic from module 4, which will be discussed in the training sessions
  30. 30. Template Versions  Template versions define the generation of the template  V1 to V4 is available (depending on CA)  Any template version will create an X509 V3 certificate  The CA administrator should use the Certificate Template console to manage and configure templates. The template is then stored in the configuration partition of AD once the administrator closes the template’s configuration.  To access the Certificate Template console: • Log on to Enterprise Certification Authority. • Type Certtmpl.msc in the Search Programs and Files and then press Enter. 30
  31. 31. Template Versions Microsoft CAs support four types of certificate templates: Version 1, Version 2 , Version 3 and Version 4 Version 1 Certificate Templates  Version 1 templates are provided for backwards compatibility. They are created by default when a CA is installed and cannot be modified or removed. The security permissions on a V1 template is the only modification option. They can be duplicated, creating a Version 2/3/4 template that can be modified. Version 1 templates are supported on all Windows Server 2003 through Windows Server 2012 editions. 31
  32. 32. Template Versions Version 2 Certificate Templates  Version 2 templates were introduced in the Windows Server 2003 family. They allow customization of most settings in the template. Several preconfigured Version 2 templates are supplied in the default configuration, and more can be added, as necessary. This allows complete configuration flexibility for administrators.  With Windows Server 2003 and 2008, version 2 templates could only be published on CAs running on the Enterprise Edition of Windows. This limitation was ended with Server 2008 R2 and later. 32
  33. 33. Template Versions Version 3 Certificate Templates  Version 3 templates were introduced in the Windows Server 2008. These certificate templates have been updated to support new features available in the Windows Server 2008–based CA, including Cryptography Next Generation (CNG), which introduces support for Suite B cryptographic algorithms, such as ECC. Administrators can configure support for these new certificate template features using the template properties options in the Certificate Templates snap-in in Windows Server 2008.  Version 3 templates are created by duplicating a Version 2 template, selecting Windows Server 2008 R2/Windows 7 on the compatibility tab and Key Storage Provider on the Cryptography tab. 33
  34. 34. Template Versions Version 4 Certificate Templates The new features that version 4 certificate templates include are:  Renew with the same key  Support for both CSP and KSP as well as the ability to organize providers in order of preference  Allow key-based renewal  Enable requestor specified issuance  Only available on Windows 2012 CAs  In contrast to Version 3 templates, Version 4 templates, you can switch between Legacy CSP and KSP and have the algorithm name determined by the CSP. 34
  35. 35. 35 (*) Starting in Windows Server 2008 R2 V2 and V3 can be issued by an Enterprise CA running on a Standard Server OS Template Versions Version 1 Version 2 Version 3 Version 4 Minimum CA OS Windows Server 2000 Windows Server 2003 Enterprise Windows Server 2008 Enterprise Windows Server 2012 Minimum Client OS Any Windows XP Limited compatibilit y with Windows XP Windows Vista and later Options Just ACRS, no auto- enrollment Can be customized Supports CNG or KSP Supports CSP and KSP together (*) (*)
  36. 36. 36 Module 05: Enhancements in Windows Server 2012 and later 36  Windows Server 2012 (and later) and Windows 8 (and later) introduce a lot of new PKI-related features: • New installation and deployment features • New Server Core features • Enhanced RPC Security • ADCS Site Awareness for ADCS and PKI Clients • Support for Internationalized Domain Names (IDNs) • Template management and Version 4 templates • Group Protected PFX • Certificate Lifecycle Notification • Key-based renewal • Certificate renewal with same key • TPM Key Attestation • Policy module for NDES
  37. 37. 37 Brief summary of module 5 : The below mentioned topics will be covered in this module Installation and Deployment  Installation and deployment features – Installation process – Overview of new server core features – Overview of Enhance RPC security ADCS Site Awareness for ADCS and PKI Clients  Overview of ADCS Management Pack – Enable ADCS Site Awareness for ADCS and PKI Clients – Detailed discussion on Internationalized Domain Names (IDNs) – Detailed discussion on Template Versions – Group Protected PFX Certificate Lifecycle Notification Key-based Renewal – Requirements for key based renewal – Certificate Renewal with same key Module Review Q& A Module 05: Enhancements in Windows Server 2012 and later - cont’d
  38. 38. 38 Brief summary of module 5 : The below mentioned topics will be covered in this module Key-based Renewal – Requirements for key based renewal – Certificate Renewal with same key TPM Key Attestation – CA Configuration Policy Module Support for NDES Module Review Q& A Module 05: Enhancements in Windows Server 2012 and later - cont’d
  39. 39. Key Based Renewal NOTE: We are providing an overview of the above-mentioned topic from module 4, which will be discussed in the training sessions
  40. 40. 40 Key-based Renewal Key-based automatic certificate renewal  Certificate Enrollment Web Services in Server 2012 and later adds the ability to automatically renew certificates for computers that are part of untrusted AD DS domains or even not joined to a domain **The details of Certificate Enrollment Web Services will be covered in module 6 of this workshop
  41. 41. 41 Requirements for Key-based Renewal  Windows Server 2019  Windows Server 2019/Windows 8 and later client  Template settings: • Template must be marked to require CA certificate manager approval • Valid existing certificate, Allow key base renewal must be enabled • Use subject information from existing certificates for autoenrollment renewal requests must be enabled • Key usage must include Client Authentication  Certificate Enrollment Policy: authentication type cannot be Windows integrated  Key-based Renewal must be enabled on the Policy Server
  42. 42. 42 Module 06: Public Key Infrastructure (PKI) Maintenance & Availability Operations 42  CA Operations • Offline CA Maintenance • CA Backup • Private Key Backup & Storage • CA Renewal • Maintenance Tasks on a Clustered CA  CRL Maintenance • Offline CA CRL Publishing • CRL Re-Signing/Emergency CRL Signing  Exit Modules: • Functionality • Availability  CA Monitoring **While the technical setup of Active Directory Certificate Services (ADCS) is (normally) an easy and straight forward task, CA maintenance and operation is often handled with low priority. This lesson is introduced to bring this important tasks to your attention.
  43. 43. 43 Brief summary of module 6 : The below mentioned topics will be covered in this module CA Operations  CA maintenance – Planning for highly available PKI – Security best practices for offline CA maintenance – Protection of Private CAs – Define physical and logical access to the offline CAs – Overview of CA backup and private key storage (backup CA registry and configuration files, general information, PKI configuration from AD etc.) – Overview of CA Renewal process – Factors to be aware of, when planning CA certificate lifetimes. – Standards of Key length and CA security – CA security Vs. CA access – How to maintain a clustered CA CRL Maintenance  Best Practices for CRLs – Set CRL overlapping period – Controlling CRL Size – Removing expired CRLs – Planning for offline CA CRLs Publish – Overview on CRL Re-signing and Emergency CRL singing Module 06: Public Key Infrastructure (PKI) Maintenance & Availability Operations - cont’d
  44. 44. 44 Brief summary of module 6 : The below mentioned topics will be covered in this module Exit Modules  Exit module functionality – Utilization of Exit Modules – Exit Modules available from Microsoft CA Monitoring  Overview of ADCS Management Pack – CA Service status checking – Events monitoring – Overview of SCOM ADCS health roll-up – Overview of complete PKI health roll-up – Summary of the monitoring status checking Documentation and Processes  Overview of all the necessary documents to be prepared for the CA handling process Module Review Q& A Module 06: Public Key Infrastructure (PKI) Maintenance & Availability Operations - cont’d
  45. 45. Planning for High Availability NOTE: We are providing an overview of the above-mentioned topic from module 4, which will be discussed in the training sessions
  46. 46. 46 Planning for High Availability Planning for a highly available PKI involves thinking of the following when designing the solution: Hardware Software Processes Redundant issuing Certificate Authorities (CAs) Virtualization Recovery procedures Hardware selection Clustering (Fail-over and Network Load Balancing (NLB)) Recovery contingency Resilient disk layout Built-in HA logic for CEP/CES Testing and change procedures Cold standby Redundancy for Certificate Revocation List (CRL) and Authority Information Access (AIA) Hardware Security Module Availability CRL overlap and extended validation period
  47. 47. 47 Planning for High Availability Planning for a highly available PKI involves thinking of the following when designing the solution:  High availability can be achieved by a design with redundancy built into it, but it also requires planning for the unexpected.  Redundancy can be done in multiple ways.  On the hardware side, we have redundant Certificate Authorities (CAs), virtualization, cold standby, Redundant Array of Independent Disks (RAID), multiple network and disk channels etc.  On the software side, we have clustering, redundant Certificate Revocation List (CRL) and Authority Information Access (AIA).
  48. 48. 48 Planning for High Availability  Recovery processes and change processes are also needed to ensure the service availability. Redundant Issuing CAs  Having more than one CA capable of issuing each certificate type will allow you to continue issuing and renewing certificates in the event of a single CA failure. The same certificate templates must be available on each CA. This will not improve the availability of revocation information, so it may be of limited value. You need to decide whether the increased availability of enrollment services is worth the additional complication of duplicating CAs.
  49. 49. 49 Planning for High Availability Hardware Selection  Using resilient server hardware will make hardware component failure less likely. Pay particular attention to fault-prone components such as disks and power supplies. Use only one or two identical hardware specifications for all the CAs to make recovery easier. Resilient Disk Layout  Putting the certificate database and the database logs on separate physical volumes (that is, independent disk sets) will give you the best chance of recovering CA data following a catastrophic disk failure.
  50. 50. 50 Planning for High Availability Creating a Cold Standby  To recover from failure as quickly as possible, you can create a standby server. This is a server with the Operating System (OS) pre-loaded, but without certificate services installed. Such a system will allow you to recover the CA’s private key, database, logs and configuration. This is normally only needed for online issuing CAs. The server must duplicate the hardware specification of the CA(s) to be recovered if physical hardware is used. If you use HSMs, you need a duplicate HSM as a part of your standby configuration. You should install the same version of the OS as the one you used on your CAs.
  51. 51. 51 Planning for High Availability HSM Availability  The HSM can often be cluster. Redundant network links between the CAs and the HSMs can also be needed. You must also establish special procedures and controls around the HSM hardware, the key store, and the operator and key regeneration cards. This should include a regular audit of the card holders, so you know that you are able to quickly obtain the correct cards in and documentation on how to set up the connection again in case of an emergency.
  52. 52. 52 Planning for High Availability Virtualization  It can provide hardware redundancy if the Virtual Machine (VM) can move between the hosts in case of hardware failure. Be aware that virtualization does not prove resilience for software failure of the VM and that it can be used in combination with clustering with some limitations. Clustering  The CAs can be clustered using Fail-over clustering as an active/passive pair sharing the same disk. This will provide the highest redundancy for enrollment services but will provide limited value to the availability of revocation. Any cluster increases the complexity of the design and the implementation.  Web servers and Online Certificate Status Protocol (OCSP) can use Network Load Balancing (NLB) (both software and hardware)
  53. 53. 53 Planning for High Availability Built-in HA logic for Complex Event Processing (CEP)/CES  CEP/CES has built-in load balancing features: http://social.technet.microsoft.com/wiki/contents/articles /7734.certificate-enrollment-web-services-in-active- directory-certificate- services.aspx#Planning_Load_Balancing_and_Fault_Toler ance  Network Device Enrollment Service (NDES) cannot be clustered.
  54. 54. 54 Planning for High Availability Redundancy for CRL and AIA  Improving the availability of revocation information by using multiple CRL and AIA distribution points. This can be done by using clustered (network load balanced) Web servers for your HTTP distribution points and by using Active Directory (AD) domain controllers if Lightweight Directory Access Protocol (LDAP) is used since information then is stored in the configuration partition of Active Directory and replicated to all domain controllers in the forest. CRL overlap and extended validation period  CRLs need to be accessible; overlap periods and extension of validity period can be used to buy time for correcting a problem with issuing a new CRL.
  55. 55. 55 Planning for High Availability Recovery Procedures  You need to document the manual steps required to recover one or more of your CAs. The support staff who will carry out the recovery procedures need to be trained in the procedure. You must also rehearse the procedure fully to ensure that it works correctly and in a timely manner.
  56. 56. 56 Planning for High Availability Recovery Contingency  You should also ensure that you have recovery contingency procedures in place that allow the Public Key Infrastructure (PKI) to continue to function while the recovery procedures are being performed. The most critical is a means to extend the life of a CRL if the CA that issued it cannot be brought back online in time to issue a new one. You can extend the lifetime of a CRL using the procedure re-signing a CRL or certificate to extend its validity. (You must have access to the CA's private key to do this.) You may also need to back up the CA to temporarily take over the issuance and renewal of certificates from the failed CA.
  57. 57. 57 Planning for High Availability Testing and Change Procedures  By verifying the changes in a test environment and following a change process potential problems can often be discovered and avoided before they cause problems for production.
  58. 58. 58 Module 07: Cloud PKI Hierarchy 58  In this module, you will learn: • Different PKI Hierarchy in Cloud PKI deployment • CA Security considerations in Cloud
  59. 59. 59 Brief summary of module 7 : The below mentioned topics will be covered in this module PKI Hierarchy in Cloud PKI deployment  CA Architecture in cloud Integration of PKI with Cloud Providers  Several architectural overview of PKI with cloud providers  Advantages of PKI in cloud Offline Root CA  Install and configure offline Root CA Subordinate Issuing CA  Install and Configure Subordinate Issuing CA  How to configure CDP/AIA in Cloud Certification Authority Security (Risk Exposure)  Protect the CA private keys  Recommendations for hardening certificate authority  Configure audit policies Module 07: Cloud PKI Hierarchy
  60. 60. Integration of PKI with Cloud Providers NOTE: We are providing an overview of the above-mentioned topic from module 4, which will be discussed in the training sessions
  61. 61. 61 Simple Model #1 Name: Root CA Type: Stand alone CA – on prem Name: Issuing CA Type: Enterprise CA , on the cloud  This is the simplest cloud-based model for PKI  In this approach the root CA is on-prem and kept offline  The issuing CA is on the cloud  The Root CA is issuing certificate to the issuing CA  Issuing CA is the primary enterprise issuing CA  Issuing CA is issuing certificates to the end-entity
  62. 62. 62 Two Tier Model #2  In this approach the Root CA is on-prem and kept offline  Two issuing CAs are deployed – CA1 (on- prem) and CA2 (on the cloud)  CA2 will focus on issuance and availability outside of the premises  Whereas the on-prem issuing CA or CA1 will have security focus on non-cloud resources for example: workstation authentication, domain certificate etc.  This model can also be used as HA (high availability) concept – If one issuing CA is unavailable then the other one can take over ( optional). Name: Root CA Type: Stand alone CA – on prem Name: Issuing CA Type: Enterprise CA , on prem On prem HSM On prem HSM Name: Issuing CA Type: Enterprise CA , on the cloud Cloud HSM
  63. 63. 63 Three Tier Model #3  In this model Policy CA is configured on Prem and kept offline and secure  Policy CA is configured with a very explicit issuance and application policies  These policies will decide what is going to be issued and how it is going to be issued in any subordinate CA/issuing CA  The issuing CA is placed on the cloud, it will get a certificate from the policy CA placed above in the hierarchy (on-prem)  The issuing CA will not be able to issue certificate for another purpose expect the ones explicitly defined in the policy CA Name: Issuing CA Type: Enterprise CA , on the cloud Name: Root CA Type: Stand alone CA – on prem Name: Policy CA Type: On prem, with specific issuing policies
  64. 64. 64 Three Tier Hybrid Model #4  Root CA - on prem, kept offline and it is using HSM for its signing key  Policy CA- on prem, kept offline and it is using HSM for its signing key  Incorporating the approach explained in option 3  One issuing CA is in the cloud (CA2) and another issuing CA is on-prem (CA1) and both issuing CAs using HSMs  With this model we can allow the CA to be placed in the cloud and also be assured with the FIPS- level 3 certified HSM being secured on the cloud Name: Issuing CA Type: Enterprise CA , on the cloud Name: Root CA Type: Stand alone CA – on prem Name: Policy CA Type: On prem, with specific issuing policies Name: Issuing CA Type: Enterprise CA , on prem On prem HSM On prem HSM On prem HSM Cloud HSM
  65. 65. 65 PUNEET SINGH Principal puneetsingh@encryptionconsuting.com +1 (469) (815) (4136)

Editor's Notes

  • Certificate Verification is a multilevel process. The first chapter of this module deals with revocation checking based on CRLs.

  • When an application calls CryptoAPI 2.0 to verify a certificate that specifies locations to Online Responders, the revocation infrastructure performs the following basic steps (for each Online Responder specified in the authority information access extension):
    Search the local CryptoAPI 2.0 in-memory and disk caches to find a cached OCSP response that has a valid time. The disk cache is located at: <drive>:\Users\<User name>\AppData\LocalLow\Microsoft\CryptnetUrlCache. Note By default, response caching is performed by the OCSP client. This behavior can be changed by modifying the ChainCacheResyncFiletime value located in the HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config registry key. The ChainCacheResyncFiletime value specifies the date and time to clear the in-memory cache. The following Certutil commands can be used to modify the ChainCacheResyncFiletime value:
    To set a registry value to the current date and time: certutil –setreg chain\ChainCacheResyncFiletime @now
    To set a registry value to the current date and time plus 3 days and 1 hour: certutil –setreg chain\ChainCacheResyncFiletime @now+3:1
    To display a registry value: certutil –getreg chain\ChainCacheResyncFiletime
    To delete a registry value: certutil –delreg chain\ChainCacheResyncFiletime

  • 1. CAs publish CRLs
    2. OCSP array has access to these CRLs
    3. The client wants to verify a single certificate and sends the serial number of the certificate to the OCSP array using a HTTP request
    4. OCSP responder(s) verify the serial number by checking if the serial number was revoked, this is done by the OCSP server by CRL checking or by OCSP CRL cache checking
    5. If the certificate / serial number was revoked, the client will get this information in the HTTP response

  • The table below explains the variables used to configure CDP and AIA:
  • The sequence is as follows:
    The Root CA’s certificate does neither contain CDP nor AIA. In reality, they are not empty but simply not there.
    The Root CA’s configuration is adapted after the installation has completed.
    The Root CA’s configuration will be written to the Sub CA’s certificate.
    The Sub CA’s configuration is adapted after the installation has completed.
    The Sub CA’s configuration will be written to the end-entity’s (user or computer) certificate.



  • Certificate templates are an integral part of an Enterprise CA. They are an important element of the certificate policy for an environment, which is the set of rules and formats for certificate enrollment, use, and management.
    When a CA receives a request for a certificate, groups of rules and settings must be applied to that request to perform the requested function, such as certificate issuance or renewal. These rules can be simple or complex and may apply to all the users or specific groups of users. Certificate templates are the sets of rules and settings that are configured on a CA to be applied against incoming certificate requests. Certificate templates also give instructions to the client on how to create and submit a valid certificate request.
    Although all issued certificates are based on a certificate template, certificate templates can only be issued by an Enterprise CA running on Microsoft Windows Server 2008 R2 Standard, Microsoft Windows Server 2019 Enterprise, and Microsoft Windows Server 2019 Datacenter editions or above. The templates are stored in Active Directory (AD) for use by every CA in the forest. This allows the CA to always have access to the current standard template and ensures homogenous application of certificate policy across the forest.
  • The details of Certificate Enrollment Web Services will be covered in module 6 of this workshop.
    Certificate Enrollment Web Services were introduced with Windows Server 2008 R2 and Windows 7. This feature provides a possibility to enroll certificates to computers that are part of untrusted AD DS domains or even not joined to a domain. In Server 2008 R2 and Windows 7, enrollment of computer certificates is a manual task. For auto enrollment and renewal of certificates to work, the CA requires a very important piece of information: The identity of the requestor. In an intra-forest or Trust scenario, we can leverage Windows Integrated security to achieve this goal. Key based Renewal considers that the ownership of the certificate can be your identity. With the certificate itself as the authentication, any subject with access to the private key will be able to renew the certificate prior to its expiration.

×