TheSaffaGeek

My ramblings about all things technical

Requesting Certificates for vRealize Automation Components

Leave a comment

 

For the project I am currently working on we are doing a distributed installation of vRealize Automation with load balancers and therefore internally signed as a minimum is required. the trust requirements of these are shown below from the diagram in the vcloud-automation-center-61-installation-and-configuration document.

 

image

 

Now the point of this posting is that I personally found it fairly confusing what is required in the cfg files and why it is required as my customer challenged all of the portions of the cfg files we were supplying them to ascertain if they were in fact a hard requirement and what the impacts would be to their security if they signed our certificate requests. Also due to them using UniCERT-PKI-software ,the creation of the template to sign the requests was not as simple as it would be via a Microsoft CA.

Requesting the certificates

For the certificate requests Eiad Al-Aqqad has done two really great postings (part 1 and part 2 ) around the formats required and using openssl to create the certificate requests. For me the certificate requests via openssl wasn’t an option due to the PKI being used so I needed to supply the requests in cfg format as per the example below (sanitised of course) with the portions I needed to change in blue.

 

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment, nonRepudiation
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:vRAApp1, DNS: vRAApp1.TheSaffaGeek.co.uk, IP:192.168.1.1, DNS:vRAApp2, DNS: vRAApp2.TheSaffaGeek.co.uk, IP:192.168.1.2, DNS: DNS:TheSaffaGeekvRA, IP:192.168.2.1, DNS:TheSaffaGeekvRA.TheSaffaGeek.co.uk

[ req_distinguished_name ]
countryName = UK
stateOrProvinceName = South England
localityName = London

0.organizationName = TheSaffaGeek
organizationalUnitName = TheSaffaGeekLab

commonName = TheSaffaGeekvRA

 

For the SubjectAltName section I was challenged around the requirement I had submitted with the IP:192.168.1.1 included ,which is actually just a VMware recommendation so this could be dropped from my request. Another section that had conflicting information was for the organizationalUnitName where it was stated that this needed to be unique for each vRA component. This is only applicable if all the vRA components (this also applies to vSphere components btw) are installed on the same server as stated in this vCenter certificates kb and quoted below:

 

Each SSL Certificate needs a unique Distinguished Name (DN). The examples in this article use the OrganizationalUnitName (OU) field to achieve this uniqueness, based on a configuration where all components are installed on the same server. If the services are all on separate servers, they have a unique DN by default.

 

Due to us deploying a distributed installation this was not applicable and so the customers standard could be applied for this section.

 

Hopefully this is beneficial to people coming across the UniCERT-PKI-software and having to motivate why certain entries are required and others are just nice to have. If it isn’t then it’s just here for my future reference 😀

 

Gregg

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s