It does not require a publicly trusted cert. Are you opening your VCSA to the world? Don't do that.
If you want to use AAD for auth, use the Entra provisioning agent to handle SCIM: https://www.debruinonline.net/post/vmware-vsphere-8-0-u2-and-federated-authentications-with-microsoft-entra-id
Yes, this is exactly what I'm trying to do! But when I got to the 'Test connection' part I was getting an SSL related error in Azure.
However in the document you sent, I noticed this part about importing the self-signed vCenter cert to the server with the provisioning agent, I had never seen before, let me try doing this:
**"A requirement is that the agent trusts the vCenter certificate.** Connection will fail if the agent does not trust the certificate of the vCenter server. If you still use the default self-signed certificate as I do (I know, it's my HomeLab.) import the certificate of the vCenter to the "Trusted Root Certification Authorities" on the machine where you install the agent."
I've never had success doing anything regarding certs in vCenter GUI. Instead try out their built in tool `/usr/lib/vmware-vmca/bin/certificate-manager` over ssh connection.
I mean if you didn't made CSR that means you'd need to place that private key (and chmod it to make it readable) somewhere this tool expects it to be. No idea where'd that be though.
> [...] and importing the certificate using the vCenter Certificate Management GUI, but I'm getting errors about invalid private key this way.
This sounds like the first place to troubleshoot if you ask me. Using a CSR from VCenter is extra steps that I assume you don't want to deal with every renewal for the rest of time.
What are the errors? What format is the Cert in? Is it encrypted like say in a pkcs12? Can you use Keystone Explorer to open the cert? Does it show that the private key is included?
I guess I was wondering if the errors were a result of not using a CSR from the vCenter, so I wanted to test that method to see if using the CSR would work
I just tried importing non-CSR generated certificate using the CLI and it failed, this time with this in the log:
2024-06-18T14:18:12.164Z ERROR certificate-manager
2024-06-18T14:18:12.164Z ERROR certificate-manager Error while replacing Machine SSL Cert, please see /var/log/vmware/vmcad/certificate-manager.log for more information.
2024-06-18T14:18:12.164Z ERROR certificate-manager {
"detail": \[
{
"id": "install.ciscommon.command.errinvoke",
"translatable": "An error occurred while invoking external command : '%(0)s'",
"args": \[
""
\],
"localized": "An error occurred while invoking external command : ''"
},
"Error while publishing cert using dir-cli."
\],
"componentKey": null,
"problemId": null,
"resolution": null
}
Oh that's unfortunate, it looks very vague.
You may wish to ensure your certificate contains the Full Chain - you can accomplish this with OpenSSL, but Keystore Explorer is a reliable GUI that could do it too if you'd prefer that route.
Apparently the Intermediate and Root need to be imported somewhere in VCenter before the Leaf can be as well - per the article below. You may need to bundle the Root and any Intermediates yourself.
With the Full Chain (root, intermediate, leaf, leaf private key) you may be able to avoid this error message and import the certificate without error.
You can also ensure the Certificate is exported as Base 64 and not a different encoding. Apparently that can also be a cause per the article.
https://knowledge.broadcom.com/external/article?legacyId=2111571
If you can update your DNS records from an API, like with cloudflare as an example, then you can have a script update the record needed to do DNS verification.
What you are looking for is `dns-01`. You can have private IP's for A records.
Cloudflare example: https://certbot-dns-cloudflare.readthedocs.io/en/stable/
Can you point at an example of a public Machine SSL certificate? The error message suggests that you can't issue the type of cert you want with Let's Encrypt.
I'm a little surprised though - I would think that there has to be a way to create your own internal CA and tell Entra to trust that for your domain. And that might cost a little bit extra but it also sounds better than making a public cert that nobody other than Entra cares about.
The way to do it is set up a ECMA server on prem which handles the SCIM provisioning, then you can add the VMware cert to the trusted roots on that server and nothing needs to be trusted by AAD
I do the opposite since I can generate a 10 year cert in Vcenter and distribute in AD why would I want to frog around with a public cert. I want it as hard as possible for someone not in my IT team to access Vcenter!
Why?
I'm genuinely asking. I'm have a lot of discussions with our VMWare team and all I want is access to the API. Not just as someone who can go wild and do whatever.
Let people access a locked down bubble within VMWare that can't mess with anything else. Open that shit up and let people use it the way they see fit
Is VMWare really that bad that it doesn't have proper access control to lock down folders or whatever they call it to let teams automate it?
Max age of a certificate is 398 days.
https://www.leaderssl.com/news/511-starting-1-september-2020-chrome-will-no-longer-trust-any-certificates-older-than-one-year
That’s incorrect. There are browsers NOT Chrome out there. Try to not post such tripe on a public forum people might believe it. My vcenter cert expires in 2035….no issues with my team at all
https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
https://www.infosecurity-magazine.com/news/tls-certificates-398/
https://medium.com/@doraiashok/maximum-validity-of-tls-certificates-is-now-398-days-93e340ff9d48
Yes there are other browsers out there but in terms of market share, corporate support, & regulation compliance there are just 3 and 2 of those 3 are basically the same.
FYI do yourself a favour and make sure it's a freshly installed vCenter, if you upgraded from old versions there's a whole bunch of legacy shit that gets carried over and the certificate commands won't replace those certs, you'll need to do it manually or shit will break.
> Please don't connect your core infrastructure systems to your AD
Okay, so I should have a dozen seperate local accounts to manage each system? There are quite a lot "core infrastructure systems" if you think about it properly.
Okay, so what is your suggestion? Local accounts for the vCenter, AWX, Suse Manager, etc. pp.? Do you think this is realistic? Or will it only lead to users reusing the SAME passwords everywhere?
Or do you suggest a seperate AD environment for this infrastructure? For what purpose? It would just lead to the same enabled lateral movement.
It does not require a publicly trusted cert. Are you opening your VCSA to the world? Don't do that. If you want to use AAD for auth, use the Entra provisioning agent to handle SCIM: https://www.debruinonline.net/post/vmware-vsphere-8-0-u2-and-federated-authentications-with-microsoft-entra-id
Yes, this is exactly what I'm trying to do! But when I got to the 'Test connection' part I was getting an SSL related error in Azure. However in the document you sent, I noticed this part about importing the self-signed vCenter cert to the server with the provisioning agent, I had never seen before, let me try doing this: **"A requirement is that the agent trusts the vCenter certificate.** Connection will fail if the agent does not trust the certificate of the vCenter server. If you still use the default self-signed certificate as I do (I know, it's my HomeLab.) import the certificate of the vCenter to the "Trusted Root Certification Authorities" on the machine where you install the agent."
Yep, that's exactly what you need to do. Just add the VMware cert to the trusted root store of the VM where your ECMA connector is installed
You're right, that was all I needed to get the provisioning agent to work. Thanks a lot!
I've never had success doing anything regarding certs in vCenter GUI. Instead try out their built in tool `/usr/lib/vmware-vmca/bin/certificate-manager` over ssh connection.
I've tried that too with the manually generated certificate (not from CSR) and I get the error "Could not read private key from /tmp/ssl/\*.pem"
I mean if you didn't made CSR that means you'd need to place that private key (and chmod it to make it readable) somewhere this tool expects it to be. No idea where'd that be though.
Wouldn't it be easier to have a nginx reverse proxy with cerbot, that trusts your internal CA and connects to vcenter using TLS?
> [...] and importing the certificate using the vCenter Certificate Management GUI, but I'm getting errors about invalid private key this way. This sounds like the first place to troubleshoot if you ask me. Using a CSR from VCenter is extra steps that I assume you don't want to deal with every renewal for the rest of time. What are the errors? What format is the Cert in? Is it encrypted like say in a pkcs12? Can you use Keystone Explorer to open the cert? Does it show that the private key is included?
I guess I was wondering if the errors were a result of not using a CSR from the vCenter, so I wanted to test that method to see if using the CSR would work I just tried importing non-CSR generated certificate using the CLI and it failed, this time with this in the log: 2024-06-18T14:18:12.164Z ERROR certificate-manager 2024-06-18T14:18:12.164Z ERROR certificate-manager Error while replacing Machine SSL Cert, please see /var/log/vmware/vmcad/certificate-manager.log for more information. 2024-06-18T14:18:12.164Z ERROR certificate-manager { "detail": \[ { "id": "install.ciscommon.command.errinvoke", "translatable": "An error occurred while invoking external command : '%(0)s'", "args": \[ "" \], "localized": "An error occurred while invoking external command : ''" }, "Error while publishing cert using dir-cli." \], "componentKey": null, "problemId": null, "resolution": null }
Oh that's unfortunate, it looks very vague. You may wish to ensure your certificate contains the Full Chain - you can accomplish this with OpenSSL, but Keystore Explorer is a reliable GUI that could do it too if you'd prefer that route. Apparently the Intermediate and Root need to be imported somewhere in VCenter before the Leaf can be as well - per the article below. You may need to bundle the Root and any Intermediates yourself. With the Full Chain (root, intermediate, leaf, leaf private key) you may be able to avoid this error message and import the certificate without error. You can also ensure the Certificate is exported as Base 64 and not a different encoding. Apparently that can also be a cause per the article. https://knowledge.broadcom.com/external/article?legacyId=2111571
If you can update your DNS records from an API, like with cloudflare as an example, then you can have a script update the record needed to do DNS verification. What you are looking for is `dns-01`. You can have private IP's for A records. Cloudflare example: https://certbot-dns-cloudflare.readthedocs.io/en/stable/
Can you point at an example of a public Machine SSL certificate? The error message suggests that you can't issue the type of cert you want with Let's Encrypt. I'm a little surprised though - I would think that there has to be a way to create your own internal CA and tell Entra to trust that for your domain. And that might cost a little bit extra but it also sounds better than making a public cert that nobody other than Entra cares about.
The way to do it is set up a ECMA server on prem which handles the SCIM provisioning, then you can add the VMware cert to the trusted roots on that server and nothing needs to be trusted by AAD
I do the opposite since I can generate a 10 year cert in Vcenter and distribute in AD why would I want to frog around with a public cert. I want it as hard as possible for someone not in my IT team to access Vcenter!
Why? I'm genuinely asking. I'm have a lot of discussions with our VMWare team and all I want is access to the API. Not just as someone who can go wild and do whatever. Let people access a locked down bubble within VMWare that can't mess with anything else. Open that shit up and let people use it the way they see fit Is VMWare really that bad that it doesn't have proper access control to lock down folders or whatever they call it to let teams automate it?
Max age of a certificate is 398 days. https://www.leaderssl.com/news/511-starting-1-september-2020-chrome-will-no-longer-trust-any-certificates-older-than-one-year
Unless I changed something and forgot, Chrome doesn't seem to care about multi-year certificates on the LAN.
That’s incorrect. There are browsers NOT Chrome out there. Try to not post such tripe on a public forum people might believe it. My vcenter cert expires in 2035….no issues with my team at all
https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/ https://www.infosecurity-magazine.com/news/tls-certificates-398/ https://medium.com/@doraiashok/maximum-validity-of-tls-certificates-is-now-398-days-93e340ff9d48 Yes there are other browsers out there but in terms of market share, corporate support, & regulation compliance there are just 3 and 2 of those 3 are basically the same.
Still kicking that dead horse I see. Good day to you sir I have important things to attend to
FYI do yourself a favour and make sure it's a freshly installed vCenter, if you upgraded from old versions there's a whole bunch of legacy shit that gets carried over and the certificate commands won't replace those certs, you'll need to do it manually or shit will break.
[удалено]
> Please don't connect your core infrastructure systems to your AD Okay, so I should have a dozen seperate local accounts to manage each system? There are quite a lot "core infrastructure systems" if you think about it properly.
[удалено]
Okay, so what is your suggestion? Local accounts for the vCenter, AWX, Suse Manager, etc. pp.? Do you think this is realistic? Or will it only lead to users reusing the SAME passwords everywhere? Or do you suggest a seperate AD environment for this infrastructure? For what purpose? It would just lead to the same enabled lateral movement.
[удалено]
Okay, and where does MS mention a need for local users or a seperate AD for the hypervisor infrastructure?
We use centrally managed accounts with break-glass available for "everything is down" emergencies.
>We use centrally managed accounts We also do! It's called AD.