Browser error : net::err_cert_common_name_invalid

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: aiimmaglobal.com

I ran this command: sudo yum install certbot python3-certbot-nginx -y & certbot --nginx

It produced this output: Certificate successfully installed but all browsers are giving errors NET::ERR_CERT_COMMON_NAME_INVALID

My web server is (include version): NGINX

The operating system my web server runs on is (include version): Redhat Linux

My hosting provider, if applicable, is: AMAZON AWS

I can login to a root shell on my machine (yes or no, or I don't know): YES

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): NO

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 1.22.0

1 Like

The website https://aiimmaglobal.com/ is working perfectly from my point of view.

Please share e.g. a screenshot of the browser with the error.

2 Likes

Thank you very much Osiris for your quick respond and i so much appreciate. The website is ONLINE but the first attempt of every browser to the same would show that the SSL Certificate is invalid with the NET::ERR_CERT_COMMON_NAME_INVALID error on the browser until you tell the browser to proceed anyway from the option.

The main error is that in my programming the frontend is making request to my backend and they are both https i.e the frontend is HTTPS(https://aiimmaglobal.com) and the backend server that the frontend calls is HTTPS as well and it uses the same Letsencrypt SSL certificate that the frontend uses but the browser cannot validates the SSL Certificates as it shows NET::ERR_CERT_COMMON_NAME_INVALID so it threw CORS(Request Did Not Succeed) errors and after I investigated the error I saw that it is certificate issue because I saw from the browser that the certificate is not valid.

Please help on how I can rectify this.

1 Like

As I said before, I can't reproduce your issue. Here's a screenshot of your site in Google Chrome:

I don't really follow, sorry. Frontends, backends.. A users browser only deals with frontends, so how is the backend related?

1 Like

The website is opening but it will first show [net::err_cert_common_name_invalid] and gave you the option to "proceed anyway" and after proceeding it will display the website. That error is preventing the login programming in my backend that uses the https to fail. Try understand

I will produce screenshot of what i meant soon

No, it did not. And if it did, I wouldn't have the "normal" lock symbol in the address bar. When overruling a certificate warning, it would have been crossed out.

I understand that somehow you're getting an error, but you also have to understand it's not possible to remotely debug that when the error isn't shown from my point of view :wink: Everything seems to be working perfectly.

5 Likes

@OlammieAO It works perfectly from my Android phone too - for what that's worth.

4 Likes

My guess is:
It seems possible that a system exists that is using a cert that doesn't cover the "www" name:


And when you hit that system via that name "www" name it complains and after accepting you are redirected and continue correctly.

So...
Are there load-balanced systems inline?
Are you only seeing this problem from one specific network?

3 Likes

Thank you Osiris and MikeMcQ for your respond. The certificate showed that it is issued on my AWS RedHat Linux but browsers usually invalidate the certificate perhaps making my web application not to function properly infact, visitors cannot login using my website login page because the backend server is an HTTPS API that uses the same Letsencrypt certificate that the website itself uses so CORS complain the HTTP Request Did Not Succeed and because browser complained that the certificate is invalid. All browsers I have tested this on would first complain that the certificate name is invalid and would give an option to Proceed Anyway which may want some website visitors not want to continue.

See the screenshot attached

1 Like

I understand the certificate showed that it is perfectly working at your end but how visitors browser respond to the certificate is the main point, they all read it as invalid or is it a must/necessary that a browser first invalidate any https website that the certificate is not valid and give an option to proceed anyway? I guess NO sir.

My hosting environment is Redhat Linux and my web server is NGINX.

I will appreciate a positive respond and I thank you for your assistance.

Thank you @rg305, reason why the lock symbol is at the address bar is because you have accepted to proceed anyway from the option given by the browser. A cautious visitor may not want to proceed as (s)he may think it is a dubious website and in respond to your question below:

  1. Are there load-balanced systems inline? NO, Load Balancing. I only have reverse proxy to my backend https api server running on the same server.

  2. Are you only seeing this problem from one specific network? All networks see that error even when you change IP. You won't see the invalid certificate again once your browser accepted to proceed anyway and you will think your application is working properly until visitors started complaining.

Why I have much issue with the certificate is that it is preventing my backend server to be reached from the browser because of ERR_CERT_COMMON_NAME_INVALID .

Cross Origin Requests keeps blocking the request to reach the https backend server despite the fact that I have allowed cross origin with cors package in my backend.

Thank you

2 Likes

Check that your system time is correct (for the OS running your browser). [Your screenshot shows an invalid date error]

3 Likes

Thank you for your response @webprofusion , it is not about my computer time. Infact, if I proceed anyway on my computer and accept the browser ERR_CERT_COMMON_NAME_INVALID, i would login successfully and my application would be working fine on my computer but visitors on different computer at remote location can't login using my web application login page and this almost cost me my job because people are complaining they cannot login into the dashboard of the application and because I have accepted the browser warning on my computer to proceed anyway, i was able to login and i couldn't see from visitors perspective until I used a different computer and inspect what was going on and I realised it is CORS blocking the request due to invalid certificate.

My application frontend is https and backend is https too and they both use the letsencrypt certificate I generated on my Linux server. So i believe it is not about system time because I do visit other websites on my computer and I don't get such warning.

1 Like

@OlammieAO I understand, it's just that the screenshot you showed is showing a date issue, not an invalid name:
image

I think I see what the problem could be though, your API is being loaded using just an IP address as https://52.87.25.92:8184. A Let's Encrypt certificate cannot be used for just an IP and you need to use a proper dns name as browser won't trust a certificate for a domain if it's being used to access an IP address instead. I would suggest you change all your app API urls to use https://aiimaglobal.com:8184/ instead of https://52.87.25.92:8184/

3 Likes

Where did you find that? I cannot find that IP address in the source anywhere.

Also, might that be the "backend" OP is talking about, which I still don't understand? (Users shouldn't connect to a backend, only to frontends..)

3 Likes

I used the 'source' tab in google chrome dev tools. The app helpfully included js source maps back to the original TypeScript.

3 Likes

You are right @webprofusion and thank you for that, i saw that and it will be fixed but you truly saw that it has CORS Request Not Succeeded error which after I explored I got to realised it was NET::ERR_CERT_COMMON_NAME_INVALID . Infact, Google Chrome inspect would tell you it was NET::ERR_CERT_COMMON_NAME_INVALID error that it preventing the code to call the funtion that will redirect to the dashboard after logging in. I put a code to investigate and the code before the calling of the main function that will do the checking wasn't called from the running backend https api server because of the CORS blocking it as it cannot trust the certificate name.

1 Like

Wooow, you are wonderful @webprofusion , I never knew this that Letsencrypt certificate is not permitted to be used on IP address alone. So you mean if I use the DNS name of the server i won't get the error message anymore?

I will try that and get back.

Thank you

4 Likes