Using SSL with Friendica

This document has been updated in November 2016. SSL encryption is relevant for security. This means that recommended settings change fast. Keep your setup up to date and do not rely on this document being updated as fast as technologies change!

If you are running your own Friendica site, you may want to use SSL (https) to encrypt communication between servers and between yourself and your server.

There are basically two sorts of SSL certificates: Self-signed certificates and certificates signed by a certificate authority (CA). Technically, both provide the same valid encryption. There is a problem with self-signed certificates though: They are neither installed in browsers nor on other servers. That is why they provoke warnings about “mistrusted certificates”. This is confusing and disturbing.

For this reason, we recommend to get a certificate signed by a CA. Normally, you have to pay for them - and they are valid for a limited period of time (e.g. a year or two).

There are ways to get a trusted certificate for free.

Your SSL certificate will be valid for a domain or even only for a subdomain. Make your final decision about your domain resp. subdomain before ordering the certificate. Once you have it, changing the domain name means getting a new certificate.

If your Friendica instance is running on a shared hosting platform, you should first check with your hosting provider. They have instructions for you on how to do it there. You can always order a paid certificate with your provider. They will either install it for you or provide an easy way to upload the certificate and the key via a web interface. With some providers, you have to send them your certificate. They need the certificate, the key and the CA’s intermediate certificate. To be sure, send those three files. You should send them to your provider via an encrypted channel!

If you run your own server, we recommend to check out the “Let’s Encrypt” initiative. Not only do they offer free SSL certificates, but also a way to automate their renewal. You need to install a client software on your server to use it. Instructions for the official client are here. Depending on your needs, you might want to look at the list of alternative letsencrypt clients.

Visit the Mozilla’s wiki for instructions on how to configure a secure webserver. They provide recommendations for different web servers.

When you are done, visit the test site SSL Labs to have them check if you succeeded.

If you can successfully access your Friendica instance through https, there are a number of steps you can take to ensure your users will use SSL to access your instance.

This is the simplest way to enforce site-wide secure access. Every time a user tries to access any Friendica page by any mean (manual address bar entry or link), the web server issues a Permanent Redirect response with the secure protocol prepended to the requested URL.

With Apache, enable the modules rewrite and ssl (with a shared hosting provider, this should be enabled already):

    sudo a2enmod rewrite ssl

Add the following lines to the .htaccess file in the root folder of your Friendica instance (thanks to AlfredSK):

    RewriteEngine On
    RewriteCond %{SERVER_PORT} 80
    RewriteRule ^(.*)$ https://your.friendica.domain/$1 [R=301,L]

With nginx, configure your server directive this way (documentation):

    server {
         listen 80;
         server_name your.friendica.domain;
         return 301 https://$server_name$request_uri;

In the Admin Settings, there are three SSL-related settings:

  1. SSL link policy: this affects how Friendica generates internal links. If your SSL installation was successful, we recommend “Force all links to SSL” just in case your web server configuration can’t be altered like described above.
  2. Force SSL: This forces all external links to HTTPS, which may solve Mixed-Content issues, but not all websites support HTTPS yet. Use at your own risk.
  3. Verify SSL: Enabling this will prevent Friendica to interact with self-signed SSL sites. We recommend you leave it on as a self-signed SSL certificate can be a vectorfor a man-in-the-middle attack.
  • Last modified: 2022-06-24 15:05