Tag Archive for Certificate

Active Directory Certificate Services on Windows Server 2012

Certificate

Active Directory Certificate Services

Active Directory Certificate Services (AD CS) is an Identity and Access Control security technology that provides customizable services for creating and managing public key certificates used in software security systems that employ public key technologies.

What is a Certificate?

  • An Electronic document which contains information
  • Has an Issuer
  • Contains who the certificate is issued to
  • Contains an expiry date
  • Contains a public key which allows data to be encrypted only by someone who has the Private Key
  • Contains a digital signature which proves the certificate came from a trusted source and provides a checksum to the certificate for checking the certificate has not be altered

Features in AD CS

By using Server Manager, you can set up the following components of AD CS:

  • Certification authorities (CAs). Root and subordinate CAs are used to issue certificates to users, computers, and services, and to manage certificate validity.
  • Web enrollment. Web enrollment allows users to connect to a CA by means of a Web browser in order to request certificates and retrieve certificate revocation lists (CRLs).
  • Online Responder. The Online Responder service decodes revocation status requests for specific certificates, evaluates the status of these certificates, and sends back a signed response containing the requested certificate status information.
  • Network Device Enrollment Service. The Network Device Enrollment Service allows routers and other network devices that do not have domain accounts to obtain certificates.
  • Certificate Enrollment Web Service. The Certificate Enrollment Web Service enables users and computers to perform certificate enrollment that uses the HTTPS protocol. Together with the Certificate Enrollment Policy Web Service, this enables policy-based certificate enrollment when the client computer is not a member of a domain or when a domain member is not connected to the domain.
  • Certificate Enrollment Policy Web Service. The Certificate Enrollment Policy Web Service enables users and computers to obtain certificate enrollment policy information. Together with the Certificate Enrollment Web Service, this enables policy-based certificate enrollment when the client computer is not a member of a domain or when a domain member is not connected to the domain.

cert15

Benefits of AD CS

Organizations can use AD CS to enhance security by binding the identity of a person, device, or service to a corresponding private key. AD CS gives organizations a cost-effective, efficient, and secure way to manage the distribution and use of certificates.

Applications supported by AD CS include

  • Secure/Multipurpose Internet Mail Extensions (S/MIME)
  • Secure wireless networks
  • Virtual private network (VPN)
  • Internet Protocol security (IPsec)
  • Encrypting File System (EFS)
  • Smart card logon
  • Secure Socket Layer/Transport Layer Security (SSL/TLS)
  • Digital signatures.

Among the new features of AD CS are:

  • Improved enrollment capabilities that enable delegated enrollment agents to be assigned on a per-template basis.
  • Integrated Simple Certificate Enrollment Protocol (SCEP) enrollment services for issuing certificates to network devices such as routers.
  • Scalable, high-speed revocation status response services combining both CRLs and integrated Online Responder services

Hardware and software considerations

AD CS requires Windows Server 2008 and Active Directory Domain Services (AD DS). Although AD CS can be deployed on a single server, many deployments will involve multiple servers configured as CAs, other servers configured as Online Responders, and others serving as Web enrollment portals. CAs can be set up on servers running a variety of operating systems, including Windows Server 2008, Windows Server 2003, and Windows 2000 Server. However, not all operating systems support all features or design requirements, and creating an optimal design will require careful planning and testing before you deploy AD CS in a production environment

A limited set of server roles is available for a Server Core installation of Windows Server 2008 and for Windows Server 2008 for Itanium-based systems. AD CS cannot be installed on Server Core or Itanium-based installations of Windows Server 2008.

Managing AD CS

You can use either Server Manager or Microsoft Management Console (MMC) snap-ins to manage AD CS role services. Use the following steps to open the snap-ins:

  • To manage a CA, use the Certification Authority snap-in. To open the Certification Authority snap-in, click Start, click Run, type certsrv.msc, and click OK.
  • To manage certificates, use the Certificates snap-in. To open the Certificates snap-in, click Start, click Run, type certmgr.msc, and click OK.
  • To manage certificate templates, use the Certificate Templates snap-in. To open the Certificate Templates snap-in, click Start, click Run, type certtmpl.msc, and click OK.
  • To manage an Online Responder, use the Online Responder snap-in. To open the Online Responder snap-in, click Start, click Run, type ocsp.msc, and click OK.

Installing Certificate Services. Setting up an Enterprise CA

  • Open Server Manager
  • Click Add Roles and Features

cert1

  • Select Role based or feature based installation

cert2

  • Select Destination Server

cert3

  • Select Active Directory Certificate Services

cert4

  • Click Add Features

cert5

  • Click Next on Select Features

cert6

  • Read the Active Directory Certificate Services Page and click Next

cert7

  • On the Select Role Services, select Certification Authority and Online Responder

cert9

  • Read the Web Server Role (IIS) Page

cert10

  • Select IIS Role Services

cert11

  • Check the Confirm Installation Selections Page

cert12

  • Finish
  • On the Dashboard Page, you will see a warning triangle saying Further Configuration is needed
  • Click Configure Active Directory Services

cert13

  •  Specify the Credentials to configure Certificate Services

cert14

  • Select Role Services to Configure

cert16

  • Choose Enterprise CA

cert17

  • Specify CA type. Choose Root CA

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

cert18

  • Specify the type of the Private Key
  • Create a new Private Key

cert19

  • Specify the Cryptographic Options
  • Accept the default values

cert20

  • Specify the name of the CA

cert21

  • Specify the validity Period
  • Defaults to 5 years

cert22

  • Specify the Database Location

cert23

  • Check the Confirmation

cert24

  • Check Results
  • Click on the Web Links to learn more

cert25

  • Now you can hold down the Windows Key and Q which will open the Aero view
  • Select Certificate Services which will open the below

cert26

Configure the CA

After a root or subordinate CA is installed, you must configure the Authority Information Access (AIA) and CRL distribution point (CDP) extensions before the CA issues any certificates. The AIA extension specifies where to find up-to-date certificates for the CA. The CDP extension specifies where to find up-to-date CRLs that are signed by the CA. These extensions apply to all certificates that are issued by that CA.

Configuring these extensions ensures that this information is included in each certificate that the CA issues so that it is available to all clients. This ensures that PKI clients experience the least possible number of failures due to unverified certificate chains or certificate revocations, which can result in unsuccessful VPN connections, failed smart card sign-ins, or unverified email signatures.

As a CA administrator, you can add, remove, or modify CRL distribution points and the locations for CDP and AIA certificate issuance. Modifying the URL for a CRL distribution point only affects newly issued certificates. Previously issued certificates will continue to reference the original location, which is why you should establish these locations before your CA distributes any certificates.

Consider these guidelines when you configure CDP extension URLs:

  • Avoid publishing delta CRLs on offline root CAs. Because you do not revoke many certificates on an offline root CA, a delta CRL is probably not needed.
  • Adjust the default LDAP:/// and HTTP:// URL locations on the Extensions tab of the certification authority’s Properties Extension tab according to your needs.
  • Publish a CRL on an HTTP Internet or extranet location so that users and applications outside the organization can perform certificate validation. You can publish the LDAP and HTTP URLs for CDP locations to enable clients to retrieve CRL data with HTTP and LDAP.
  • Remember that Windows clients always retrieve the list of URLs in sequential order until a valid CRL is retrieved.
  • Use HTTP CDP locations to provide accessible CRL locations for clients running non-Windows operating systems.

cert27

Active Directory Certificate Services Best Practices

http://microsoftguru.com.au/2012/11/10/active-directory-certificate-services-best-practices/

Microsoft lab for building a two-tier certification authority PKI hierarchy

http://technet.microsoft.com/library/hh831348.aspx

Accessing the help files

  • Click Start > Run > Type hh certmgr.chm

Replace default certificate with a CA certificate

padlock

How default certificates work

The ESXi host uses automatically generated certificates that are created as part of the installation process. These certificates are unique and make it possible to begin using the server, but they are not verifiable and they are not signed by a trusted, well-known certificate authority (CA).
Using default certificates might not comply with the security policy of your organization. If you require a certificate from a trusted certificate authority, you can replace the default certificate.

Things to consider

  • If the host has Verify Certificates enabled, replacing the default certificate might cause vCenter Server to stop managing the host. If the new certificate is not verifiable by vCenter Server, you must reconnect the host using the vSphere Client.
  • ESXi supports only X.509 certificates to encrypt session information sent over SSL connections between server and client components.
  • For information about replacing default certificates on a vCenter Server system, see the vSphere Examples and Scenarios documentation.
  • All file transfers and other communications occur over a secure HTTPS session. The user used to authenticate the session must have the privilege Host.Config.AdvancedConfig on the host

Procedure

  • Log in to the ESXi Shell and acquire root privileges.
  • In the directory /etc/vmware/ssl, rename the existing certificates using the following commands.

mv rui.crt orig.rui.crt
mv rui.key orig.rui.key

  • Copy the new certificate and key to /etc/vmware/ssl.
  • Rename the new certificate and key to rui.crt and rui.key.
  • Restart the host after you install the new certificate.
  • Alternatively, you can put the host into maintenance mode, install the new certificate, and then use the Direct Console User Interface (DCUI) to restart the management agents.

See Pages

71-73 of the vSphere 5 Security Guide

32-36 VMware vSphere Examples and Scenarios

Generate ESXi host certificates

padlock

When to generate certificates

You typically generate new certificates only if you change the host name or accidentally delete the certificate. Under certain circumstances, you might be required to force the host to generate new certificates.

Procedure

  • Log in to the ESXi Shell and acquire root privileges.
  • In the directory /etc/vmware/ssl, back up any existing certificates by renaming them using the following commands.

mv rui.crt orig.rui.crt
mv rui.key orig.rui.key

ssl

  • NOTE If you are regenerating certificates because you have deleted them, this step is unnecessary.
  • Run the command /sbin/generate-certificates to generate new certificates.

sbin

  • Restart the host after you install the new certificate.
  • Alternatively, you can put the host into maintenance mode, install the new certificate, and then use the Direct Console User Interface (DCUI) to restart the management agents.
  • Confirm that the host successfully generated new certificates by using the following command and comparing the time stamps of the new certificate files with orig.rui.crt and orig.rui.key.
  • ls -la

Enable/Disable Certificate checking

padlock

Procedure

  • Log in to the vCenter Server system using the vSphere Client.
  • Select Administration > vCenter Server Settings.
  • Click SSL Settings in the left pane and verify that Check host certificates is selected.

Cert1

  • If there are hosts that require manual validation, compare the thumbprints listed for the hosts to the thumbprints in the host console.

To obtain the host thumbprint, use the Direct Console User Interface (DCUI)

  • Log in to the direct console and press F2 to access the System Customization menu.
  • Select View Support Information.
  • The host thumbprint appears in the column on the right.
  • If the thumbprint matches, select the Verify check box next to the host.
  • Hosts that are not selected will be disconnected after you click OK.
  • Click OK.

thumbprint

  • Note that certificate checking is required to use VMware Fault Tolerance