Troubleshooting

If you have a problem with the Frontal module, please contact us and provide all of the following:

• Logs
• How to reproduce the issue
• Reference if needed

Logs

Frontal logs can be found at %Installation Directory%/frontalweb/dist/daemon/logs/.

These files contain revelant information:

• zetalyfrontal.err.log
• zetalyfrontal.out.log
• zetalyfrontal.wrapper.log

If you are able to reproduce your issue, before sending us the logs file.

Certificate

In general, it is recommended to use a trusted SSL certificate from a trusted Certificate Authority (CA) to secure your website. This will help prevent SSL errors and provide a higher level of security for your website visitors. It is important to note that using an SSL/TLS certificate with incorrect SANs can leave your connection vulnerable to interception or impersonation attacks, so it is recommended to use a properly configured certificate to ensure the security of your connection.

Problem encountered	Reason	Screenshot	Resolution
ERR_CERT_COMMON_NAME_INVALID	Your site has a self-signed SSL certificate installed and your browser does not recognize it as valid or secure.		Regenerate the certificate: You can generate a new self-signed certificate and make sure that the common name (CN) matches the domain name you are using to access the website.
ERR_CERT_COMMON_NAME_INVALID	Use the correct domain name: Make sure you are using the correct domain name to access the website. If you are using a different domain name, the certificate will not match and you will get the "ERR_CERT_COMMON_NAME_INVALID" error.		Regenerate the certificate: You can generate a new self-signed certificate and make sure that the common name (CN) matches the domain name you are using to access the website.
ERR_CERT_COMMON_NAME_INVALID	You tried to switch your website to HTTPS without first installing an SSL certificate. Your antivirus software is blocking your SSL connection. A browser extension is interfering with your site’s SSL connection. Your proxy settings are misconfigured. Your browser cache or SSL state has become corrupted.		Add an exception to your browser: You can also add an exception to your browser to ignore the SSL error and access the website anyway. However, this is not recommended as it can compromise your security.
"This server could not prove that it is [IP Address]; its security certificate does not specify Subject Alternative Names. This may be caused by a misconfiguration or an attacker intercepting your connection" indicates that the SSL/TLS certificate being used by the server does not include Subject Alternative Names (SANs) that match the IP address used to access the server.	This error can occur when a self-signed certificate is used, or when a certificate from a trusted Certificate Authority (CA) is used but is not properly configured with the correct SANs.		Regenerate the certificate with the correct SANs: If you have control over the server, you can generate a new SSL/TLS certificate and ensure that the SANs include the IP address being used to access the server. Obtain a new SSL/TLS certificate from a trusted CA: If you obtained the certificate from a CA, contact the CA and request a new certificate with the correct SANs. Temporarily bypass the error: If you need to access the server immediately, you can temporarily bypass the error by adding a security exception to your browser. However, this is not recommended as it can compromise your security.

To generate a new SSL/TLS certificate with the correct Subject Alternative Names (SANs), you can follow these general steps:

• Generate a private key: You can generate a new private key using a tool such as OpenSSL. This key will be used to generate the certificate signing request (CSR). Here is an example command:

openssl genpkey -algorithm RSA -out [private_key_file_name].key -aes256

• Generate a CSR: Once you have a private key, you can generate a CSR that includes the correct SANs. Here is an example command:

openssl req -new -key [private_key_file_name].key -out [csr_file_name].csr -config san.cnf

Note that you will need to create a configuration file (e.g. san.cnf) that includes the SANs you want to include in the CSR. Here is an example configuration file:

[req]
distinguished_name = req_distinguished_name req_extensions = req_ext prompt = no 
[req_distinguished_name]

[req_ext]
subjectAltName = @alt_names 
[alt_names]
IP.1 = [IP address]
DNS.1 = [domain name]

• Replace [IP address] and [domain name] with the appropriate values.
• Submit the CSR to a trusted CA: Once you have a CSR with the correct SANs, you can submit it to a trusted CA to obtain a new SSL/TLS certificate. The exact process for doing this may vary depending on the CA you are using.
• Install the new certificate: Once you have obtained the new SSL/TLS certificate, you can install it on your server. The exact process for doing this may vary depending on your server configuration and the software you are using.

After completing these steps, you should have a new SSL/TLS certificate with the correct SANs that can be used to secure your server.