Microsoft Certificate Authority Server

You can use this procedure to install Active Directory Certificate Services (AD CS) so that you can enroll a server certificate to servers that are running Network Policy Server (NPS), Routing and Remote Access Service (RRAS), or both.

Microsoft Certificate Authority Server

DOWNLOAD

A certification authority (CA) is responsible for attesting to the identity of users, computers, and organizations. The CA authenticates an entity and vouches for that identity by issuing a digitally signed certificate. The CA can also manage, revoke, and renew certificates.

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.

CAs that are not root CAs are considered subordinate. The first subordinate CA in a hierarchy obtains its CA certificate from the root CA. 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.

In Active Directory Domain Services (AD DS), the name that you specify when you configure a server as a CA becomes the common name of the CA, and this name is reflected in every certificate that the CA issues. For this reason, it is important that you do not use the fully qualified domain name for the common name of the CA. This way, malicious users who obtain a copy of a certificate cannot identify and use the fully qualified domain name of the CA to create a potential security vulnerability.

The CA name should not be identical to the name of the computer (NetBIOS or DNS name). Also, you cannot change the name of a server after Active Directory Certificate Services (AD CS) is installed without invalidating all the certificates that are issued by the CA. For additional considerations regarding CA names, see TechNet Wiki article: Considerations for Certification Authority (CA) Names.

After a root certification authority (CA) has been installed, many organizations will install one or more subordinate CAs to implement policy restrictions on the public key infrastructure (PKI) and to issue certificates to end clients. Using at least one subordinate CA can help protect the root CA from unnecessary exposure. When you install a subordinate CA, you must obtain a certificate from the parent CA.

You can use this guide to install Active Directory Certificate Services (AD CS) as an Enterprise root certification authority (CA) and to enroll server certificates to servers that are running Network Policy Server (NPS), Routing and Remote Access service (RRAS), or both NPS and RRAS.

In this scenario, the Enterprise Root certification authority (CA) is also an issuing CA. The CA issues certificates to server computers that have the correct security permissions to enroll a certificate. Active Directory Certificate Services (AD CS) is installed on CA1.

When you deploy server certificates, you make one copy of the RAS and IAS servers certificate template and then configure the template according to your requirements and the instructions in this guide.

You utilize a copy of the template rather than the original template so that the configuration of the original template is preserved for possible future use. You configure the copy of the RAS and IAS servers template so that the CA can create server certificates that it issues to the groups in Active Directory Users and Computers that you specify.

After you configure the certificate template on the CA, you can configure the default domain policy in Group Policy so that certificates are autoenrolled to NPS and RAS servers. Group Policy is configured in AD DS on the server DC1.

On the CA, configure a copy of the RAS and IAS Servers certificate template. The CA issues certificates based on a certificate template, so you must configure the template for the server certificate before the CA can issue a certificate.

Configure server certificate autoenrollment in Group Policy. When you configure autoenrollment, all servers that you have specified with Active Directory group memberships automatically receive a server certificate when Group Policy on each server is refreshed. If you add more servers later, they will automatically receive a server certificate, too.

Refresh Group Policy on servers. When Group Policy is refreshed, the servers receive the server certificate, which is based on the template that you configured in the previous step. This certificate is used by the server to prove its identity to client computers and other servers during the authentication process.

All domain member computers automatically receive the Enterprise Root CA's certificate without the configuration of autoenrollment. This certificate is different than the server certificate that you configure and distribute by using autoenrollment. The CA's certificate is automatically installed in the Trusted Root Certification Authorities certificate store for all domain member computers so that they will trust certificates that are issued by this CA.

In the first part in this series, I am going to walk you through setting up a simple Certificate Authority on Windows 2016 Server for a lab environment. If you want to get rid of those annoying warnings every time you open a web session for vCenter, or ESXi or pretty much any VMware product, you have to have a signed and trusted certificate on the web server. Without it, you are required to acknowledge the risk of connecting to the site and then clicking to continuing on to that site. This is particularly painful when you are trying to demo a product like the vROps Tenant App for vCD that has a iFrame that connects to the App. Unless you go and do the acceptances before you start the demo, you are stuck getting rid of these warnings which interrupt proceedings. In my lab environment, I setup a Microsoft Certificate Authority to sign certificates for the various tools I am running allowing me to get rid of that warning and have all green URLs in my browser.

• Exporting the Root CA Certificate from the Active Directory (AD) Server In the AD server, launch the Certificate Authority application by Start Run certsrv.msc.

• Right click the CA you created and select Properties.

• On the General tab, click View Certificate button.

• On the Details tab, select Copy to File.

• Follow through the wizard, and select the DER Encoded binary X.509 (.cer) format.

• Click browse and specify a path and filename to save the certificate.

• Click Next button and click Finish.

You can now access the NDES server from a web browser as an SCEPSvc user. From the NDES server, you can view the CA certificate thumbprint, the enrollment challenge password, and the validity period of the challenge password.

In a public key infrastructure (PKI), a certificate authority (CA) is a trusted entity that issues digital certificates. These digital certificates bind a public key to an identity (a person or organization) by means of public key cryptography and digital signatures. To operate a CA, you must maintain trust by protecting the private key that signs the certificates issued by your CA. You can store the private key in the HSM in your AWS CloudHSM cluster, and use the HSM to perform the cryptographic signing operations.

In this tutorial, you use Windows Server and AWS CloudHSM to configure a CA. You install the AWS CloudHSMclient software for Windows on your Windows server, then add the Active Directory CertificateServices (AD CS) role to your Windows Server. When you configure this role, you use an AWS CloudHSM keystorage provider (KSP) to create and store the CA's private key on your AWS CloudHSM cluster. The KSPis the bridge that connects your Windows server to your AWS CloudHSM cluster. In the last step, yousign a certificate signing request (CSR) with your Windows Server CA.

The US Government may not be the only one you trust. In fact, you probably trust a few different governments. If you could trace back a passport from someone in Japan to a valid root authority, you might trust them as well. And the UK, and Germany, and Mexico, and so on. If someone were to hand you a piece of paper that says "I am Kaylee Frye because I say I am", you may or may not trust them. This is a self-signed certificate, and we see them often in enterprises that don't stand up their own Certificate Authorities.

When you check on Amy's ID (certificate), you can see it was issued by the US Passport Authority. You may trust that authority already (because they're already in your Certificate Store as trusted), or you may trust them because you trust the US Government at the root. If someone were to come to you with an ID from Wakanda, and you don't already trust Wakanda as a Root Authority, you need to decide if you'll start trusting them, or if you won't.

Finally, we need to configure the CRL for this CA so that clients can find it. The CRL is a list of certificates that have been revoked by this authority. Revocation is different than an expiration; when a certificate has been revoked, someone is typically saying that it's either no longer in use, or that it has been compromised. Some services will ignore a missing CRL, while many others will not consider a certificate valid if it cannot find an updated CRL. 2ff7e9595c