Warning: call_user_func_array() expects parameter 1 to be a valid callback, no array or string given in /home/kalofero/public_html/blog/wp-includes/class-wp-hook.php on line 286
vCO Workflow to automate the certificate generation process (SKKB1003) | Spas Kaloferov's Blog

vCO Workflow to automate the certificate generation process (SKKB1003)

Posted on by Spas Kaloferov

Introduction

In this post we will take a look into a workflow that can help the automation of certificate generation. Certificates that are generated from the vCO/vRO workflow are standard certificates that can be used with VMware Products or for any other purpose or software. Here are some of the files that can be produced by the workflows
– openssl.cfg   – OpenSSL config file
– rui.crt              – CRT Certificate
– rui.csr              – Certificate Signing Request.
– rui.key            – Private-key of a specific certificate (PEM formatted)
– rui.p12            – PKCS12 Package containing CRT and Private key.
– rui.p7b           – PKCS7 Package containing CRT
– rui.pem          – PEM Certificate with Private-key
– rui-orig.key   – Private-key of a specific certificate

Most of the certificate aspects and properties, like Subject alternative Names (SAN) are customizable during execution.
We will take a look into few of the many possibilities the workflows in this package provide:

  • Use Case 1: Create certificate request file – In the first use case we will use the workflows in the package to create certificate request (.CSR) file. This file can then be used by administrators to generate a certificate form the internal company certificate authority or send to external public certificate authorities who will generate the certificate instead.
  • Use Case 2: Convert existing certificate to PEM – In the second use case we will use the workflows in the package to convert an existing certificate into .PEM certificate. Let’s say that you have received a certificate you must use on your VMware Appliance. IN order to use this certificate you must convert it to .PEM format to be used by the appliance. It can be a .cer certificate or a PKCS12 (P12) or PKCS7 (P7B) certificate package containing the certificate.
  • Use Case 3: Using the “Generate Certificate: WF to automate the end-to-end process – In the third use case we will use a workflow to automate the end-to-end certificate generation process. From the creation of OpenSSL configuration file, creating a certificate request file, submitting this to a certificate authority, receiving the generated certificate, converting it to linux usable PEM format and finally exporting it to certificate package.

This com.SpasKaloferov.library.pki.package library of workflows can be downloaded here.

Lab Environment

The following environment has been used in all of the examples below:

  • Active Directory Domain called vmware.com
  • Windows Server 2012 R2 (with FQDN lan1dc1.vmware.com)
    • Domain Controller
    • DNS Server.
    • PowerShell v4 Host.
    • .NET 4 Framework installed (4.0.30319)
  • Windows Server 2008 R2 SP1 (with FQDN lan1dm1.vmware.com)
    • Domain Member
    • PowerShell v3 Host.
    • .NET 4 Framework installed (4.0.30319)
  • vCO 5.5.1.0 Virtual Appliance (with FQDN vco-a-01.vmware.com)
    • vCO PowerShell Plugin installed (version 1.0.4.1736639)

The full lab logical design can be seen HERE.

 

Getting to know the main workflow

Once you install the package you will find the workflows in vRO under [Workflsows > SpasKaloferov > Library > PKI]

The package contains many PKI related workflows , but the main one which automates the end-to-end certificate generation process is called “Generate Certificate”
Lets take a quick look at the workflow and the input parameters it requires.
On the General page you will find some general information about the workflow.

On the Prerequisites page you will find the prerequisites that this workflow needs in order to run successfully.
Workflow execution prerequisites:

     – Microsoft Visual C++ 2008 Redistributable Package is installed.
– Shining Light Productions installer for OpenSSL  is installed. (Default path: C:/OpenSSL/bin)
– Functional Microsoft Certificate authority.
– Certificate Authority template has been create and ready for use. (Default name: VMware
Certificate)

As can see most , if not all, of there prerequisites are commonly found on any environment so there might be little or no work needed form your side. 

The Workflow page provides some information on the files that will be created after the execution and the folder structure that is generated for each certificate.

On the Choose Action page you can select the action you want to perform. Currently supported actions are:

     – Start a new PEM certificate generation process by entering certificate information
– Convert existing CER (DER encoded binary) file to PEM file.
– Convert existing P7B (PKCS # 7 Package) file to PEM file?
– Convert existing P12 (PKCS # 12 Package) file to PEM file?

Expected in future:
– Convert existing CER (Base-64 encoded) file to PEM file.

Regardless of which option you select , few of the common input parameters you must provide are:

  • PSHost: A powershell host that can be used to execute commands.
  • FolderOut: A folder that will contain the generated files.
  • OpenSSLFolder: The path to the bin folder of a windows-based OpenSSL installation.

Will go into details about the rest of the options on the Dynamic and Static pages when we discuss Use Case 3.

If you are interested in how to configure a powershell host and add it to vCO check my post: Using CredSSP with the vCO PowerShell Plugin

 

Use Case 1: Create certificate request file

In this use case we will use the workflows in the package to create certificate request (.CSR) file. This file can then be used by administrators to generate a certificate form the internal company certificate authority or send to external public certificate authorities who will generate the certificate instead.
The WF we can use to accomplish this is called [Create Certificate Request in OpenSSL using PS] and is located in [Workflows > Library > PKI > OpenSSL]
Before you can use the workflow you must have existing, or create , a openssl.cfg config file containing the certificate information that can be used to generate the certificate request. For example:

When you start the WF , the required input parameters are:

  • PSHost: A powershell host that can be used to execute commands.
  • FolderOut: A folder that will contains the openssl.cfg configuration file. The file must be named openssl.cfg
  • OpenSSLFolder: The path to the bin folder of a windows-based OpenSSL installation.

Once the execution finishes you will see the certificate request (csr) file named rui.csr and the private key of the certificate in a file named rui-orig.key. If  you select Yes for the encrypt_key value , then the password specified in the encrypt_key_pass value will be used to encrypt the private key which is generated.

You can now use this certificate request file and supply it to you PKI administrators or a public certificate authority and request a certificate corresponding to this certificate request.

 

 

Use Case 2: Convert existing certificate to PEM

In this use case we will use the workflows in the package to convert an existing certificate into .PEM certificate. Let’s say that you have received a certificate you must use on your VMware Appliance. IN order to use this certificate you must convert it to .PEM format to be used by the appliance. It can be a .cer certificate or a PKCS12 (P12) or PKCS7 (P7B) certificate package containing the certificate.

Lets say for example that you have a PKCS certificate package (.p7b) that you want to convert to a certificate usable for you VMware appliance. For this purpose we must convert it into .PEM certificate.

 

To accomplish this we can use the [Convert P7B to PEM in OpenSSL using PS] WF located in [Workflows > SpasKaloferov > Library > PKI > OpenSSL].

The WF will ask you for the PSHost, FolderOut and the OpenSSLFolder input parameters. This were discussed in the previous use case and at the beginning of the article.

Once the WF finishes you will see the rui-p7b.pem file being generated.

Nota that the certificate also contains the certificate chain.
Another example will be if you have a DER encoded certificate (.cer) and want to convert it to .PEM one.

To accomplish this we can use the [Convert CER (DER) to PEM in OpenSSL using PS] WF located in [Workflows > SpasKaloferov > Library > PKI > OpenSSL].

The WF takes the already familiar to you parameters as input:

Once the WF finishes you will see the rui-der.pem file being generated.

 

 

Use Case 3: Using the “Generate Certificate” WF to automate the end-to-end process

In this use case we will use a workflow to automate the end-to-end certificate generation process. From the creation of OpenSSL configuration file, creating a certificate request file, submitting this to a certificate authority, receiving the generated certificate, converting it to linux usable PEM format and finally exporting it to certificate package.

To accomplish this we can use the [Generate Certificate] WF located in [Workflows > SpasKaloferov > Library > PKI].

As we already discussed the first few pages of the WF presentation in the “Getting to know the main workflow” section I will skip to the interesting part: Starting new certificate generation process.

Starting a new PEM certificate generation process is the default option on the Choose Action page, so we will just click Next.

The WF takes the already familiar to you parameters as inputs with a few new once CAName and CATemplate

The CAName is the name of the certificate authority to which we are going to submit the certificate request. You can find this by running [certutil –getconfig]. The value in this case is [LAN1DC1.vmware.com\RootCA]

C:\Users\Administrator>certutil -getconfig
Config String: "LAN1DC1.vmware.com\RootCA"
CertUtil: -getconfig command completed successfully.

The CATemplate  is the name (without trailing spaces) of the certificate template  from which you want to create a certificate. In this example I have a certificate template called “VMware Certificate” already created and published on my Certificate authority

Once you have found these values fill them in and click Next.

Note: For the automatic certificate generation to work you Windows certificate authority must be configured to automatically approve and issue certificate request.

On Dynamic page under the Certificate Attributes section you define values which are likely to change between subsequent WF runs. For example the subject name of the certificate. If you are creating certificates for multiple machines than this is likely to change each time.

The VmwareProduct value is a bit tricky. This input value is used for the sole purpose of creating a folder structure in which to place the generated files. For example if you have selected C:\MyCerts for the FolderOut value on the Settings page and vCO for the VMwareProduct value under the Dynamic attributes page, at the end the following folder structure will be created FolderOut\VMwareProduct or [C:\MyCerts\vCO] :

Further example if you select vSphere for VMwareProduct value on the next run a [C:\MyCerts\vSphere]  folder will be created.

Note: Regardless of the values you select for the VMwareProduct, the certificates generated are the same. The certificates are not tight to a VMware product. You can generate certificates for any product tor application regardless if it from Vmware or not.

For the purpose of this example I will select vCO for the VMwareProduct input because I want to select two vCO certificates for my appliances.

For the subjectAltName input value you must specify the subject alternative name (SAN) name for the certificate. This can be the DNS name, IP address or both. Lets say I have two vCO appliances for which I want to create certificates:

  • First one has a name vco-a-01.vmware.com and IP 192.168.100.1
  • Second one has a name vco-a-02.vmware.com and IP 192.168.100.2

The subjectAltName value for the first appliance will be :

DNS: vco-a-02.vmware.com, IP: 192.168.100.1

The organizationUnitName value is self-explanatory. This should be aligned with your company naming convention. For this example I will enter vCnter Orchestrator as a value.

The organizationUnitName value is again self-explanatory. This should be aligned with your company naming convention. Note that for Vmware product certificates the value should be the hostname. In this example I will enter vco-a-01.vmware.com as a value.

This value has one more purpose. This will also be used to create the final folder structure where the certificates will be placed. As you remember from above the folder where all files will be placed is a combination of FolderOut + VmwreProduct value. The organizationUnitName is actually the last value that forms the folder structure. In its final form the folder structure is based on FolderOut + VmwreProduct + organizationUnitName input values. Following the example above if we have define the following values:

FolderOut = C:\MyCerts
VmwreProduct = vCO
organizationUnitName = vco-a-01.vmware.com

Then all files will be created in C:\MyCerts\vCO\ vco-a-01.vmware.com folder. All these folder are created automatically during WF run.

Here once again the final values on the Dynamic page

Click next and let’s move to the Static page.

The inputs on the Static page are inputs that are likely not going to be changed between multiple certificate creations. For example the Country name or state or providence name information which will be added to the certificate. Another example is the default key size of the  private key witch will most likely change every few years depending how fast your company is growing and how fast the infrastructure and applications are changing and being able to support higher key lengths

The values which are predefined here are the recommended VMware values at the time this blog is written. For example the current Vmware recommendation for the default key length is 2048 bits. You can change these as you can see fit, but once you change them you will probably use the same values for the next few years, that’s why I’ve called them Static attributes.

We will take a look only at two input parameters here that are of any interest at this point and worth mentioning: encrypt_key and encrypt_key_pass

The encrypt_key value determines if the private key which is generated should be saved encrypted in the rui.key file which will be created.

If you select Yes for the encrypt_key value than you must also specify the encrypt_key_pass value which will be the password with which the key is encrypted.

Note: The password which you specify here will also be used for all certificate packages like the PKCS12 package. Otherwise the password for the certificated packages will be empty.

For this example I will not encrypt the private key and will just click Submit on the Static attributes page without making any changes. 

Once the workflow finishes when you open the vco-a-01.vmware.com folder you will see all the files being generated:

Note: As explain above , as I have selected No for the encrypt_key value and therefore haven’t specified any encrypt_key_pass, the rui.p12 certificate package has an empty password.

Now lets see how quickly we can create another certificate for the second vco appliance vco-a-02.vmware.com

Run again the last workflow execution.
Go straight to the Dynamic attributes page. 
Change the subjectAltName to [DNS: vco-a-02.vmware.com, IP: 192.168.100.2]
Change the commonName to [vco-a-02.vmware.com]
Click Submit.
And you have just created another certificate in 20 seconds.
You can find it In the vco-a-02.vmware.com folder.

Q: How cool is that?
A: Very very cool 😀

Lets say now that you have decided to join both vCO appliances in a cluster and need a certificate with multiple subject alternative names.

Run again the last workflow execution.
Go straight to the Dynamic attributes page. 
Change the subjectAltName to [DNS: vco-a-ha.vmware.com, DNS: vco-a-ha, DNS: vco-a-01, DNS: vco-a-02, DNS: vco-a-01.vmware.com , DNS: vco-a-02.vmware.com, IP: 192.168.100.100]
Change the commonName to [vco-a-ha.vmware.com]
Click Submit.
And you have just created another certificate in 20 seconds.
You can find it In the vco-a-ha.vmware.com folder and it has all the SAN names included.

 

DISCLAIMER; This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual.
All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
Photos
Unless stated, all photos are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. If used with watermark, no need to credit to the blog owner. For any edit to photos, including cropping, please contact me first.
Recipes
Unless stated, all recipes are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. Please credit all recipes to the blog owner and link back to the original blog post.
Downloadable Files
Any downloadable file, including but not limited to pdfs, docs, jpegs, pngs, is provided at the user’s own risk. The owner will not be liable for any losses, injuries, or damages resulting from a corrupted or damaged file.
Comments
Comments are welcome. However, the blog owner reserves the right to edit or delete any comments submitted to this blog without notice due to
– Comments deemed to be spam or questionable spam
– Comments including profanity
– Comments containing language or concepts that could be deemed offensive
– Comments containing hate speech, credible threats, or direct attacks on an individual or group
The blog owner is not responsible for the content in comments.
This policy is subject to change at anytime.

Leave a Reply

Your email address will not be published. Required fields are marked *