Letsencrypt Certificate SymLink

Hi, I’ve been using the letsencrypt autocert script , which plunks my new certs under /etc/letsencrypt/archive/mail.example.com/cert1.pem , etc.

I see that dovecot uses a defined config statement, which points to /home/user-data/ssl/ssl_certificate.pem .

I created a symbolic link between the two, but for some reason, every day at 03:00 my ssl_certificate.pem file in /home/user-data/ssl keeps overriding the symlink and keeps linking to itself! Its breaking my mail in the middle of the night.

Am i goign about this right? Should i just point dovecot to the original under /etc/letsencrypt?

lrwxrwxrwx 1 root root 39 Feb 12 03:00 /home/user-data/ssl/ssl_certificate.pem -> /home/user-data/ssl/ssl_certificate.pem

From dovecot config in /etc/dovecot/conf.d/10-ssl.conf

#ssl_cert = </etc/dovecot/private/dovecot.pem
#ssl_key = </etc/dovecot/private/dovecot.key

No … I am curious why you have installed a separate LE client … MiaB already comes with one. MiaB is doing exactly what it is supposed to be doing, checking to see that the certificate is valid each day and replacing any ‘broken’ configs when it runs maintenance at 03h00.

I did not know that… ! ok, back to reading the docs.

From the main Main-in-a-Box homepage:

Please note that the goal of this project is to provide a simple, turn-key solution. There are basically no configuration options and you can’t tweak the machine’s configuration files after installation.


Getting a signed TLS (SSL) certificate

Use the TLS Certificates page of the control panel to provision a free TLS (SSL) certificate from Let’s Encrypt. If you don’t want to use Let’s Encrypt, you can also add any other certificate and import it in the box. The box will help you by generating a private key. Just follow the instructions given in the control panel.

So i will reinstall and use the defacto letsencrypt, my bad on that part.

One thing i will have to modify (i believe), is the reconfiguration to use a forwarder at amazon, specifically, a stunnel configuration and add the AWS key and secret to the sasl password db.

I’ll stay in touch here. Thank you.

I am sorry, but I don’t know exactly what you are referring to. Can you please elaborate so that someone can advise if there is indeed something you will have to do and how to best handle it?

I should be a bit more specific … you cannot tweak the configuration files of the pieces of the puzzle that make up the complete mail system as those configuration files will be overwritten when MiaB does it’s daily maintenance or when MiaB is upgraded to a new version. However, there are things that are not directly related to email that can indeed be tweaked. For example my SSH keys for login have been added. I have edited /etc/sshd_config to disallow root login and change the SSH port, etc. Those kinds of changes are not affected.

Using MiaB in AWS presents challenges with regards to trustworthiness. Many of the public (elasticIP) address ranges have been greylisted on several address lists. If you’re unlucky enough to have this problem, receiving ends may drop your email. This happened to me before.

AWS realises this and provides a service to forward emails. SES. They require that you update your DNS records with TXT to prove domain or email address ownership, and provide a dash to help you determine if your mail server is behaving correctly. The only catch is that you can directly receive inbound emails using MiaB, but when sending outside the box to the internet at large, you must use the SES forwarding service. Their servers are trusted. It’s way too easy for bad actors to stand up a fly-by-night mail spam server with AWS, and this is the resolution to help legit users, like me.

They require that you implement an SSL tunnel (stunnel) and provide SASL credentials for the forwarding device.

As such, the modifications for postfix’s main.cf are as follows:

relayhost =
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

The stunnel config is as follows:

ubuntu@ip-172-31-15-250:/media/OLD14/etc$ cat stunnel/stunnel.conf
accept = 2525
client = yes
connect = email-smtp.us-east-1.amazonaws.com:465  #or whatever they tell you
delay = yes
#cert = /etc/stunnel/mail.pem

The SASL password generation is private, and per AWS user. It must be binary’d using postfix map:

/etc/posfix/sasl_passwd: AWSKEY:AWSSECRET

In order to startup stunnel automatically, it is required:

/etc/default# more stunnel4
# /etc/default/stunnel
# Julien LEMOINE <speedblue@debian.org>
# September 2003

# Change to one to enable stunnel automatic startup

# Change to one to enable ppp restart scripts

Also, please understand that this is how i’ve been operating in the previous version of MiaB for years now. Only i’ve had to revisit all this since upgrading to the 18.04 supported version.

Ok, gotcha! That all makes sense. The stunnel won’t be affected, but I have to wonder if the modifications that you made to postfix’s main.cf are lost each time you do an upgrade? Or did you never upgrade versions while running on Ubuntu 14.04?

I suspect that they do survive, as there are people using an external SMTP relay, and honestly I have not heard anyone complaining that they lost their configs.

@alento: bingo.

So i just set up the box from scratch again :

Mail-in-a-Box uses Let's Encrypt to provision free SSL/TLS certificates
to enable HTTPS connections to your box. We're automatically
agreeing you to their subscriber agreement. See https://letsencrypt.org.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Registering without email!

 - Your account credentials have been saved in your Certbot
   configuration directory at /home/user-data/ssl/lets_encrypt. You
   should make a secure backup of this folder now. This configuration
   directory will also contain certificates and private keys obtained
   by Certbot so making regular backups of this folder is ideal.


Your Mail-in-a-Box is running.

I’ll poke around now some more. I hope my backup and restore using the guide method didn’t hurt anything…

great, i went to provision the cert that was auto-generated for me.

Now i hope that the backup and restore doens’t overwrite /home/user-data/ssl/ contents…

Provision certificates


The TLS certificate was provisioned and installed.


Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer None Performing the following challenges: http-01 challenge for mail.yourdomain.com Using the webroot path /home/user-data/ssl/lets_encrypt/webroot for all unmatched domains. Waiting for verification… Cleaning up challenges Server issued certificate; certificate written to /tmp/tmp4pt_9qzf/cert Cert chain written to 8 Cert chain written to 9 IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /tmp/tmp4pt_9qzf/cert_and_chain.pem Your cert will expire on 2019-05-14. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew all of your certificates, run “certbot renew” - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let’s Encrypt: etcetc Donating to EFF: etcetc

updating primary certificate

mail services restarted

web updated

It will … the entire /home/user-data/ is restored from the backup. Which will mean one of two things … your certificate which was previously used will be reinstalled, or in the unusual case that something goes tilt, you will need to delete contents of the /home/user-data/ssl/ directory and rerun sudo mailinabox.

OK, i’m working 100% now.

I used the scratch install and cert provision copy of /home/user-data/ssl instead of relying on an old one.

Now let’s see if it can survive for more than 24 hours!

Thanks for your help.