Hmm okay that seemed to do the trick. I wasn’t sure what it asking when it said --webroot-path, I was following a guide which suggested to use that as default.
Should I remove /live/silverpvp.com-0001 now and change back my server blocks to non -0001.
the you need all to use the same cert (as certs generally are seen/served before the client tells the server which site it was looking for)
the type of cert with multiple names is a SAN cert (easy with letsencrypt) -d name1 -d name2 etc
obviously you also have to ensure verification works for all the names (usually by having each site direct .well-known/acme-challenge/ at the same location
Based on your description I’m not sure which domains are covered by the certificate in silverpvp.com-0001 and whether they’re still in use. If you don’t need certificates for any domain other than www.silverpvp.com and silverpvp.com, I guess you won’t be needing it anymore. Where is it still being used in your configuration right now?
I just changed my server blocks for silverpvp.com to use the non-0001 version now, so I don’t think it’s being used anywhere else to my knowledge so I feel like it should be safe to remove?
you can have many many names in one SAN cert (no need for same parent domain)
just look at any site behind cloudflare you’ll see the cert is valid for many entirely unrelated domains)
Interesting, well do I really how to bother to make them under one certificate now that they already have their own? Noted for future reference if I have to set up additional sites though.
You can add up to 100 domains to the same certificate, and they don't all have to be subdomains (you can have example1.com and example2.com on one certificate). You might still want to separate certificates per "root domain" to keep it manageable if you're dealing with a lot of domains.
Shouldn't be a problem if you delete them, then. I'd create a backup of /etc/letsencrypt first anyway, just in case. Note: you might also have to delete the corresponding .conf file in /etc/letsencrypt/renewal/. I'm not sure how that works with multiple directories, but I reckon letsencrypt renew might complain if it finds the .conf file but not the certificate and key.
I also ran that command regarding updating the certificates to include www.hueblur.com and hueblur.com and pointed it towards the right webpath for hueblur.com as well.
Unfortunately seems like the original NET::ERR_CERT_COMMON_NAME_INVALID still shows up at images.silverpvp.com.
I made a backup of /live/letsencrypt and then deleted -0001 version of silverpvp.com.
If you want to use SSL with that domain, refer to the following comment:
As you don't currently have a certificate covering that domain as far as I know, you'll also have to run letsencrypt-auto again and add -d images.silverpvp.com to the list of domains (in addition to the other two. Don't forget --expand.)
Revoking a certificate is something you should be doing when someone maliciously steals your private key. It's not necessary (and doesn't really serve a purpose) when you're just replacing certificates for operational reasons.
I wouldn't mess with replacing all your certificates with one big SAN certificate for now, since you're close to running into the rate limit of 5 certificates per 7 days as well. I'd stick with one certificate per root domain.
I thought I saw that too initially, but when I checked again for that post, it was only silverpvp.com. There's an older certificate that covered both domains from January, I guess it got switched around during one of the web server restarts today or something.
as i said before just first check that your server has .well-known/acme-challenge/ pointed at the same location for each name
(i test this by putting test.txt at this location then browsing to each name/.well-known/acme-challenge/text.txt and seeing is it there)
once authentication is ready just apply for the cert as i said before with -d name1 -d name2 -d name3 etc etc
i cant walk you through it as i use different server software and a different acme client but the basic process is the same
we plan to have around 90 names on our cert when i get all the code past test phase as ours is a small scale cdn for many customers (currently only http but once we get the certs working https will become the default)
The thing is like images.silverpvp.com was working fine before not being on https, all of a sudden I can’t go to that domain without getting the error. If you go to silverpvp.com and click on store, which redirects you to store.silverpvp.com it also gives the same error, however store.silverpvp.com is just a cname(?) to another website, you can see that the certification for store.silverpvp.com is cloudlfare.
I mean, I’ll go ahead and make images.silverpvp.com https for now, but I’m not sure how to make it so people can visit store.silverpvp.com. Again, this WAS working before I believe I created hueblur.com.
Just as a confirmation, to make images.silverpvp.com https (Of course I have to configure the nginx server block), I just have to run this right?: root@oxygen:~# ./letsencrypt-auto certonly -a webroot --webroot-path=/var/www/silverpvp.com/public_html -d silverpvp.com -d www.silverpvp.com images.silverpvp.com --expand
Your domain appears to be on the HSTS preload list, which will force all requests to any subdomain to use https. If you have subdomains that do not support https (like store.silverpvp.com, which is hosted by a third-party), that’s not really a good idea. Unfortunately, I’m not sure if there’s even a process for HSTS preload removal. It’ll probably take a few months to propagate anyway. Your best bet might actually be to switch to a different domain for the store.