Over the past few days when I’ve logged in to my MIAB I’ve seen
The TLS (SSL) certificate has a problem: The certificate has expired or is not yet valid. It is valid from 2018-07-12 19:16:27 to 2018-10-10 19:16:27.
This is for the box.mydomain.com certificate. I started to panic yesterday. Looking around here I found people who said I just needed to run sudo mailinabox and it would get a new certificate after asking me to agree to the certbot TOS. That didn’t happen. Digging a bit further I found a suggestion to run ssl_certificates.py. This produces an error
Traceback (most recent call last):
File “/root/mailinabox/management/./ssl_certificates.py”, line 660, in
provision_certificates_cmdline()
File “/root/mailinabox/management/./ssl_certificates.py”, line 372, in provision_certificates_cmdline
status = provision_certificates(env, limit_domains=domains)
File “/root/mailinabox/management/./ssl_certificates.py”, line 348, in provision_certificates
ret.extend(post_install_func(env))
File “/root/mailinabox/management/./ssl_certificates.py”, line 458, in post_install_func
if cert and os.readlink(system_ssl_certificate) != cert[‘certificate’]:
OSError: [Errno 22] Invalid argument: ‘/home/user-data/ssl/ssl_certificate.pem’
As you’ll observe this certificate has expired and my MIAB has now become semi-unusable. I’ve tried running certbot manually but I can’t figure the exact command to recreate the cert in a way that MIAB can use it - it does create it in the certbot/live folder.
As I mentioned, I’ve found things like this
If you recently upgraded (to 0.28) Let’s Encrypt changed something on their end which is causing the MiaB install script to skip their request to accept their ToS. Typically rerunning sudo mailinabox will fix this.
But that doesn’t happen. The MIAB installer runs without an error though.
Anyone have any suggestions on why this cert didn’t renew and/or how I can renew it?
The TLS (SSL) certificate for this domain is currently self-signed. You will get a security warning when you check or send email and when visiting this domain in a web browser (for webmail or static site hosting).
Also, I forgot to mention, I don’t get any helpful errors in the logs. In fact, the logs seem to imply that everything is working fine.
2018-10-11 12:50:48,708:DEBUG:certbot.main:certbot version: 0.26.1 2018-10-11 12:50:48,708:DEBUG:certbot.main:Arguments: ['-q'] 2018-10-11 12:50:48,708:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot) 2018-10-11 12:50:48,721:DEBUG:certbot.log:Root logging level set at 30 2018-10-11 12:50:48,723:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log 2018-10-11 12:50:48,740:DEBUG:certbot.plugins.selection:Requested authenticator <certbot.cli._Default object at 0x7f83870c8588> and installer <certbot.cli._Default object at 0x7f83870c8588> 2018-10-11 12:50:48,759:INFO:certbot.renewal:Cert not yet due for renewal 2018-10-11 12:50:48,760:DEBUG:certbot.plugins.selection:Requested authenticator standalone and installer None 2018-10-11 12:50:48,760:DEBUG:certbot.renewal:no renewal failures
So a certificate that has expired is being reported as certbot.renewal:Cert not yet due for renewal
Running ssl_certificates.py now works but with the self-signed cert it says
skipped: mydomain.com The domain has a valid certificate already. (The certificate expires in 74 days on 12/25/18. Certificate: /home/user-data/ssl/box.mydomain.com-20181225-867a8c88.pem, private key /home/user-data/ssl/ssl_private_key.pem)
If I put the old one back, the error returns so removing /home/user-data/ssl/ssl_certificate.pem appears to be relevant but isn’t the solution.
I had the same issue. Running sudo mailinabox gave me the LetsEncrypt TOS agreement prompt. After doing this I was able to login to the admin console and press the Provision button.
Just to be clear I’m NOT seeing this problem. I don’t get the error You should register before running non-interactively, or provide --agree-tos and --email <email_address> flags and running sudo mailinbox completes without errors but doesn’t ask me to agree to the LE ToS. The problem I originally reported in this thread is NOT related - as far as I can see - to the LetsEncrypt ToS problem which is covered in lots of other posts.
I am kind of lost as to what is the exact status at this point … when you put the old what back?
You should now have a NEW DIFFERENT /home/user-data/ssl/ssl_certificate.pem than you had originally if you followed Josh’s instruction. So exactly what else have you done?
As an aside: contrary to the thread title - the SSL Certificate renewal did indeed happen. The question now is why is the cert not being used? I think my first step would be to reload nginx.
I changed /home/user-data/ssl/ssl_certificate.pem to /home/user-data/ssl/ssl_certificate.old.
I restarted the machine and re-ran sudo mailinabox. I then logged in to https://1.2.3.4 - not the box FQDN - and the error message has changed to being about the certificate being self signed.
Different message, not progress. And since certificates aren’t being generated I’d sensibly made a back up of the one that was already there. So I removed /home/user-data/ssl/ssl_certificate.pem and renamed /home/user-data/ssl/ssl_certificate.old to /home/user-data/ssl/ssl_certificate.pem, restarted and tried again. Back to the message about the certificate having expired.
I think my first step would be to reload nginx.
Pretty sure about 50 restarts and a similar number of sudo mailinabox’s would have achieved that but for the record I just tried it. No difference.
the SSL Certificate renewal did indeed happen. The question now is why is the cert not being used?
The fact that removing the certificate changes the error to being a self signed certificate and then removing the self signed cert and putting the other one back changes to the message about the cert having expired would imply - in fact it confirms - that a relevant and useful certificate is not being created. A certificate is being created and nginx is using it because the error message changes depending on which cert is in place. But it’s not the cert for my domain which would be much more useful.
In rereading my last reply, it seems that some parts of what I intended to quote did not actually get included in the quote … so ignore my last reply and focus on this please.
Rereading your OP, it seems that you had indeed rerun ssl_certificates.py, but it is not mentioned that you removed the contents of the /home/user-data/ssl/ directory first.