Check up this:
This series of blog posts aim to help people who are about to start working on PKI and want a quick start guide. So we are going to design a PKI infrastructure for Contoso. Later, i will publish the Implementation Series to carry on the Contoso PKI story.
- CA management strategy implemented by Contoso Corporate. Since Centralized IT administration is implemented in Contoso IT environment, a central team in Head Office will define the PKI design.
- Prior Existing of PKI in Contoso network. There is already single enterprise CA in Contoso network, mainly used for Microsoft office live communicator server.
Applications that use PKI
A PKI deployment is typically launched when one or more applications that are dependent on the existence of a PKI are introduced. This leads to defining requirements as to who will manage the applications, the number of users, the certificate distribution, and how certificates are used by the applications.
PKI-Enabled Applications in Contoso International Network:
- 802.1x port-based authentication.
- Digital signatures.
- Encrypting File System (EFS).
- Web authentication and encryption.
- IP security.
- Smart card logon.
- Secure e-mail.
- Future Needs ( Network Access Protection NAP ,etc)
Holders of Certificates
Certificate holders are those who request and require certificates .Certificate holders are:
- Network Devices
- Security Requirements: CA hierarchy must enforce Contoso security policy and since there are many partners involved, CA hierarchy should also enforce any security requirements for external partners. This is done by implementing high Security measures such as physical security and O.S hardening.
- Administration Requirements: Centralized administrations requires Centralized CA servers on the root active directory domain of Contoso. Management tasks will be handled by the IT team in the main office.
- Availability requirements: Installing many CA servers and maintaining certificates templates on each server increase the availability of certificate issuing services. Spreading CA server in different geographical locations also prevents a natural disaster hitting one data center to affect other CA servers.
The business requirements for designing a PKI include internal and external access requirements, availability requirements, and legal requirements.
- External Access Requirements: To issue certificates to partners, at least one CA should be accessible from the internet. Microsoft ISA server can be used to implement web publishing and to authenticate partners with active directory .Publication of the certificate revocation lists (CRL) and CA certificates should be taken into consideration for external certificates validation.
- Legal Requirements: Certificate Authorities should inform certificate holders and requesters about any legal requirements and obligations for certificate use of issued certificates. By defining Certificate Practice Statements (CPS), Contoso International can define legal requirements for certificate enrollment, use and revocation. CPS can be used also to define liability of Contoso Corporate in the event of a beach of security.
Define Legal Requirements
That is, defining Contoso International legal requirements for issuing certificates that are issued by CAs. The legal requirements are published in Contoso Security Policy, Certificate Policy, and Certificate Practice Statement (CPS). CPS must be published on a CA and available to all users and computers that require certificates from Contoso PKI.
CA Hierarchy Design
Since Contoso International Technical Support is centralized, and due to the nature of separating Contoso stations to child domains under the forest root domain, CA servers will be hosted on the root forest domain and will issue certificates to certificate recipients hosted on the child domains.
CA servers location will be centralized in Contoso data centers (Hierarchy by location) because of:
- Each Region is connected to Contoso data center.
- Business requirements for CA availability in the event of disaster in one data center.
- Localize distribution, management and enrollment of certificates
Defining the PKI Management Staff
- CA administrator. Responsible for managing the configuration of the CA computer, including defining the CA’s property settings and certificate managers. A user is delegated this role through the assignment of the Manage CA permission at the CA. This rule is given the Infrastructure Team in Contoso Head Office IT Team.
- CA officer. Responsible for certificate management. Also known as the certificate manager. Tasks include certificate revocation, issuance, and deletion. In addition, the certificate manager extracts archived private keys for recovery by a key recovery agent. A user is given this role through the assignment of the Issue and Manage Certificates permission at the CA. This rule is given the Infrastructure Team in Contoso HEAD OFFICE IT Team.
- Backup operator. Responsible for the backup and recovery of the CA database and CA configuration settings. A user is delegated this role through the assignment of the Back Up Files and Directories or the Restore Files and Directories user rights at the Group Policy Object (GPO) assigned to the CA or in the CA’s local security policy. This rule is given the Operations Team in Contoso HEAD OFFICE IT Team.
- Auditor. Responsible for defining the events audited at the CA and for reviewing the security log for events related to PKI management and operations. A user is given this role through the assignment of the Manage Auditing and Security Log user right at the GPO assigned to the CA or in the CA’s local security policy. This role is given to both IT operations Team and the IT Infrastructure Team with the help of Microsoft MOM to collect such events from the online issuing CAs.
Defining the PKI Hardware Resources
The hardware resources depend on the level of security required and the type/number of PKI applications involved.
Storing the CA keys on Hardware Security Modules (HSM) is the most secure way but also most expensive ways .Other ways could be smartcards .In Contoso International Implementation, the CA keys will be kept on the local computer store, thus eliminating extra cost and providing satisfying level of security.
At the time or writing this document, smartcards are not to be implemented yet but could be in the near future. Smartcard implementation will provide extra cost for any PKI Implementation because of purchasing the smartcards itself and the smartcard readers.
The Offline Root CA is to be hosted in a virtual machine, thus eliminating the need to purchase a new hardware for it.
The initial implementation of the Contoso PKI project will consist of Offline Root CA hosted in virtual machine and another online Policy/Issuing CA hosted on a live server. All CA keys are stored locally by choosing Microsoft CSP to generate the keys.
In summary, the hardware resources for the initial implementation are the online issuing CA server hardware since the Offline Root CA will be hosted in a virtual machine. No other issuing CA servers will be installed in the first phase of the PKI implementation.
PKI Design – Number of Tiers
Contoso IT Team has decided that a two-tier PKI topology is the most suitable for their organization. A two-tier hierarchy comprises an offline root CA and one or more issuing CAs. The issuing CAs are a combination of policy CAs and issuing CAs.
To ensure security in a two-tier hierarchy, the root CA is deployed as a standalone root CA. This allows an organization to deploy the root CA offline—that is, the CA is removed from the network to provide the computer with additional physical security.
In a multi-tier CA hierarchy, it does not matter which second-tier CA issues the certificates to computers, users, services, or network devices. All that matters is that the certificate issued by the second-tier CA chains to a trusted root CA—the offline root CA in this configuration.
To enhance the availability of Certificate Services, two or more issuing CAs must exist at the second tier. This prevents Certificate Services from being unavailable due to a single point of failure. The number of issuing CAs depends on the organization’s requirements. For example, a CA hierarchy can have different CAs for each geographic region, each sector or business unit, or each identified certificate policy used to validate a certificate’s subject. In the initial implementation, one issuing CA will be installed. Later on, other issuing CA servers will be installed.
Choosing an Architecture
The more certificates distributed, the more CAs required especially true that Contoso organization is geographically dispersed across continents or regions. A common design places issuing CAs at major hub sites in the network topology to provide regional site availability. This also provides high availability for certificate services since clustering is not supported for CA servers. Having multiple Issuing CAs ensures that the organization can still issue certificates in case one of the issuing CAs is down. Separating the issuing CAs in geographically separated hubs ensures that a big disaster hitting one hub will not bring the whole PKI system down.
Determining Certificate Validity Periods and renewal strategy
A certificate has a predefined validity period that comprises a start date and time and an end date and time. An issued certificate’s validity period cannot be changed after certificate issuance. Determining the validity period at each tier of the CA hierarchy, including the validity period of the certificates issued to users, computers, services, or network devices, is a primary step when defining a CA hierarchy.
The recommended strategy for determining certificate validity periods is to start with the certificates issued to users, computers, services, or network devices by issuing CAs. The main point to remember is that a CA should not issue a certificate that exceeds the remaining lifetime on the CA certificate(actually the CA will NOT issue certificates with validity period that exceeds the remaining lifetime on the CA certificate). Although allowed by the standards, this scenario can lead to certificates with remaining validity periods to expire when the issuing CA’s certificate expires. It should be ensured that the CA has enough remaining lifetime on its certificate to issue certificates with the required validity periods. A good rule of thumb is to make the CA certificate validity period at least twice as long as the maximum validity period of any CA-issued certificates.
In addition to doubling the validity period, we can also follow best practices and ensure that the CA renews its CA certificate value at half of the remaining validity period. The first time we renew an issuing CA certificate (after a period of five years in this scenario), we renew it with the original key pair. After the next five years pass, we renew the CA certificate with a new key pair. This ensures that the same key pair is never used for a period longer than the intended original validity period of 10 years.
Note: Setting the Validity period for issued certificates on an issuing CA will determine the MAXIMUM validity period for any issued certificate, not the actual one. The actual one is determined by the Certificate Template of that certificate in case it is shorter than the CA certificate remaining lifetime period.
In this example, an issuing CA has Certificate (Version 1) valid from t=0 to t=10 and pair of public and private keys called (Key Pair X). The CA will renew its Certificate (Version 2) with the same key Pair X with validity between t=5 to t=15. The CA will renew its certificate again (Version 3) with new key pair Y with validity between t=10 to to=20.
It is also important to mention that the CA will issue certificates with validity of 5 years which is the half period of the issuing CA certificate validity period.
Let us say that a user got a certificate on t=3, it will be signed with CA Key pair X and will be valid till t =8. During the period (t=3 to t=8), the certificate can be used since the CA certificate that issue it (Version 1) is valid until t=10.
Let us assume also that a user got a certificate on t=7, it will signed with the CA key pair X and will be valid till t =12. During this period (t=7 to t=12), the certificate can be used since the CA certificate that issue it (Version 2) is valid until t = 15.
It is important to remember that the CA when renewing its certificate, it keeps the old certificate in its store in order for the certificates issued with the old one to continue been used during their validity.
In the case of a standalone CA, the definition of a validity period defines the validity period for all CA-issued certificates. In the case of an enterprise CA, the maximum validity period acts as a maximum value for any CA-issued certificates. An issued certificate is always assigned the lesser value of the remaining validity period of the CA certificate and the configured maximum validity period. In other words, if you define the maximum validity period as four years and the CA only has three years remaining in its certificate’s validity period; the validity period of a newly issued certificate is three years.
In the case of an enterprise CA, another variable enters the picture. Enterprise CAs issue certificates based on certificate templates. Each certificate template has its own configured validity period. The applied validity period for certificates issued by an enterprise CA is the minimum value of the CA certificate’s remaining validity period, the CA’s maximum validity period setting, and the certificate template’s validity period.
Let me explain more here ,suppose that the CA certificate will expire in 3 years , and the CA is configured via (Certutil.exe utility) to with validity period for issued certificate equals to 4 years , and a certain certificate template is configured with validity period of 5 years .The resultant is an issued certificate with 3 years validity!