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. Wenn der lokale Webserver beim Aufruf einer Seite dann sein https-Zertifikat schickt, kann die Zertifikatskette durch das vorher importierte root-Zertifikat erfolgreich validiert werden.

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.

Unabhängig vom Tool mkcert erfolgt die Verwaltung von SSL/TLS-Zertifikaten unter Ubuntu primär über das Paket ca-certificates und das Kommandozeilenwerkzeug update-ca-certificates. Für benutzerdefinierte Verzeichnisse kommt das c_rehash-Tool zum Einsatz, um Hash-basierte symbolische Links für OpenSSL-Anwendungen zu erstellen.

Der systemweite Zertifikatsspeicher wird durch das Kopieren neuer Zertifikate (im PEM-Format mit der Endung .crt) in das Verzeichnis /usr/local/share/ca-certificates/ erweitert. Der Befehl update-ca-certificates scannt dieses Verzeichnis sowie /usr/share/ca-certificates/, aktualisiert die symbolischen Links in /etc/ssl/certs/ und generiert die konsolidierte Datei /etc/ssl/certs/ca-certificates.crt.
Um gelöschte Zertifikate vollständig aus dem Speicher zu entfernen oder verwaiste Links zu bereinigen, wird die Option --fresh verwendet. Dieser Modus entfernt alle bestehenden Links im Zielverzeichnis und erstellt sie basierend auf den aktuell vorhandenen Quelldateien neu. Das Paket ca-certificates selbst kann zudem über den Paketmanager (apt upgrade ca-certificates) aktualisiert werden, um aktuelle Root-CAs der Distribution zu erhalten.
Das Tool c_rehash dient dazu, in einem beliebigen Verzeichnis symbolische Links zu erstellen, die nach dem Hash-Wert des Zertifikatsubjekts benannt sind (Format HHHHHHHH.D). Dies ist zwingend erforderlich, wenn OpenSSL-Anwendungen ein Verzeichnis über die Option -CApath als Trust-Store nutzen sollen, da diese Mechanismen zur effizienten Zertifikatssuche benötigen.
Historisch wurde hierfür das Perl-Skript c_rehash verwendet. Mit Einführung von OpenSSL 1.1.0 wurde die Funktionalität direkt in den openssl-Befehl integriert (openssl rehash). Ab OpenSSL 4.0 wurde das separate Skript c_rehash vollständig entfernt. Für maximale Kompatibilität und zukunftssichere Skripte ist die Verwendung von openssl rehash /pfad/zum/verzeichnis empfohlen. Das Tool entfernt beim Ausführen standardmäßig alte Hash-Links im Zielverzeichnis, bevor neue erstellt werden; dies kann mit der Option -n unterbunden werden.

Die Erstellung von Hash-basierten symbolischen Links dient ausschließlich der Effizienzsteigerung bei der Zertifikatssuche durch OpenSSL und kompatiblen Bibliotheken. Ohne diese Mechanismen müsste jede Anwendung, die eine Zertifikatskette verifiziert, potenziell hunderte oder tausende von Zertifikatsdateien in einem Verzeichnis sequenziell öffnen und parsen, um den passenden Aussteller (Issuer) zu finden.

Windows

In der geöffneten Konsole (certmgr.msc oder certlm.msc) zum gewünschten Ordner navifieren (z. B. "Vertrauenswürdige Stammzertifizierungsstellen" -> „Zertifikate“). Dann mit der rechten Maustaste in den rechten freien Bereich oder auf den Ordner klicken. Dort "Alle Aufgaben" -> "Importieren" auswählen und dem Assistenten folgen. Für .pem-Zertifikate bei der Dateiauswahl rechts unten "Alle Dateien (.)" oder "X.509-Zertifikat (.cer;.crt)", auswählen, um betroffene Dateien einzublenden.

Android

Auf Android wird das Root-Zertifikat als CA-Zertifikat (rootCA.pem, welches zuvor mit mkcert -CAROOT) erzeugt wurde, einfach auf das Gerät gebracht und im Dateimanager installiert. Danach wird das Zertifikat in den Android-Einstellungen als vertrauenswürdige CA hinzugefügt:

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 auf das Mobilgerät kopiert, z.B. über AirDrop, E-Mail, SSH, SFTP, localsend oder durch einen Download von einer Webseite gebracht werden. Anschließend wird in den Einstellungen das "Profil" genannte Zertifikat installiert und in den iOS-Vertrauenseinstellungen vollständig aktiviert:

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

Operation	Öffentlich	Privat
Tool-Installation	`sudo apt update && \` `sudo apt install certbot python3-certbot-nginx`	`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`
Zertifikatserstellung	Webserver stoppen `sudo certbot certonly --standalone -d example.com -d www.example.com` Webserver starten	Webserver stoppen `mkcert home.lan` Webserver starten
Webserver-Einbindung	Das Domain-Zertifikat und sein privater Schlüssel müssen in die Webserver-Konfiguration eingebunden werden HTTPS-Module im Webserver müssen evtl. aktiviert werden Meist wird eine http->https-Umleitung eingerichtet Das root-Zertifikat gehört LetsEncrypt (oder einem kostenpflichtigen Zertifikatsanbieter) und muss nicht gepflegt werden, dafür muss der Server von Letsencrypt (also von außen) erreichbar sein	Sowohl das root-Zertifikat als auch das Domain-Zertifikat müssen in die Webserver-Konfiguration eingebunden werden HTTPS-Module im Webserver müssen evtl. aktiviert werden Meist wird eine http->https-Umleitung eingerichtet Das root-Zertifikat muss manuell auf den Clients installiert und erneuert werden, im Gegenzug muss eine Erreichbarkeit von außen nicht gewährleistet sein

Zurück zur Hauptseite