debian, linux, networking, nextcloud, raspberrypi, 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.

Configuration

  • 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.

Installation

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).

Then,

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

Details

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.

Code

github

References

https://wiki.archlinux.org/index.php/Let%u2019s_Encrypt

https://certbot.eff.org/docs/using.html

https://letsencrypt.org/getting-started/

 

Author: nachoparker

Humbly sharing things that I find useful [ github dockerhub ]

10 Comments on “Let’s Encrypt installer for Apache

  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?
    thx

  2. I have some odd problem…

    Entered:

    The config application comes up with…

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

    This comes up…

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

    I enter…

    I get this in return…

    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. it seems to me that you are writing .installer instead of ./installer.sh.

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

      Note that you have to change 192.168.0.130 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.

      ./installer.sh whatevernewthing.sh

      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 website.com:9000 but I cannot enter website.com:9000 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.

Leave a Reply

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