How to setup a Microsoft CA on windows server 2016 – pictorial representation

We are going to setup a Microsft CA in windows server 2016, this is an article which will give you step by step pictorial representation on how to setup the CA. Yes, the article is pretty long with pictures which will make your work simpler.

Setup a Microsoft CA Authority:

The below are the three steps to setup the Microsoft CA authority

a. Install Certificate Authority on Windows Server 2016

b. Configuring certificate Authority in Windows Server 2016

c. Setting up OSCP.

Perquisites:

  1. The server must be joined to the domain.
  2. License the Server

Steps to setup Microsoft CA authority:

a. Install Certificate Authority on Windows Server 2016

  1. Open Server Manager

2. Select Add Roles and Features and Click Next

3. Select the installation type as Role based or feature based installation:

4. Select the server from the server pool:

5. Select Active Directory certificate services – Select and click Next -> Add Features

6. We are creating a Certificate Authority, Certificate authority Web Enrollment, Online responder as part of Role services.

what is Online Responder?

It’s a role that runs on the server whenever a cert is used by a client it checks if the certificate is valid or not so we can monitor the validity of the certificates in the environment:

Now in AD-CS click -> Next

7. Select the role services Certificate Authority, Certificate authority Web Enrollment, Online responder.

Certificate Authority, Certificate authority Web Enrollment, Online responder

7. We are enabling the Web Server Role (IIS):

8. Select the below Roles as per the Wen Server Role:

9. Click -> Next. We successfully installed the Certificate Authority Role on the machine.

We successfully installed the Certificate Authority Role on the machine.

b. Configuring certificate Authority in Windows Server 2016

1. Now we must do Post configuration after the install, click on the Falg Icon at the right side top corner of the page and select Configure AD Certificate services.

2. Select the Super user Administrator account as credentials.

3. Go to Role Services -> Select Certification Authority -> Next

4. Now select Setup Type -> Enterprise CA to make sure that it can isseu certificates

5. Select CA type -> Root CA – this will be the first and may be the only Certificate Authority.

6. Select Private Key -> Create a New private key (We are selecting this option because we do not have a private key).

7. In the Cryptography options

Cryptographic Provider : RSA#Microsoft Software Key Storage Provider

Key Length: 2048

Hash Algorithm for signing certificates: 2048

8. Create the CA Name -> Next

9. Select the validity period for the root certificate as 10 years.

10. Select the location to save the certificate Database,

11. Confirm all the details and click -> Configure

12. Certificate Authoirty configuration is successful.

13. Let’s continue to configure Certificate authority Web Enrollment, Online responder.

14. Confirm the Roles and click -> Conifgure

15. Configuration of Certificate authority Web Enrollment and Online responder is successful.

c. Setting up OSCP:

  1. Click on Start ->mmc (Microsoft Management Console)

2. Click on File -> Add/Remove snap-in or Press Ctrl + M.

3. Select -> Certificate templates, Click on Add to the console

4. Now click on Certificates, Click on Add

5. Select Certificates Snap-in -> Computer account

6. if the certificate Authority is installed use another computer, In our case we have the certificate Authority in the server so we select Local computer,

7. Select Certiifcate Authority Click -> Add and Click OK

8. Select -> Certification Authority – Expand and select Certificate Templates Right click on Manage

9. Select OSCP Response Signing -> properties

10. Select the security Tab -> click on ADD

11. Click on Object types and select Computers

12. Select the server AD machine and click on check name and then click -> OK

13. Select AD server and provide Full control

14. Select the gsslabs-CA, right click and select properties

15. Select -> Extensions tab

16. Select AIA (Authority Information Access):

17. Click on ADD -> Enter the location as https://ad.gsslabs.org/ocsp -> click OK

18. Click OK -> Click on yes to restart the services.

Now your Certificate Authority is completely configured. This CA can be used to provide certifcates to the machines and the website.

vSphere SSL Certificates

What is a certificate?

A Certificate or digital certificate is a unique, digitally Signed document that authoritatively identifies the identity of an individual or organization. Using public-key cryptography, its authenticity can be verified to ensure that the software or website you are using is legitimate. On the Internet, a certificate is signed by a trusted CA (certificate authority), and verified with the authority’s public key. The decrypted certificate contains a verified public key of the certificate holder (website operator), with which encrypted HTTPS communications can be established.

An operating system or web browser may alert the user when loading software or a website whose digital certificate is not verified by a trusted CA.

A certificate, contains information about the owner of the certificate, like e-mail address, owner’s name, certificate usage, duration of validity, resource location or Distinguished Name (DN) which includes the Common Name (CN) (web site address or e-mail address depending of the usage) and the certificate ID of the person who certifies (signs) this information.

It contains also the public key and finally a hash to ensure that the certificate has not been tampered with. As you made the choice to trust the person who signs this certificate, therefore you also trust this certificate. This is a certificate trust tree or certificate path.
Usually your browser or application has already loaded the root certificate of well known Certification Authorities (CA) or root CA Certificates.

The CA maintains a list of all signed certificates as well as a list of revoked certificates.

A certificate is insecure until it is signed, as only a signed certificate cannot be modified.

You can sign a certificate using itself, it is called a self signed certificate.

All root CA certificates are self signed.

We have seen what is a certificate, Now let’s see how are certificates used in the vSphere Environment.

vSphere Certificate:

The below is error that we get when we try to login to the vCenter server using the browser, because the certificate is not trusted by the computer in your organization by default.

In day to day scenario’s most of us see the below web browser certificate warnings when accessing the vSphere Web Client? Those are caused by an untrusted (and perhaps self-signed) Machine SSL certificate.

We will be able to bypass warning by different methods, let see how it works and what are the different ways to use the certificates in the vSphere environment.

vSphere Certificate Management:

Certificates ensure that communication between services, solutions, and users are secure and that systems are who we think they are. By default, VMCA acts as a root certificate authority. Certificates are issued that chain to VMCA where the root certificate of VMCA is self-signed as it is the end of the chain.

The certificate Lifecycle can be defined in two ways,

VMware vSphere 6.x Solution for Complete Certificate Lifecycle Management

VMware Certificate Authority (VMCA):

Located on: Embedded Deployment and Platform Services Controller (vCSA with external PSC).

VMware Endpoint Certificate Store (VECS):

Located on: Embedded Deployment, and vCenter Management Node (vCSA with external PSC).

VMware Certificate Authority (VMCA):

  • Dual Operational modes:
    • Root CA
    • Issuer CA
  • Root CA:

Automated one which is created during the installation, this has the capability of issuing other certs, all solutions and endpoint certificates are created and trusted to this root cert

  • Issuer CA:
  1. Can replace all default root CA certificate created during installation.
  2. This requires a CSR from VMCA to be used by an enterprise or 3rd party CA to generate a new issuing certificate.
  3. This will replace all the default certificates issued during the installation.
  4. Managed using the certificate manager utility
    • /usr/lib/vmware-vmca/bin/certificate-manager
  5. VMCA then issues certificates to any vCenter Servers and associated ESXi hosts that are registered to it.
  6. The real value of the VMCA is in the automation of replacing and renewing certificates without having to manually generate CSRs, mint certificates, then manually install those certificates.

VMware Endpoint Certificate Store (VECS):

  • Repository for certificates and private keys
  • Key stores:
    • Machine SSL certs
    • Trusted roots
    • CRLs
    • Solution users (certificates issued by the VMCA are for internal service-to-service communication within vCenter Server)
    • others (e.g. VVOLS, VASA etc.).
  • We can manage VECS using the vecs-cli
  • Does not manage SSO certificates

Types of Certificates in VMware vSphere 6.x:

  • ESXi Certificates
  • Machine SSL Certificate
  • Solution User Certificates
  • Single Sign-On Certificates

ESXi Certificates:

Machine SSL certificates:

Solution User Certificates:

  • Solution User Certificate Certificate stores are located in VECS on each management node (PSC) and embedded deployment.
  • machine – Used by component manager, license server, and the logging service.
  • vpxd – vCenter service daemon (vpxd) store on management nodes and embedded deployments. vpxd uses the solution user certificate to authenticate to vCenter Single Sign-On.
  • vpxd-extensions – Includes the Auto Deploy service, inventory service, and other services that are not part of other solution users.
  • vsphere-webclient – Includes the vSphere Web Client and some additional services such as the performance chart service.

Single Sign-On Certificates:

  • Not stored in VECS.
  • Not managed with certificate management tools.
  • Security Token Service (STS) – an identity provider that issues, validates, and renews SAML tokens that are used for authentication throughout vSphere
  • By default, the STS signing certificate is generated by VMCA
  • Manually refresh STS certificate via vSphere Web Client when the certificate expires.

We will see in detail about the different types of certificates and how to implement them. Please follow my page for regular updates on virtualization.