Certificates name mismatch


Hey everyone,
So everything was going well until I registered a new certificate for a new domain on the same server. I’m using nginx and to my knowledge I thought everything was working perfectly.

However, the new certificate I registered for a different domain is now somehow linked to my other certificate/domain. For example if I go to images.exampleOne.com I now get NET::ERR_CERT_COMMON_NAME_INVALID

When I check the certificate information for images.exampleOne.com I expect to see certificateOne for exampleOne, however it shows the certificate for exampleTwo.com instead.

The default domain with no subdomains works just fine with the correct certificate, IE (exampleOne.com) however, I believe www.exampleOne.com doesn’t work.

Hopefully this is a easy fix and an obvious error on my part.

Let me know if I need to provide more information, thank you!


Without the relevant parts of your config file(s) and/or the actual domain names, there isn’t much I can tell you to fix this I’m afraid…


Hey Osiris,
What configuration files do you need, the nginx server blocks?

The actual domains are silverpvp.com, if you go to images.silverpvp.com and check the certificate information it shows, hueblur.com.


www.silverpvp.com also has the wrong certificate configured…

The nginx server blocks would be helpful indeed :slight_smile:


Did you add another name later? Is there a directory called /etc/live/silverpvp.com-0001 or so?





Yeah, just checked there is a silverpvp.com-0001.


That’s the certificate you have to configure. There’s a --expand flag or so in the official client that prevents creating files like that and instead overrides the old one.


Still, the problem of serving the wrong certificate is an issue, even when pointing to the right folder in /live/.

I don’t know exactly how nginx works, but I think the www.silverpvp.com server {} block uses the ‘default’ certificate, because you didn’t specify one. Could that be nginx’ behaviour?


You’ll have to include the correct ssl_certificate and ssl_certificate_key in every server block that uses ssl, otherwise nginx won’t know which certificate to use.

Additionally, I don’t see any mention of images.silverpvp.com at all; you’ll have to specify that server_name explicitly, or nginx will fall back to the first certificate it finds in the configuration. You can add multiple names with server_name host1.example.com host2.example.com host3.example.com;


I’m not sure exactly what there is to configure, sorry for sounding newbie. Should I change the ssl_certificate line for my silverpvp.com to point towards /etc/letsencrpyt/live/silverpvp.com-0001/fullchain.pem; etc?


Hey pfg,
Forgot to mention my images.silverpvp.com server block.


That seems to be a http-only server block; if you request that domain via SSL, it’ll fall back to the first certificate nginx encounters. Make sure you explicitly use listen 443 ssl; if you want to access that domain via https, and make sure that every server block using listen 443 ssl; also has ssl_certificate (and the other directives) set - even for the redirect-only server block for www.silverpvp.com.


I’m fine having images.silverpvp.com remain http-only.

I’ll add the ssl_certificate etc. to each block that uses listen 443 ssl right now, thanks.


Adding ssl_certificate and ssl_certificate_key to the blocks that use listen 443 ssl doesn’t seem to fix anything unfortunately. The only other thing I’ve done is point those certificates for silverpvp.com towards /live/silverpvp.com-0001/ instead.


The certificate you use for silverpvp.com doesn’t seem to include www.silverpvp.com. You’ll have to include every subdomain you’re going to use explicitly. The official client accepts multiple -d arguments for this purpose, i.e. -d example.com -d www.example.com. I’d recommend using the --expand flag as well to make sure the client replaces the existing certificate files instead of creating another 0001 directory.


So I should run this command again?
/letsencrypt-auto certonly -a webroot --webroot-path=/usr/share/nginx/html -d silverpvp.com -d www.silverpvp.com --expand ?


Yep, looks good to me.


I’m getting this error when I run the command above:


Your silverpvp.com server block has the following directive

root   /var/www/silverpvp.com/public_html;

So --webroot-path should probably be set to that directory.