#StandardsGoals for 2024: What’s new for BISAC - Tech Forum 2024
VMworld 2015: VMware vSphere Certificate Management for Mere Mortals
1. VMware vSphere Certificate Management for Mere Mortals
Ryan Johnson, VMware, Inc
@tenthirtyam
Adam Eckerle, VMware, Inc
@eck79
vmware.com/go/podcast
INF4529
#INF4529
2. • This presentation may contain product features that are currently under development.
• This overview of new technology represents no commitment from VMware to deliver these
features in any generally available product.
• Features are subject to change, and must not be included in contracts, purchase orders, or
sales agreements of any kind.
• Technical feasibility and market demand will affect final delivery.
• Pricing and packaging for any new technologies or features discussed or presented have not
been determined.
Disclaimer
2
4. Certificate Lifecycle Management
VMware vSphere 6.0 Solutions for Complete Certificate Lifecycle Management
VMware
Certificate
Authority
VMCA
VMware
Endpoint
Certificate Store
VECS
Located on:
Embedded Deployment, and
Platform Services Controller
Located on:
Embedded Deployment, and
vCenter Management Node
4
5. VMware Certificate Authority (VMCA)
5
Dual Operational Modes
Root CA
• During installation, VMCA automatically
creates a root CA certificate.
• This certificate is capable of issuing
other certificates.
• All solutions and endpoint
certificates are created and trusted
through to this certificate.
Issuer CA
• Can replace the default root CA
certificate created during installation.
• Requires a CSR issued from VMCA to
be used by an enterprise or 3rd party
CA to generate a new issuing
certificate.
• Requires replacement of all issued
default certificates after
implementation.
6. VMware Endpoint Certificate Store (VECS)
Repository for Certificates and Private Keys
Mandatory Component
(Used even if you don’t sign your certificates with the VMCA… )
Key Stores:
– Machine SSL Certificates
– Trusted Roots
– Certificate Revocation Lists (CRLs)
– Solution Users Certificates
– Others (e.g. Virtual Volumes)
Managing VECS is done via vecs-cli
(Or better yet, use the vSphere 6.0 Certificate Manager… coming up in a bit… )
Does Not Manage Single Sign-On Certificates
6
VMware vSphere 6.0
9. ESXi Certificates
9
VMware vSphere 6.0
Post-install, ESXi always has an auto-generated
certificate
VMCA will provision a signed certificate when host is
joined to vCenter (default mode)
Custom certificates can be use if desired (custom mode)
ESXi certificates are stored locally on each host in
the /etc/vmware/ssl
VMCA issued certificates can be renewed via the
vSphere Web Client or PowerCLI
11. Machine SSL Certificates
Creates a server-side SSL socket
Server verification and secure communication
e.g. HTTPS or LDAPS
Each node has its own Machine SSL Certificate.
i.e. Embedded Deployment; Management Node; or Platform Services Controller
All services use a Machine SSL Certificate for endpoint encryption.
All services communicate through the reverse proxy
Traffic does not go to the services themselves
e.g. The vpxd service uses the MACHINE_SSL_CERT to expose its endpoint.
11
VMware vSphere 6.0
12. Solution User Certificate
Certificate stores are located in VECS on each management node and
embedded deployment:
machine – Used by component manager, license server, and the
logging service
vpxd – vCenter service daemon (vpxd) store on management nodes
and embedded deployments. vpxd uses the solution user certificate
to authenticate to vCenter Single Sign-On
vpxd-extensions – Includes the Auto Deploy service, inventory
service, and other services that are not part of other solution users
vsphere-webclient – Includes the vSphere Web Client and some
additional services such as the performance chart service
12
VMware vSphere 6.0 – More Services but Consolidated Behind Solution Users that Hold the Certificate
13. Solution User Certificates
Encapsulates one or more vCenter Server services
Certificate authenticated by vCenter Single Sign-On
and issued a SAML token to authenticate to other
solution user and services
Each solution user must be authenticated to vCenter
Single Sign-On
Re-authentication occurs after a reboot and after a
timeout
The timeout configurable in the vSphere Web Client
and defaults to 2592000 seconds (30 days)
Maximum Holder-of-Key Token Lifetime
13
VMware vSphere 6.0
30 DAYS
14. Single Sign-On Certificates
VMware Directory Service SSL Certificate –
With custom certificates you may need to replace this SSL
certificate explicitly.
VMware vCenter Single Sign-On Signing Certificate –
Security Token Service (STS) – an identity provider that
issues, validates, and renews SAML tokens that are used for
authentication throughout vSphere
By default, the STS signing certificate is generated by VMCA
Manually refresh STS certificate via vSphere Web Client when
the certificate expires or changes
14
VMware vSphere 6.0
15. Single Sign-On Certificates
Not stored in VECS.
Not managed with certificate management tools.
Changes are not necessary, but in special situations,
you can replace these certificates.
15
Remember…
16. VMware vSphere 6.0 Certificates
16
Summary
Certificate Type Provisioning Storage
ESXi Certificates VMCA (Default) Locally on ESXi Hosts
Machine SSL Certificates VMCA (Default) VECS
Solution User Certificates VMCA (Default) VECS
Single Sign-On Certificates Provisioned During Installation Manage in vSphere Web Client.
Directory Service Certificates Provisioned During Installation In certain custom certificate
corner cases, you may need to
replace this certificate.
19. Common Certificate Manager Use Cases
19
VMCA
as Root CA
(Default or
Option 4)
VMCA
as Enterprise
CA
Subordinate
(Option 2)
Custom CA
(Option 1 & 5)
Hybrid
(Combination)
21. VMCA as Enterprise CA Subordinate
Private Key Algorithm: RSA with 2048 bits.
Standard: X.509 v3
Format: PEM (PKCS8 and PKCS1) with a header of ---BEGIN CERTIFICATE---
Recommended Signature Algorithms: SHA256, SHA384, or SHA512
Does NOT support wildcard cards or SubjectAltName
You CANNOT create subsidiary CAs of VMCA.
No explicit limit to the length of the certificate chain.
Synchronize time for all nodes in environment.
21
Requirements
22. VMCA as Enterprise CA Subordinate
Create and publish custom Subordinate Certificate Authority template per KB 2112009
Generate Certificate Signing Request and Key in Certificate Manager with Option 2
On VCSA run chsh –s /bin/bash root to enable WinSCP file transfers.
Submit Certificate Signing Request – root_signing_cert.csr – to Enterprise Certificate Authority
Create the Full Certificate Chain – root_signing_chain.pem
Import the Full Certificate Chain and Key to Replace VMCA Root Signing Certificate in Certificate Manager with Option 2
Configure certool.cfg with proper values.
Restart vCenter Services on Connected vCenter to Reflect the Change
service-control –stop | --start –all
Replace Machine SSL Certificate with VMCA Certificate on Connected vCenter(s) with Option 3
Provide the FQDN or IP of Platform Service Controller
Configure certool.cfg with proper values.
Replace Solution User Certificates with VMCA Certificates on Connected vCenter(s) with Option 6
Provide the FQDN or IP of Platform Service Controller
22
Workflow
23. Demo Time
VMCA as Enterprise CA Subordinate:
Certificate Replacement
24. VECSVMCA
Demo Scenario
VMCA
Signing Certificate
Machine SSL
Certificate
Root CA
Certificate
Enterprise CA
Certificate
Microsoft Enterprise
Certificate Authority
mgmt01dc01.sddc.local vSphere 6 Platform Services Controller
mgmt01psc01.sddc.local
Signed Signed Signed
VECS
Machine SSL
Solution Users
Certificates
vCenter 6 Server
mgmt01vc01.sddc.local
24
26. 26
Default Value = vmca
Possible Values = vmca | custom | thumbprint
Search for certmgmt
27. VMCA Authority Mode
The default mode
Post-install ESXi always has an auto-generated certificate
ESXi certificates are stored locally on each host in the /etc/vmware/ssl
VMCA provisions the host a signed certificate when added to vCenter Server
Host certificates include the full chain to VMCA
ESXi certificates can be renewed via the vSphere Web Client or PowerCLI
vpxd.certmgmt.mode = vmca
24 Hour Rule – VMCA as Enterprise CA Subordinate
Signing certificate must have a valid date of 24 hours prior before renewing host certificates or
adding new hosts to vCenter
Plan for this aging period when configuring an environment
Replace certificates prior to putting an environment into production
27
28. Custom Mode
Replacement is the same as vSphere 5.5
– ESXi Shell
– HTTPS GET/PUT
vifs will wrap these operations.
Custom / 3rd Party certificates
– Must change vpxd.certmgmt.mode to custom or risk replacement by VMCA
– Must update TRUSTED_ROOTS store in VECS on vCenter with the custom root certificates to
ensure trust relationship – use the vecs-cli entry create command
vpxd.certmgmt.mode = custom
28
29. Thumbprint Mode
Legacy mode
Fallback option for vSphere 6.0
May be used to retains vSphere 5.5 certificates during an upgrade
DO NOT use this mode unless encountering issues with vmca or custom mode
vCenter 6.0 and later services may not work correctly in thumbprint mode
Switching from thumbprint to vmca mode requires extensive planning
29
vpxd.certmgmt.mode = thumbprint
30. Demo Time
VMCA as Enterprise CA Subordinate:
ESXi Certificate Replacement
31. VECSVMCA
Demo Scenario
31
VMCA
Signing Certificate
Machine SSL
Certificate
Root CA
Certificate
Enterprise CA
Certificate
Microsoft Enterprise
Certificate Authority
mgmt01dc01.sddc.local vSphere 6 Platform Services Controller
mgmt01psc01.sddc.local
Signed Signed Signed
VECS
Machine SSL
Solution Users
Certificates
vCenter 6 Server
mgmt01vc01.sddc.local
/etc/vmware/ssl/
ESXi Certificate
ESXi 6.0 Host
mgmt01esx01.sddc.local
Signed
33. Deployment Considerations
VMCA as Enterprise CA Subordinate
– Perform the signing certificate replacement on all Platform Services Controllers to
ensure trusted certificates for all vCenter Server 6.0 installations
• Remember the ‘24 Hour Rule’
– Signing certificate must have a valid date of 24 hours prior before renewing host
certificates or adding new hosts to vCenter
– Plan for this aging period when configuring an existing environment
– Replace certificates prior to putting a new environment into production
33
VMware vSphere 6.0
34. Managing Certificates
• Supports replacing certificates
• No CRL enforcement against PKI for vCenter Server and ESXi hosts
• If you suspect that one of your certificates has been compromised, revoke and
replace all existing certificates, including the VMCA root certificate
• If you do not remove revoked certificates, a man-in-the-middle attack might
enable compromise through impersonation with the account's credentials.
34
VMware vSphere 6.0
35. Upgrades & Auto Deploy
Host Upgrades and VMCA Signed Certificates
– Upgrade process replaces self-signed certificates with VMCA-signed certificates
– vCenter then monitors certificates and displays details vSphere Web Client
Host Upgrades and Custom Certificates
– Custom certificates are retained – even if expired or invalid
– Change vxd.certmgmt.mode to custom to ensure certificates are not replaced accidentally
Update Manager
– Not compatible with the Machine SSL certificate template in vSphere 6.0.
Use the vSphere 5.5 certificate template for Update Manager 6.0
35
36. A Call to Action
Determine the Best Approach for Your Organization.
VMCA
as Root CA
(Default or
Option 4)
VMCA
as Enterprise
CA
Subordinate
(Option 2)
Custom CA
(Option 1 & 5)
Hybrid
(Combination)
36
38. Ryan Johnson
Senior Technical Marketing Manager
@tenthirtyam
Adam Eckerle
Technical Account Manager
@eck79
vmware.com/go/podcast
39.
40. VMware vSphere Certificate Management for Mere Mortals
Ryan Johnson, VMware, Inc
@tenthirtyam
Adam Eckerle, VMware, Inc
@eck79
vmware.com/go/podcast
INF4529
#INF4529
Editor's Notes
Good afternoon. Welcome to VMworld session #INF4529 - VMware vSphere Certificate Management for Mere Mortals. My name is Ryan Johnson. I'm a Senior Technical Marketing Manager with the Integrated Systems Business Unit at VMware - where I focus on the Software-Defined Data Center as we as architectures and enablement for the VMware Validate Designs you've learned about here at the conference.
(To Adam….)
Good afternoon and welcome to VMworld session INF4529 – this is VMware vSphere Certificate Management for Mere Mortals.
Get ready to learn quite a bit about certificates and certificate lifecycle management in vSphere 6.0.
My name is Ryan Johnson. I'm a Senior Technical Marketing Manager with the Integrated Systems Business Unit at VMware - where I focus on the Software-Defined Data Center as we as architectures and enablement for the VMware Validated Designs you've learned about here at the conference.
You can follow me on twitter at @tenthirtyam or on the weekly VMware Communities Podcast at vmware.com/go/podcast.
(To Adam….)
This slide introduces the two new components of certificate management.
The VMware certificate authority also known as VMCA and the VMware endpoint certificates services also known as VECS.
One of the key things to remember is that certificates are now stored within VECS and no longer stored in the filesystem of vCenter. Even if you are using third party certificates you will still need to store them in VECS.
For ESXi the certificates are still stored locally on the host this has not changed.
VMCA provisions each vCenter server and Service with certificates that are signed by VMCA. We will go into further detail in the next couple of slides.
Key take away: VMCA and VECS provide a common platform for managing certificates
Okay. So, Adam's presented you with a primer on the awesome Certificate Lifecycle Management c apabilities we've added in the vSphere 6.0.
Now it’s time we dive a bit deeper. And for that, we're going to discuss the types of certificates used in vSphere 6.0.
(click….)
These are: ESXi Certificates, Machine SSL Certificates, Solutions User Certificates and the Single Sign-On certificates.
Let's get started with ESXi Certificates
(click….) Post-install, an ESXi host will always have an auto generated certificate…
(click….) Now, you'll learn more about ESXi certificate replacement options from Adam a little later on.. but when a host is joined to vCenter Server and the default ESXi certificate replacement is in tact, that is, when the vpxd-certmgmt.mode is set to equal vmca… a host will receive a freshly minted certificate from the VMware Certificate Authority.
(click….) If the mode is set to custom, that is, vpxd.certmgmt.mode is set equal to custom, custom certificates may be used. But keep in mind that custom ESXi certificates will be more exhaustive process. More about that later with Adam.
(click….) These ESXI certificates, either VMCA-issued or custom, are not stored in VECS but rather are stored locally on each host in the /etc/vmware/ssl directory.
(click….) A VMCA-issued certificates can be renewed from either the vSphere Web Client or through PowerCLI.
(click….) Let's take a look at the vSphere Web Client. If you navigate to host and select its Manage > Settings and then locate the Certificate section in the content pane you'll see the…
the certificate subject;
the Issuer - note, that's our Platform Services Controller in our management cluster;
the Valid From and to - note, that by default, ESXi certificate has a validity of 5 years; and
the current status. If the certificate was nearing expiration, the Status would change and an alert would be generated .
(click….)
If you'd rather not perform manual certificate renewal in the vSphere Web Client, then PowerCLI is your friend. Here's an example PowerCLI snippet to illustrate how you can renew a VMCA-issued certificate on a host by running the CertMgrRefreshCertificates_Task.
Later on, Adam will show you... well, we'll just wait for that now won't we... so stick around….
That was ESXi Certificates, now let's move on to Machine SSL Certificates in vSphere 6.0.
(click….) Machine SSL Certificates are used to create a server-side SSL socket.
(click….) This is use to provide both server verification and secure communications channels - for example, over HTTPs or Secure LDAP.
(click….) Each node will have a Machine SSL Certificate. For a vCenter embedded deployment node; where the management and platform services reside together; or an external vCenter deployment model where the management and platform services services reside on their respective management node and platform service controller node.
(click….) All services will use a Machine SSL Certificate for endpoint encryption and all services will (click...) communicate through a reverse proxy….
(click….) as the traffic does not communicate directly with the services themselves.
Now, on let’s move on to Solution User Certificates.
In vSphere 6.0 we've added a lot more services to vCenter Server than seen in prior version, but we've consolidated access to these services behind a set of Solution Users that hold the certificate.
These Solution User certificate are located in VECS on each management node and each embedded deployment.
Let's take a look at the four types of Solution Users and their certificate stores in VECS....
(click….)
The machine Solution User is used by the component manager, license and logging services. Note that the machine solution user certificate has nothing to do with the machine SSL certificate. The machine solution user certificate is used for the SAML token exchange; while the machine SSL certificate is used for secure SSL connections for a machine.
Also note that you will also find that this machine store is also included on each Platform Services Controller node.
(click….)
The vpxd Solution User consolidates the vCenter Service Daemon on management and embedded deployments and uses the certificate to authenticate to vCenter Single Sign-On.
(click….)
The vpxd-extensions Solution User includes Auto Deploy and Inventory Services as well as other services not part of other SUs.
(click….)
Lastly, there's the vsphsre-webclient Solution User that includes the vSphere Web Client and additional services such as performance charts.
(click…)
Recall that these Solution Users are encapsulating one or more vCenter Service services.
(click…)
The certificate is authenticated by vCenter Single Sign-On to issued a SAML token so that it each and every solution user may authenticated to other solution users and services.
(click…)
For example, the vpxd solution user presents its certificate to vCenter Single Sign-On. The vpxd solution user receives a SAML token and then use th at token to authenticate to other solution users and services.
(click…)
Solution users will re-authenticate with SSO either after a reboot or when the configured timeout expires.
(click…)
By default, the Maximum Holder-of-Key Token Lifetime is ~2.6M seconds... that's 30 days by the way. and it can be set in the vSphere Web Client... (click…).... here.
Now on to Single Sign-On Certificates
These include - the
(click…) (click…)
Directory Service SSL Certificate and
(click…)
2) vCenter Single Sign-On Signing Certificate.
These are provisioned during installation, and are not stored in VECS.
(click…)
(click…)
The vCenter Single Sign-On Signing Certificate is the identity provider that issues, validates and renews the SAML tokens that are user for authenticate through vSphere can be manually refreshed in the vSphere Web Client if required (click….) as can be seen in this (click…)
screenshot.
Do not change this certificate in the file system or unpredictable behavior results.
Remember, these certificates are not stored in VECS and…are not managed by any certificate management tools.
And changes are typically nore necessary but in some special corner cases with custom certificates you may need to replace these.
So let's recap.
(click….)
- ESXi Certificates - Provisioned by VMCA after joining vCenter - Stored on ESXi Hosts
- Machine SSL Certificates - Provisioned by VMCA and Stored in VECS
- Solution Users - Provisioned by VMCA and Stored in VECS
- SSO Certificate - Provisioned During Installation - Managed in vSphere Web Client
- Directory Service Certificate - Provisioned During Installation - Changes are typically not necessary but in some speil corner cases with custom certificates you may need to replace these.
There are four certificate replacement options for vCenter.
The first is... VMCA as Root CA:
VMCA provides the Root certificate
All vSphere certificates chain to VMCA.
You can regenerate certificates on demand easily.
And you can add the root certificates to your trusted authorities.
Next is VMCA as Enterprise CA Subordinate: (aka Intermediate)
You replace the VMCA CA certificate with a subordinate CA certificate from the Enterprise CA or commercial CA.
Upon removal of the old VMCA CA certificate, all old certificates will be regenerated.
Third is using a Custom CA
Here you do not use VMCA as a certificate authority.
Instead you provision your own custom certificates for each solution user and machine endpoint
External certificates are stored directly in VECS but the VMCA is not used.
You are responsible for all certificate provisioning and monitoring.
Note that this is a more complicated option and is meant For highly security conscious customers only
And lastly there is a Hybrid approach...
Herd you use a mixed approach.
For example:
VMCA provides the root certificates and issues certificates to ESXi hosts and solution users.
But you Provision your own customer SSL certificates for the endpoints.
This is what one customer called "The best of both worlds”… using certificates that chaing corporate PKI for user-facing services and VMCA certificates to secure the vSphere internal components so we can retain all the VMCA functionality
Of the four options, the easiest method is to use VMCA in default Root CA mode and next, is VMCA as Enterprise CA Subordinate
Please Note: The vSphere 6.0 Certificate Manager and VMCA cannot currently be used to issue certificates to any other Products. Only vCenter Server 6.0 currently integrates with VMCA.
So, how have we make all these certificate replacement options easier? With the vSphere 6.0 Certificate Manager Utility. This utility is essentially a menu-driven Python program that simplfies inteactions with the VMCA and use of 3rd party certificates. There's no need to fumble around with OpenSSL or even VECS CLIs. It even generates your certificate signing requests.
(click…)
Certificate Manager is present on both form vCenter Form Factors on the embedded deployment, management node and platform services controller node:
On the vCenter Server Appliance it's present in: /usr/lib/vmware-vmca/bin/certificate-manager
And on Windows vCenter Server it's present in: <Drive>:\Program Files\VMware\vCenter Server\vmcad\certificate-manager
Now, let's talk about the Common Certifiace Manager Use Cases. Speficially, as it relates to the 4 certificate replacement options.
(click…)
VMCA as Root CA (Leave as Default or Option 4)
This use case is when...
If you have no plan on implementing custom CA certificates signed by either an in-house CA or a Commercial CA.
VMCA will signs, generates and issues certificates and these certificates will then stored by the VMware Endpoint Certificate Store (VECS).
These certificates issued by the VMCA will not be trusted by default but can in imported into your Trusted Root Authorities.
(click…)
VMCA as Enterprise Subordina te CA (Option 2)
This use case is when...
You want to replace the default VMCA certificate and key with a custom CA certificate and key from either an in-house CA or a commercial CA.
VMCA generates and issues new certificates signed by the custom CA certificate and key. These are then stored by the VMware Endpoint Certificate Store (VECS).
These certificates issued by the VMCA will be trusted through the signing authority.
(click…)
Custom CA (Option 1 and 5)
This use case is when..
You want to replace the Machine SSL Certificate and all Solution User Certificates with custom CA certificates signed by either an in-house or a commercial CA.
VMCA is not responsible for issuing the certificates. These are still stored by the VMware Endpoint Certificate Store (VECS).
(click…)
And Hybrid, of course, is a combination therein. For example, you'd like to use replace Machine SSL for end-user facing services on the vCenter Server and PSC but use the VMCA-issued certificates for Solution Users and ESXi.
If you would like to continue use the VMCA as Root CA default, but are like me get eally annoyed by these warning messages and extra clicks, you can avoid the warning messages.
(click…)
Connect to your vCenter Server’s default URL -- in this example http://mgmt01vc01.sddc.local -- and (click….) follow the steps outline in VMware KB 2108294 to download the root certificates and add these to your trusted certificates in your Group Policy(s).
It's worth noting that by default, the VMCA root certificate expires after 10 years, and all certificates that VMCA signs expire when the root certificate expires, that is, after a maximum of 10 years.
If you'd like to use the VMCA as an Enterprise CA Subordinate let's understand the requirements.
Use a Private Key Algorithm of RSA with 2048 bits.
The certificate must be of the X.509 v3 Standard:
The format must be PEM-Encoded (PKCS8 and PKCS1) with a header of ---BEGIN CERTIFICATE---
The recommended signature algorithms are SHA256, SHA384, or SHA512
Also, be cognizant that...
The VMCA does NOT support wildcard cards or SubjectAltName...
While there is no explicit limit to the length of the certificate chain, the VMCA uses the OpenSSL default, which is ten certificates.
VMCA will only issue the certificate types we've discussed and only to those VMware vSphere solutions -- vCenter Server, PSC and ESXi.
Therefore, you cannot create subsidiary CAs of VMCA.
And, of course, you must ensure that time is synchronized for all nodes in environment.
Okay. So, what does the process look like to enable the VMCA as an Enterprise CA Subordinate?
Let's take a look at the workflow of tasks for an external deployment model... (click…)
First we need to create and publish custom subordinate certificate authority template per KB 2112009 (click…)
Then we generate a certificate signing request and key in Certificate Manager with Option 2 (click…)
Note that on VCSA you need to run 'chsh –s /bin/bash root' to allow SCP file transfers. (click…)
Next, we submit certificate signing request – root_signing_cert.csr – to Enterprise Certificate Authority (click…)
We create the full certificate chain – root_n signing_chain.pem (click…)
We Import the full certificate chain and key to replace VMCA root signing certificate in Certificate Manager with Option 2 (click…)
Configure certool.cfg with proper values. (click…)
Restart vCenter services on connected vCenter to reflect the change (click…)
service-control –stop | --start –all (click…)
Replace Machine SSL certificate with VMCA certificate on connected vCenter(s) with Option 3 (click…)
Provide the FQDN or IP of Platform Service Controller (click…)
Configure certool.cfg with proper values. (click…)
Replace Solution User Certificates with VMCA certificates on connected vCenter(s) with Option 6 (click…)
Provide the FQDN or IP of Platform Service Controller (click…)
A CRITICAL NOTE: If you have multiple Platform Services Controllers, you need to perform the signing certificate replacement on all Platform Services Controllers to ensure trusted certificates for all vCenter Server 6.0 installations.
Got all that? :)
Well, you will. Because now it's time for a full demo.
But first, let’s review the scenario for this demo…
This is with regards to ESXi hosts. NOT vCenter Server.
Clarification: This slide is only if you are NOT using VMCA.
ESXi certificate replacement is still the same. There is no VECS on ESXi. Use the certificate manager tool to install 3rd party certs on ESXi.
The certificate manager tool will do the following for you.
Run vecs-cli to add the new certificates to the TRUSTED_ROOTS store, for example:
/usr/lib/vmware-vmafd/bin/vecs-cli entry create --store TRUSTED_ROOTS --alias rbd_cert --cert /etc/vmware-rbd/ssl/rbd-ca.crt
Note: If you decide not to upgrade your hosts to vSphere 6.0 or later, the hosts retain the certificates that they are currently using even if the host is managed by a vCenter Server that uses VMCA certificates.
Auto Deploy:
Signed certificate stored by the Auto Deploy server in its local certificate store and re-used on boot
If VMCA is not available then the a stateless host will cycle through shutdown and reboot until VMCA is available
VMCA as Root CA – Self-Signed and Trusted (Uses VECS)
VMCA as Enterprise CA Subordinate – Full Chain to Root CA (Uses VECS)
Custom CA – Least Desirable, More Exhaustive Choice (Requires VECS)
Hybrid – 3rd Party for Machine SSL; VMCA for Solutions User (Yep, Also Requires VECS)
VMCA as Root CA (Option 4)
No plan on implementing custom CA certificates signed by either an in-house CA or a Commercial CA.
VMCA signs, generates and issues certificates. These stored by the VMware Endpoint Certificate Store (VECS).
These certificates issued by the VMCA will not be trusted by default.
VMCA as Enterprise Subordinate CA (Option 2)
Replace the default VMCA certificate and key with a custom CA certificate and key from either an in-house CA or a commercial CA.
VMCA generates and issues new certificates signed by the custom CA certificate and key. These stored by the VMware Endpoint Certificate Store (VECS).
These certificates issued by the VMCA will be trusted.
Custom CA (Option 5)
Replace the Machine SSL Certificate and all Solution User Certificates with custom CA certificates signed by either an in-house or a commercial CA.
VMCA is not responsible for issuing the certificates. These are still stored by the VMware Endpoint Certificate Store (VECS).
And that folks, is VMware vSphere Certificate Management for Mere Mortals.
We hope you’ve learned a lot about certificates and their management in vSphere 6.0.
But before you go, we want to leave you with this….
(click…)
Go to vmware.com/go/inf4529 to access this presentation, the full demo videos that you saw plus a demo on vRealize Operations certificate management, as well as the PowerCLI and PowerActions scripts to refresh VMCA-issued certificate on a host or an entire cluster.
On behalf of Adam and myself, thanks for making this an awesome session. We hope you’ve enjoyed it and learned a lot – have a safe trip home!
Good afternoon. Welcome to VMworld session #INF4529 - VMware vSphere Certificate Management for Mere Mortals. My name is Ryan Johnson. I'm a Senior Technical Marketing Manager with the Integrated Systems Business Unit at VMware - where I focus on the Software-Defined Data Center as we as architectures and enablement for the VMware Validate Designs you've learned about here at the conference.
(To Adam….)
Good afternoon and welcome to VMworld session INF4529 – this is VMware vSphere Certificate Management for Mere Mortals.
Get ready to learn quite a bit about certificates and certificate lifecycle management in vSphere 6.0.
My name is Ryan Johnson. I'm a Senior Technical Marketing Manager with the Integrated Systems Business Unit at VMware - where I focus on the Software-Defined Data Center as we as architectures and enablement for the VMware Validated Designs you've learned about here at the conference.
You can follow me on twitter at @tenthirtyam or on the weekly VMware Communities Podcast at vmware.com/go/podcast.
(To Adam….)