Incorrect common name in SSL certificate of a subdomain


First of all, AWESOME!

I have secured 4-5 of my web applications via Let’s Encrypt and all of them has been secured in one go without a single hiccup. But today, I’m trying to secure a subdomain at but when I’m opening the page it says ERR_CERT_AUTHORITY_INVALID. analyzer says Certificate name mismatch.

I’m not sure how CN is 38:90:a5:27:e0:40. Am I missing something?

I decoded the generated CSR as well and it is showing the correct common name in there.


This is using a self-signed cert. You’ve issued a cert for this domain, but your server isn’t using it yet. You’ll need to fix your server configuration. And if you’d answered the questions that the site gave you when you chose the Help catagory, rather than deleting them, we might have some more detailed suggestions about how to do that.


Also… while several of the issues in the SSL Labs report are related to the self-signed certificate, most of them aren’t, and that server is old and insecure.

You should keep it somewhere safe, like the bottom of the ocean.

More seriously, you should upgrade it if possible.

If it’s not possible, consider putting a more modern reverse proxy in front of it.


Oh! thanks @danb35. But I do not have any clue of what to do in fixing the self-signed certificate. How can I move forward? If you can point me in a direction then I can further investigate.

Regarding the questions that you mentioned (that site asks while raising a help), I don’t get that, probably I signed up and posted immediately? But I went to compose a new topic and copied the questions. Here are the answers:

I ran this command:

sudo yum install certbot-nginx
sudo certbot --nginx

It produced this output:

[dev@snpengg ~]$ sudo certbot --nginx
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
Starting new HTTPS connection (1):

Please read the Terms of Service at You must
agree in order to register with the ACME server at
(A)gree/(C)ancel: A

Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
(Y)es/(N)o: N

Which names would you like to activate HTTPS for?
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/nginx.conf

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting all traffic on port 80 to ssl in /etc/nginx/nginx.conf

Congratulations! You have successfully enabled

You should test your configuration at:

 - Congratulations! Your certificate and chain have been saved at:
   Your key file has been saved at:
   Your cert will expire on 2018-07-09. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

My web server is (include version):

Nginx version: nginx/1.12.2

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

CentOS Linux release 7.4.1708 (Core)

My hosting provider, if applicable, is:

Hosted on a personal server.

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

Yes, I can login.

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


Thanks again!


Nginx 1.12.2!? I’m not sure it’s possible to configure Nginx as insecurely as that web server.

I don’t think is actually hitting your Nginx server.

Is port forwarding involved? Are you sure it’s configured correctly?

The certificate details say:

O=Cisco Systems, Inc.,L=Irvine,C=US,surName=Califomia

(That’s “Califomia”. With an “M”.)

Anyway, I bet it’s a Cisco RV042 model router with the MAC address 38:90:a5:27:e0:40.

Does that sound like a device on your network?


Thanks @mnordhoff That’s really helpful. We have a Cisco router in front of the server which is forwarding the port to our server. I’ll debug that way.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.