Hi, MIAB is unable to update the SSL certificate and I don’t know why. Where’s the debug log?
I thought it was because I was using version 0.30 so tried to upgrade but it still won’t create a certificate. The other threads I’ve found on here have unrelated advice about deleted a folder under the letsencrypt directory or changing the DNS server but I’ve tried both and neither does a thing.
I am working on trying to get the new version working.
How can I tell it to try again? Rebooting has no effect.
EDIT: There are no errors shown in /var/log/letsencrypt/letsencrypt.log only DEBUG and INFO messages.
running /root/mailinaboxe/management/ssl_certificates.py makes the System->TLS (SSL Certificates) page say “Self-signed. Get a signed certificate to stop warnings. The domain name does not resolve to this machine:” but this is wrong. I have checked that the A record does point to that server and it resolves this way both on the host and on other machines I’ve tried.
Hi - you’ve not really given enough information to know what is going wrong … what exactly have you tried, and what exact output did you get? We need some kind of a starting point.
I don’t know what to tell you, MIAB is a pretty closed box until you have to dive into the config. I’m poking around files trying to figure things out now and updating my post as I go but, really, all I can say is that it’s not updating the certificate because that’s all MIAB tells me.
Ok, well MiaB does return a lot of information if you know what you are looking at.
So as I mentioned, we need a starting point … you said that you upgraded … is your upgrade completely functional except for the SSL certificate? IOW - all mailboxes restored from backup, etc? If so that is likely a good place to start.
You just added this info to your OP …
So regardless of what you know and think, MiaB thinks differently … so let’s dive into this…
Would you be willing to provide your MiaB’s hostname (in PM is fine)? That will help diagnose things.
The original box, Box_A, with version 0.30 is still running and the new version of MIAB is on Box_B. All DNS is pointed at Box_A and I have enabled the firewall rules again so that it will receive any inbound mail, albeit with the SSL error so it probably isn’t receiving much of anything.
Box_A is currently using a self-signed certificate after running ssl_certificates.py. Prior to this it said the certificate had expired.
Box_B is also using a self-signed certificate.
Neither box shows errors in the letsencrypt log.
I just found the command to trigger cert renewal, here’s the result from Box_A:
root@mailsrv:~# certbot -q renew
root@mailsrv:~# tail /var/log/letsencrypt/letsencrypt.log
2019-06-28 12:21:50,845:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint #webroot)
2019-06-28 12:21:50,858:DEBUG:certbot.log:Root logging level set at 30
2019-06-28 12:21:50,859:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2019-06-28 12:21:50,860:DEBUG:certbot.renewal:no renewal failures
2019-06-28 20:26:22,262:DEBUG:certbot.main:certbot version: 0.31.0
2019-06-28 20:26:22,263:DEBUG:certbot.main:Arguments: [‘-q’]
2019-06-28 20:26:22,263:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint #webroot)
2019-06-28 20:26:22,279:DEBUG:certbot.log:Root logging level set at 30
2019-06-28 20:26:22,280:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2019-06-28 20:26:22,281:DEBUG:certbot.renewal:no renewal failures
So my original question wrt box B still stands … is it completely functioning other than the SSL? It makes no sense to fix box A and then redo the backup/reinstall unless you are receiving email now as we speak and that will create issues…
Which provider are you using?
That was Box_A
I don’t know if Box_B is fully functional because everything is throwing SSL errors. However, because this problem affects both servers I suspect the fix will be the same.
Box_A is the live machine so I would like to get that working and then I can redo the backup/restore afterwards. This isn’t a critical production box, it’s just my personal email and a few family members, but I’d prefer not to lose any email.
Please come to Slack … this will be so much easier there.
If that is not an option we can try to do this here in PM,
The solution was to add the IPv6 IP address to the external DNS.
No idea why this is suddenly a problem with LE … I will be asking on their forum.
@FrogLettuce Slack quit sending messages to you which is why I went silent there.
Slack is being weird. Yes, the solution was to add the AAAA record for the IPv6 address on my DNS provider. Thanks @alento for all your help!
I have opened an issue on Github concerning this as this is not the first time this week that I have helped someone with this problem.
If it helps, I’m not sure that my droplet was created with an IPv6 address. I don’t remember adding it manually but I certainly could have done and if that’s the case then this problem might have been because DigitalOcean doesn’t add the PTR automatically if IPv6 is assigned after creation. There’s also no way add a PTR manually from what I can tell. I’ve opened a ticket with them about this.
I don’t see how the PTR record would have any bearing on the certificate issuance.
It is not clear to me why a lack of an IPv6 address causes this issue as LE doesn’t require one (unless things have changed on their end). Also, why did MiaB not look up the IPv4 when the IPv6 failed …
If you have not destroyed box b yet, will you do a test please … add the IPv6 to Cloudflare and see what shows in the admin area TLS page … does it still report DNS not resolving to the server?
Ah, yes, I’m getting confused over DNS records again. The PTR is irrelevant to the issue here.
Sorry, I’ve already destroyed the test box. Now planning to do the upgrade & preserve IP sometime tomorrow.
No worries! Good luck tomorrow.