Let's Encrypt certificate did not auto-renew

[459217974]

I have seen in some other issues how to renew the SSL certificate, you say it will automatically renew, but my SSL certificate does not renew automatically until expired, what should I do?

[cpu]

@459217974 Please respond to the new issue template questions that you deleted so that we can help:

Expected behavior:

Actual Behavior:

Steps to Reproduce:

[ contents of streisand-diagnostics.md here ]

Additional Details:

Log output from Ansible or other relevant services (link to Gist for longer output):

Target Cloud Provider:

Operating System of target host:

Operating System of client:

Version of Ansible, using ansible --version :

Output from git rev-parse HEAD in your Streisand directory :

Can you verify you're using the Let's Encrypt option? Can you also share the domain name of the certificate?

[459217974]

Sorry I did not follow the template to submit the issue, but that template may not be suitable for my problem.According to your design, streisand Once deployed, I can no longer ssh to that machine, so in theory I even do not know what happened on that machine, and after the deployment, the machine I was deploying might have deleted the streisand project, so I might not be able to provide the information I needed in the template. Well, the above is just grumbling, in fact I can provide some information: Target Cloud Provider: Bandwagon Host Operating System of target host: Linux ubuntu 4.13.12-041312-generic #201711080535 SMP Wed Nov 8 10:40:26 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Operating System of client: Linux caoda 4.9.0-deepin13-amd64 #1 SMP PREEMPT Deepin 4.9.57-1 (2017-10-19) x86_64 GNU/Linux Version of Ansible, using ansible --version :

ansible 2.4.1.0 config file = None configured module search path = [u'/home/caoda/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules'] ansible python module location = /home/caoda/.pyenv/versions/2.7.13/lib/python2.7/site-packages/ansible executable location = /home/caoda/.pyenv/versions/2.7.13/bin/ansible python version = 2.7.13 (default, Sep 27 2017, 01:40:18) [GCC 6.3.0 20170321]

Output from git rev-parse HEAD in your Streisand directory : ca2106e73db72209c360dc6912acddfa76b5c6b8

I confirm that I am using Let's Encrypt . My Domain is ss.unpython.com .

And my problem is that my SSL certificate is not renew, I need a way to renew my SSL certificate. There are ways to manually rebew as well, I can now ssh to the streisand server.

[cpu]

Sorry I did not follow the template to submit the issue, but that template may not be suitable for my problem.

No problem. Please always try to fill out the issue template. Even when it's not immediately applicable it gets a lot of questions out of the way up front :-)

According to your design, streisand Once deployed, I can no longer ssh to that machine,

I'm a bit confused! That's not part of our design. You should retain the SSH keypair that you configured Streisand to use during deployment so that you will be able to SSH to the deployed server.

I noticed you used "Bandwagon Host" as the target so I'm guessing that meant you used the Existing Server or Localhost deployment options. As specified in the description these are more advanced options. I recommend that you try a supported provider to make your life easier :-) They specifically handle making sure SSH access is set up correctly.

I confirm that I am using Let's Encrypt . My Domain is ss.unpython.com . And my problem is that my SSL certificate is not renew, I need a way to renew my SSL certificate. There are ways to manually rebew as well, I can now ssh to the streisand server.

Thanks for providing that information. The certificate should have renewed itself automatically. Since that didn't happen we can investigate further, it smells like a bug.

I happen to work for Let's Encrypt and can check some server-side validation logs that are not available to the general public. I'll check what happened with ss.unpython.com on Monday - I can only access that information from my work laptop and I try not to open that on Saturdays :-)

[cpu]

@459217974 Could you also run this command on your Streisand server for me and share the output? openssl x509 -in /var/lib/acme/live/ss.unpython.com/cert -noout -startdate -enddate

[cpu]

@459217974 One last question: Did you manually renew the certificate already? I see a currently valid certificate right now:

openssl s_client -connect ss.unpython.com:443 </dev/null 2>/dev/null | openssl x509 -noout -startdate -enddate -serial
notBefore=Feb 10 06:58:45 2018 GMT
notAfter=May 11 06:58:45 2018 GMT
serial=03852C1B4A60947C60E7129873658DA35B4E

If you have already renewed the certificate manually then the command I asked for above won't be very helpful - it will show the same thing I see. I was hoping to figure out whether:

1. ACMETool did renew the certificate but nginx was still using the old one
2. ACMETool didn't renew the certificate at all

[459217974]

I renew the certificate by myself with certbot. l will provide more information tomorrow. l am in China, so, it's too late for me. And I apologize for some of my inappropriate comments. thanks this awesome project.

[cpu]

I renew the certificate by myself with certbot. l will provide more information tomorrow.

OK! I'm glad you got a working certificate! This will make debugging trickier but I'll see what I can see in the logs on Monday and we can go from there.

And I apologize for some of my inappropriate comments. thanks this awesome project.

No need to apologize! I don't think you said anything inappropriate :-) Thank you for the kind words.

Rest well

[Barafu]

I had the same issue. Sorry, I did not take the logs befiore destroying that VPS. However, I am pretty sure what was the problem. On the VPS, I have run "acmetool reconcile". And it asked me to assept some kind of agreement (with Y|n). I think that interaction is what prevented it from updating automatically. When I typed Y, it updated without problems.

[cpu]

@Barafu Thanks for sharing that detail - that's interesting! Acmetool shouldn't require any action for an existing account when Let's Encrypt changes the terms of service. In a perfect world that would only affect new account creation. I'll see if I can reproduce this situation and then file an acmetool bug if it turns out to be something that happens inappropriately.

[Barafu]

And account creation happens during initial configuration, right? I did not use Lets Encrypt before.

[cpu]

And account creation happens during initial configuration, right?

Yup, it happens the first time the server is set up and acmetool is installed/run.

[Barafu]

Most likely, I attached the domain to the VPS right before running the script. It is possible that during the setup, domain has not yet propagated properly.

[459217974]

Sorry for such a long time before I reply because China was on the Spring Festival ... Let's talk about what I did. I run this commands:

apt-get install certbot
certbot certonly -d ss.unpython.com

But there is a redirect program listen 80 port, so you can not use certbot to renew the certificate, I killed the program and successfully renew the certificate.

lsof -i:80
kill 884  # The rediect program pid

Then I found from the nginx configuration file where the certificate exists, and run this commands:

rm -f cert chain fullchain privkey
ln -s /etc/letsencrypt/live/ss.unpython.com/cert.pem cert
ln -s /etc/letsencrypt/live/ss.unpython.com/chain.pem chain
ln -s /etc/letsencrypt/live/ss.unpython.com/fullchain.pem fullchain
ln -s /etc/letsencrypt/live/ss.unpython.com/privkey.pem privkey
nginx -s reload

So far everything seems fine, but after a while I found that the redirected program did not run automatically after the reboot, and to get around the problem, I changed the nginx configuration file to allow access to port 80 Redirect to port 443, I add this:

server {
    listen 80;
    server_name ss.unpython.com;
    rewrite ^(.*)$  https://$host$1 permanent;
}

Now everything is normal, but I know that streisand server must have been a mess... ha ha ha... because I hit a bunch of crappy patches.

[cpu]

@459217974 Thanks for the update!

I haven't had a chance to test @Barafu's theory that a Streisand instance created prior to the last Let's Encrypt subscriber agreement change would have auto-renewals broken by ACMETool until done interactively to agree to the new change. I think this is the leading theory for why autorenewal wouldn't have worked in the cases reported here.

But there is a redirect program listen 80 port, so you can not use certbot to renew the certificate, I killed the program and successfully renew the certificate.

I did some testing of my own yesterday and noticed this acmetool redirector failed to bind :80 on an initial provision, seemingly killing acmetool in the process and preventing the initial issuance. I think this is a separate issue to look into. We should have Nginx bind :80 as you suggest (being mindful of the Tor hidden service config). I'll look into this separately.

[pguizeline]

Changing for acme.sh could be considered? It seems that acmetool is not as maintained as acme.sh. https://github.com/Neilpang/acme.sh

[cpu]

I did some testing of my own yesterday and noticed this acmetool redirector failed to bind :80 on an initial provision, seemingly killing acmetool in the process and preventing the initial issuance. I think this is a separate issue to look into.

I opened https://github.com/StreisandEffect/streisand/issues/1349 for this issue.

Changing for acme.sh could be considered? It seems that acmetool is not as maintained as acme.sh.

@pguizeline I'm still partial towards acmetool for the time being. It has a solid design and I'm more comfortable working with Go in the event it needs to be forked or patched for Streisand's needs. It would be more work to completely replace acmetool than to figure out the remaining acmetool issues.

[Landsil]

If someone got here because of the email they got from let's encrypt about expiring cert. Check on your website, my is fine, it's was just a reminder. (and I'm new and stupid)