SSL certificate has expired (again)
zinosama opened this issue · 16 comments
Seems like SSL certificate has expired at Wednesday, May 29, 2019 at 9:00:14 PM Pacific
This is blocking deployment 😢
I wonder how come one cannot automate the renewal? There are tons of tools available, e.g. https://github.com/go-acme/lego etc. Let's Encrypt recommends the renewal every 60 days at least, lego can check daily and only request certificates when it's time (renew --days 60).
It's a shame rails-assets is down every 90 days for the past year.
I am switching to http://insecure.rails-assets.org for now
👍
SSL certificate has expired again :
rails-assets.org
Issued by: Let's Encrypt Authority X3
Expired: Thursday, 30 May 2019 at 9:30:14 AM India Standard Time
"rails-assets.org" certificate expired ,
@joshjordan ping...
@leshik if you're volunteering, we would welcome your efforts!
As has been stated here a few times, certificate renewal automation is implemented and working. Its nginx that isn't playing nicely. It just needs some manual touch when it goes down. We haven't solved it yet and it is hard to justify the time to spend automating when it takes seconds to to fix manually. Its certainly on the todo list, but with rails-assets usage waning (as we're encouraging folks to migrate to npm/yarn), hard to justify.
What exactly is nginx doing when it's "not playing nicely"? I see no reason why an nginx -s reload should ever fail.
Thanks!
Me neither, in my case I use systemctl reload nginx.service but it does nginx -s reload internally thus it should be fine. Permissions issue maybe?
For anyone thats following this. The issue has now been resolved.
Restarting the nginx service does just fine and that is what I am doing manually. Its doing it automatically after renewal that has been failing, and like I said, has not really been worthwhile to investigate so far.
has not really been worthwhile to investigate so far.
Excuse me, but breaking production install seems to be "worthwhile". Happy to donate 200 USD right now if you find that a "worthwhile" motivation to investigate this, or to at least set up a meaningful monitoring for this, because it's getting a bit boring. Let me know.
I don't mean to make light of the breakage. If it is that worthwhile for you, I take your meaning. We've seen decreased usage over time and generally have 2-3 complaints, usually about local development (as opposed to deployment), in the time window between expiration and when I or someone else restarts. We've generally felt that the provided workaround of using insecure.rails-assets.org is sufficient for the handful of people effected, but clearly folks feel otherwise.
I will implement this today. No donation required (although always kindly accepted).
Donated.
I’m pretty sure it’s permissions issue. Certbot or lego or whatever you use always chmods keys and certs to 0600. When you first start nginx, it will read all configs as root, then it drops to unprivileged user, such as nginx or www-data. When certs get updated and nginx is reloaded, it then can’t read these files and fallbacks to old ones. It won’t fail but will complain to error.log. You must chown certs to nginx user after renewal, or chgrp to nginx group then chmod to 0640.
Fairly certain I have this solved. We will see if the June LE cert gets picked up properly.