Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
It produced this output:Alternative names lazygranch.com MISMATCH
My web server is (include version):nginx 1.14.0
The operating system my web server runs on is (include version):centos 3.10.0-862.3.2.el7.x86_64
My hosting provider, if applicable, is:digital ocean
I can login to a root shell on my machine (yes or no, or I don’t know):yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):no
I issue a separate cert for lazygranch.com and www.lazygranch.com. Did something change in the last three months? Maybe subdomains are handled differently.
Seems the thing that has changed is that your previous certificate covered 4 domains, including www.lazygranch.com and lazygranch.com and now you have issued independent certs for www.lazygranch.com and lazygranch.com so you should configure your nginx with independent server blocks pointing to the right certs.
If you issued your certs using certbot you can show the output of certbot certificates and also your nginx conf for these domains.
I have two domains and it appears both have this mismatch problem. My nginx.conf is set up for www.lazygranch.com and lazygranch.com to be in the same nginx “server”.
Here are my “live” directories:
drwxr-xr-x 2 root root 93 Mar 26 10:00 inplanesight.org
drwxr-xr-x 2 root root 93 Jun 5 22:19 inplanesight.org-0001
drwxr-xr-x 2 root root 6 Mar 26 22:32 lazygranch.com
drwxr-xr-x 2 root root 93 Jun 6 15:51 lazygranch.com-0001
drwxr-xr-x 2 root root 93 Jun 5 22:20 www.inplanesight.org
drwxr-xr-x 2 root root 93 Jun 6 16:55 www.lazygranch.com
@gariac if you are using only one server block for lazygranch.com and www.lazygranch.com then you should issue your certbot command covering only those domains.
I’ve removed the other domains and added --cert-name lazygranch.com to be sure the certificates issued are using this path /etc/letsencrypt/live/lazygranch.com then you should configure your nginx to point the ssl directives to this path.
If you use this approach keep in mind that you should reload nginx every time the certificate is renewed, you can tell certbot to do this in every renewal adding the --deploy-hook param.
You should do the same with the other two domains.
Once done, and once you get it working you should remove the other certificates using certbot delete command (but first made a backup of /etc/letsencrypt/).
I’m not really sure I like any of these options. I use the same certs for my email, so I don’t think the webstore is the best location. I canceled the operation. Note that I block many IP addresses, so I need the dns method.
sh-4.2# sh create_cert_lazyg
Saving debug log to /var/log/letsencrypt/letsencrypt.log
How would you like to authenticate with the ACME CA?
-------------------------------------------------------------------------------
1: Nginx Web Server plugin - Alpha (nginx)
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)
-------------------------------------------------------------------------------
Select the appropriate number [1-3] then [enter] (press 'c' to cancel):
If you must use dns challenge then you should install certbot-dns-digitalocean plugin. As far as I known there is no package for your distribution yet so you could install it using pip3 (I don't recommend it), or you can use certbot-auto instead of the certbot packaged by your distribution and install the dns plugin for certbot-auto, you can use lexicon plugin id-rsa.pub - Easy SSL Auto-Renewal via DNS using Certbot with Lexicon or you could switch to another client like https://acme.sh that supports digital ocean dns api out of the box.
Regarding cert location, mail and web are different users, so I rather not have the cert in the webroot. In any event, I loaded acme.sh as suggested.
The Digital Ocean DNS instructions are buried, but can be found here: https://github.com/Neilpang/acme.sh/tree/master/dnsapi
I figured I would include the link in the event someone else is reading this thread. Actually it is only two lines.
Here is the output. Note that acme.sh uses sslabs to test the cert. I have managed to block their server, so the first run failed.
I only get a B on ssllabs test. The complaint is
This server's certificate chain is incomplete. Grade capped to B.
For completeness, here is the acme output, sanitized a bit.
sh-4.2# ./acme.sh --force --issue --dns dns_dgon -d lazygranch.com -d www.lazygranch.com
[Wed Jun 6 22:16:40 UTC 2018] Registering account
[Wed Jun 6 22:16:41 UTC 2018] Registered
[Wed Jun 6 22:16:41 UTC 2018] ACCOUNT_THUMBPRINT=<redacted>
[Wed Jun 6 22:16:41 UTC 2018] Multi domain='DNS:lazygranch.com,DNS:www.lazygranch.com'
[Wed Jun 6 22:16:41 UTC 2018] Getting domain auth token for each domain
[Wed Jun 6 22:16:41 UTC 2018] Getting webroot for domain='lazygranch.com'
[Wed Jun 6 22:16:41 UTC 2018] Getting new-authz for domain='lazygranch.com'
[Wed Jun 6 22:16:42 UTC 2018] The new-authz request is ok.
[Wed Jun 6 22:16:42 UTC 2018] Getting webroot for domain='www.lazygranch.com'
[Wed Jun 6 22:16:42 UTC 2018] Getting new-authz for domain='www.lazygranch.com'
[Wed Jun 6 22:16:42 UTC 2018] The new-authz request is ok.
[Wed Jun 6 22:16:42 UTC 2018] Found domain api file: /usr/local/src/acme.sh/dnsapi/dns_dgon.sh
[Wed Jun 6 22:16:42 UTC 2018] Using digitalocean dns validation - add record
[Wed Jun 6 22:16:44 UTC 2018] Found domain api file: /usr/local/src/acme.sh/dnsapi/dns_dgon.sh
[Wed Jun 6 22:16:44 UTC 2018] Using digitalocean dns validation - add record
[Wed Jun 6 22:16:45 UTC 2018] Sleep 120 seconds for the txt records to take effect
[Wed Jun 6 22:18:46 UTC 2018] Verifying:lazygranch.com
[Wed Jun 6 22:18:49 UTC 2018] Success
[Wed Jun 6 22:18:49 UTC 2018] Verifying:www.lazygranch.com
[Wed Jun 6 22:18:52 UTC 2018] Success
[Wed Jun 6 22:18:52 UTC 2018] Removing DNS records.
[Wed Jun 6 22:18:52 UTC 2018] Using digitalocean dns validation - remove record
[Wed Jun 6 22:20:34 UTC 2018] Using digitalocean dns validation - remove record
[Wed Jun 6 22:20:36 UTC 2018] Verify finished, start to sign.
[Wed Jun 6 22:20:36 UTC 2018] Cert success.
<redacted>
-----END CERTIFICATE-----
[Wed Jun 6 22:20:36 UTC 2018] Your cert is in /root/.acme.sh/lazygranch.com/lazygranch.com.cer
[Wed Jun 6 22:20:36 UTC 2018] Your cert key is in /root/.acme.sh/lazygranch.com/lazygranch.com.key
[Wed Jun 6 22:20:37 UTC 2018] The intermediate CA cert is in /root/.acme.sh/lazygranch.com/ca.cer
[Wed Jun 6 22:20:37 UTC 2018] And the full chain certs is there: /root/.acme.sh/lazygranch.com/fullchain.cer
I see. Here are the old and new lines from the nginx.conf.
# ssl_certificate /etc/letsencrypt/live/www.lazygranch.com/fullchain.pem; # managed by Certbot
# ssl_certificate_key /etc/letsencrypt/live/www.lazygranch.com/privkey.pem; # managed by Certbot
ssl_certificate /root/.acme.sh/lazygranch.com/lazygranch.com.cer;
ssl_certificate_key /root/.acme.sh/lazygranch.com/lazygranch.com.key;
I assume I should use full chain. But specifically which two lines do I use:
[Wed Jun 6 21:57:50 UTC 2018] Your cert is in /root/.acme.sh/lazygranch.com/lazygranch.com.cer
[Wed Jun 6 21:57:50 UTC 2018] Your cert key is in /root/.acme.sh/lazygranch.com/lazygranch.com.key
[Wed Jun 6 21:57:51 UTC 2018] The intermediate CA cert is in /root/.acme.sh/lazygranch.com/ca.cer
[Wed Jun 6 21:57:51 UTC 2018] And the full chain certs is there: /root/.acme.sh/lazygranch.com/fullchain.cer
should be used in the ssl_certificate configuration directive. (It contains the contents of bothlazygranch.com.cer and lazygranch.com/ca.cer in a single file.)
ssl_certificate and ssl_certificate_key directives are ok.
Regarding ssl_trusted_certificate you only need this directive if you are verifying client certificates or if you have enabled the ssl_stapling directive and in this case, instead of fullchain.cer you should use ca.cer file; ssl_trusted_certificate /root/.acme.sh/lazygranch.com/ca.cer.
Note however that acme.sh considers the ~/.acme.sh/ folder structure unstable and recommends using --install-cert to copy the files to locations that you explicitly specify. This also supports a --reloadcmd option that works like certbot’s --deploy-hook to reload your webserver etc after renewal.
I’m not really sure what the problem is regarding /root/.acme.sh/, but I will will put the certs elsewhere.
Otherwise everything is working, including email. Thanks all for your help. I will do a PSA post on the Digital Ocean community regarding using the acme.sh for centos. Once I found the info on how to feed it the token, everything was straightforward.
The problem is simply that future versions of acme.sh might use a different folder structure which could break your configuration
BTW, don't move the certificates manually - use acme.sh --install-cert as described on the page I linked above. If you follow the nginx example from there, it should also automatically reload your nginx config to activate the new certificate after it auto-renews.
I assume I need to issue the certs again with the --install-cert for the new location. No big deal.
However I want to check with the postfix/dovecot gurus regarding how I generate the cert. Right now the mail system only uses one cert for two different domains. This is really common for hosting companies (though the VPS is just for me). Basically incoming mail doesn’t check if the domain matches the cert. But google slowly has been making the email servers they communicate with shall we say “cleaner.” Either now or soon, if you don’t pass dmarc, your mail will go to spam or perhaps be flagged as dicey. I’m sure at some point they won’t like the email domain not matching the cert domain. Apologies in advance if I don’t get the terminology correct.