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!
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.comserver {} 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?
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.
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 ?