Some of the documentation around creating certificates for vCenter or SRM seems to be lacking, so I documented a few steps for each and outlined the differences, also created a video :)
This can be done from any machine, as long as openssl is installed. If you’re creating/requesting multiple certs, create folders for each request and work from within there so you don’t mix them up. I use d:\cert\vcenter and d:\cert\srm. I added “D:\OpenSSL-Win32\bin\” to may path variable so it’ll work in any folder I’m in.
Make sure you’ve installed OpenSSL, which can be downloaded here. Next, open a command prompt (not a PowerShell window). I have a tendency to do the latter, since I do everything in PowerShell, but PS sometimes does not like what we’re typing.
If you have an internal PKI root CA, like RSA or Microsoft CA, you can proceed like normal, otherwise, you’ll need to create a root CA via OpenSSL, which I’ cover in another post HERE.
First thing is to generate the Certificate Signing Request, aka csr. To do this, we’ll need to create our config file. It can be named anything, I chose openssl.cnf, and it should be in your working folder (SRM, vCenter, etc) to keep track of what config file was used to generate which key & csr. There are a few differences in the openssl.cnf, depending on if it’s for SRM or vCenter.
This one’s for vCenter:
[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
#Don't encrypt the key
encrypt_key = no
prompt = no
string_mask = nombstr
[ req_distinguished_name ]
countryName = US
stateOrProvinceName = State
localityName = City
0.organizationName = Company Name
organizationalUnitName = IS
emailAddress = email@address
commonName = fqdn.of.vc.server
This one’s for SRM:
[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
#Don't encrypt the key
encrypt_key = no
prompt = no
string_mask = nombstr
[ req_distinguished_name ]
countryName = US
stateOrProvinceName = State
localityName = City
0.organizationName = Company Name
organizationalUnitName = IS
emailAddress = email@address
commonName = SRM
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS: fqdn.of.srm.server
The main differences in the SRM config file are extendedKeyUsage = serverAuth, clientAuth
and commonName = SRM
Since you will have two SRM servers, the commonName (or CN) will need to be “SRM”, then the subjectAltName (or SAN) will need to be the actual FQDN of each server. You will need two certs. I aliased my vCenter to vcprod, so my vCenter csr also has the SAN of vcprod, while CN is the actual fqdn of the vCenter server itself. Fwiw, if you use RSA, the SAN can be added when the cert is signed, thus not needed in the config file. Notice rui.key? It will generate the .key file needed for vCenter. This is not needed for SRM, but nice to have.
Now, let’s run the first command to create the .key & .csr files:openssl req -newkey rsa:2048 -nodes -out rui.csr -config openssl.cnf
From here, you can do one of two things: 1) submit the CSR to your internal PKI; or 2) sign the cert yourself via OpenSSL.
The preferred method is to use an internal PKI, like RSA or Microsoft. When you submit your request, you can either upload the .csr file, or copy the contents of it and paste it in the web form, then make a PKCS#10 request. Once the request is approved, you’ll receive notification to the email in the config file. You’ll need to create rui.crt and copy everything in the approved/signed cert request (—–BEGIN CERTIFICATE—– and —–END CERTIFICATE—– and everything in between!). Save that to the current working directory.
Now we have two different commands, depending on use: SRM or vCenter. SRM requires a .p12 file, while vCenter requires a .pfx file. They’re essentially the same, you just use either rui.pfx or rui.p12 in the -out switch of the command:openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.p12
This is where you either do rui.pfx or rui.p12. vCenter requires the pfx file. Yes, I’m redundant here, but I best most viewers of this post will only see the code blocks and do a c&p without actually reading the content. I’ve been guilty of that on occasion, I bet most probably are.
Next, rename rui.crt to rui.crt.old, then we need to convert it with openssl:openssl x509 -text -in rui.crt.old > rui.crt
With that, we should have three files for vCenter (rui.key, rui.crt, and rui.pfx), or our single rui.p12 for SRM.
And now the video:
Hi
I have tried your process using the same openssl version that is recommended by VMware when changing the certs for vCenter. When I look at the p12 file after I have imported it there is no subject alternative name listed. I have an internal Microsoft CA. What could I possibly be doing wrong.
Thanks
I’ve never used the Microsoft CA to test this, but I know in RSA, the signer (admin who does the signing) could add the SANs to the cert, too. Is OpenSSL used only to generate the CSR? You might see if Microsoft requires a different format in the CSR. The syntax in my config file was for OpenSSL’s CA, which may differ from Microsoft’s.
@Seamus OBrien
during signing that certificate, you have to add subject alternative (additional atributes).
Luke,
I prepared certificates, paired sites SRM “accepted” certificates :). Is it normal that I have to type login and username for remote site after going to SRM (Home –> Solutions.. –> SRM)
Yes, it’s authenticating you against the target/recovery site SRM server/vCenter server. You’re already logged into the source/protected, but haven’t actually authenticated to the other one in the pair.
I just found out that Windows CA’s ignored the SAN attributes in the request (strangely enough specified in the CN attribute). In order to fix this problem, I created an alternate openssl.cnf file to generate the request:
[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
#Don’t encrypt the key
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = x509v3_extensions
[ req_distinguished_name ]
countryName =
stateOrProvinceName =
localityName =
0.organizationName =
organizationalUnitName =
emailAddress =
commonName =
[ x509v3_extensions ]
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = clientAuth,serverAuth
subjectAltName = @altname_sec
[ altname_sec ]
DNS.1 =
DNS.2 =
IP =
Thanks for the head’s up, Erwin! I’ll try to get this added.