(Day 7 of 22 in our Cybersecurity Awareness Month series. Today: certificates)
Certificates generate more questions than almost any other security topic we cover. We find that most of those questions come from misunderstandings about what certificates do. The biggest one is that a certificate means you can trust something. Truth is, it mostly means the connection is encrypted.
A certificate does two things. It helps two computers encrypt what they say to each other, and it’s good at that. It also makes a claim about who is on the other end, and whether that claim is true depends on people a lot more than on technology.
What Certificates Do
Many certificate questions come from not knowing what a certificate is for, so we’ll start there.
How Do You Exchange Keys With Someone You Don’t Know?
To encrypt a conversation, both sides need to share a secret key. That is easy if you can meet first and agree on one. Computers on a network usually can’t.
Public-key cryptography solves this. Each side creates two related keys, a private key and a public key. You keep the private key to yourself, and you can hand the public key to anyone. A message encrypted with your public key can only be decrypted with your private key. Problem solved, as long as the other side can find your public key.
What Is Inside a Certificate
The remaining problem is finding the other side’s public key. That is what a certificate carries. Transport Layer Security (TLS), the protocol that secures network connections, reads the public key from the certificate the server presents.
A certificate also carries the server’s names, the organization, the issue and expiration dates, and the name of the certificate authority (CA) that issued it. The CA adds a digital signature, which lets anyone check that nobody altered the certificate.
Certificates Are Not Trust
The CA’s signature was meant to do more than protect the certificate. It was meant to vouch for the owner. The idea is that you trust the CA, so you can trust what the CA signed.
Encryption Without Trust
In practice it is not that simple. Anyone who controls a domain name can get a certificate within minutes, often at no cost. That has been very good for the internet, because it put encryption on a huge number of web sites.
It also means a certificate says little about who you are dealing with. A personal blog gets a certificate, and so does a small business. But malware sites and ransomware gangs get them, too. All of those connections are encrypted. Whether you should trust what is on the other end is a separate question, and the certificate does not answer it.
A Browser Warning Is an Opinion
Your browser decides whether to warn you by checking the certificate against a list of CAs. That list ships with the browser or the operating system, and it is long. Anyone with administrative access to your computer can add to it.
So when a browser shows no warning, it is saying that the connection is encrypted and that a CA on its list signed the certificate. It is not saying the application is safe. When a browser does show a warning, the connection may still be encrypted properly. Something about the certificate did not match what the browser expected.
A warning is still useful. It can be a hint that something is misconfigured or wrong. Treat it as a hint and find out why it appeared.
This is also one of the main places where security and compliance diverge. A compliance framework may require encrypted network connections. Some organizations read that as “no browser warnings,” and those are different goals.
People Establish Trust
In VMware Cloud Foundation (VCF), the people who run the environment establish trust. When you add a host, you are asked to confirm that it is the host you expect, using the SHA-256 fingerprint. When you approve, you are vouching for it. Encryption is automated, but trust is a decision that somebody makes.
It also helps to ask who needs to trust a management interface at all. Only your administrators should be able to reach it. If 100,000 employees need to trust a certificate, you have a hard distribution problem. If ten administrators do, the problem is small. Besides, you should have access controls and firewall rules preventing 100,000 employees from even being able to reach the management interfaces.
How VCF Uses Certificates
VCF encrypts its management connections with TLS, which means it uses a lot of certificates. Every VMware ESX host has one. VMware vCenter has several, and so do the other components. Even though appliance services are behind a reverse proxy, it is still too many to manage by hand, not to mention coordinate timing for replacement. As such, VCF automates it.
The VMware Certificate Authority
The VMware Certificate Authority (VMCA) is built into vCenter. It is just enough of a CA to issue and renew the certificates inside your environment, and it is not a general-purpose CA. Its root certificate is created when you install vCenter, so it is unique to you, even though the name on it says “VMware Engineering” and such (you can change that if you replace the CA root).
This causes friction with public key infrastructure (PKI) teams, because they have a checklist for what a CA does (usually the checklist they, themselves, are judged on). The VMCA has no certificate revocation list (CRL), for example. It doesn’t need one, because people manage the trust. To revoke a host’s certificate, you remove the host.
Four Ways to Run It
- Fully automated: This is the default. The VMCA issues and renews everything, and administrators import its root certificate into their own browsers if they want the warnings to stop.
- Hybrid: The VMCA still automates the certificates inside the environment. You replace only the certificate that people see when they log in, using one from a CA your browsers already trust.
- Intermediate/Subordinate CA: Your enterprise CA signs the VMCA’s certificate, so everything the VMCA issues is trusted wherever your enterprise CA is. This can scale well. PKI teams often object, because the VMCA can then issue certificates in the organization’s name. A good compromise might be a separate CA for infrastructure, apart from the main enterprise one. Administrators keep the automation, and the PKI team keeps the infrastructure certificates apart from the rest of the organization’s.
- Fully custom: You turn the automation off and manage every certificate yourself. This is a lot of work; we strongly suggest using the automation instead.
Managing Certificates Across the Fleet
In VCF 9.1, certificate management lives in one place, in VMware Cloud Foundation Operations (VCF Operations). From there you can see the certificates you are responsible for across the fleet, with their expiration dates, their chains, and their renewal status.
You can renew or replace certificates in bulk, and you can sign them with the VMCA inside vCenter, Microsoft Active Directory Certificate Services (AD CS), or OpenSSL. Certificates can renew automatically. When you import a certificate, VCF Operations checks that it matches the signing request the component generated, which helps catch a common mistake before it causes an outage.
Some components manage their own internal certificates. VCF Operations raises an alert if one of those fails to renew. There are public APIs for all of this.
Network Encryption Is More Than Certificates
A certificate identifies a server and starts the encryption. The strength of the encryption comes from the TLS version and the cipher suites the two sides agree on.
You do not need to edit individual services to control those. ESX and vCenter use TLS profiles, which set the TLS parameters and ciphers in one place. The default profile is named COMPATIBLE, and ESX 9.0+ added a profile that allows only TLS 1.3. If an auditor asks you to disable older protocols or ciphers, choose a stricter profile. Before you do, check that everything that connects to VCF supports it, including backup and monitoring systems.
The Security Configuration Guide has guidance for configuring TLS profiles. You can find it in our GitHub repository at: https://github.com/vmware/vcf-security-and-compliance-guidelines
What to Do About Certificates
Use the automation. Replacing certificates by hand takes staff time and invites mistakes, both for the VCF admins as well as the PKI admins. The time is often better spent on patching and access control, which usually do more for your security. If it’s a choice between patching systems and changing certificates, patch first.
Only administrators care about management interface certificates. This should be a small group. Limit who can reach the management interfaces. Fewer people then need to trust those certificates, and every certificate decision gets easier.
Talk to your PKI team early. Explain that you want to meet corporate policy with as little manual work as possible, and ask for their help. A dedicated CA root for infrastructure might give administrators the automation and give the PKI team the isolation it wants. Having the PKI team sign the VMCA root certificate, which is the subordinate CA mode described above, is another option. The PKI team gets certificates the organization trusts, and VCF administrators keep the automation. The guide linked in the FAQ below walks through it. By the way, these techniques can help manage certificate complexity in other IT infrastructure systems, too.
Plan for shorter lifetimes. The CA/Browser Forum sets the rules for publicly trusted certificates, and it is shortening how long they can last. The maximum is 200 days as of March 15, 2026, 100 days as of March 15, 2027, and 47 days as of March 15, 2029. Those rules don’t bind a private CA, but expectations tend to follow them. Nobody wants to replace certificates by hand every few weeks.
Watch expirations. Expired certificates take things down, usually at a bad time. Turn on automatic renewal where you can, and use the alerts in VCF Operations for the rest.
Test before you replace. Try a replacement in a test environment first (remember that ESX and vCenter can be deployed as VMs, which makes a great test environment). Take a backup or a snapshot before you change a certificate in production. Broadcom support is excellent, but it’s usually easier to revert a snapshot than to call. Stagger bulk replacements, because each one can trigger components to re-establish trust with each other. Work through VCF Operations which understands these relationships.
Check what connects. After you replace a certificate, confirm that the systems that connect to VCF still work. Backup and monitoring systems are important ones to check right away.
Frequently Asked Questions About Certificates
Q1: My browser says a newly installed vCenter is “not secure.” Is it?
A1: The connection is encrypted. The warning appears because the certificate was created at install time and no CA on your browser’s list signed it. You decide whether to trust it. If you import the VMCA root certificate into your browser, the warning stops.
Q2: Where is the VMCA’s certificate revocation list?
A2: There isn’t one. People manage the trust in VCF, so you revoke a certificate by removing the component from the environment. All a CRL would do here is add complexity, and we like removing complexity.
Q3: Do organizations in regulated industries use the VMCA?
A3: Yes, many do. The automation saves staff time and reduces human error for administrators, PKI staff, and auditors alike.
Q4: Can I use the VMCA to issue certificates for other things, like a web site?
A4: Technically yes, but it is not meant for that. This might be a good place for a short written policy. Agree with your PKI team that infrastructure administrators issue certificates only as part of the built-in automation, for their own management interfaces. They can verify your compliance with their scanners, after all.
Q5: My PKI team does not like intermediate CA/subordinate CA mode. What now?
A5: VCF administrators need some level of automation inside the environment, and a PKI team needs to understand that. Start there, and then offer options. You might ask them to build a separate CA for infrastructure, or build one with them. That can give you the automation and give them the isolation they want.
Q6: Can I use a wildcard certificate?
A6: No. VCF components check the names in a certificate as part of establishing trust, and a wildcard certificate does not name a specific system.
Q7: Can we put a passphrase on the private keys?
A7: No. Services need to start without a person typing a passphrase, or the environment could not recover from a restart unattended.
Q8: My auditor wants older TLS versions and ciphers turned off. How do I do that?
A8: This is a good idea. Use a TLS profile, as described above, and follow the Security Configuration Guide when you configure it. Test it first, because older third-party tools in your environment that connect to VCF may stop working.
Q9: Can I change the organization and location details on the certificates the VMCA issues?
A9: Yes. vCenter has advanced settings, named vpxd.certmgmt.certs.cn.*, that set the country, state, locality, organization, organizational unit, and email address the VMCA puts on certificates. Set them before you renew or replace certificates. Afterward, refresh the CA certificates on your ESX hosts and renew the host certificates, so they pick up the new details. Our guide to subordinate CA mode has the steps:
Q10: What do you recommend overall?
A10: Don’t make this harder than it needs to be. Spend time on certificates only where it improves security. Administrators, PKI teams, and auditors are on the same team, and each of them worries about things the others have not had to think about. Work it out together.
Discover more from VMware Cloud Foundation (VCF) Blog
Subscribe to get the latest posts sent to your email.