vCenter Server (VCSA) 6.5 – Add root CA cert to Windows Server 2016 AD to enable the default VCSA cert to be trusted

Posted by & filed under Active Directory, Server Admin, Virtualization, VMWare.

The VCSA has it’s own CA built in. It uses that CA to generate certs for all the various services. There are two options available to ensure that the certificate is trusted in the browser:

  1. Generate a CSR for the cert and submit to a CA who can generate the cert.
  2. Use Microsoft Active Directory GPO to push out the VCSA’s root CA cert, thereby allowing the workstations to trust the cert already installed.

I went with the second one because the VCSA is using vcenter.mydomain.lan and is only accessible from inside my network which also means only machines on the domain will be connecting to the web interface. This was very simple to make happen…

On the DC:

To distribute certificates to client computers by using Group Policy

  1. On a domain controller in the forest of the account partner organization, start the Group Policy Management snap-in.
  2. Find an existing Group Policy Object (GPO) or create a new GPO to contain the certificate settings. Ensure that the GPO is associated with the domain, site, or organizational unit (OU) where the appropriate user and computer accounts reside.
  3. Right-click the GPO, and then click Edit.
  4. In the console tree, open Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies, right-click Trusted Root Certification Authorities, and then click Import.
  5. On the Welcome to the Certificate Import Wizard page, click Next.
  6. On the File to Import page, type the path to the appropriate certificate files (for example, \\fs1\c$\fs1.cer), and then click Next.
  7. On the Certificate Store page, click Place all certificates in the following store, and then click Next.
  8. On the Completing the Certificate Import Wizard page, verify that the information you provided is accurate, and then click Finish.
  9. Repeat steps 2 through 6 to add additional certificates for each of the federation servers in the farm.

Once the policy is setup, you will need to either wait for machine reboots, or for the GP tp update. As an alternative, you can also run gpupdate /force to cause the update to occur immediately. Once complete, you can verify the cert was installed by running certmgr.msc and inspecting the Trusted Root Certification Authorities tree for the cert. It was my experience that the machine still required a reboot due to the browser still not recognizing the new root CA and therefore still displaying the ugly SSL browser error. After a reboot it was good to go.

Reference: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/distribute-certificates-to-client-computers-by-using-group-policy

Apache key and cert generation

Posted by & filed under Server Admin.

Here’s a nice one liner to generate a private key and csr:

Generates the key and the csr in one shot.

Generating KEY/CSR/CRT with OpenSSL on Windows

Posted by & filed under Uncategorized.

I had to generate a CRT for a server that runs Windows but has Apache and OpenSSL installed. I figured I'd do a quick key/csr/crt refresher.

First go to the /bin directory in the OpenSSL install and run openssl.exe

First, generate a keyfile. Thawte is pushing the use of 2048 bit sized keyfiles, so substitute if needed.

genrsa -des3 -out keyfile.key 1024

Next -- verify the keyfile:

rsa -noout -text -in keyfile.key

Create a unsecured version of the keyfile so Apache doesnt ask for a password every time it loads. Apache.conf

rsa -in keyfile.key -out unsecured.keyfile.key

Create the actual CSR:

req -new -key keyfile.key -out certificate.csr

If you get this error:

OpenSSL req -new -key digitss.key -out digitss.csr

Unable to load config info from /usr/local/ssl/openssl.cnf

Run this to specify the config file instead:

OpenSSL req -new -key keyfile.key -out certificate.csr -config openssl.cnf

Now just point Apache at the keyfile, and install the cert when it arrives.