Troubleshooting intermittent MC load failures

Troubleshooting errors when switching from UC to MC.

This topic provides information about troubleshooting errors when you switch from UC to MC.

Overview

You might intermittently encounter certificate validation errors when returning to Management Console (MC) after navigating away from UC. The issue does not occur during a new log in session. The UI fails to load even when the main page appears to load successfully. The MC server certificate is both self-signed and missing a Subject Alternative Name (SAN) extension. These certificate issues cause browsers to reject fresh TLS connections, resulting in inconsistent application behavior.

Issue summary and resolution

Issue Workaround
Users intermittently received ERR_CERT_AUTHORITY_INVALID when accessing MC. Use a properly configured certificate instead of a self-signed certificate and ensure that clients trust the certificate.
Certificate does not contain a Subject Alternative Name (SAN) extension. Generate a new certificate that includes the appropriate SAN entry for the server IP address and/or hostname.
Google Chrome and other browsers reject the certificate with ERR_CERT_COMMON_NAME_INVALID. Ensure that the SAN field contains the exact hostname or IP address used to access MC. Modern browsers validate SAN entries rather than relying solely on the Common Name (CN).
The issue appears intermittent rather than occurring on every request. Deploy a SAN-compliant certificate and restart MC. This ensures that all TLS connections validate successfully, including background asset requests.
Manual selection of Proceed anyway. Replace the certificate instead of relying on browser exceptions. Browser exceptions may apply only to specific connections and do not reliably cover all background requests.
Existing keystore Inspect the keystore, back it up, create a new certificate with SAN attributes, remove the outdated certificate, and restart MC.
Clients continues to use previously imported certificates. Remove obsolete certificates from the browser or operating system trust store and import the updated certificate.
Certificate replacement failed or caused unexpected issues. Restore the original keystore.jks backup and restart the MC service.

Troubleshooting steps

  1. Identify the MC Keystore. The default MC keystore location is /opt/vconsole/config/keystore.jks.
  2. Inspect the existing certificate. Check whether the certificate is self-signed and includes a SAN extension. 
        keytool -list -v -keystore /opt/vconsole/config/keystore.jks -storepass password | grep -A2 "SubjectAlternativeName\|Owner\|Issuer"
  3. Backup the existing keystore. Before making any changes, create a backup. 
        cp /opt/vconsole/config/keystore.jks  /opt/vconsole/config/keystore.jks.bak
  4. Generate a New SAN-enabled certificate. Create a new key pair and include the required SAN entry. 
        keytool -genkeypair /-alias mc-new /-keyalg RSA /-keysize 2048 /-validity 3650 /-keystore /opt/vconsole/config/keystore.jks -storepass password -keypass password -dname "CN=<machine_ip>, OU=Vertica, O=Vertica, L=Cambridge, ST=Massachusetts, C=US" \-ext "SAN=IP:<machine_ip>"
  5. Remove the old certificate entry. Delete outdated certificates from the keystore. 
        keytool -delete -alias <old_alias> -keystore /opt/vconsole/config/keystore.jks -storepass password
  6. Restart the MC service. Restart MC so that it loads the updated certificate.
  7. Verify the SAN configuration. Confirm that the server presents a certificate with the expected SAN field. 
        echo | openssl s_client -connect <mc_server_ip>:5450 -showcerts 2>/dev/null \ openssl x509 -noout -text \| grep -A1 "Subject Alternative Name"
  8. Update the client Trust Stores. If users previously imported the old certificate:
    1. Reimport the new certificate.
    2. Restart the browser if necessary.

Future behavior

In newer MC releases that include updated certificate-generation components, SAN information is expected to be a required certificate field during certificate creation. Users only need to trust the generated certificate if it is not signed by a public CA. No additional certificate modifications will be required.

Recovery procedure

If certificate replacement is unsuccessful:

  1. Restore the backup keystore. 
    cp /opt/vconsole/config/keystore.jks.bak /opt/vconsole/config/keystore.jks
  2. Restart the MC service.

After deploying a certificate that contains valid SAN entries and is trusted by client systems, all TLS connections validate consistently. This includes both page navigation requests and background asset requests. As a result, users no longer encounter intermittent certificate validation errors, and MC loads reliably without requiring manual Proceed anyway action.