Certificates name mismatch


#1

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!


#2

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…


#3

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.


#4

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

The nginx server blocks would be helpful indeed :slight_smile:


#5

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


#6

silverpvp.com

hueblur.com


#7

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


#8

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.


#9

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?


#10

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;


#11

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?


#12

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


#13

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.


#14

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.


#15

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.


#16

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.


#17

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 ?


#18

Yep, looks good to me.


#19

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


#20

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.