Windows AD Certificate Services Family---Deployment CA (1)

When you decide to deploy a PKI in your enterprise, the first thing to be sure is how you plan to design your CA structure, which determines the core design of your internal PKI and the purpose of each CA in the structure. Each CA structure typically has two or more CAs, and in general, the deployment of the second CA and all subordinate CAs is for some special purpose, and only the root CA is required to be installed.

Note : The deployment of the CA structure does not mandate the use of PKI and certificates, and for smaller and simpler environments, you can deploy only one CA in the CA structure, which is typically the enterprise root CA.

If you decide to deploy a CA structure and you already have a root CA, then you have to decide what role to assign to the second and third tier CAs, generally we do not recommend building more than three layers of CA structure unless the company is a complex distributed environment.

The most common CA structure is a two-tier structure, the root CA is on the top level, the subordinate CA is on the second tier, and typically we leave the root CA offline and then issue and manage certificates for all clients through a subordinate CA, but in some complex scenarios you also need to deploy other types of CA structures. The CA structure typically falls into one of several types:

1. The CA structure with the policy ca. A policy CA is a subordinate CA type that is directly under the root CA in the CA structure. The policy CA will issue the certificate to the subordinate CA directly below it, and the enterprise deploys a policy CA to describe the policies and procedures to ensure the security of the PKI, which verifies the identity of the certificate holder and the mandatory management certificate. The policy certificate will only issue certificates to other CAs, and the CA that receives the certificate must accept and enforce policies defined by the policy ca. However, a policy CA is not mandatory unless the enterprise has multiple different departments, industries, or branches across the enterprise that require different issuance policies and processes. But if your business requires different issuance policies and processes, you must include a policy CA in the CA structure to define each unique policy. For example, a company can deploy a policy CA to issue all certificates to internal users, and then deploy another policy CA to issue all certificates to non-internal users.

2. A CA structure with Cross-certification Trust. In this case, when one CA in a CA structure issues a cross-certified CA certificate to a CA in another CA structure, these two separate CA structures interoperate. When performing this action, a two-way trust relationship is established between the two different CA structures.

3. Two-tier CA structure. In a two-tier structure, there is at least one root CA and one subordinate CA, at which point the subordinate CA is responsible for policy and issuing certificates to the certificate requester.

Stand-alone CAs and enterprise CAs

In Windows2012, you can deploy two types of CAs: stand-alone CAs and enterprise CAs. The biggest difference between the two is the integration and dependency of the Active Directory. A standalone CA does not require an ad domain and does not need to be dependent on the ad domain, whereas an enterprise CA requires an ad domain, but enterprise CAs have many advantages, such as the ability to register automatically.

From the comparison in the following table, we can see the most important differences between a stand-alone CA and an enterprise CA.

properties	standalone CA	enterprise CA
represent how to use	Standalone CAs are typically used as offline CAs However, it can be used as a CA, consistent with the CA on the network.	Enterprise CAs are often used to issue certificates to users, computers, and services. And will not normally be used as an offline CA.
Active Directory dependent	standalone CA not dependent on AD domain and can be deployed in a non-domain environment
Certificate request method		Users can request a certificate from an enterprise CA in the following ways: 1. Manual registration 2.WEB Registration 3. Autoenrollment 4. Registration Agent
Certificate issuing method	Certificate administrators must manually approve all certificate requests

The most common deployment structure is to use a root CA as a stand-alone CA that is set up offline after it has issued a certificate to itself and its subordinate CA, which is typically deployed as an enterprise CA.

Considerations when deploying a root CA

There are a couple of things to focus on when you deploy the root CA, first you decide whether to deploy an offline root CA, and in that case you need to decide if you want to deploy a stand-alone root CA or deploy an enterprise root CA.

Usually if we are deploying a single-layer CA structure with only one CA in the entire CA structure, we will typically choose to deploy it as an enterprise root CA, but if we deploy a two-tier CA structure, we typically choose to deploy a standalone root CA and an enterprise subordinate CA.

The next thing we need to consider is how the operating system is installed, AD CS supports the full installation and core installation of the operating system, the core installed operating system has a small attack surface and reduce the advantages of administrator operations, so in an enterprise environment we can consider the deployment of core installed operating systems, of course, ad CS is also capable of supporting the minimal Server interface operating system installation Method (Lite type).

In Win2012 we can also deploy the AD CS role through PowerShell. It is important to remember that after you have deployed a CA, you cannot change the computer name of the CA or the domain membership of the computer, and of course our domain name cannot be changed, so it is critical to confirm that the following properties are in place when installing the CA:

Precautions	Describe
Cryptographic service Provider (CSP cryptograhic service provider) for generating a new secret key	Default CSP as Microsoft Strong encryption Provider The provider with the character # in the name is the next generation encryption provider
Secret key length	The default key length of the Microsoft strong encryption provider is 2048 characters, which is the recommended minimum key length for the root CA secret key, but the best practice recommends using a 4,096-bit key.
The hash algorithm used by the CA-issued signing certificate	The default hashing algorithm is secure Hash algorithm 1, if your company does not have an older version of the operating system, such as XP, then you can choose to update the hash algorithm, such as SHA256
The validity period of a CA-issued certificate	A default value is defined for the validity period in the certificate template, and you can set different validity periods for different templates.
Status of the root CA (online or offline)	Try to configure the root CA as an offline CA, which enhances the security of the root certificate because it cannot be attacked over the network.

If you decide to deploy an offline standalone root CA, there are several special places to consider:

1. Before you issue a subordinate certificate from the root CA, the stand-alone root CA acts as a CDP (Revocation Publishing Point) and AIA (Authority Information Access), so when you configure the root CA to take offline, revocation checking fails because CDP and AIA are inaccessible at this time, So when you redefine the CDP and AIA locations, you need to manually copy the CRL and AIA information to the new location.

2. Setting the validity period, such as setting the validity period of one year for a CRL published by the root CA, means that you must publish a new CRL from the root CA every other year, and copy the new CRL to the location where the client can obtain the CRL, and if you do not perform this action, after the root CA's CRL expires, Revocation checking for all certificates will fail.

3. Use Group Policy to publish the root CA certificate to the trusted root certification authorities for all servers and clients. Because a standalone CA cannot be executed as automatically as an enterprise CA, you must manually install the certificate for the server and client in the context of a stand-alone CA. You can also use the certutil command to publish the root CA certificate to the ad domain.

Considerations for deploying subordinate CAs

You can use a subordinate CA to deploy policy restrictions for your PKI and publish certificates to clients, and when you have a root CA installed in your company, you can install one or more subordinate CAs.

When you use a subordinate CA to publish certificates to users and computers in a domain, you can configure the subordinate CA as an enterprise CA so that you can use the data from the client accounts in the AD domain to publish and manage certificates and publish the certificates to the AD domain. However, to complete this action, the account you use must be a member of the local Administrators group or the same level of permissions, if you want to configure the subordinate CA as an enterprise CA, your account needs to be a member of the Domain Admins group or the same level of permissions, from a security perspective, It is recommended to use an offline root CA in conjunction with an enterprise subordinate CA.

The subordinate CAs are typically deployed to implement some of the following features:

1. Use. You can issue certificates for a variety of purposes, such as Secure Multipurpose Internet Mail Extensions (S/MIME), Efs,ras (Remote Access Service). The policies that issue certificates for these purposes can be different and can be managed separately from these policies.

2. Organizational Division. You can use different policies to issue certificates, depending on the role that the department or organization plays in the organization, and you can create subordinate CAs to isolate and manage these policies.

3. Geographical division. Organizations may have agencies that are distributed across different physical sites, and the network bandwidth of communication between these sites is limited, so we need to deploy separate subordinate CAs to those sites or all sites.

4. Load Balancing. If you want to publish and manage a large number of certificates through a PKI, only one CA will cause the network load of this CA to be too large, deploy multiple subordinate CAs to issue the same type of certificate, and distribute Network load across the various CAs.

5. Backup and fault tolerance. Deploying multiple CAs increases the availability of CAs, ensuring that you always have a functioning CA server on your network, increasing the likelihood that users will receive a response when they request a certificate.

Use the CAPolicy.inf file to install

If you want to deploy a root CA or subordinate CA, use some pre-defined values during installation, or want to define some additional parameters, we can use CAPolicy.inf to achieve these goals. The CAPolicy.inf file is a plain text file that contains multiple configuration items when the AD CS role installs or renews the CA certificate. The CAPolicy.inf file does not require the AD CS role to be installed, but without AD CS, only the default settings are applied, and in most cases it is not enough to use the default settings, and we can do more complex deployments with the CAPolicy.inf file.

Each CAPolicy.inf file is divided into several areas, and it has a simple structure, as described below:

1. section is an area of the. inf file that contains a logical set of keys that are always enclosed in parentheses in the. inf file

2. The secret key appears to the left of the "=" sign as a parameter

3. Value appears to the right of the "=" sign as a parameter

For example, if you want to specify an authority information access point in the CAPolicy.inf file, you can use the following syntax:

[AuthorityInformationAccess]

Url=http://pki.adatum.com/certdata/adatumca.crt

In the above example, AuthorityInformationAccess is an area where the URL is the secret key, http://pki.adatum.com/CertData/adatumCA.crt is the value.

You can also specify some CA server settings in the CAPolicy.inf file, for example:

[Certsrv_server]

renewalkeylength=2048

Renewalvalidityperiod=years

Renewalvalidityperiodunits=5

Crlperiod=days

crlperiodunits=2

Crldeltaperiod=hours

Crldeltaperiodunits=4

Clockskewminutes=true

Loaddefaulttemplates=true

Alternatesignaturealgorithm=0

Forceutf8=0

Enablekeyconuting=0

You can also define the following configurations when you install AD CS through the CAPolicy.inf file:

1. Certificate Implementation statement. Describes the implementation settings that the CA uses to issue certificates, including the types of certificates issued, the information issued, the renewal and recovery of certificates, and other detailed CA configurations.

2. The object identifier (OID object Identifier). Identifies a specific object or attribute

3. The CRL advertisement interval. Defines the interval at which the underlying CRL is advertised.

4. CA update settings. Define the following update settings

   A. Secret key size. Defines the length of the pairing key for the root CA renewal

   B. Certificate validity period. Define the validity period of the root CA certificate

   C.CDP and AIA paths. Provide these paths for root CA installation and renewal

Once you have created the CAPolicy.inf file, you must copy it to the server's%systemroot% folder before installing the AD CS role or renewing the CA certificate.

This article is from the "Dry Sea Sponge" blog, please be sure to keep this source http://thefallenheaven.blog.51cto.com/450907/1611149

Windows AD Certificate Services Family---Deployment CA (1)