Using Let's Encrypt with Kerio Connect

Using Let's Encrypt with Kerio Connect

This is an updated version of my original post.
As Let’s Encrypt is probably the best thing happening to the internet for the last decade or two, I wanted to use the certificates with a Kerio Connect installation at a customer. The software documentation advises you to copy and paste the certificate information via their admin web interface. Let’s Encrypt certificates expire every 90 days, so that’s just not an option for a lazy (read: productive, smart) system administrator. The instance I set this up on is running on Debian Jessie and performed flawless so far. Here’s how you do it.

Turn off HTTP

Stop the HTTP service if it is running. Set it to start manually so it won’t activate itself again on restart. Change the HTTPS service port to 8843 in the admin panel. The setup won’t work otherwise because Certbot needs ports 80 and 443 to verify the domain and get the certificate. If you want to renew the certificates automatically, this is essential.

Install Nginx

Since we don’t want to end up doing things manually, and also be able to use standard web ports, we need to set up a reverse proxy in front of Kerio Connect. This is an established practice for all kinds of web applications. It enables us to let the certificate process run without interaction — with the added benefit of being able to host other services and websites on the same server, should we want to.
First, we need to create a web root.
mkdir -p /var/www/mail
chown www-data:www-data /var/www/mail
Then we install nginx and the ssl-cert package, so we have easy access to a self-signed SSL certificate.
apt-get install nginx ssl-cert
Create a file called /etc/nginx/sites-available/kerio-connect.conf with the following content:
server {
listen 80;
server_name mail.example.com;
server_name_in_redirect off;
rewrite ^ https://$server_name$request_uri? permanent;
} server { listen 443 ssl; server_name mail.example.com;
ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;
ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem; location /.well-known { alias /var/www/mail/.well-known;
proxy_set_header X-Real-IP $remote_addr;
} location / { proxy_pass https://localhost:8843; proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Remote-Port $remote_port; proxy_redirect off; }
Link the file to make it an active site.
ln -s /etc/nginx/sites-available/kerio-connect.conf /etc/nginx/sites-enabled/kerio-connect.conf
Check if the configuration is correct.
nginx -t
If there are no errors, restart Nginx.
systemctl restart nginx.service

Get Certbot

wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto
Run it once without any parameters to check for dependencies.

Create the Certificate

Here, we set a webroot for Certbot to put the test files in so it won’t need to open up the ports 80 and 443, which would fail as they are now in use by Nginx.
./certbot-auto certonly --webroot -w /var/www/mail -d mail.example.com
If you’re running this the first time, you’ll need to enter your email address for emergency usage like revoking a certificate. This only needs to be done once.
Congratulations, you now have a valid SSL certificate on your server.

Actually Using the Certificate

Edit /etc/nginx/sites-available/kerio-connect.conf and change
ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;
to the location of our real certificate
ssl_certificate /etc/letsencrypt/live/mail.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mail.example.com/privkey.pem;
Restart Nginx.
To make renewal easy for Kerio Connect, just link the created certificate and key to the appropriate folder inside the Kerio Connect hierarchy.
ln -s /etc/letsencrypt/live/mail.example.com/fullchain.pem /opt/kerio/mailserver/sslcert/mail.crt
ln -s /etc/letsencrypt/live/mail.example.com/privkey.pem /opt/kerio/mailserver/sslcert/mail.key
Now open the admin panel, select Configuration > SSL Certificates and see your certificate appear. Select it and set as active.
That’s it.


Just run:
./certbot-auto renew
Since we want to automate renewal, set up a cronjob to run periodically. If the certificate is close to expiring, it will be renewed automatically, otherwise it will be kept until the next run.
First copy Certbot to a convenient location. I recommend /usr/local/bin.
cp certbot-auto /usr/local/bin/
Services need to be restarted after a successful renewal to pick up the new certificate. Create a script /root/certbot-post-hook.sh with the following content:
systemctl restart nginx.service
systemctl restart kerio-connect.service
Make it executable and secure it.
chmod 500 /root/certbot-post-hook.sh
chown root:root /root/certbot-post-hook.sh
Create a cronjob file at /etc/cron.d/certbot:
0 3 * * * root perl -e 'sleep int(rand(3600))' && certbot-auto -q renew --post-hook "/root/certbot-post-hook.sh"
This entry will run once a day at 3 am as root, sleep for a random number of minutes and run Certbot. The --post-hook parameter is run only when the certificate was in fact replaced, effectively restarting Nginx and Kerio Connect only when needed. The Certbot website recommends running the renewal command two times a day. However, in a production setting, restarting a mail server process as heavy as that Java behemoth Kerio Connect during work hours is often not feasible. Adjust the timing as needed. More than two times a day is overkill and won’t make your certificate renewal more reliable.


If you’re still running an unsecured mail server, now is the time to change that. It will cost you about 30 minutes and you probably will never have to worry about it again.

Food for Thought

Do yourself a favor and check out ModoboaMail-in-a-Box or iRedMail for a more lightweight, more scalable, way more flexible and seriously more performant open source alterative. They leverage the best components for the job and combined with a webmail frontend like RainLoop even look better. For full groupware functionality, consider adding SOGo to the stack. Sure, you’ll need to dig into Postfix, Dovecot and the glue holding it together. In the long run you’ll be happy you did. Because you will have freed yourself from having to pay for every mailbox over and over again every year, just to receive critical security updates, all the while throwing ever more resources at Kerio so it will continue to run smoothly. Better donate 25% of your current yearly bill to those open source projects. You save, they win.
Here’s an idea: set a mail server up as a cheap VPS for you and your friends/trusted colleagues. Test it thoroughly and work out the kinks. Read, learn, research, peruse log files, break it, repair it – be a nerd. I bet you’ll like it.
As a system administrator within a small to medium business setting with lots of Outlook clients, you may want to hold off though. Arguably, Kerio Connect works in such a setting and you shouldn’t add a possible pain point execs could grill you over. If something breaks, it’s Kerio’s fault, not yours. The same reason I suppose many companies still employ Microsoft software: execs know it and if it breaks, they can shout at a Microsoft representative, not the IT guy.


[GlusterFS]SOFTLINK for Common Data

root@ns563942_Mail01:/opt/gfs# uname -a
Linux ns563942_Mail01 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

root@ns563942_Mail01:/opt/gfs# cat /etc/lsb-release

root@ns563942_Mail01:/opt/gfs# cat /proc/cpuinfo | grep Xeon
model name      : Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz
model name      : Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz
model name      : Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz
model name      : Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz
model name      : Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz
model name      : Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz
model name      : Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz
model name      : Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz

root@ns563942_Mail01:/opt/gfs# cat /proc/meminfo | grep Total
MemTotal:       32719044 kB
SwapTotal:        523260 kB
VmallocTotal:   34359738367 kB
CmaTotal:              0 kB
HugePages_Total:       0

root@ns563942_Mail01:/opt/gfs# fdisk -l|  grep dev/s
Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
/dev/sda1      2048    1048575    1046528  511M EFI System
/dev/sda2   1048576    2095103    1046528  511M Linux filesystem
/dev/sda3   2095104   43053055   40957952 19.5G Linux filesystem
/dev/sda4  43053056   44099583    1046528  511M Linux swap
/dev/sda5  44099584 3907012607 3862913024  1.8T Linux LVM
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
/dev/sdb1   2048 3907029134 3907027087  1.8T Linux filesystem

root@ns563942_Mail01:/opt/gfs# lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
sda                         1.8T           
├─sda1         vfat         511M /boot/efi  EFI_SYSPART
├─sda2         ext4         511M /boot      /boot
├─sda3         ext4        19.5G /          /
├─sda4         swap         511M [SWAP]     swap-sda4
└─sda5         LVM2_member  1.8T           
  ├─vg-lv01var ext4          20G /var       /var
  └─vg-lv02opt ext4         3.6T /opt       /opt
sdb                         1.8T           
└─sdb1         LVM2_member  1.8T           
  └─vg-lv02opt ext4         3.6T /opt       /opt


#GlusterFS 2 node:
#/etc/hosts: gfs01 gfs02

apt-get install software-properties-common
add-apt-repository ppa:gluster/glusterfs-4.1
apt-get update
apt-get install glusterfs-server
service glusterd start
service glusterd status
#systemctl | grep gluster

sudo systemctl enable glusterd.service
sudo service glusterd.service start

#Testing on 2 node:
gluster peer probe gfs02
gluster peer status

gluster peer probe gfs01
gluster peer status

#GFS01: Creating new VOLUME. Volumename = "volume1"
#gluster volume create volume1 replica 2 transport tcp gfs01:/opt/.gfserver gfs02:/opt/.gfserver force
gluster volume start volume1
gluster volume info
gluster volume profile volume1 info
gluster volume profile volume1 start
gluster volume profile volume1 info
gluster volume status

#TEST GFS01 + GFS02:
gluster pool list
gluster peer status

#If you want to delete current volume:
gluster volume stop volume1
gluster volume delete volume1

#service glusterd restart

#Cài đặt GLUSTER thành công. Tiến hành MOUNT ổ đĩa để hệ điều hành tự nhận mỗi khi reboot:
#mkdir -p /opt/gfs
#mount -t glusterfs gfs01:/volume1 /opt/gfs
#echo "gfs01:/volume1 /opt/gfs glusterfs defaults 0 0" >> /etc/fstab
#mkdir -p /opt/gfs
#mount -t glusterfs gfs02:/volume1 /opt/gfs
#echo "gfs02:/volume1 /opt/gfs glusterfs defaults 0 0" >> /etc/fstab

apt-get install iozone3

mkdir -p $IOZONE
echo "iozone -w -c -e -i 0 -+n -r 64k -s 1024m -t 8 -F f{0,1,2,3,4,5,6,7,8}.ioz"  > network.performance.load.test.sh
chmod +x network.performance.load.test.sh















[OVH-SP-32-S] Build SSD LVM

A/ Install OS from OVH UBUNTU 16.04 TEMPLATE
A.1/ /dev/sda

/boot: 500MB
/: 20GB
swap: default

/var: lv01: 20GB
/opt: lv02: remain

A.2/ dev/sdb
+Add to LVM, lv02


watch -n 5 "COLUMN= lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL;pvs;vgs;lvs;df -h;date;"

#Change LVM INFO:
nano /etc/lvm/lvm.conf
        #QWERTY: ORIGIN:
#       locking_type = 1
        locking_type = 0

#Disable iptables:            
service netfilter-persistent flush


fdisk /dev/sdb

mkfs.ext4 /dev/sdb1

root@ns563707 /# pvcreate /dev/sdb1
WARNING: ext4 signature detected on /dev/sdb1 at offset 1080. Wipe it? [y/n]: y
  Wiping ext4 signature on /dev/sdb1.
  Physical volume "/dev/sdb1" successfully created
root@ns563695 /# vgextend  vg /dev/sdb1
  Volume group "vg" successfully extended


lvresize -l +100%FREE --resizefs  /dev/vg/lv02


A Guide to Common Types of Two-Factor Authentication on the Web

Two-factor authentication (or 2FA) is one of the biggest-bang-for-your-buck ways to improve the security of your online accounts. Luckily, it's becoming much more common across the web. With often just a few clicks in a given account's settings, 2FA adds an extra layer of security to your online accounts on top of your password.
In addition to requesting something you know to log in (in this case, your password), an account protected with 2FA will also request information from something you have (usually your phone or a special USB security key). Once you put in your password, you'll grab a code from a text or app on your phone or plug in your security key before you are allowed to log in. Some platforms call 2FA different things—Multi-Factor Authentication (MFA), Two Step Verification (2SV), or Login Approvals—but no matter the name, the idea is the same: Even if someone gets your password, they won't be able to access your accounts unless they also have your phone or security key.
There are four main types of 2FA in common use by consumer websites, and it's useful to know the differences. Some sites offer only one option; other sites offer a few different options. We recommend checking twofactorauth.org to find out which sites support 2FA and how, and turning on 2FA for as many of your online accounts as possible. For more visual learners, this infographic from Access Now offers additional information.
Finally, the extra layer of protection from 2FA doesn't mean you should use a weak password. Always make unique, strong passwords for each of your accounts, and then put 2FA on top of those for even better log-in security.


When you enable a site's SMS 2FA option, you'll often be asked to provide a phone number. Next time you log in with your username and password, you'll also be asked to enter a short code (typically 5-6 digits) that gets texted to your phone. This is a very popular option for sites to implement, since many people have an SMS-capable phone number and it doesn't require installing an app. It provides a significant step up in account security relative to just a username and password.
There are some disadvantages, however. Some people may not be comfortable giving their phone number—a piece of potentially identifying information—to a given website or platform. Even worse, some websites, once they have your phone number for 2FA purposes, will use it for other purposes, like targeted advertising, conversion tracking, and password resets. Allowing password resets based on a phone number provided for 2FA is an especially egregious problem, because it means attackers using phone number takeovers could get access to your account without even knowing your password.
Further, you can't log in with SMS 2FA if your phone is dead or can't connect to a mobile network. This can especially be a problem when travelling abroad. Also, it's often possible for an attacker to trick your phone company into assigning your phone number to a different SIM card, allowing them to receive your 2FA codes. Flaws in the SS7 telephony protocol can allow the same thing. Note that both of these attacks only reduce the security of your account to the security of your password.

Authenticator App / TOTP 2FA

Another phone-based option for 2FA is to use an application that generates codes locally based on a secret key. Google Authenticator is a very popular application for this; FreeOTP is a free software alternative. The underlying technology for this style of 2FA is called Time-Based One Time Password (TOTP), and is part of the Open Authentication (OATH) architecture (not to be confused with OAuth, the technology behind "Log in with Facebook" and "Log in with Twitter" buttons).
If a site offers this style of 2FA, it will show you a QR code containing the secret key. You can scan that QR code into your application. If you have multiple phones you can scan it multiple times; you can also save the image to a safe place or print it out if you need a backup. Once you've scanned such a QR code, your application will produce a new 6-digit code every 30 seconds. Similar to SMS 2FA, you'll have to enter one of these codes in addition to your username and password in order to log in.
This style of 2FA improves on SMS 2FA because you can use it even when your phone is not connected to a mobile network, and because the secret key is stored physically on your phone. If someone redirects your phone number to their own phone, they still won't be able to get your 2FA codes. It also has some disadvantages: If your phone dies or gets stolen, and you don't have printed backup codes or a saved copy of the original QR code, you can lose access to your account. For this reason, many sites will encourage you to enable SMS 2FA as a backup. Also, if you log in frequently on different computers, it can be inconvenient to unlock your phone, open an app, and type in the code each time.

Push-based 2FA

Some systems, like Duo Push and Apple's Trusted Devices method, can send a prompt to one of your devices during login. This prompt will indicate that someone (possibly you) is trying to log in, and an estimated location for the login attempt. You can then approve or deny the attempt.
This style of 2FA improves on authenticator apps in two ways: Acknowledging the prompt is slightly more convenient than typing in a code, and it is somewhat more resistant to phishing. With SMS and authenticator apps, a phishing site can simply ask for your code in addition to your password, and pass that code along to the legitimate site when logging in as you. Because push-based 2FA generally displays an estimated location based on the IP address from which a login was originated, and most phishing attacks don't happen to be operated from the same IP address ranges as their victims, you may be able to spot a phishing attack in progress by noticing that the estimated location differs from your actual location. However, this requires that you pay close attention to a subtle security indicator. And since location is only estimated, it's tempting to ignore any anomalies. So the additional phishing protection provided by push-based 2FA is limited.
Disadvantages of push-based 2FA: It's not standardized, so you can't choose from a variety of authenticator apps, and can't consolidate all your push-based credentials in a single app. Also, it requires a working data connection on your phone, while Authenticator apps don't require any connection, and SMS can work on an SMS-only phone plane (or in poor signal areas).

FIDO U2F / Security Keys

Universal Second Factor (U2F) is a relatively new style of 2FA, typically using small USB, NFC or Bluetooth Low Energy (BTLE) devices often called "security keys." To set it up on a site, you register your U2F device. On subsequent logins, the site will prompt you to connect your device and tap it to allow the login.
Like push-based 2FA, this means you don't have to type any codes. Under the hood, the U2F device recognizes the site you are on and responds with a code (a signed challenge) that is specific to that site. This means that U2F has a very important advantage over the other 2FA methods: It is actually phishing-proof, because the browser includes the site name when talking to the U2F device, and the U2F device won't respond to sites it hasn't been registered to. U2F is also well-designed from a privacy perspective: You can use the same U2F device on multiple sites, but you have a different identity with each site, so they can't use a single unique device identity for tracking.
The main downsides of U2F are browser support, mobile support, and cost. Right now only Chrome supports U2F, though Firefox is working on an implementation. The W3C is working on further standardizing the U2F protocol for the web, which should lead to further adoption. Additionally, mobile support is challenging, because most U2F devices use USB.
There are a handful of U2F devices that work with mobile phones over NFC and BTLE. NFC is supported only on Android. On iOS, Apple does not currently allow apps to interact with the NFC hardware, which prevents effective use of NFC U2F. BTLE is much less desirable because a BTLE U2F device requires a battery, and the pairing experience is less intuitive that tapping an NFC device. However, poor mobile support doesn't mean that using U2F prevents you from logging in on mobile. Most sites that support U2F also support TOTP and backup codes. You can log in once on your mobile device using one of those options, while using your phishing-proof U2F device for logins on the desktop. This is particularly effective for mobile sites and apps that only require you to log in once, and keep you logged in.
Lastly, most other 2FA methods are free, assuming you already have a smartphone. Most U2F devices cost money. Brad Hill has put together a review of various U2F devices, which generally cost USD $10-$20. GitHub has written a free, software-based U2F authenticator for macOS, but using this as your only U2F device would mean that losing your laptop could result in losing access to your account.

Bonus: Backup Codes

Sites will often give you a set of ten backup codes to print out and use in case your phone is dead or you lose your security key. Hard-copy backup codes are also useful when traveling, or in other situations where your phone may not have signal or reliable charging. No matter which 2FA method you decide is right for you, it's a good idea to keep these backup codes in a safe place to make sure you don't get locked out of your account when you need them.
Source: https://www.eff.org/deeplinks/2017/09/guide-common-types-two-factor-authentication-web?fbclid=IwAR1MuTpnQAxw-FOg_Id8wA_CmgRvn3_LjmSBaAJtsFf8WsDXa_mG6r12BSw