On the Specify the type of the private key page, verify that Create a new private key is selected, and then click Next. Large key character lengths provide optimal security; however, they can impact server performance and might not be compatible with legacy applications. It is recommended that you keep the default setting of On the CA Name page, keep the suggested common name for the CA or change the name according to your requirements.
Ensure that you are certain the CA name is compatible with your naming conventions and purposes, because you cannot change the CA name after you have installed AD CS. The default setting of five years is recommended. On the CA Database page, in Specify the database locations , specify the folder location for the certificate database and the certificate database log.
If you specify locations other than the default locations, ensure that the folders are secured with access control lists ACLs that prevent unauthorized users or computers from accessing the CA database and log files. In Confirmation , click Configure to apply your selections, and then click Close. Skip to main content. This browser is no longer supported.
How you configure your production environment is up to you, but for this lab we're going to use 6 months. Next, we also want to ensure that our Subordinate CA's certificate doesn't expire yearly, which is the default. Remember, no CA can issue certificates for beyond its own expiration, so if we use a year, then nine months from now it won't be able to issue certificates with validity periods longer than three months.
We're going to use half of the life of the Root CA in our lab, which is ten years. Select the REQ file that you copied in the previous step, there will be no message that the request has been submitted. Go to the Pending Requests folder, right click on the request, and select Issue, the request should disappear. There are now three files we're going to need to copy. The first is the exported P7B from the wizard you just completed. Using whatever method works for you, get these three files back over the subordinate CA.
The REQ Request file that you used to generate the certificate is no longer required and can be safely deleted. If you're following along, we said these would be available in the CertEnroll folder of the intermediate server webserver.
When you're all done, it'll look something like this:. Are you getting this error? You've missed the step on ensuring "Include in the CDP extension of issued certificates" is checked from Part 1 of this series. Go back, enable that, and then start the request process again beginning from "Complete the following steps on your Root CA" a few paragraphs above this notice. Unlike our Root CA, this server will always be online.
Enterprise CAs use information that is stored in AD DS, including user accounts and security groups, to approve or deny certificate requests. Enterprise CAs use certificate templates. When a certificate is issued, the Enterprise CA uses information in the certificate template to generate a certificate with the appropriate attributes for that certificate type. If you want to enable automated certificate approval and automatic user certificate enrollment, use Enterprise CAs to issue certificates.
These features are available only when the CA infrastructure is integrated with Active Directory. Additionally, only Enterprise CAs can issue certificates that enable smart card sign-in, because this process requires that smart card certificates are mapped automatically to the user accounts in Active Directory.
By default, you must be a member of the Enterprise Admins group to install and configure an Enterprise CA. If you want a low-privileged domain administrator to install and configure an Enterprise CA, see Delegated Installation for an Enterprise Certification Authority. If you use stand-alone CAs, all information about the requested certificate type must be included in the certificate request.
By default, all certificate requests that are submitted to stand-alone CAs are held in a pending queue until a CA administrator approves them. You can configure stand-alone CAs to issue certificates automatically upon request, but this is less secure, and it is usually not recommended because the requests are not authenticated.
From a performance perspective, using stand-alone CAs with automatic issuance enables you to issue certificates at a faster rate than you can by using enterprise CAs.
However, unless you are using automatic issuance, using stand-alone CAs to issue large volumes of certificates usually comes at a high administrative cost because an administrator must manually review and then approve or deny each certificate request. For this reason, stand-alone CAs are best used with public key security applications on extranets and on the Internet, when users do not have user accounts and when the volume of certificates to be issued and managed is relatively low. You must use stand-alone CAs to issue certificates when you are using a non-Microsoft directory service or when AD DS is not available.
You can use both enterprise and stand-alone certification authorities in your organization, as explained in the following table. A root CA is the CA that is at the top of a certification hierarchy. It must be trusted unconditionally by clients in your organization. All certificate chains terminate at a root CA. Whether you use enterprise or stand-alone CAs, you need to designate a root CA. Since the root CA is the top CA in the certification hierarchy, the Subject field of the certificate that is issued by a root CA has the same value as the Issuer field of the certificate.
Likewise, because the certificate chain terminates when it reaches a self-signed CA, all self-signed CAs are root CAs. The decision to designate a CA as a trusted root CA can be made at the enterprise level or locally by the individual IT administrator.
A root CA serves as the foundation upon which you base your certification authority trust model. It guarantees that the subject's public key corresponds to the identity information shown in the subject field of the certificates it issues.
Different CAs might also verify this relationship by using different standards; therefore, it is important to understand the policies and procedures of the root certification authority before choosing to trust that authority to verify public keys. The root CA is the most important CA in your hierarchy. If your root CA is compromised, all CAs in the hierarchy and all certificates issued from it are considered compromised.
You can maximize the security of the root CA by keeping it disconnected from the network and by using subordinate CAs to issue certificates to other subordinate CAs or to end users. CAs that are not root CAs are considered subordinate.
This first subordinate CA can use this key to issue certificates that verify the integrity of another subordinate CA. These higher subordinate CAs are referred to as intermediate CAs. An intermediate CA is subordinate to a root CA, but it serves as a higher certifying authority to one or more subordinate CAs. An intermediate CA is often referred to as a policy CA because it is typically used to separate classes of certificates that can be distinguished by policies. For example, policy separation includes the level of assurance that a CA provides or the geographical location of the CA to distinguish different end-entity populations.
A policy CA can be online or offline. The private key is part of the CA identity, and it must be protected from compromise. Offline CAs should be stored in secure locations and not connected to the network. Issuing CAs use their private keys when issuing certificates, so the private key must be accessible online while the CA is in operation. In all cases, the CA and its private key on the CA should be physically protected. If you already have an existing private key that you want to use during installation, you can use the Existing Key screen to locate that key.
You can use the Change button to modify the cryptographic provider, and optionally, the CA that you want to search for an existing key. If you already have a certificate that contains the private key for the CA, you can use the Existing Certificate screen to locate it.
0コメント