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.


  • DOMAIN is the URL to access from outside and inside your house. Use the same one you signed up with no-ip.org 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.


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

Do it yourself

First, clone the repo

Online installation through SSH

Use the generic software installer with the script letsencrypt.sh

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.

Offline installation (Raspbian)

You can do this process offline using QEMU.

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


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


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

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








Humbly sharing things that I find useful [ github | gist ]