Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for creekhouse.ingber.com
http-01 challenge for www.ingber.com
http-01 challenge for ingber.com
Using the webroot path /var/www-ssl for all unmatched domains.
Waiting for verificationā¦
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0002_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0002_csr-certbot.pem
IMPORTANT NOTES:
Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/ingber.com/fullchain.pem. Your cert will
expire on 2017-06-19. To obtain a new or tweaked version of this
certificate in the future, simply run letsencrypt-auto again. To
non-interactively renew all of your certificates, run
"letsencrypt-auto renew"
If you like Certbot, please consider supporting our work by:
Iāve been using SSLstart certs for some time. When I switch my /etc/apache2/sites-enabled/ssl.conf script to use the LE paths, ingber.com and www.ingber.com pass OK, but creekhouse fails:
[Tue Mar 21 05:14:24.103468 2017] [ssl:emerg] [pid 24481] AH02572: Failed to configure at least one certificate and key for creekhouse.ingber.com:443
[Tue Mar 21 05:14:24.103562 2017] [ssl:emerg] [pid 24481] SSL Library Error: error:140A80B1:SSL routines:SSL_CTX_check_private_key:no certificate assigned
[Tue Mar 21 05:14:24.103572 2017] [ssl:emerg] [pid 24481] AH02311: Fatal error initialising mod_ssl, exiting. See /var/log/apache2/error.log for more information
AH00016: Configuration Failed
The entry in the error.log just confirms this:
Failed to configure at least one certificate and key for creekhouse.ingber.com:443
Note that I do have proper DNS records set up for creekhouse.
Iām using CloudFlare for our sites. I do not have any special http -> https rules set up. However, on ingber.com, I do have in my http file under sites-enabled/
<VirtualHost :80>
ServerName www.ingber.com
ServerAlias ingber.comwww.ingber.com
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.) https://%{HTTP_HOST}%{REQUEST_URI}
I deleted all letsencrypt, then did a fresh install using
apt-get install python-letsencrypt-apache
then did
letsencrypt certonly --email root@ingber.com --text --renew-by-default --agree-tos --webroot -w /var/www-ssl/ -d ingber.com -w /var/www-ssl/creekhouse/ -d creekhouse.ingber.com -w /var/www-ssl/ -d www.ingber.com
I got the same (negative) results in /var/log/apache2/error.log
AH02572: Failed to configure at least one certificate and key for creekhouse.ingber.com:443
Iām not positive of this, but I believe you have to configure the relevant certificate and key in the VirtualHost definition for creekhouse, not just in the general ssl.conf file. When Certbot itself does HTTPS configuration for Apache (which doesnāt happen with certonly and may not be preferred for every use case), it will put certificate, chain, and key configuration into each individual VirtualHost separately, even, I believe, when the certificate is shared among several separate virtual hosts.
Hi. Yes, it has been working for a couple of years or so. I have a
StartSSL yearly subscription, which covers all *.ingber.com domains; LE
does not (yet?) permit wildcards.
Cloudflare requires such an active public cert to enforce their āSSL: Full
(strict)ā setting, so it would have flagged a problem by now.
I didnāt mean to run those commands as they were, but to run them once each supplying the path of each individual PEM file. In this case youāre asking to analyze files in rootās home directory, which donāt exist.
Iām puzzled that there are apparently no Apache configuration lines beginning with āSSLā. Could you try the grep command again without the ^ character?
E-mail attachments arenāt supported by this forum software, so the attachment didnāt come through. But the other useful thing would be to still have -r in the grep to make it recursive (applying to subdirectories). I believe only /etc/apache2 is a relevant place to look.
Iāll try to find someone with more Apache knowledge who might be able to help, but from the output of that command, it seems to me that your Apache configuration is rather non-standard. For one thing, you seem to have kept around old, no longer used versions of your configuration in sites-enabled, where expect that Apache would still try to use them. Do you think you could move the disused configurations somewhere else to be sure that theyāre no longer used, and then restart Apache? And could we see the default-ssl.conf.letsenc fileās contents?
--renew-by-default will get you new certificates every time you run the command. But the issuing of the certificates isnāt actually the problem, so it will give you new certs every time. With the (almost certain) possibility of hitting the rate limits.
Hi. I doubt that is a problem. The only active conf files are those that
end in .conf, per my settings. There is only one (1) active cert from
startssl. If I switch files to .conf.lestenc -> .conf, then there still is
only one (1) cert from LE.
Sorry, I wasn't trying to directly help you with your current problem. But you are using the certbot client (the name letsencrypt for the client was renamed to certbot in 2016) to get real Let's Encrypt certificates issued. If you look at the rate limits page I linked to, you can see you can't do that indefinitely within the time frame of 7 days.
So I was trying to warn you about the existence of these rate limits, so you won't get an error when you try to use letsencrypt-auto again.
The reason you're having so much certificates issued already is the --renew-by-default switch. If you leave that one out, the client should ask you what to do: really issue a new cert? (You already have many, many issued on March 22nd) Or just install an already issued certificate.