I think I ended up screwing up the original creation of the certificate because it seems to have 2 certificates and I’m not sure how to remove one so that I can renew the other.
I got two emails about expiration.
One email: Your certificate (or certificates) for the names listed below will expire in
9 days (on 30 Sep 17 01:53 +0000). Please make sure to renew
your certificate before then, or visitors to your website will encounter errors.
2nd Email:
Your certificate (or certificates) for the names listed below will expire in
19 days (on 03 Oct 17 22:59 +0000). Please make sure to renew
your certificate before then, or visitors to your website will encounter errors.
If you "add domains to a certificate" you actually create a new one, and due to a limitation on Let's Encrypt's side you end up getting expiration e-mails for the old one. But certbot replaces your old certificate with your new one, so there might not be two certificates on your system. The command above will allow you to check this.
Did you recently add any sort of CDN, proxy, or load balancer to the affected domain(s)? Apache must be listening directly on port 443 at the IP address listed for your A record for tls-sni-01 verification to work. Any sort of middle-man will break it and cause this error.
I do have a CDN on the Secfenia domain, but had it when I did the original certificate. If this is the potential break point, what is the work around for this? Is there another challenge I can use?
certbot is working with one certificate. You can safely ignore the other e-mail.
It would only fail for that domain. I doubt you have the CDN enabled for the mail subdomain, so it should work. I actually think you have
This is actually a clue, but not how you think. Ordinarily this would indicate that the domain uses SNI, and the default certificate that is used for clients that don't support SNI is the second one it is talking about. But I checked your domain, and it does not have a second certificate, so I think the second certificate the ACME server is talking about is actually the acme.invalid certificate the validation server is looking for.
Are there any duplicate/conflicting VirtualHost entries in your Apache configuration? If nothing seems out of the ordinary, you could share your Apache configuration files and we might be able to identify what is tripping it up.
There are two other validation methods: http-01 requires placing a file in your web serving directory for each domain (and dealing with any RewriteRules or authentication that may be in the way), while dns-01 requires placing a TXT record in your DNS for each domain.
To use http-01/webroot authentication, you would need to reissue the certificate, relisting all your domains again, and tell certbot the directory files are served to the Internet from, e.g.
List loveagamer.com first to reuse the same certificate name.
If you use linode DNS for all your domains (I only checked one), dns-01 is a feasible option, but only the acme.sh and dehydrated clients have support for its API; unfortunately certbot doesn't.
Hi @Patches, I don't agree with your interpretation here — normally the "two certificates" are the end-entity certificate and the chain certificate. (I agree that this situation arises when a server sends its default certificate chain, but the two certificates are almost always the two certificates in that chain, not the acme.invalid certificate together with some other certificate.) I tried connecting to this host with
and I see two certificates which are indeed the default end-entity certificate plus the Let's Encrypt X3 intermediate, typical of other hosts with an existing HTTPS listener that fail TLS-SNI-01 challenges.
This doesn't necessarily affect the overall diagnosis or advice, but I just wanted to point out this clarification about what the "two certificates" are in this situation.
Now that I understand Boulder’s error message, I suspect your server just isn’t set up for SNI.
Does the following line exist anywhere in your Apache configuration?
NameVirtualHost *:443
If not, does validation work if you add it? (You can stick it in an existing <IfModule mod_ssl.c> if desired but it should otherwise be defined at the top-level and not in any <VirtualHost>.)
Apache will probably warn you that this line is unneeded (and that may be why you may have removed it at some point since validation last worked) but you can safely ignore that, because you do need it from time to time.
Here is an example of one of my SSL Apache Configs:
<IfModule mod_ssl.c>
<VirtualHost 23.92.30.62:443>
ServerAdmin support@nflpicks.org
ServerName nflpicks.org
ServerAlias www.nflpicks.org
DocumentRoot /web/nflpicks/public_html
ErrorLog /web/nflpicks/logs/error.log
CustomLog /web/nflpicks/logs/access.log combined
<Directory />
Require all granted
</Directory>
RewriteEngine on
# Some rewrite rules in this file were disabled on your HTTPS site,
# because they have the potential to create redirection loops.
SSLCertificateFile /etc/letsencrypt/live/loveagamer.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/loveagamer.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>
Hope that helps and thank you for your help so far.