I run a single server with 2 different domains. My cert request command looks something like this:
letsencrypt certonly -a webroot --webroot-path=/var/www/foo.com/htdocs -d foo.com --webroot-path=/var/www/bar.com/htdocs -d bar.com
In this way I generate one certificate file for both domains and include it in the main nginx.conf file http { } block once, so it applies to all server { } blocks, keep it short and clean. It all works, certificate is valid, no errors, pass all tests, etc.
But if you run curl -l https://www.bar.com you get curl: (51) SSL: certificate subject name (foo.com) does not match target host name 'bar.com'
Reiterating what schoen mentioned, without more info it’s exceptionally difficult to help troubleshoot this. Please provide the actual domain names in use. Bear in mind that these have already been publicly - and permanently - posted to the certificate transparency logs, so there’s no real increase in secrecy by not divulging them.
Don’t want to be rude, but posting links in public forums expose them to search engines. Why not just try to guide me through the troubleshoot steps? Or I can PM links.
That’s neither rude nor the first time someone has espoused that particular concern, no worries! It’s worth noting that domains are indexable in the CT logs as well. (Although in fairness, less likely to be found in most casual search engine results.) One option if you’re concerned about this, however, is to edit the post once things are solved. It’ll still be visible in edit history of course, but this isn’t indexed by search engines to the best of my knowledge.
Thinking a bit more about this, another option would be if you could you provide the fingerprint of the certificate? That would give us the ability to look up the info in CT logs without exposing anything of value on the forum itself. EDIT: Fingerprint can be taken from the certificate with openssl x509 -in certificatefile.pem -noout -fingerprint -sha256, or you could look it up yourself at https://crt.sh and paste the fingerprint or link to the CT entry here.
Most of us are volunteers with varying skillsets, PMs to a couple people cut down the help you will get from the community and also slow down responses while those you’ve informed of your domain are the only ones most equipped to assist. The issue with just trying to walk you through steps is that it ends up taking several times as long, when as I mentioned, most people here are volunteers.
I can’t speak for Schoen’s ideas of what to look for next, but my steps would be the following: Use openssl’s s_client to connect to the domain with an issue and see what certificate is coming back and go from there.
No problem! So, from everything I can tell, it’s looking good to me for the four SANs listed on that certificate. I didn’t get any validation errors. I’ll be checking redirects in a second, but in the meantime, could you verify something for me? In your example, you’re saying bar.com works, but www.bar.com does not. There are indeed four domains in that, but they’re not www.foo.com, foo.com, www.bar.com, bar.com. Rather, you have something more akin to: d7.foo.com, foo.com, www.foo.com, and bar.lt. So, if you are trying bar.lt and www.bar.lt, you’ll get a validation error on the latter.
Looking at the crt.sh logs, you do seem to have a certificate that covers the www and non-www versions of both domains (and some more subdomains); it’s just not the certificate that your webserver is using.
You might try using the letsencrypt certificates command (if you have a recent enough version of letsencrypt / certbot) to see if that helps you identify the correct certificate to use.
I deleted all letsencrypt directories and reinstalled latest version and recreated new certs and I still get same curl error. letsencrypt certificates finds only one certificate.
Well, that certificate is missing one of the www subdomains (the .lt one). (You can see the (sub)domains that the certificate is valid for on crt.sh under the heading “X509v3 Subject Alternative Name”).
If you deleted all the old ones, including the one that covered the correct set of domains, you’ll just have to issue it again. This time, make sure to specify all the domains you need on the certificate, in a single command.