Erstellung von privaten oder öffentlichen HTTPS-Zertifikaten

Autor: Gerd Raudenbusch
Stand: 15.07.2026

Öffentliche HTTPS-Zertifikate

Vor dem Ausstellen des Zertifikats müssen DNS-Einträge auf den Server zeigen und die Ports 80 sowie 443 erreichbar sein. Let’s Encrypt empfiehlt für Shell-Zugriff grundsätzlich Certbot, weil damit Ausstellung und Erneuerung automatisiert werden können.

Certbot installieren

Auf Linux kann z.B. Certbot installiert werden, um Let’s-Encrypt-Zertifikate anzufordern und zu verwalten. Je nach System kann das Paket direkt per apt installiert werden; zusätzlich sollte geprüft werden, ob die automatische Erneuerung aktiv ist.

sudo apt update
sudo apt install certbot python3-certbot-nginx

Zertifikat erzeugen

Das Zertifikat kann entweder im Standalone-Modus oder direkt über Nginx erstellt werden. Für eine bestehende Nginx-Installation ist die Nginx-Variante meist am einfachsten, weil die Domain geprüft und das Zertifikat anschließend direkt zugewiesen wird.

sudo certbot --nginx -d example.com -d www.example.com

Falls Nginx noch nicht passend konfiguriert ist, kann alternativ nur das Zertifikat erzeugt werden:

sudo certbot certonly --standalone -d example.com -d www.example.com

Private HTTPS-Zertifikate

mkcert auf Linux installieren

Für Linux wird zuerst libnss3-tools benötigt, damit mkcert auch Firefox/NSS-Trust-Stores bedienen kann; die offiziellen Hinweise nennen je nach Distribution zusätzlich die passenden NSS-Pakete wie nss-tools oder mozilla-nss-tools. Anschließend kann mkcert per Paketmanager oder als Binary installiert werden; danach sorgt mkcert -install dafür, dass die lokale CA in den System-Trust-Store eingetragen wird.

Beispiel für Ubuntu/Debian:

sudo apt update
sudo apt install libnss3-tools
curl -JLO "https://dl.filippo.io/mkcert/latest?for=linux/amd64"
chmod +x mkcert-v*-linux-amd64
sudo cp mkcert-v*-linux-amd64 /usr/local/bin/mkcert
mkcert -install

Der Speicherort der Root-CA wird mit mkcert -CAROOT angezeigt.

Zertifikat für home.lan

mkcert erzeugt Zertifikate, indem der gewünschte Hostname als Argument übergeben wird; das offizielle Usage-Beispiel lautet sinngemäß mkcert example.org für ein Zertifikat und den dazugehörigen Schlüssel. Für die Domain home.lan lautet der Befehl daher:

mkcert home.lan

Falls der Dienst zusätzlich über localhost, 127.0.0.1 oder ::1 erreichbar sein soll, können diese Namen einfach mit angegeben werden, denn mkcert unterstützt mehrere Namen in einem Aufruf. Dabei entstehen typischerweise zwei Dateien, etwa home.lan.pem und home.lan-key.pem.

Private Root-Zertifikate platzieren

Das relevante Root-Zertifikat ist rootCA.pem im Verzeichnis, das mkcert -CAROOT ausgibt; das private Gegenstück rootCA-key.pem wird nicht verteilt. Browser-Warnungen verschwinden nur dann zuverlässig, wenn dieses Root-Zertifikat im jeweiligen Trust-Store sowohl des Servers als auch des Clients installiert ist.

Ubuntu-Linux

Auf Ubuntu ist das Ziel in der Praxis der System-Trust-Store; mkcert erledigt das mit mkcert -install automatisch. Für Firefox ist zusätzlich der NSS-Trust-Store relevant, den mkcert ebenfalls über libnss3-tools bzw. die NSS-Integration bedienen kann.

Praktische Prozedur:

mkcert -install
mkcert -CAROOT

Die dabei ausgegebene rootCA.pem kann bei Bedarf auch manuell in den System-Trust-Store übernommen werden; in der Regel ist das aber nicht nötig, weil mkcert die Installation selbst vornimmt.

Windows

Unter Windows wird mkcert üblicherweise über Chocolatey oder Scoop installiert, und danach wird mkcert -install in einer administrativen Shell ausgeführt. Dadurch landet die lokale CA im Windows-Trust-Store, sodass Browser wie Chrome und Edge die Zertifikate akzeptieren.

Wenn das Root-Zertifikat manuell platziert werden soll, ist die Prozedur statt eines Ordners die Windows-Zertifikatsverwaltung: rootCA.pem in „Vertrauenswürdige Stammzertifizierungsstellen“ importieren.

Android

Auf Android wird das Root-Zertifikat als CA-Zertifikat auf dem Gerät installiert; mkcert nennt dafür ausdrücklich die rootCA.pem aus mkcert -CAROOT. Danach wird das Zertifikat in den Android-Einstellungen als vertrauenswürdige CA hinzugefügt, wobei neuere Android-Versionen je nach App und Browser zwischen System- und Benutzerzertifikaten unterscheiden.

Praktische Prozedur:

• rootCA.pem auf das Gerät kopieren.
• In den Zertifikats-/Sicherheits-Einstellungen installieren.
• Falls eine App ihr eigenes TLS-Trust-Handling hat, müssen Benutzerzertifikate dort eventuell extra erlaubt werden.

iOS

Auf iOS wird ebenfalls rootCA.pem aus mkcert -CAROOT installiert; mkcert nennt dafür AirDrop, E-Mail oder einen HTTP-Download als Übertragungsweg. Anschließend wird das Profil installiert und in den iOS-Vertrauenseinstellungen vollständig aktiviert.

Praktische Prozedur:

• rootCA.pem per AirDrop, Mail oder Download bereitstellen.
• Profil auf iPhone/iPad installieren.
• In den Einstellungen das Zertifikat als vertrauenswürdig markieren.

HTTPS-Zertifikate in Webserver einbinden

certbot kann die Konfiguration eigentlich selbst anpassen und HTTPS für die angegebene Domain aktivieren, z.B. mit sudo certbot --nginx -d example.com -d example.com für den Nginx-Webserver oder ``sudo certbot --apache -d example.com -d example.com` für Apache. Der manuelle Weg ist jedoch nicht nur der sicherste, sondern er zeigt auch, was passieren muss, damit es funktioniert. Dabei werden im Wesentichen das Zertifikat und der private Schlüssel in der Webserverkonfiguration referenziert.

nginx

Bei Nginx sind die Pfade unter /etc/letsencrypt/live/<domain>/ üblich.

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # weitere Konfiguration
}

Zusätzlich wird meist eine Weiterleitung von HTTP auf HTTPS eingerichtet.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Apache

Bei Apache mit für die entsprechende Domain ein funktionierender VirtualHost auf Port 80 existieren, z. B.:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com

    ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>

und auch aktiviert sein (sites-enabled bzw. Include in httpd.conf).

Das SSL-Modul muss aktiviert sein:

sudo a2enmod ssl
sudo a2enmod socache_shmcb  # oft empfohlen
sudo systemctl restart apache2

In /etc/apache2/sites-available/example.com-ssl.conf wird dein HTTPS-Listener angelegt:

<VirtualHost *:443>
    ServerName example.com
    ServerAlias example.com
    DocumentRoot /var/www/example.com

    SSLEngine on
    SSLCertificateFile      /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile   /etc/letsencrypt/live/example.com/privkey.pem
    ErrorLog ${APACHE_LOG_DIR}/beispiel.de-ssl-error.log
    CustomLog ${APACHE_LOG_DIR}/beispiel.de-ssl-access.log combined

    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
    SSLHonorCipherOrder     off
    SSLSessionTickets       off
</VirtualHost>

Die Aktivierung erfolgt mit

sudo a2ensite example.com-ssl
sudo systemctl reload apache2

2.4 Optional: Umleitung von HTTP auf HTTPS

Im VirtualHost auf Port 80 (oder global per Rewrite):

<VirtualHost *:80>
    ServerName beispiel.de
    ServerAlias www.beispiel.de

    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</VirtualHost>

Kurz-Übersicht HTTPS-Zertifikate