I have received several emails that the customers.eletter.gr certificate is expiring.
When I tried to renew it, using the mechanism from zerossl.com
on a debian 8 server with nginx it comes up with this:
Too early for renewal, certificate expires in 89 days.
Screen capture here: response from renewal process
These emails warn about exact combinations of names. If you previously had a certificate for a slightly different list of DNS names, maybe adding a www or removing one for example, the expiry warning mails about the old certificate still happen even though you now have a newer certificate with slightly different names in it.
Thank you for the response.
But If you try to visit this link, https://customers.eletter.gr you will actually see that the certificate has expired, even though the certificate files are in place within nginx!
Any thoughts?
There was a new certificate obtained on Sep 20, 2016 though https://crt.sh/?id=33146941 (I assume by you ), just not installed on your nginx yet ?
I have being trying to get it working but the site still comes up with no certificate authority.
And I am certain that settings on nginx are properly set.
What are the date stamps on the certificate files ? were they renewed on the 20th ? or are they still the old ones ?
If you can’t find the cert. you can obtain a copy of the certificate itself from https://crt.sh/?d=33146941
(I assume you already have the private key and CA chain ).
Have you got more than one copy of nginx running or anything silly like that ( I’ve seen it happen, and restarting doesn’t restart the “live” one properly).
There are still the old ones…
I can’t figure out what is going on.
it might be worth asking @leader (who I think is the author of zerossl), or contacting zerossl support through that site.
Alternatively, manually download the latest certificate ( I provide the link in a previous comment) and installing it, along with your private key.
Thank you for your help!
I will try your recommendation!
OK, I believe I might know what is happening in this case 
Basically when you use renew and specify the number of days before expiration (I believe you used 7 days) when renewal should take place, ZeroSSL client has 2 methods of making sure that the renewal happens within that specified interval.
First it is checked whether the certificate is locally available. Simply put - whether the file you have specified in --crt parameter exists and readable. If it does, then it is checked for the expiration value.
If the certificate is NOT available locally, then the client will try to connect via HTTPS to the domains listed on CSR (or in --domains) until at least one of the names responds. Then the response is checked for the expiration value.
Now, from what I can see, in your case the local file has been checked and the expiration value seems to be fine (89 days left). Considering that crt.sh also lists the successful issuance of the certificate, I believe what happened is that you run it on the day but never installed the renewed certificate on the site.
So you have a properly renewed certificate file on your disk, but it has not been copied into proper folder for your webserver or it was, but the server has not been reloaded.
P.S. Perhaps I should add an option to still try to verify the certificate available on the domain even if the local one is renewed and produce some sort of message encouraging installing that certificate in its rightful place
@leader thanks for responding to this.
Well I did check all these before posting here…
I am afraid I am on a dead end.
The command my shell script generates is here: https://github.com/davidoster/letsencrypt-fast/blob/master/le.sh
Basically what my script does is to create a keys folder where I keep all the certificates etc.
Then I point to this very directory nginx to look for the .crt and .key files.
So, I would expect to be ok when the renewal takes place without any moving around.
Well this same script works perfect, along with your zerossl client to a different server and managed to renew certificates hassle free.
I can’t figure out what is going on here!
The process and that shell script are certainly working. As I explained, the certificate file must have been generated for you as customers.eletter.gr.crt. If I'm reading that shell script correctly, the files would likely be found under /root/software/keys/customers.eletter.gr.keys/ in your case. Now what is important is to remember that even though the file might have been updated on the disk, your web server needs a reload or restart to start using it.
You can check the timestamp on the crt file with
ls -al /root/software/keys/customers.eletter.gr.keys/customers.eletter.gr.crt
It is very likely to be a recently updated file. For Nginx to use it (assuming that as you said it has already been configured to point to the right files), you would just need to run:
service nginx reload
Then reload some of your pages in the browser and they should be shown fine with the new cert.
If you issued the certificate on 9/22/2016 with your existing CSR, you can download your new certificate from http://crt.sh/?d=33954209, and leave your private key unchanged. Remember to reload nginx after updating certificate.
I would like to thank, all of you people for trying to resolve this issue.
In the end, I figured out that the server itself needed a restart.
Nginx and php-fpm themselves didn’t restart as expected and during my tries to get it working a couple of the sites that are served stopped responding.
So in the end I did a hard restart and everything works smoothly now.
Thank you all.
Hi David
One of the ways I usually troubleshoot these sort of things is to compare the Thumbprints of the certificates.
A) Review the certificate in your Clients Store (i.e. what was issued) or Review the certificate from crt.sh
B) Review the certificate that the browser receives
If the thumbprints are not the same then the certificate is not being used and you can troubleshoot the web server component as to why
A lot of Lets Encrypt clients automate processes but there are internals on how they work that you need to be aware of. If not then it can be hard to reconcile what you think is happening and what is actually happening.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.