Replace VMware Virtual Center SSL Certificate with Microsoft CA

[dmaster]

Hello All,

I'm trying to replace the default SSL certificates from Virtual Center 2.01 with certificates from my own Microsoft Enterprise root CA..

I followed this howto..

http://edward.aractingi.net/blog/archives/virtualization/[/b]

in this article i'am missing how i get my rui.crt[/b] certificate ?

i am only able to get the rui.pem[/b] , rui.pfx[/b] and rui.key[/b] files

And this howto..

http://www.vmware.com/pdf/vi_vcserver_certificates.pdf[/b]

(I get the feeling that this document is not meant for a Microsoft CA just a local root CA)

in this article i get stuck on page 8 with the line..

openssl ca -out ruit.crt -config openssl.cnf -infiles mycsr.csr

error message[/b]

c:\Program files\openssl\openssl ca -out Webaccess.crt -config openssl.cfg -infiles Webaccess.csr

Using configuration from openssl.cfg

Loading 'screen' into random state - done

unable to load CA certificate

3360:error:0906D06C:PEM routines:PEM_read_bio:

no start line:.\crypto\pem\pem_lib.c:663:Expecting: CERTIFICATE

Was anybody able to replace this certificates ? Who can help me out ?

[masaki]

the certificates are on the ESX HOST under /etc/vmware/ssl

[RobMokkink]

I install the openssl tools on the VC server and then do a request to the MS CA website.

When the certificate is in, i use a couple of openssl commands to export it to openssl format, so that VC can use it.

Currently i can't access the documents, when i am home i will post them here.

[dmaster]

Do i also have to replace the certificates from my esx3 host to get VC2 and Webaccess working with my Microsoft Enterprise root CA ?

according page 4 of the VMware white paper i have to replace rui.key , rui.crt and rui.pfx

i cannot figer out how i get my new rui.crt certificate, probably with openssl but i don't know the exact syntax.. as you can see in the error message..

[Tr0llk1ng]

rui.crt as far as i know is just the Root Certificate to trust. you can check if you open the file on a windows client - it shows the root certificate. (you can also open the PFX with "testpassword" as password.. found this in the pdf above..)

basically i've the same problem afterwards, i've tried to replace the rui files but restart of the Virtual Center Server leads to an unexpected terminate of the service without information why.. Change back to original RUI and everything works fine.

also tested to change PFX password to testpassword or without password, now change..

anybody able to change the ssl certificate of just the web access?

[RobMokkink]

do this:

install openssl tools on VC server.

generate a new key:

openssl genrsa 1024 > rui.key

Create a signing request:

openssl req -new -key rui.key > rui.csr

Open the rui.csr with a text editor and select all the text.

Issue the certificate on the MS CA and download the cert file to rui.crt

Then convert the rui.crt to rui.pfx with the following command:

openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout

pass:testpassword -out rui.pfx

[dmaster]

Hello All,

i managed to replace my virtualcenter 2.01 certificates, so i can use virtualcenter webaccess without getting a warning of untrusted certificates..

+++++++++++++++++

But[/b] what about the certificates : rui.key and rui.crt wich are located on the ESX Server Host (/etc/vmware/ssl/[/b] ) ? Do i have to replace them also ? Do i have to create new certificates for the ESX server host ?

What is the advantage of that ? Is this necessary when you replaced the virtualcenter host certificates ?

+++++++++++++++++

i created a small howto for replacing the VC2 host certificates..

Thanks Rob for your hint about creating the rui.crt certificate..

*********************************************************

Howto - Create new certificates with Openssl and Microsoft Certificate Services Web Enrollment for VirtualCenter 2.01

rui.key

=======

openssl genrsa 1024 > rui.key

rui.csr

=======

openssl req -new -key rui.key > rui.csr -config openssl.cfg

when asked for common name, fill in the hostname or the FQDN of the VirtualCenter server

rui.crt

=======

Goto --> Microsoft Certificate Services Web Enrollment

press --> Request a certificate

then press --> Or, submit an advanced certificate request.

then press --> Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a

base-64-encoded PKCS #7 file.

then paste the contents of rui.csr into the field "Saved Request:"

choose with "Certificate Template:" for "Web Server"

press submit

select "Base 64 encoded"

then download the certificate and rename it to rui.crt

rui.pfx

=======

openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -out rui.pfx

Enter Export Password:

Replacing the Certificates on VirtualCenter 2 Host

==================================================

copy the files : rui.key , rui.crt and rui.pfx to C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\

Restart your VirtualCenter server service. This will also restart your Webaccess service..

Message was edited by:

dmaster

[smpeck]

Thanks for the information. I followed these directions and I am now able to use the VI client witout cert warnings using a certificate fom my local domain's CA. However, I run into problems accessing the web interface. Using IE, I get the following message box:

"Choose a digital certificate. The website you want to view requests identification. Please choose a certificate." There are no certificates listed in the menu. Any ideas?

[mikkel-robin]

Hi smpeck.

Did you solve the "The website you want to view requests identification" problem?

[scerazy]

Why on earth the certificate issue is so messy even in 2.5 U3?

When using wildcard certificate that comes with certificate Authority certificate chain both VI client complains (in really odd way, I connect to vcenter.domain.org & it complains that certificate for 10.0.0.54 - why to resolve? - is issued to *domain.com) & also webaccess insists on some certificate that does not show in the box

Seb

[Markisha1979]

Hi all.

I've got some problems following the procedure posted before.

When i paste my cert request i HAVE NO possibility to select "web server" certificate type...

Where should i find it???

[RobMokkink]

just retested the procedure.

Make sure when you download the certitificate you select base64

When you didn't specified a password on the request you can just issue the following command to create a .pfx

openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -out rui.pfx

[RobMokkink]

hey dmaster you where a little bit faster then me :smileywink:

[RobMokkink]

i also replaced the certificates on the esx hosts.

Unfortunaly i doesn't like the new certs.

Can't get the servers in VC anymore.

strange that is didn't test this sooner?

[dmaster]

What about the ESX Host certificates : rui.key and rui.crt wich are located /etc/vmware/ssl/ ?

Do i have to replace them also ? The are probably not the same like the VirtualCenter Host certificates.

Do i have to create new certificates for the ESX server host on the same way i did on the VC2 host, again with a webserver template ?

What is the advantage of that ?

Is this necessary when you replaced the virtualcenter host certificates ?

[RobMokkink]

If you want to connect through the webinterface from a client etc.

[dmaster]

okay.. it's clear for me now.. thanks for the help..

[Dennis2]

do this:

install openssl tools on VC server.

generate a new key:

openssl genrsa 1024 > rui.key

Create a signing request:

openssl req -new -key rui.key > rui.csr

Open the rui.csr with a text editor and select all the text.

Issue the certificate on the MS CA and download the cert file to rui.crt

Then convert the rui.crt to rui.pfx with the following command:

openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout

pass:testpassword -out rui.pfx

My vpxdeamon on VC2.5 keeps freaking out when replacing the certificates with error

2008-01-14 18:33:04.790 'App' 3920 error crypto failure: error:0407106B:rsa routines:RSA_padding_check_PKCS1_type_2:block type is not 02

2008-01-14 18:33:04.790 'App' 3920 error Failed to decrypt password: applying key to encrypted data failed (likely the wrong key)

I'm using Win32 OpenSSL Light 0.9.8g to generate the keys.

I haven´t used password anywwhere but in the conversion to pfx-file so i suspect there is a bug in the Win32-version.

Can anyone here confirm that this is an issue?

[Dennis2]

I get the same error when generating the certificate with Open SSL 0.9.7a from an ESX 3.0.1 b42829 console.

[Ales]

You try use KB article 'VirtualCenter Server Fails to Start After You Replace Default SSL Certificates with Custom SSL Certificates' ID 1003070

[Dennis2]

What does vpxd -p do?

It requires me to enter a password for some database. Should that be fore the same account and database used when installing VC?

[Dave_Mishchenko]

The command will re-encrypt the database login with the new SSL cert. The encrypted password is then stored in the registry. It'll be the same password that you already use for SQL login to the VC database. Without this change you won't be able to start VC with a new cert.

[Dennis2]

Thanks Alex and Dave.

VC works like a charm now :smileyhappy:

[Box293]

I followed all the steps and it all works OK, no warnings when I log into VC.

However when I try and bring up the console of a virtual guest all I get is a black screen.

If I revert back to the original certificates and do the vpxd -p thing the consoles works OK again.

I only did the certificate change on the VC server. Do I need to do it to all the ESX servers as well?

[Dave_Mishchenko]

You have to disconnect and reconnect your hosts (see the bottom of this article - http://kb.vmware.com/kb/1003070).

[Box293]

Ahhh the good old read the manual thingy.

I'll have to do that this weekend we are performing some maintenance.

Thanks very much.

[todd_shawcross]

Hello,

Has anyone tried replacing the certificates for VC 2.5? I can generate all the files using these steps (however they are different size's to VMWare ones), but the VC service will not start. I'm at a bit of a loss at the moment VMWare support will not help when a Microsoft CA is involved.

I'm using:

Win32OpenSSL-0_9_8g (installed on VC server)

VirtualCenter 2.5

Thanks,

Todd

[Dave_Mishchenko]

Did you run the vpxd -p command after replacing the certificate?

[todd_shawcross]

Yeah, tried that. I just generated the certificates with the lite verion of open ssl and it is working now....

[Dennis2]

Exactly this has already been asked 10 entires above yours and answered to in the following entries.

[todd_shawcross]

Thanks for you input Dennis.

[dmaster]

problem solved, answer is posted in this topic

[RobMokkink]

Today iw as rebuilding my test lab and i made a huge error in my post:

openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -out rui.pfx

Do this:

openssl pkcs12 -export -in rui.crt -inkey rui.key -name -out rui.pfx

This also fixed a lot of other issues.

[dmaster]

Hi Rob,

Did you also have the problem that you canno't use the custimization specifications ? because it's complaining about problems with unecrypting the password.. after you changed the SSL certificates of VC2 ?

[RobMokkink]

sorry no time to test guest customization.

What still is buggy is the vpxa daemon crashes on the esx hosts.

So i left the esx hosts without a certificate.

[Jwoods]

Today iw as rebuilding my test lab and i made a huge error in my post:

openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -out rui.pfx

Do this:

openssl pkcs12 -export -in rui.crt -inkey rui.key -name <your fqdn of the virtualcenter server> -out rui.pfx

This also fixed a lot of other issues.

Rob/Dmaster, does the "security warning" still appear for you after replacing the ssl cert on VC? Whenever I generate a cert for either hostname or FQDN I still receive the security warning.

Cert generated using hostname "VCSERVER1" --> The certificate received from "vcserver1.foo.foo.com" was issue for "VCSERVER1". Secure communication with "vcserver1.foo.foo.com" cannot be guaranteed.

Cert generated using FQDN "vcserver1.foo.foo.com" --> The certificate received from "VCSERVER1" was issue for "vcserver1.foo.foo.com". Secure communication with "vcserver1.foo.foo.com" cannot be guaranteed.

I didn't expect to receive any warning after replacing the cert. Just thought it would go straight through after login. I know I can simply check "Do not display..." or just ignore, but wanted to verify whether or not this behavior is expected.

[Dennis2]

If your computer doesn't trust the issuer of the certifiacte you have to install the root certificate of the issuer on all your computers that will be running the VC client.

[Jwoods]

If your computer doesn't trust the issuer of the certifiacte you have to install the root certificate of the issuer on all your computers that will be running the VC client.

And that's the weird part. The cert was issued by my Enterprise CA. The VC server is in the domain and has the root cert in the cert store.

[Dennis2]

Have you verifed that the root certificate actually is loaded on your client computer where you start the VC cleint application?

[Jwoods]

Have you verifed that the root certificate actually is loaded on your client computer where you start the VC cleint application?

Yep, it's there. What I'm getting from your questioning is that the additional screen that I'm seeing upon login should not exist after the cert has been replaced?

[Jwoods]

Problem solved. Cert had the FQDN, but it seems VIC requires FQDN to compare against cert! I was originally using shortname. Thanks for the help Dennis!

[Dennis2]

Yep. That's how certifictes work. If you deviate from the subject name in any way the check will fail.

[astrolab]

I tried to put together a step-by-step process on regenerating the VirtualCenter certificate. It applies to an environment with a Microsoft CA, but it can be adapted to any root CA. Please let me know of any errors.

1. *Install openSSL Light on the VC Server. ** Moderator note: Win32 OpenSSL Light can be downloaded from the kind folks at **

2. Generate an RSA private key and a certificate-signing request

BACK UP THE EXISTING RUI.CRT, RUI.KEY and RUI.PFX TO A SECURE LOCATION.

They are located in c:\docs and settings\all users\app data\vmware\ VMware VirtualCenter\SSL

From the VC Server, navigate at the command prompt to the openSSL\bin directory

Issue the following commands:

openssl genrsa 1024 > rui.key

openssl req -new -key rui.key > rui.csr

Fill in the appropriate information. ** Moderator note: Your Name/Common Name is the FQDN of your VC Server ie. servername.domain.com **

3. Request a Certificate

Go to your CA webpage.

Click on Request a Certificate

Open the file that you saved above with notepad and copy all of the the contents including the "---BEGIN CERTIFICATE REQUEST-" and "-END CERTIFICATE REQUEST---" lines

Be sure that the Certificate Template is set to Web Server. There is no need to enter anything into the Additional Attributes field.

Click on Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.

Paste the notepad contents of the certificate request file from above into the Saved Request field and click on the Submit button.

Select Base 64 Encoded and click Download Certificate and save the certificate to C:\...\openSSL\bin ** Moderator note: Save file name as rui.crt **

During this process, you may receive an email with certificate information in it. You may safely delete the email.

4. Create a .pfx (personal individual exchange) file for rui.crt

At the Command Prompt on the VC server navigate to C:\...\openSSL\bin and issue:

openssl pkcs12 -export -in rui.crt -inkey rui.key -name VirtualCenterServerFQDN -out rui.pfx

5. Move rui.crt, rui.key, and rui.pfx to

c:\docs and settings\all users\app data\vmware\ VMware VirtualCenter\SSL

6. Disconnect all ESX hosts managed by VirtualCenter ** Moderator note: (original step: Power off all VMs on the hosts in the VC. This needs to be done because after the VC loads the new certs it will not be possible to gracefully shutdown the VMs from the VC Client, though it can still be done through RDP or Service Console.)

7. ** Moderator note: Added step 7: Stop the VMware VirtualCenter Server service **

7.5

• From CMD, navigate to the C:\Program files\VMware\Infrastructure\VirtualCenter Server\* directory, and issue the following command:

Vpxd -p (it re-encrypts the DB password). When prompted. type the pw used for the VC database.

8. Start the VMware VirtualCenter Server service ** Moderator note: Starting the VC Service should be sufficient. (oringal step: Restart the VC server.) 9. ** Moderator note: This step not necessary ** (original step: Restart all ESX hosts.)

10. Reconnect all ESX hosts, ** Moderator note: VMs should already be powered on ** (original step: and power on the VMs.)

11. IMPORTANT: connect to the VC Infrastructure by using the Virtual Center FQDN.

Now, the question for the forum is: if I regenerate the certificate on every single ESX host, using the same Microsoft CA, the host is not happy, gets disconnected and when trying to reconnect I receive the error: bad username or password. Has anybody implemented a comprehensive certificate strategy where both VC and the single hosts use certificates issued by the same CA?

Message was edited by: jasonboche

Added/changed some steps as noted.

[Dennis2]

You forgot to say that you should enter the FQDN of the VC at Enter your name when generating the request.

[celak]

Hello,

Is there any way to completely disable the SSL feature of VI3?

I don't want to use SSL and don't want to see validation error messages of SSL certs.

Thanx.

[Jwoods]

Yes this is the last BUT very important part. If not done, you'll be spinning your wheels trying to fix what's not broken.

[madcult]

When I try to connect to a VirtualCenter server there always appears this message that the certificate is not trusted. Every time I have to click ignore. Even if I install this certificate the information appears next time again.

Message:

>>The certificate received from "server1.domain.com" was issued for "VMware". Secure communication with "server1.domain.com" cannot be guaranteed. Ensure that the fully-qualified daomain name on the certificate matches the address of the server you are trying to connect to. <<

I think our problem is that the certificate "was issued for 'VMware'" and not for the FQDN "server1.domain.com"! We have no root CA or maybe I misunderstood what it is for but atm we do not work with certificates except with those usually made by any linux machine when we connect to it per ssh. How can I solve this? We don't want to let our admins to see this message. It makes other admins think that something went wrong and that's what we want to avoid. :smileywink:

[rbeu]

Has anyone tried replacing the certs without shutting down the vm's and instead vmotion'ing them off one host at a time and then restarting that host? I have a feeling vmotion will fail between the hosts without them being restarted first but I'm curious if anyone has tried this.

[Jwoods]

Has anyone tried replacing the certs without shutting down the vm's and instead vmotion'ing them off one host at a time and then restarting that host? I have a feeling vmotion will fail between the hosts without them being restarted first but I'm curious if anyone has tried this.

There's no need to restart the host. This is how I replaced my certs. Left the VMs as is, created and replaced the cert on VC. Disconnected, removed and re-added the each of the hosts. No problems sited.

[astrolab]

You're right. I re-ran the test without shutting down the hosts or the VMs, just

1- disconnected the hosts.

2- Removed them.

3- Stopped VC service.

4- Installed new certs on the VC server.

5- Ran vpxd -p

6-restarted service

7-Re-added the hosts.

So why does VMWare recommend a restart of both the VC server and the hosts?

[rbeu]

Thanks for the tip, JWoods. Tried it today and it worked for me as well except I didn't remove the hosts from VC, I just disconnected and reconnected them.

[meistermn]

There is a KB Articel for re-authentication.

[jasonboche]

I've made some updates to Astrolab's procedures based on the experience of others and based on my own experience as noted by the ** Moderator note: ** . Modifications of these steps saves significant time and avoids outage of VMs and ESX hosts.

Thank you Astrolab, dmaster, and everyone else for providing all the information on this thread.

Jas

Jason Boche

VMware Communities User Moderator

[meistermn]

This step should be approved:

Open the file that you saved above with notepad and copy all of the the contents including the "---BEGIN CERTIFICATE REQUEST-" and "-END CERTIFICATE REQUEST---" lines

For Opening the file you should use Ultraedit or some other good editor to prevent that it convert to dos formart , as notepad and wordpad does.

[jtweathers]

I am running into the same issue you noted at the bottom. I have replaced my certificates on virtual center and run vpxd.exe -p and virtual center starts without issue.

I have also replaced the certificates on one of my ESX hosts. On the ESX host with the new certificates when I try and add to Virtual center I get Failed to install the virtualcenter agent service. It still appears in Virtual center but shows disconnected. When trying to reconnect you immediately get login failed due to a bad username or password, you then enter the username and password and the agent install fails again.

If I try and add the ESX hosts where I did not replace the certificates they work fine.

Did you ever figure out what has to be done for virtual center to communicate with an ESX 3.5 host that has had its certificates replaced?

[ThomasV]

If you replace the ESX certificate on the host you have to perform a /etc/init.d/mgmt-vmware restart

If you use faulty certificates the vpxa service will be stopped and in the vpxa log an error will be displayed: tail -f /var/log/vmware/vpx/vpxa.log will display the last lines

The faulty certificate is due to the copy paste of the certificate request with wordpad. If you open the resulting certificate with notepad++ and check show special characters you will see there are CR/LF at the end of each line. For the certificate to be valid only LF are allowed, simply click convert to unix in notepad++ and re-upload it to you esx.

[astrolab]

I installed MS CA certificates on several hosts, performed mgmt-vmware restart but still the problem persists as indicated by you. Basically what's happening is:

1-VC has the certificates installed===&gt; Works fine

2-Stand-alone ESX hosts have Certs installed==&gt; works fine

3-If both VC and ESX hosts managed by VC have certs===&gt; No Good, the hosts get disconnected and stay so.

[ThomasV]

After you replace the certificates on an ESX host and you perform a mgmt-vmware restart, what does "/etc/init.d/vmware-vpxa status"' gives as outcome? That service should be started.

If not, id really verify if you .crt file does not contains any CR's

[jtweathers]

I figured it out today. It was the cr/lf issue. I noticed in the vcagent log that the rui.crt file was unknown to the agent. I opened the rui.crt file with nano and it stated that there were 21 lines converted from DOS. I saved the file using rui.crt.1. Then deleted rui.crt and copien rui.crt.1 to rui.crt and everything is working now.