In vSphere 6.0 the VMCA (VMware Certificate Authority) was introduced. This is basically vSphere’s own CA and it’s purpose is to simplify certificate generation and implementation in vSphere, in conjunction with VECS (VMware Endpoint Certificate Store)
While I do agree it does simplify the whole process, it’s not without its limitations and known issues. Hopefully this guide will help you avoid those pitfalls.
Firstly let me explain the small lab environment I will use.
- I have a Root CA on my domain controller (dc.domain.com)
- I have an Intermediate CA (interca.domain.com)
- I have a Platform Services Controller 6.0 U2 Appliance (psc.domain.com)
- I have a vCenter Server 6.0 U2 Appliance (vc.domain.com)
Create the Certificate Templates
In this guide we are using a Microsoft Certificate Authority.
Review https://kb.vmware.com/kb/2112009 and perform the steps outlines in the sections ‘Creating a new template for vSphere 6.0 to use for VMCA as a Subordinate CA’ and also ‘Adding a new template to certificate templates’
Generate VMCA Certificate Signing Request (CSR)
SSH to the Platform Services Controller (or vCenter Server if using VC w/ Embedded PSC)
Enable the BASH shell and set it to the default shell (we’ll need that when uploading the new certificate files)
shell.set --enabled True shell chsh -s /bin/bash root
Reference: https://kb.vmware.com/kb/2100508
1. Launch the certificate-manager utility from /usr/lib/vmware-vmca/bin/certificate-manager
/usr/lib/vmware-vmca/bin/certificate-manager
2. Select Option 2. Replace VMCA Root certificate with Custom Signing Certificate and replace all Certificates.
3. The certificate-manager will ask a question about generating all certificates using configuration files. We will answer Y to this question
4. Provide the administrator@vsphere.local credentials
5. Next we will be asked to configure the configuration file for MACHINE_SSL_CERT. The important bit here is to provide the FQDN for ‘Hostname‘ and I also recommended providing the FQDN for the ‘Name‘ field too.
6. Next we will be asked to configure the machine solution user configuration file. Same as the Machine_SSL_CERT in the previous step, provide the FQDN for the ‘Hostname‘ field. For the ‘Name‘ field use the format <solution_user>-fqdn. i.e. machine-psc.domain.com
Important: It is crucial that the subject information of all solution user certificates in this environment are kept unique. You can read more about that in my earlier post Caution: Solution User Certificates in vSphere 6.0
7. Next we will be asked to configure the vsphere-webclient solution user configuration file. Repeat the same process as step 6 above. i.e. Make the ‘Name‘ field vsphere-webclient-psc.domain.com
8. If this was a vCenter Server with Embedded PSC there would be two more solution user configuration files to configure in the same manner; vpxd and vpxd-extension. Since this is an external PSC only two solution users exist.
9. Select Option 1: Generate Certificate Signing Request(s) and Key(s) for VMCA Root Signing certificate
10. Provide a path to save the resulting csr and key file. In this example I just use the /tmp directory.
11. Next we will be asked to configure yet another configuration file called certool.cfg. This will control the information that our new VMCA certificate will contain. Again, provide the FQDN for the ‘Hostname‘ field and for the ‘Name‘ field use the format of VMCA-FQDN. i.e. VMCA-psc.domain.com
12. The certificate-manager will then generate the vmca_issued_csr.csr and vmca_issued_key.key in the location you specified earlier.
13. Using WinSCP or similar, copy the vmca_issued_csr.csr off the PSC Appliance.
14. Provide this csr to your certificate team to be issued with the new certificate. I will walk through this process using a Microsoft CA
Important: There is a known issue in 6.0 U2 where the CSR created for the VMCA as a Subordinate does not have the required attributes. Most Microsoft CA’s will force the inclusion of the attributes based on the certificate template used.
Check the certificate you just created from your CA by running the following OpenSSL Command:
openssl x509 -in vmca.cer -noout -text
The attributes we need present are CA:TRUE, Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
If it is missing these attributes then you will need to create the CSR a different way by following this KB Article http://kb.vmware.com/kb/2145544
Obtain the signed Certificates from a Microsoft CA
1. Open a browser to your certificate authority web interface. i.e. http://interca.domain.com/certsrv
2. Select ‘Request a certificate‘ then select ‘advanced certificate request‘
3. Open the vmca_issued_csr.csr in a text editor like notepad and copy and paste the entire contents into the ‘Saved Request‘ text field and choose your VMCA Root certificate template from ‘Certificate Template‘ drop down and then hit ‘Submit‘
4. Select ‘Base 64 encoded‘ and then hit ‘Download certificate chain‘. You will be prompted to download and save a certnew.p7b file.
5. Open the certnew.p7b file in Windows and drill down to the Certificates container. You should see the new VMCA Root Certificates as well as your Root MS CA and any Intermediate MS CA certificates.
6. Export each of these certificates. In my lab I exported root.cer, inter.cer and vmca.cer
Right-Click > All Tasks > Export Next > Base-64 encoded X.509 > File Path > Next > Finish
7. Open a Command Prompt to the location you exported the above certificates. Next we need to concatenate them into a single certificate chain, with the new VMCA on top, followed by the Intermediate CA, followed by the Root CA.
From the command prompt use the more command to concatenate. We will concatenate into a file called vmca_issued_cer.cer to keep with the naming convention of the files generated by the Certificate-Manager.
more vmca.cer >> vmca_issued_cer.cer more inter.cer >> vmca_issued_cer.cer more root.cer >> vmca_issued_cer.cer
8. Copy the vmca_issued_cer.cer up to /tmp/ on the PSC
Implement the signed Certificate as a new VMCA
1. Return to the Putty Session open to the PSC.
If you have closed this, return to the certificate-manager by running
/usr/lib/vmware-vmca/bin/certificate-manager
Select Option 2, then Option 1
2. Select Option 1: Continue to importing Custom certificate(s) and key(s) for VMCA Root Signing certificate
3. Provide the full path to the new VMCA Certificate Chain we created and then the Key that was created earlier
Please provide valid custom certificate for Root. File : /tmp/vmca_issued_cer.cer Please provide valid custom key for Root. File : /tmp/vmca_issued_key.key
4. Ensure you have entered all the information correctly and also ensure you have taken a snapshot of the PSC and VC machines before answering ‘Y‘ to continue
You are going to replace Root Certificate with custom certificate and regenerate all other certificates Continue operation : Option[Y/N] ? : Y
5. The Certificate-Manager will then replace the VMCA with your new Subordinate CA certificate and replace the certificates on the PSC (MACHINE_SSL_CERT, machine and vsphere-webclient solution user certificates)
It will also update the relevant service endpoints with the new MACHINE_SSL_CERT.
Lastly it will restart all the services on the PSC.
You are going to replace Root Certificate with custom certificate and regenerate all other certificates Continue operation : Option[Y/N] ? : Y Get site nameCompleted [Replacing Machine SSL Cert...] cork Lookup all services Get service cork:586c2bb6-9078-4bd7-8ba9-ddc411798c1b Update service cork:586c2bb6-9078-4bd7-8ba9-ddc411798c1b; spec: /tmp/svcspec_xVqq3K Get service cork:fd3833cd-d96a-454e-9ccc-ea25d0befdfc // Snip // Get service 79b06bf4-a18d-4f9e-b5a9-04affc35d2a4_com.vmware.vsan.health Don't update service 79b06bf4-a18d-4f9e-b5a9-04affc35d2a4_com.vmware.vsan.health Get service a82770ef-91ec-4e97-ba5a-b48fa3d5a371 Don't update service a82770ef-91ec-4e97-ba5a-b48fa3d5a371 Get service 7137e349-af59-4d0e-a03f-d235c9406740 Don't update service 7137e349-af59-4d0e-a03f-d235c9406740 Get service 3996a8c7-40a7-47e6-8912-bc4688dbbc59 Don't update service 3996a8c7-40a7-47e6-8912-bc4688dbbc59 Get service 29e3287a-f635-4b2f-aded-5241cbf25395 Don't update service 29e3287a-f635-4b2f-aded-5241cbf25395 Updated 9 service(s) Status : 100% Completed [All tasks completed successfully]
Note: If this is a vCenter Server with Embedded PSC you would be complete and you would see more Updated Services.
If your vCenter Server is External then proceed to the next section.
Replace the Machine SSL Certificate on the vCenter Server from the new VMCA
1. Open a Putty session to the vCenter Server
2. Restart the vCenter Server service first before proceeding.
service-control --stop --all service-control --start --all
3. Launch the Certificate-Manager
/usr/lib/vmware-vmca/bin/certificate-manager
4. Select Option 3 Replace Machine SSL certificate with VMCA Certificate
5. Provide the administrator@vsphere.local credentials
6. Since this is a vCenter Server with an external PSC you will be asked to provide the IP Address of the PSC.
Performing operation on distributed setup, Please provide valid Infrastructure Server IP. Server : 192.168.2.101
7. Similar to before, we will be asked to configure the configuration file for MACHINE_SSL_CERT. The important bit here is to provide the FQDN for ‘Hostname‘ and I also recommended providing the FQDN for the ‘Name‘ field too.
8. Ensure the information entered is correct before answering ‘Y‘ to continue. Also ensure you have taken a new snapshot of the PSC and VC Machines.
You are going to regenerate Machine SSL cert using VMCA Continue operation : Option[Y/N] ? : Y
9. The vCenter Server MACHINE_SSL_CERT will be replaced with a new one issued by the VMCA as a Subordinate, the relevant service endpoints with the new MACHINE_SSL_CERT and the services will be restarted.
You are going to regenerate Machine SSL cert using VMCA Continue operation : Option[Y/N] ? : Y Get site nameompleted [Replacing Machine SSL Cert...] cork Lookup all services Get service cork:586c2bb6-9078-4bd7-8ba9-ddc411798c1b Don't update service cork:586c2bb6-9078-4bd7-8ba9-ddc411798c1b Get service cork:fd3833cd-d96a-454e-9ccc-ea25d0befdfc Don't update service cork:fd3833cd-d96a-454e-9ccc-ea25d0befdfc Get service cork:a46b5ede-2566-4d5a-9749-e83cbb644449 Don't update service cork:a46b5ede-2566-4d5a-9749-e83cbb644449 Get service be040cf2-5668-46fc-a013-3571745c7e12 Don't update service be040cf2-5668-46fc-a013-3571745c7e12 Get service f73219a5-730e-4429-81c2-4de727d16f73 // Snip // Update service 08970f6b-2b84-4e84-81f6-04d87ba44e49_kv; spec: /tmp/svcspec_nIUxUp Get service 4d30cfc1-d4eb-4303-8bfc-c2189cd1e7a1 Update service 4d30cfc1-d4eb-4303-8bfc-c2189cd1e7a1; spec: /tmp/svcspec_lkUrH5 Get service f371971c-4689-4f87-ae67-7db58f4d56df Update service ac4d2f3f-2cd4-4a92-8ac4-8cadfb2ddb30; spec: /tmp/svcspec_Qej_nM Update service a82770ef-91ec-4e97-ba5a-b48fa3d5a371; spec: /tmp/svcspec_M7zwgb Get service 7137e349-af59-4d0e-a03f-d235c9406740 Update service 7137e349-af59-4d0e-a03f-d235c9406740; spec: /tmp/svcspec_BmOy3p Get service 3996a8c7-40a7-47e6-8912-bc4688dbbc59 Update service 3996a8c7-40a7-47e6-8912-bc4688dbbc59; spec: /tmp/svcspec_b2H6M2 Get service 29e3287a-f635-4b2f-aded-5241cbf25395 Update service 29e3287a-f635-4b2f-aded-5241cbf25395; spec: /tmp/svcspec_OlFACZ Updated 21 service(s) Status : 100% Completed [All tasks completed successfully]
Replace the Solution User Certificates on the vCenter Server from the new VMCA
To be honest, replacing any solution user certificate is completely optional as they are not directly exposed to the end user. But if you require them to also be replaced by your new VMCA Subordinate then the following should be performed.
1. Launch the Certificate-Manager
/usr/lib/vmware-vmca/bin/certificate-manager
2. Select Option 6 Replace Solution user certificates with VMCA certificates
3. The certificate-manager will ask a question about generating all certificates using configuration files. We will answer Y to this question
4. Provide the administrator@vsphere.local credentials
5. Since this is a vCenter Server with an external PSC you will be asked to provide the IP Address of the PSC.
Performing operation on distributed setup, Please provide valid Infrastructure Server IP. Server : 192.168.2.101
6. Next we will be asked to configure the machine solution user configuration file. Provide the FQDN for the ‘Hostname’ field. For the ‘Name’ field use the format <solution_user>-fqdn. i.e. machine-vc.domain.com
Important: It is crucial that the subject information of all solution user certificates in this environment are kept unique. You can read more about that in my earlier post Caution: Solution User Certificates in vSphere 6.0
Configure the vsphere-webclient, vpxd, vpxd-extension and solution user configuration files in the same manner. Ensuring that every solution user in the SSO Domain is unique.
If you follow my advice and make the ‘Name’ value <solution_user>-<fqdn> this will ensure that.
7. Ensure the information entered is correct before answering ‘Y‘ to continue. Also ensure you have taken a new snapshot of the PSC and VC Machines.
You are going to regenerate Solution User Certificates using VMCA Continue operation : Option[Y/N] ? : Y
8. The machine, vsphere-webclient, vpxd and vpxd-extension solution user certificates will be replaced with new ones issued by the new VMCA and the services will be restarted on the vCenter Server.
have you tried reinstalling? 
Nice article Féidhlim!
LikeLike
Hi Féidhlim – do you still need to wait 24 hours in between generating the certs and implementing them?
LikeLike
Hi,
We changed the behavior with 6.0 U2 to avoid this issue – see https://kb.vmware.com/kb/2123386 for more detail.
Thanks for the question.
LikeLike
Feidhlim, this article is exactly what I’ve been looking for. Now if only we could get VMware to update their support articles with this information. I’ve been beating my head on this one and Adam Eckerle pointed me to your article, definitely a life-saver!
LikeLike
Hi Feidhlim! Your article is very helpful and in my case with (vSphere 6.5) it was comlete instruction. Many thanks. Only one unclear issue remaining: ssl cert for https://:5480/… and https://:5480/ remains old and untrusted. Any ideas how correctly tegenerate them using VMCA?
LikeLike
The VAMI on port 5480 should use the Machine SSL (same one as 443). If I recall, the VAMI service doesn’t get restarted (known issue).
Try manually restart the VAMI using the following command from an SSH session.
service vami-lighttpd restartLikeLike
I’ve restarted not only service but VM. I seem’s that this service use other cert copy somewhere (where?) and it was not replaced with new cert. Indirect mention that not all certs replaced by the pricess of implementation os subordinate CA on VMCA is in docs https://pubs.vmware.com/vsphere-65/topic/com.vmware.psc.doc/GUID-3AF7757E-A30E-4EEC-8A41-28DA72102520.html
Any ideas?
LikeLike
My head was in 6.5 sorry. For 6.0 try run the following /usr/lib/applmgmt/support/scripts/postinstallscripts/lighttpd-vecs-integration.sh
LikeLiked by 1 person
Hello Feidhlim! I’ve tryed to regenerate machine ssl and noticed that they are updating both but not at a time and somehow VAMI one has broken trust chain (?!) all other values I can check without direct access to exact files are the same! What do you think? Thanks in advance!
LikeLike
Solution found!
Thanks to https://communities.vmware.com/people/Orcunus
He posted :https://communities.vmware.com/message/2620623#2620623
But I made little modification and added missing reference for ssl.ca-file like:
Config file: /opt/vmware/etc/lighttpd/lighttpd.conf
Add line: ssl.ca-file = “/etc/vmware/vmware-vmafd/ca.crt”
this is a link to correct VMCA cert
LikeLiked by 1 person
Thanks Nikolay – when I get around to updating this cert series I’ll be sure to add this in.
LikeLike
Your head was in right mood I’m in 6.5! yuo may notice that inside 6.5 docs the table referencing certs taken from 6.0 !!! Anyway, your kind path to usr/lib/applmgmt/support/scripts/postinstallscripts/ is very helpfull! Thanks!
(gone to read scripts ;))
LikeLike
Hi Nikolay,
As per your instructions i have added the below line and rebooted the PSC because when i tried to restart the vami-lighttpd service, it said service not found.
Add line: ssl.ca-file = “/etc/vmware/vmware-vmafd/ca.crt”
Even after PSC reboot the PSC gives certificate error for 5480 access. Can you please help secondly we have issued certificates to ESXi, all of the certificates properties are fine except the Subject which are still reflecting the default values what could be the issue.
LikeLike
Hey Féidhlim,
Great post! I just wanted to mention the issue you describe when referencing KB2145544 seems to be related to the certificate template which you use to generate the VMCA cert. If you check out http://kb.vmware.com/kb/2112009 and watch the youtube video, or don’t read carefully enough and follow the first set of steps in the article, it will lead you to duplicate the web server template and select the wrong options under extensions > key usage. This will result in the “Not a CA cert” error when importing the certificate chain using the certificate manager. The solution is to duplicate the Subordinate Certification Authority template instead, which contains the correct key usage extensions (which you have demonstrated with the openssl command).
It was also great to see the steps for keeping the subject information of the certificates unique. This was something I came across by accident recently when deploying a new vSphere 6.5 environment. I wish those steps were reflected in the official VMware KB articles.
Anyway, thanks again! Your post has saved me quite a bit of time.
LikeLiked by 1 person
My vCenter used to be an embedded PSC and has since moved off. I was successful in replacing the new external PSC’s certs with my sub ca certs but when I do the original vCenter appliance it does not prompt me for the new PSC’s IP address. It appears to still have all the config from the last time it used it’s own VMCA to generate it’s self signed certs (and immediately fails if i tell it to proceed anyhow. Any idea how to get the original no longer PSC vCenter server to give in to the external?
LikeLike
Hi Mark – thanks for reporting this. I’m not immediate aware of this issue. Let me get back to you on this.
LikeLike
Hi Mark,
For 6.0 this was a known issue and is fixed in 6.0 U3 (recently released) https://kb.vmware.com/kb/2133028
I’ve noticed that a similar issue is still present in 6.5 however. The KB workaround works for 6.5 also.
Thanks
LikeLike
Thank you so much, the workaround in that KB article fixed me right up! Much appreciated, on to the next one…
LikeLike
Hey Féidhlim,
Just wanted to mention to you and anyone else who may be reading that the process has changed slightly in vSphere 6.0 Update 3. When at step 5 of “Generate VMCA Certificate Signing Request (CSR)” in your guide above, certificate manager now only prompts you modify certool.cfg.
Certool.cfg also contains an extra prompt to “Enter a proper value for VMCA ‘Name'”, in addition to the other prompts for Name and Hostname. I entered “VMCA-” for the VMCA ‘Name’. I’m not sure what that field does, because the issued common name of the certificate issued to the VMCA is “CA” regardless of what you configure at the “VMCA name” step of certool.cfg. That feels like a bit of a step back, to be honest.
However, the solution user certificates are automatically created with unique common name that looks something like “vsphere-webclient-5d55adfb-29ad-42b6-ae56-46c5c0f01d96”, which is nice.
Also, don’t renew certificates through the https:///psc interface. That is broken (as it is in vSphere 6.5 as well) and will issue self-signed certificates despite having replaced the VMCA root certificate.
Cheers!
LikeLike
For some reason anything within less than/greater than brackets in my comment above was stripped out. It was supposed to say, I entered “VMCA-(FQDN)” for the VMCA ‘Name’”. Also I mentioned the http://(fqdn)/psc interface.
LikeLiked by 1 person
Yes there have been improvements to 6.0 U3 (not yet in 6.5) that hopefully prevents the solution user certs from getting identical subjects.
The “VMCA” filed is used when replacing the VMCA certificate, not used for other certs but I think the tool prompts you for all options.
Thanks for the feedback.
LikeLiked by 1 person
Hello,
I’m curious, how does your process differ when you’ve got your PSCs configured behind an F5 LB in HA? We’ve got 2 PSC nodes configured with a signed LB cert from our CA, and that cert is also on the F5 (as per VMware docs). We have not got SSL pass-through enabled; the session terminates at the F5 and is recompiled between the F5 and the PSC nodes.
VMware docs state you should configure your PSCs individually and separately as VMCAs (ignoring the LB FQDN) with their own signed root certificates. That’s fine, but now both PSC nodes have separate VMCA instances, with different FQDNs and common names. This means that depending on the PSC availability, we’re going to have some certificates in the environment with an intermediate CA of, say, “vmca-pscnode01” and some others with an intermediate CA of “vmca-pscnode02”. What impact does this have if a PSC node bites the dust?
Your post states that when the VMCA root certificate is changed, the MACHINE_SSL_CERT certificate is regenerated for the PSC node. VMware docs state that once you perform this change on the first PSC node, you should then copy the certificates and keys for MACHINE_SSL_CERT issued by the first PSC node’s VMCA to the other PSC nodes and install that ‘custom’ MACHINE_SSL_CERT. This is problematic, as it will replace our custom signed LB cert and break the connection with the F5. Is it possible to have the VMCA leave the MACHINE_SSL_CERT alone yet still sign certificates as an intermediate for ESXi, vCenter etc.? Or are we supposed to take the new MACHINE_SSL_CERT that’s generated and update the F5?
Am I even on the right track here?
LikeLike
Hi AusSTY
Can you point me to this in the VMware Docs? That isn’t right.
In 6.0 PSC HA each PSC will still have a unique Machine_SSL_cert and a unique Load Balancer Cert. So you would have three certificates.
If you are using VMCA as a Subordinate with PSC HA then it is possible that parts of the environment will get certs issued from psc-01 and other from psc-02. Unfortunately that is something you as the admin would have to manage. If you lost one of the PSC and re-installed, for example, the certificates issued by the failed PSC would still be valid and continue to work. VMCA’s are standalone and separate, but VECS is replicated between all PSCs and VCs. So the “Trusted Roots” VECS on all nodes would still contain the VMCA SubCA from the failed PSC and thus any certificates would continue to be trusted.
If you have PSC HA 6.0 currently enabled and you want to enable VMCA as a Subordinate then you should perform the following.
1. Enable VMCA on each PSC – this will automatically replace the Machine SSL and Solution Users certificates on each PSC with new certificates issued by their local VMCA SubCA.
2. If you wish to change the Load Balancer certificate to be issued by one of the VMCA SubCAs then you need to re-do the PSC HA process and scripts and also update the F5 with the new certificate that will be generated.
3. If you wish to have the attached vCenter Servers renew their certificates from the VMCA SubCAs then you would use the certificate-manager and Options 3 and 6
Hope that helps.
LikeLike
Hi Féidhlim,
Thanks for your response! I managed to figure everything out yesterday, almost down to the ‘T’ of what you’ve written. I’ll give a bit of back story around what I was trying to achieve…
I had a v5.5 SSO deployed in a HA config behind an F5. The original builder of the environment had a single LB cert generated by an enterprise CA, that included the FQDN of the VIP, as well as the FQDN, hostnames and IP’s of the SSO nodes.. all in one cert. This cert was installed on both nodes and the F5, and the F5 would terminate the secure traffic, and re-encrypt between itself and the SSO nodes.
Well, 6.0U2M came out and it was my job to migrate our infrastructure to the appliances. I successfully migrated both SSO nodes to PSCs, which maintained this certificate configuration.
Working off the VMware KB articles for re-enabling HA for the PSCs after an upgrade, I noticed that the article states I needed to enable the VMCA services first if I plan to use them. The VMCA configuration KB stated that by configuring the VMCA using the certificate-manager tool it’ll re-issue the MACHINE_SSL_CERT. I was concerned because this would break the current SSO configuration (unless I updated the F5). As I’m not in direct control of the F5, I decided to hold off until I knew more.
Once my migration had been completed (SSO->PSC, VCS->VCSA etc) I still wanted to enable the VMCA as an Intermediate CA to our enterprise CA.
Long story short I found the detailed VMware pubs that walk you through the manual steps on replacing the VMCA root certificate with my intermediate CA issuing cert, which avoids regenerating the MACHINE_SSL_CERT. This is perfect, and I was able to regenerate the solution user certificates on the PSCs all without breaking my original SSO certificate structure.
This configuration works fantastically now. Once I’ve upgraded to v6.5 (where pass-through is supported on the F5), I’ll be re-issuing the PSC MACHINE_SSL_CERTs from the VMCA.
Sorry if this seems a bit pointless, but I thought I should’ve given some context around my rookie post made earlier.
Thanks again,
AusSTY
LikeLike
Thanks AusSTY, the added context does explain things 🙂
LikeLiked by 1 person
I did not find an “Option 1: Continue to importing Custom certificate(s) and key(s) for VMCA Root Signing certificate” after generating the CSR on 6.0u2. We’ve generated the Certificates, how to continue?
LikeLike
Hi Jeefke
If you have closed the certificate-manager, return to the certificate-manager by running
/usr/lib/vmware-vmca/bin/certificate-manager
Select Option 2, then Option 1
Hope that helps.
LikeLike
I’m running 6.5 5178943 and cannot get this working. Running external PSC (tried embedded as well) and nothing is working!!! I typically get this generic error “Invalid Certificate Chain was gives as input” https://gist.github.com/JakeDEvans/cd82574d9943bfff4df12ded9aafc6d5
However the cert chain is correct (I’ve done a lot of ssl/pki work, the chain is full chain with anchored root as described above). Any suggestions I’d appreciate it, I’ve tried issuance from the root CA, a subCA, etc etc, importing the root ca into the web mgmt as a trusted ca, nothing.
LikeLike
Hi Jake,
Off the top of my head, is your vmca_chain.crt in Base-64 Encoded? If you read the file with cat/less/vi does it appear as a few blocks of:
-----BEGIN CERTIFICATE-----BlahBlahBlahBlah
-----END CERTIFICATE-----
Also, is the chain in the correct order? Again, looking at the file in cat/less/vi the first BEGIN/END block would be the new VMCA cert, the second block would be your internal Intermediate CA (if you have one) and the last block would be your internal Root CA.
Hope that helps.
LikeLike
Yes, like I said they are chained correctly, Base64, with anchored root.
“`
—–BEGIN CERTIFICATE—–
VMCA Root CA
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
Microsoft CA Intermediate
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
Microsoft CA Root
—–END CERTIFICATE—–
“`
as well as issuance off the root CA
“`
—–BEGIN CERTIFICATE—–
VMCA Root CA
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
Microsoft CA Root
—–END CERTIFICATE—–
“`
The process worked on my 6.0 U2 server, but I’m building a fresh External PSC on 6.5 as mentioned.
LikeLike
OMG Wrong damn root cert!
LikeLike
🙂 All sorted?
LikeLike
We deneiftily need more smart people like you around.
LikeLike
certnew.p7b shows only 2 certificates in store for me. Any Ideas??
LikeLike
That can be dependant on your internal CA. You probably don’t have any Intermediate CA.
LikeLike
Question for you.. So i’ve ran through this whole process on a 6.0 install of VCSA with a windows external PSC and it worked great.. I’ve since then replaced my PSC Windows servers with PSC Appliances and need to go through this again but now on 6.5..
When I attempt to regenerate the Machine SSL Certificates for vCenter (Pressing option 3 in the cert manager). The last question i’m asked is
“Enter proper value for VMCA ‘Name’ :”
I would assume they want the FQDN of the new PSC appliance that i’ve setup as the new VMCA since i decommissioned the old ones.
for example vmsso310.mydomain.ad
the cert associated with this server is vmca-vmsso310.mydomain.ad.
Appreciate the help
LikeLike
Hi – the question “Enter proper value for VMCA ‘Name’ :” is only used when making VMCA a Subordinate when the Certificate-Mananger creates the CSR for the new VMCA. It is used as the Name or CN value in the CSR for the new VMCA. At the end of the day it’s a cosmetic label. Prior, the value defaulted to “CA” so if you had more than one VMCA that was enabled as a Subordinate, it was difficult to know which VMCA issued a particular certificate as the issuer would always be “CA”.
Even though the Certificate-Manager in 6.0 U3 asks this all the time, it’s only used when creating the CSR for a VMCA as Subordinate. The value wont be used when issuing your new Machine SSL from your VMCA Subordinate.
Hope that helps.
LikeLike
Hi Féidhlim,
did follow you post but have the PSC running embedded on a Windows box.
Worked fine until the Services went for a restart.
Ther Service restart stopped at vpxd, which failed to start.
The process tried to revert but failed. 😦
Any idea?
Carsten
LikeLike
Hi Carsten,
Not without seeing the vpxd.log. Can you past what errors are seen towards the bottom of the vpxd.log? I’d also advise getting an SR open with VMware Support.
LikeLike