FOSS, linux, networking, nextcloudpi, security

Let’s Encrypt installer for Apache

This installer provides a really easy way of installing a signed certificate with Let’s Encrypt for an Apache server.


Note that you need to have both ports 80 and 443 accessible for the authentication challenge to work

  • DOMAIN is the URL to access from outside and inside your house. Use the same one you signed up with or any other DDNS provider. Your website must be accessible from the internet.
  • EMAIL in case ISRG has to contact you.
  • VHOSTCFG leave untouched for NextCloudPi. Otherwise, point to the configuration file for your virtual host that contains DOMAIN.

Your certificate will be automatically renewed every month.


Get it already made

I have included this in the latest release of my NextCloudPi, a ready to use Raspbian 8 image featuring NextCloud 11, HTTP2, PHP7 and more.

Follow the instructions provided. Once up and running, from your Raspberry Pi write

sudo nextcloudpi-config
Do it yourself

First, clone the repo

git clone
Online installation through SSH

Use the generic software installer with the script


Adjust to the IP address of your server.

This process is optimized for the Raspberry Pi, but should work in any system that certbot supports. If you are not using the default username and password for the Raspberry Pi, you can specify username and/or password in the command line.

PIUSER=nacho PIPASS=ownyourbits ./
Offline installation (Raspbian)

You can do this process offline using QEMU.

Extract the SD card and copy the image to your computer (adjust sdx).

 sudo dd if=/dev/sdx of=my_rpi.img bs=4M


./ my_rpi.img

Once done, you can copy it back (adjust sdx).

sudo dd if=my_rpi.img if=/dev/sdx bs=4M


We have always faced a bitter situation whenever we are setting up a self-hosted service.

Wether it is your own private cloud, a REST service or any other service that runs over HTTPS such as WebDav or CalDav, it doesn’t matter: HTTPS is a must, but the only choice most people have is to self-sign your own certificates.

Our systems rely on Certificate Authorities (CA) as a trusted third party to validate HTTPS connections. This is the method the web uses to prevent man-in-the-middle attacks where somebody can fake to be the server you are trying to connect to.

With self-signed certificates, the communication is encrypted end to end, but we cannot verify the identity of the other end. Browsers make it very clear that there might be a risk in the connection.

This means that you and any other user will have to be accepting exceptions for untrusted certificates which not only looks really awkward, but in many cases it is a barrier for non technical users.

Even if you accept the connection, the warning will stay there as a reminder. Android is another example where self-signed certificates produce a warning in every boot.

In addition to this, many clients for REST services will not give you the option to work with self-signed certificates. This is the case with some Android Apps that use NextCloud.

Even if they allow it, there is an extra step of copying the self-signed certificate to your phone and installing it. Definitely not the most fun thing to do.

This has been the situation for a long time.

Thankfully the Internet Security Research Group (ISRG) came to our rescue. They provide a public and free service where they verify your certificate thus introducing it in the trust chain.

Also, the EFF provides Certbot, an automatic client that fetches and deploys SSL/TLS certificates for your webserver to use with Let’s Encrypt.


The process is automated for a number of distributions and it

  • Generates the certificates, like you would with openssl
  • Performs a challenge to authenticate the server using the ACME protocol. This is why you need connectivity at the moment of configuration.
  • Optionally deploys the keys and configures the server for a number of popular solutions

After this, Let’s Encrypt, which is a CA authority already trusted and present in your system will validate your server’s identity to the browser.

This is the output of the process

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for
Waiting for verification...<em></em>
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0000_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0000_csr-certbot.pem
Deploying Certificate to VirtualHost /etc/apache2/sites-available/nextcloud.conf

Congratulations! You have successfully enabled

You should test your configuration at:

 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/ Your cert
   will expire on 2017-06-13. To obtain a new or tweaked version of
   this certificate in the future, simply run letsencrypt-auto again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "letsencrypt-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:
   Donating to EFF:          

Next time you try to open your self hosted service, the warning will be gone.



# Let's encrypt certbot installation on Raspbian 
# Tested with 2017-03-02-raspbian-jessie-lite.img
# Copyleft 2017 by Ignacio Nunez Hernanz <nacho _a_t_ ownyourbits _d_o_t_ com>
# GPL licensed (see end of file) * Use at your own risk!
# Usage:
#   ./ <IP> (<img>)
# See instructions for details
DESCRIPTION="Let's Encrypt: automatic signed SSL certificates"

  apt-get update
  apt install -y --no-install-recommends git 
  cd /etc
  git clone
  /etc/letsencrypt/letsencrypt-auto --help # do not actually run certbot, only install packages

# tested with git version v0.11.0-71-g018a304
  grep -q ServerName $VHOSTCFG_ && \
    sed -i "s|ServerName .*|ServerName $DOMAIN_|" $VHOSTCFG_ || \
    sed -i "/DocumentRoot/aServerName $DOMAIN_" $VHOSTCFG_ 

  /etc/letsencrypt/letsencrypt-auto -n --no-self-upgrade --apache --agree-tos -m $EMAIL_ -d $DOMAIN_
  echo "* 1 * * 1 root /etc/letsencrypt/certbot-auto renew --quiet" > /etc/cron.d/letsencrypt-ncp

  apt-get autoremove -y
  apt-get clean
  rm /var/lib/apt/lists/* -r
  rm -f /home/pi/.bash_history
  systemctl disable ssh

# License
# This script is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
# This script is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with this script; if not, write to the
# Free Software Foundation, Inc., 59 Temple Place, Suite 330,
# Boston, MA  02111-1307  USA



Author: nachoparker

Humbly sharing things that I find useful [ github dockerhub ]


  1. Hello,
    how about after i reinstall “NextCloudPi” ?
    How about my privat key .pem? Need i Backup this key on a stick before i reformate the SD Card?

  2. I have some odd problem…


    sudo nextcloudpi-config

    The config application comes up with…

    │ │         dnsmasq     "DNS server with cache"                            │ │
    │ │         fail2ban    "Brute force protection"                           │ │
    │ │         nc-datadir  "Change your data dir location"                    │ │
    │ │         nc-limits   "Configure system limits for NextCloudPi"          │ │
    │ │         no-ip       "free Dynamic DNS provider (need account)"         │ │

    There is no Let’s Encrypt. So I decide to install it…
    I type:

    git clone

    This comes up…

    fatal: destination path 'nextcloud-raspbian-generator' already exists and is not an empty directory.

    Ok, that makes sense. I had already done that part…

    I enter…


    I get this in return…

    -bash: .installer: command not found

    I’m at the ~ directory. I’m looking for a simple copy/paste set of instructions to get this option installed.

    Should I just re-download the full image and start over? The full image I downloaded, before, has no Let’s Encrypt configuration tool. Perhaps I just grabbed a full version before another came out.

    As my build is complete, loaded with data and themed, I cannot to a simple wipe-out and start as if doing it for the first time. So, any assistance in getting Let’s Encrypt put in, now, is greatly appreciated. Thank you for taking the imte to review this.

    – Shadowstreik

    1. -bash: .installer: command not found

      it seems to me that you are writing `.installer` instead of `./`.

      In any case, the path has changed, so the correct sequence would be

      rm -rf nextcloud-raspbian-generator
      git clone
      cd nextcloud-raspbian-generator
      ./ etc/nextcloudpi-config.d/

      Note that you have to change `` to the IP of your raspberry pi. It is printed on the screen when it boots.

      I hope it makes sense

      It is up to you wether you want to start over again. I developed the remote updates so people didn’t have to start over and over again, but I guess you will have to explore what are the new things and decide.

      In any case, I created the process from the beginning so that you can use the ‘generic installer’ to install most of the new things, just the way you tried to do.


      will still be an option for you

  3. Apparently my ISP blocks port 80 and 443, which is understandable for a residential internet provider. I can just port forward external port 9000 to internal port 443 and then go to but I cannot enter when trying to configure letsencrypt.

    Is there a better way to enable https so I don’t get the “untrusted domain” error message?

    1. You will have to manually run letsencrypt and investigate how to specify the port. Sorry I am on vacation on my phone, but I am sure there has to be a parameter

      Run `./letsencrypt –help` in the `/etc/letsencrypt` folder and look for the option to specify port, or google your problem.

  4. Great work. NextcloudPi is really the easiest way to deploy a Nextcloud instance at this moment. Regarding Let’s Encrypt: it requires renewal of the certificate every 30-something days or so. Wouldn’t an option like nc-letsencrypt-auto that does the renewal based on a cron-job make sense? It would save many of us a monthly visit to ssh (and most likely google) to renew the certificate manually.

  5. Hello,
    I was very glad to find your excellent NextcloudPI, because before I had to make long and cumbersome installation-procedures. Thanks for that!
    Now I tried to use letsencrypt to have an accepted certificate. After setting the router to the raspberrypi’s address the nextcloudPI was visible over the DNS-Address and I could even enter the nextcloudPI over the Internet, but without certificat (with the known warnings).
    When I used ncp-config to install letsencrypt, I got the following error: “The server could not connect to the client to verify the domain :: Fetching Timeout”
    The problem now is that in my nextcloudPI-server there is no directory “.well-known”. Is there an additional step nessessary that I forgot?
    Thanks for help,


Leave a Reply

Your email address will not be published. Required fields are marked *