macOS Catalina and Chrome Trust

Those of you who live on the bleeding edge of device and software updates were thrilled Monday morning for the release of the latest macOS update - Catalina.

After excitedly clicking the update button, and waiting through the download and restart, you dove in and started exploring.

Once the shininess started to wear off, and you settled in for real work, like opening Google’s Chrome Browser and logging in to your VMware vSphere instance to check on a Virtual Machine, you noticed you were actually not able to login at all.  In fact, you were greeted by the usual warnings about trusted certificates, but this time, with no way around - the trusty “Proceed to … (unsafe)” was missing!

connection is not private alert

Desperately needing to check on that Virtual Machine, you immediately turned to Firefox or - wanting to go straight to the source - Safari, only to find out that all was well, you could avoid the error, and you were able to login without issue.

Feverishly, you performed some searches to hopefully unveil the cause, when you stumbled on new Requirements for trusted certificates in iOS 13 and macOS 10.15 from Apple.  You noticed the usual - 2048-bit key sizes, SHA-2, matching DNS records - nothing out of the ordinary there.  But you also noticed some new requirements, and ignoring those for a moment, that they are only applicable to certificates issued after July 1, 2019.

Now curious, you realized the vSphere instance you were visiting was newly installed, and turned to an older and wiser vSphere instance.  To your surprise, or chagrin, the page loads as usual.

So what happened?

Well, it would seem that sites with non-compliant certificates are more affected by these more strict time-based requirements when visited in Chrome than they are when visited in Firefox or Safari.  Unfortunately, the only way around this is to replace the non-compliant certificates with ones that meet the new requirements. The two requirements that seem to be causing our issues are:

  • Certificates must contain the Server Authentication Extended Key Usage attribute
  • Certificates must be valid for no more than 825 days.

The most flexible way of doing this is to generate new, certificates, so that we can have control over every element of the certificate, rather than rely on the VMware Certificate Authority.  In order to do this, we also create our own self-signed CA certificate. Finally, the new certificates are uploaded to vSphere, adding to the Trusted CA Store, and replacing the currently in use certificate.

What follows now is a rough step-by-step outline of the process, which will hopefully help.

  1. Obtain a new version of openssl.cnf from github [Link]
    • You may choose to modify some of the defaults for some of the fields, countryName, state, etc, for example.
  2. Generate an additional extensions file for the attributes required by Apple and VMware, containing the following:
req_extensions = v3_req

[ v3_req ]

# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
extendedKeyUsage = serverAuth
DNS = <your FQDN>
email = <your admin email>
  1. Generate a self-signed CA, using this new configuration

mkdir -p rootCA/{certs,private}
chmod 700 rootCA/private/
openssl req \
    -x509 -sha256 -days 800 -newkey rsa:2048 \
    -config openssl.cnf \
    -keyout rootCA/private/rootCA.key -out
openssl x509 -in rootCA/rootCA.crt -text -noout
  1. Generate a new Machine Cert from our new CA
openssl req \

    -config my-openssl.cnf \
    -nodes \
    -sha256 -days 800 -newkey rsa:2048 \
    -keyout machine-cert/vsphere.key \
    -out machine-cert/vsphere.csr

openssl x509 \
    -req -days 800 \
    -extensions v3_req \
    -extfile ext-openssl.cnf \
    -CA rootCA/rootCA.crt \
    -CAkey rootCA/private/rootCA.key \
    -CAcreateserial \
    -in machine-cert/vsphere.csr \
    -out machine-cert/vsphere.crt
  1. Login to vSphere
    • Login as administrator@vsphere.local
    • Navigate to Menu -> Administration
    • Select “Certificate Management”
    • Login again to “localhost” with adminstrator@vsphere.local
  2. Under “Trusted Root Certificates”
    • Select Add
    • Select “rootCA/certs/rootCA.crt” for Certificate Chain
    • Select “rootCA/private/rootCA.key” for Private Key
  3. Under “Machine SSL Certificate”
    • For __MACHINE_CERT, Click “Actions->Replace”
    • Select “vsphere.crt” for Certificate Chain
    • Select “vsphere.key” for Private Key
    • Click Replace
  4. Restart all vSphere Services - There may be a less invasive method, but this seemed to work for us
    • Login via ssh to vCenter Appliance as root
    • Issue Stop/Start Commands
service-control --stop --all
service-control --start --all

Once everything comes back online, you should now be able to login to vSphere with Chrome on macOS Catalina

vSphere Client

trusted root certificates

We have all had to navigate updates so hopefully this guide will make your update a little more smooth this time around.