When a cluster is made through the openshift-deployment and the new ocp_common_deployment, the first time you try to access the web console, there are several certificate errors thrown. It does not block any functionality but should be addressed if possible.

According to AI, here is the solution. Option 2 is a workaround so that will not work. Option 1 requires the network admin to provide a cert and for the user to manually import it. Option 3 requires the server (red-chesterfield.com?) admins to take action.

You get the net::ERR_CERT_AUTHORITY_INVALID error when your web browser doesn't trust the authority (Certificate Authority or CA) that issued a website's security certificate. This usually happens in one of three scenarios:

Self-Signed Certificates: The website uses a certificate it generated itself, which no public CA validates.

Internal/Corporate CAs: The website uses a certificate issued by a CA that is trusted within a private network (like a company or government agency) but isn't included in the public trust stores used by your browser (e.g., Google, Apple, Microsoft).

Expired or Mismatched Certificates: Less commonly, the certificate is expired, revoked, or issued for the wrong domain.

Here are the most common ways to resolve this error, organized from the most secure to the least secure.

1. The Correct Resolution: Import the Trust Certificate
If the website belongs to your organization or you know the certificate is legitimate (Scenario #2 or #1), the permanent fix is to import the issuing CA's certificate into your operating system's or browser's Trust Store. This tells your browser to explicitly trust any certificate signed by that specific authority.

Steps (General)
Obtain the CA Certificate: Get the .cer, .crt, or .pem file for the issuing Certificate Authority from your network administrator or the system owner.

Import to OS/Browser:

Windows/macOS: Search your system settings for "Manage Computer Certificates" (Windows) or use the Keychain Access utility (macOS). Import the CA certificate into the Trusted Root Certification Authorities store.

Chrome/Edge: Go to Settings, search for "Manage Certificates", and import the CA certificate into the "Trusted Root Certification Authorities" tab.

Firefox: Go to Settings > Privacy & Security > Certificates > View Certificates > Authorities.

2. The Temporary/Manual Bypass (Insecure)
If you need immediate access and are certain the site is safe, you can often manually bypass the warning, although this should be avoided, especially on public Wi-Fi.

Steps (Browser-Specific)
Chrome/Edge: When you see the "Your connection is not private" screen, look for the "Advanced" button. Click it, and then look for a link at the bottom that says, "Proceed to [domain] (unsafe)".

Firefox: Click "Advanced" and then "Accept the Risk and Continue".

3. The Server-Side Resolution (For Website Owners)
If you control the server, this error indicates a problem with the certificate chain:

Install Intermediate Certificates: Ensure your web server configuration (e.g., Apache, Nginx) includes all intermediate CA certificates provided by your issuer. Browsers rely on these intermediates to build a complete chain of trust back to a publicly trusted root.

Renew or Reissue: If the certificate is expired or issued for the wrong domain, you must renew or reissue it from a publicly recognized CA (e.g., Let's Encrypt, DigiCert, etc.).

Update Root CA: If you run an internal network, ensure all client systems have the latest version of your Internal Root CA certificate installed.