Huh. Might be that somehow you have multiple cron jobs?
take a look at /etc/cron.d/. There should only be one of these: mailinabox-nightly
and it’s contents should look like:
# Mail-in-a-Box --- Do not edit / will be overwritten on update.
# Run nightly tasks: backup, status checks.
0 3 * * * root (cd /root/mailinabox && management/daily_tasks.sh)
```
Additionally, would you mind posting the output of this command:
` /root/mailinabox/management/ssl_certificates.py -v `
I see only one mailinabox-nightly under /etc/cron.d/ - so good there, and contents match what you posted.
The output of the command:
root@box:/etc/cron.d# /root/mailinabox/management/ssl_certificates.py -v
> Reading account key from /home/user-data/ssl/lets_encrypt/account.pem.
> Validating existing account saved to /home/user-data/ssl/lets_encrypt/registration.json.
> Reusing existing challenges for box.hireahelpermail.com.
> The challenges for box.hireahelpermail.com have been accepted.
> Reusing existing challenges for hireahelpermail.com.
> The challenges for hireahelpermail.com have been accepted.
> Reusing existing challenges for www.hireahelpermail.com.
> The challenges for www.hireahelpermail.com have been accepted.
> Generating a new certificate signing request.
> Requesting a certificate.
box.hireahelpermail.com, hireahelpermail.com, www.hireahelpermail.com:
Something unexpected went wrong: Error creating new cert :: Too many certificates already issued for exact set of domains: box.hireahelpermail.com,hireahelpermail.com,www.hireahelpermail.com
root@box:/etc/cron.d#
Thanks, @cromulus - even though I’m not getting an SSL error, I tried those steps and it still spits out same message:
root@box:~/mailinabox# ./management/ssl_certificates.py
box.hireahelpermail.com, hireahelpermail.com, www.hireahelpermail.com:
Something unexpected went wrong: Error creating new cert :: Too many certificate s already issued for exact set of domains: box.hireahelpermail.com,hireahelperma il.com,www.hireahelpermail.com
I’m wondering if this all started around the time there was the SSL upgrade/weird bugs in MIAB. I did log in to both my MIAB boxes and run commands (I believe from @joshdata elsewhere on this forum) to get things fixed after upgrading.
I’ve also tried re-running the MIAB install/upgrade command, rebooting, no change. Both of my boxes now have expired certs :-/
Since about the start of January the box has been requesting new certs every day. It looks like they are being issued properly which is why Lets Encrypt is starting to rate limit the requests.
What makes this worse is that I tried moving to a new box to see if that fixes it, and ran into issues with the guide: https://github.com/mail-in-a-box/mailinabox/issues/1071 - and I don’t know how to proceed from there. So I’m just stuck. Both of my boxes now have expired certs, so I may need to buy a real SSL cert or something.
I just commented out command to renew certs from the cron script. Open /home/root/mailinabox/management/daily_tasks.sh (or something like that, I’m writing from memory) and comment out the line with ssl_certificates.py (or something like that). I don’t see any new certificates on https://crt.sh today so I think its working.
Have you been able to diagnose why the certificates that are issued aren’t being saved?
You could try diagnosing by switching to the Let’s Encrypt staging server. To do so, edit management/ssl_certificates.py and modify the two places that client.issue_certificate is called – in my checkout of 0.21b the functions are called on line 332 and on line 351.
Thanks. Very strange. I updated the code and re-ran ssl_certificates.py - and I’m getting the same error! Seems unlikely since I haven’t do anything regarding their staging server, ever. Maybe this means there’s something amiss with the actual ACME client.
FYI: the staging server doesn’t produce valid certificates nor does it have a rate limit. That’s why @benschumacher suggested it. If the staging server produced the rate limit error, it’s not actually letsencrypt rate limiting you.
Very odd. Why would I be getting a rate error? Possible bug in ACME client or something else? It definitely changed the source code of the ssl_certificates.py file - I even put a print(“testing”) statement in there to make sure it was working.
I disabled the nightly ssl_certificates.py call two nights ago - and now just manually ran ssl_certificates (pointed at LetsEncrypt staging still supposedly) and it gave me… a totally valid certificate.
So I guess my problem is “fixed” for now, but that doesn’t answer:
How did MIAB get in this state to begin with?
What’s the long term fix (since I should be able to run the ssl_certificates.py nightly?)
Why isn’t the ACME client changing the server URL when passed into the method call?
I’m a C# programmer by trade, so I’m not really familiar with python enough to diagnose.
So, my hunch is that the pyOpenSSL version was outdated and incorrectly validating the ssl certificate downloaded from letsencrypt. Because validation failed, MIAB didn’t save it and thus when the cron job ran again the next day, MIAB requested another certificate. This caused MIAB to hit the rate limit.
Upgrading your pyOpenSSL package and then waiting for the rate limit to expire resulted in your ability to get a new, valid cert.
What’s the long term fix (since I should be able to run the ssl_certificates.py nightly?)
Everything should just work now. I think we might need to be more rigorous about the version of our python packages and the packages that are installed on a MIAB install.
Why isn’t the ACME client changing the server URL when passed into the method call?
Not sure what you are asking here. There is only one Lets Encrypt production URL. The staging url is only meant really for developing ACME clients or testing an implementation.