Quickstart

First, create your key and your CSR (Certificate Signing Request). In the following example, we are creating a CSR for our vCenter host, “vcenter-80.nono.io”:

CN=vcenter-80.nono.io # "CN" is the abbreviation for "Common Name"
openssl genrsa -out $CN.key 3072
openssl req \
  -new \
  -key $CN.key \
  -out $CN.csr \
  -sha256 \
  -subj "/C=US/ST=California/L=San Francisco/O=nono.io/OU=homelab/CN=${CN}/emailAddress=brian.cunnie@gmail.com" \
  -config <(cat <<EOF
[ req ]
distinguished_name = req_distinguished_name
req_extensions     = req_ext
[ req_distinguished_name ]
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1   = ${CN}
EOF
)

You’ll have two files, vcenter-80.nono.io.key and vcenter-80.nono.io.csr.

Extra credit: double-check your CSR at GoDaddy. It’s important that your “Subject Alternative Names” matches your hostname (e.g. “vcenter-80.nono.io”).

Acquire a certificate for your host from a Commercial CA. In our example, we acquired a certificate for our host vcenter-80.nono.io from SSls.com, and we purchased their least-expensive offering, the PositiveSSL 1 domain Comodo SSL.

[We do not endorse either SSLs.com or Sectigo (formerly Comodo); We encourage you to use the reseller and the Certificate Authority (CA) with which you are most comfortable].

SSLs.com sends us two files, vcenter-80.nono.io.crt and vcenter-80_nono_io.ca-bundle

Do the following:

  • On your vCenter, navigate to Menu → Administration → Certificates → Certificate Management
  • On the __MACHINE_CERT tile, click Actions, select Import and Replace Certificate.
  • Select Replace with external CA certificate(requires private key).
    • Machine SSL Certificate: click Browse File and select vcenter-80.nono.io.crt
    • Chain of trusted root certificates: click Browse File and select vcenter-80_nono_io.ca-bundle
    • Private Key: click Browse File and select vcenter-80.nono.io.key
  • Click Replace.

The change should take effect immediately, though it may take a minute for the website to be ready.

If you get errors such as “Please provide the strong signature algorithm certificate”, then refer to the Troubleshooting section below.

Troubleshooting

Error occurred while fetching tls: Provided certificate using the weak signature algorithm. Please provide the strong signature algorithm certificate

I encountered this error, and to fix it I had to edit the CA Bundle (certificate chain) and replace a cross-signed root certificate with a self-signed root certificate. Here’s the CA Bundle that I used and that worked for me.

Technical details: Sectigo included a variant of their root certificate “USERTrust RSA Certification Authority” that had been cross-signed (issued) by the old “AAA Certificate Services” which had been self-signed with the weak SHA-1 algorithm, which Google and others have been deprecating since 2016.

Sectigo has another variant of that same root certificate “USERTrust RSA Certification Authority”, which is self-signed with the strong SHA-384 algorithm. This is the variant you should use.

Renewal / Replacement of machine SSL certificate failed on vcenter-80.nono.io (Review)

We experienced this banner when updating our certificate. Upon examination, we noticed our vCenter 8.0.2 had the new certificate (based on the expiration date). We logged into https://vcenter-80.nono.io:5480 and selected Actions → Reboot. Then, when we logged back into our vCenter after reboot, our vCenter showed, under Summary → Issues and Alarms “Certificate Status”. We selected Actions → Reset To Green.

Error occurred while fetching tls: The provided MACHINE_SSL certificate and provided private key are not valid.

The private key doesn’t match the certificate. Here are two ways it happened to me:

  1. I had vCenter generate the CSR on my behalf, and Sectigo took so long to issue the certificate that I thought something went wrong and I had vCenter generate a new CSR, not realizing that would trigger a new key, but by then Sectigo came through with the certificate for the old CSR, and I didn’t realize that the certificate didn’t match the key.
  2. I reissued the certificate, but the .zip file from Sectigo had the old vcenter-80.nono.io certificate in it. The fix: I cut-and-paste the one from the email content instead (I didn’t use the wrong certificate from the .zip file).

How to Determine if a Certificate is a Self-Signed Certificate

To determine if a certificate is a self-signed certificate, confirm the subject is the same as the issuer. In the following example, we use two common TLS command line tools (cfssl and openssl).

First we use cfssl, whose output is JSON, which we pipe to jq to extract the Common Name of the issuer and subject and the signature algorithm. We choose the problematic certificate (“USERTrust RSA Certification Authority”) that has been signed by a root cert that in turn is self-signed with the weak SHA-1 algorithm (“AAA Certificate Services”):

curl https://crt.sh/?d=1282303295 | \
  cfssl certinfo -cert - | \
  jq -r '{"Issuer": .issuer.common_name, "Subject": .subject.common_name, "Signature Algorithm": .sigalg }'

produces:

{
  "Issuer": "AAA Certificate Services",
  "Subject": "USERTrust RSA Certification Authority",
  "Signature Algorithm": "SHA384WithRSA"
}

Now let’s look at its issuer’s (“AAA Certificate Services”) certificate, which is a root certificate, and which is self-signed with the weak SHA-1 algorithm:

curl https://crt.sh/?d=331986 | \
  cfssl certinfo -cert - | \
  jq -r '{"Issuer": .issuer.common_name, "Subject": .subject.common_name, "Signature Algorithm": .sigalg }'

produces:

{
  "Issuer": "AAA Certificate Services",
  "Subject": "AAA Certificate Services",
  "Signature Algorithm": "SHA1WithRSA"
}

Aha! That’s our smoking gun: “SHA1WithRSA” is the culprit, the reason we’ve been getting the “Provided certificate using the weak signature algorithm” error.

Let’s explore the self-signed variant (the root certificate variant) of the “USERTrust RSA Certification Authority”, this time with openssl. We can use a simple egrep to extract the information we need:

curl https://crt.sh/?d=1199354 | \
  openssl x509 -noout -text | \
  egrep "Issuer:|Subject:|Signature Algorithm:"

produces:

Signature Algorithm: sha384WithRSAEncryption
Issuer: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
Subject: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
Signature Algorithm: sha384WithRSAEncryption

(We don’t know why “Signature Algorithm” is repeated).

We can see that this is a self-signed root certificate with a strong, SHA-384 signature algorithm. This is the root certificate we should use in our certificate chain (CA bundle).

References

Corrections & Updates

2023-10-28

Included new error messages & resolutions.

2023-01-05

We mistakenly told users to upload the CA bundle when they should have uploaded the key. Thanks @obsidianindy.

2022-11-05

Expanded the “How to Determine if a Certificate is a Self-Signed Certificate” section to include the signature algorithm, and included the problematic root cert to drive home the cause of the error.