One place for hosting & domains


      How To Acquire a Let’s Encrypt Certificate Using DNS Validation with acme-dns-certbot on Ubuntu 18.04

      The author selected the COVID-19 Relief Fund to receive a donation as part of the Write for DOnations program.


      The majority of Let’s Encrypt certificates are issued using HTTP validation, which allows for the easy installation of certificates on a single server. However, HTTP validation is not always suitable for issuing certificates for use on load-balanced websites, nor can it be used to issue wildcard certificates.

      DNS validation allows for certificate issuance requests to be verified using DNS records, rather than by serving content over HTTP. This means that certificates can be issued simultaneously for a cluster of web servers running behind a load balancer, or for a system that isn’t directly accessible over the internet. Wildcard certificates are also supported using DNS validation.

      The acme-dns-certbot tool is used to connect Certbot to a third-party DNS server where the certificate validation records can be set automatically via an API when you request a certificate. The advantage of this is that you don’t need to integrate Certbot directly with your DNS provider account, nor do you need to grant it unrestricted access to your full DNS configuration, which is beneficial to security.

      Delegated DNS zones are used in order to redirect lookups for the certificate verification records to the third-party DNS service, so once the initial setup has been completed, you can request as many certificates as you want without having to perform any manual validation.

      Another key benefit of acme-dns-certbot is that it can be used to issue certificates for individual servers that may be running behind a load balancer, or are otherwise not directly accessible over HTTP. Traditional HTTP certificate validation cannot be used in these cases, unless you set the validation files on each and every server. The acme-dns-certbot tool is also useful if you want to issue a certificate for a server that isn’t accessible over the internet, such as an internal system or staging environment.

      In this tutorial, you will use the acme-dns-certbot hook for Certbot to issue a Let’s Encrypt certificate using DNS validation.


      To complete this tutorial, you will need:

      • An Ubuntu 18.04 server set up by following the Initial Server Setup with Ubuntu 18.04, including a sudo non-root user.

      • A domain name for which you can acquire a TLS certificate, including the ability to add DNS records. In this particular example, we will use your-domain and subdomain.your-domain, as well as *.your-domain for a wildcard certificate. However this can be adjusted for other domain, subdomains, or wildcards if required.

      Once you have these ready, log in to your server as your non-root user to begin.

      Step 1 — Installing Certbot

      In this step, you will install Certbot, which is a program used to issue and manage Let’s Encrypt certificates.

      Certbot is available within the official Ubuntu Apt repositories, however, it is instead recommended to use the repository maintained by the Certbot developers, as this always has the most up-to-date version of the software.

      Begin by adding the Certbot repository:

      • sudo apt-add-repository ppa:certbot/certbot

      You’ll need to press ENTER to accept the prompt and add the new repository to your system.

      Next, install the Certbot package:

      Once the installation has completed, you can check that Certbot has been successfully installed:

      This will output something similar to the following:


      certbot 0.31.0

      In this step you installed Certbot. Next, you will download and install the acme-dns-certbot hook.

      Step 2 — Installing acme-dns-certbot

      Now that the base Certbot program has been installed, you can download and install acme-dns-certbot, which will allow Certbot to operate in DNS validation mode.

      Begin by downloading a copy of the script:

      • wget

      Once the download has completed, mark the script as executable:

      • chmod +x

      Then, edit the file using your favorite text editor and adjust the first line in order to force it to use Python 3:

      Add a 3 to the end of the first line:

      #!/usr/bin/env python3
      . . .

      This is required in order to ensure that the script uses the latest supported version of Python 3, rather than the legacy Python version 2.

      Once complete, save and close the file.

      Finally, move the script into the Certbot Let’s Encrypt directory so that Certbot can load it:

      • sudo mv /etc/letsencrypt/

      In this step, you downloaded and installed the acme-dns-certbot hook. Next, you can begin the setup process and work toward issuing your first certificate.

      Step 3 — Setting Up acme-dns-certbot

      In order to begin using acme-dns-certbot, you’ll need to complete an initial setup process and issue at least one certificate.

      Start by running Certbot to force it to issue a certificate using DNS validation. This will run the acme-dns-certbot script and trigger the initial setup process:

      • sudo certbot certonly --manual --manual-auth-hook /etc/letsencrypt/ --preferred-challenges dns --debug-challenges -d *.your-domain -d your-domain

      You use the --manual argument to disable all of the automated integration features of Certbot. In this case you’re just issuing a raw certificate, rather than automatically installing it on a service as well.

      You configure Certbot to use the acme-dns-certbot hook via the --manual-auth-hook argument. You run the --preferred-challenges argument so that Certbot will give preference to DNS validation.

      You must also tell Certbot to pause before attempting to validate the certificate, which you do with the --debug-challenges argument. This is to allow you to set the DNS CNAME record(s) required by acme-dns-certbot, which is covered later in this step. Without the --debug-challenges argument, Certbot wouldn’t pause, so you wouldn’t have time to make the required DNS change.

      Remember to substitute each of the domain names that you wish to use using -d arguments. If you want to issue a wildcard certificate, make sure to escape the asterisk (*) with a backslash ().

      After following the standard Certbot steps, you’ll eventually be prompted with a message similar to the following:


      ... Output from Please add the following CNAME record to your main DNS zone: _acme-challenge.your-domain CNAME Waiting for verification... ...

      You’ll need to add the required DNS CNAME record to the DNS configuration for your domain. This will delegate control of the _acme-challenge subdomain to the ACME DNS service, which will allow acme-dns-certbot to set the required DNS records to validate the certificate request.

      If you’re using DigitalOcean as your DNS provider, you can set the DNS record within your control panel:

      A screenshot of the DigitalOcean DNS control panel, showing an example of a CNAME record for ACME DNS

      It is recommended to set the TTL (time-to-live) to around 300 seconds in order to help ensure that any changes to the record are propagated quickly.

      Once you have configured the DNS record, return to Certbot and press ENTER to validate the certificate request and complete the issuance process.

      This will take a few seconds, and you’ll then see a message confirming that the certificate has been issued:


      ... Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your-domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/your-domain/privkey.pem ...

      You’ve run acme-dns-certbot for the first time, set up the required DNS records, and successfully issued a certificate. Next you’ll set up automatic renewals of your certificate.

      Step 4 — Using acme-dns-certbot

      In this final step, you will use acme-dns-certbot to issue more certificates and renew existing ones.

      Firstly, now that you’ve successfully issued at least one certificate using acme-dns-certbot, you can continue to issue certificates for the same DNS names without having to add another DNS CNAME record. However, if you wish to acquire a certificate for a different subdomain or entirely new domain name, you will be prompted to add another CNAME record.

      For example, you could issue another standalone wildcard certificate without having to perform the verification again:

      • sudo certbot certonly --manual --manual-auth-hook /etc/letsencrypt/ --preferred-challenges dns --debug-challenges -d *.your-domain

      However, if you were to attempt to issue a certificate for a subdomain, you would be prompted to add a CNAME record for the subdomain:

      • sudo certbot certonly --manual --manual-auth-hook /etc/letsencrypt/ --preferred-challenges dns --debug-challenges -d subdomain.your-domain

      This will show an output similar to the initial setup that you carried out in Step 3:


      ... Please add the following CNAME record to your main DNS zone: _acme-challenge.subdomain.your-domain CNAME Waiting for verification... ...

      Now that you’re able to use acme-dns-certbot to issue certificates, it’s worth considering the renewal process as well.

      Once your certificates are nearing expiry, Certbot can automatically renew them for you:

      The renewal process can run start-to-finish without user interaction, and will remember all of the configuration options that you specified during the initial setup.

      To test that this is working without having to wait until nearer the expiry date, you can trigger a dry run. This will simulate the renewal process without making any actual changes to your configuration.

      You can trigger a dry run using the standard renew command, but with the --dry-run argument:

      • sudo certbot renew --dry-run

      This will output something similar to the following, which will provide assurance that the renewal process is functioning correctly:


      ... Cert not due for renewal, but simulating renewal for dry run Plugins selected: Authenticator manual, Installer None Renewing an existing certificate Performing the following challenges: dns-01 challenge for your-domain dns-01 challenge for your-domain Waiting for verification... Cleaning up challenges ...

      In this final step, you issued another certificate and then tested the automatic renewal process within Certbot.


      In this article you set up Certbot with acme-dns-certbot in order to issue certificates using DNS validation. This unlocks the possibility of using wildcard certificates as well as managing a large estate of distinct web servers that may be sitting behind a load balancer.

      Make sure to keep an eye on the acme-dns-certbot repository for any updates to the script, as it’s always recommended to run the latest supported version.

      If you’re interested in learning more about acme-dns-certbot, you may wish to review the documentation for the acme-dns project, which is the server-side element of acme-dns-certbot:

      The acme-dns software can also be self-hosted, which may be beneficial if you’re operating in high-security or complex environments.

      Alternatively, you could dig into the technical details of ACME DNS validation by reviewing the relevant section of the official RFC document which outlines how the process works:

      Source link

      Einrichten und Konfigurieren einer Certificate Authority (CA) unter Debian 10


      Eine Zertifizierungsstelle (Certificate Authority, CA) ist eine Stelle, die für die Ausstellung digitaler Zertifikate zur Überprüfung von Identitäten im Internet verantwortlich ist. Obwohl öffentliche CAs eine beliebte Wahl für die Überprüfung der Identität von Websites und anderen Diensten sind, die der allgemeinen Öffentlichkeit zur Verfügung gestellt werden, werden private CAs normalerweise für geschlossene Gruppen und private Dienste verwendet.

      Die Erstellung einer privaten Zertifizierungsstelle ermöglicht es Ihnen, Programme zu konfigurieren, zu testen und auszuführen, die verschlüsselte Verbindungen zwischen einem Client und einem Server erfordern. Mit einer privaten CA können Sie Zertifikate für Benutzer, Server oder einzelne Programme und Dienste innerhalb Ihrer Infrastruktur ausstellen.

      Einige Beispiele für Programme unter Linux, die ihre eigene private CA verwenden, sind OpenVPN und Puppet. Sie können Ihren Webserver auch so konfigurieren, dass er Zertifikate verwendet, die von einer privaten CA ausgestellt wurden, um Entwicklungs- und Staging-Umgebungen an Produktionsserver anzupassen, die TLS zur Verschlüsselung von Verbindungen verwenden.

      In diesem Leitfaden lernen wir, wie eine private Zertifizierungsstelle auf einem Debian 10-Server eingerichtet wird und wie mit einer neuen CA ein Testzertifikat erzeugt und signiert wird. Außerdem erfahren Sie, wie Sie das öffentliche Zertifikat des CA-Servers in den Zertifikatsspeicher Ihres Betriebssystems importieren, damit Sie die Vertrauenskette zwischen der CA und entfernten Servern oder Benutzern überprüfen können. Schließlich werden Sie lernen, wie Sie Zertifikate widerrufen und eine Zertifikatswiderrufsliste verteilen, um sicherzustellen, dass nur autorisierte Benutzer und Systeme Dienste nutzen können, die auf Ihrer CA beruhen.


      Um dieses Tutorial zu absolvieren, benötigen Sie Zugriff auf einen Debian 10-Server, der Ihren OpenVPN-Dienst hosten kann. Sie müssen einen non-root user mit sudo-Rechten konfigurieren, bevor Sie diesen Leitfaden starten können. Sie können unserem Leitfaden zur Ersteinrichtung eines Debian-10-Servers folgen, um einen Benutzer mit entsprechenden Berechtigungen einzurichten. Das verknüpfte Tutorial richtet auch eine Firewall ein, und in diesem Leitfaden wird davon ausgegangen, dass sie vorhanden ist.

      Dieser Server wird in diesem Tutorial als CA-Server bezeichnet.

      Stellen Sie sicher, dass der CA-Server ein eigenständiges System ist. Er wird nur zum Importieren, Signieren und Widerrufen von Zertifikatanforderungen verwendet. Auf ihm sollten keine anderen Dienste ausgeführt werden, und idealerweise ist er offline oder wird vollständig heruntergefahren, wenn Sie nicht aktiv mit Ihrer CA arbeiten.

      Anmerkung: Der letzte Abschnitt dieses Tutorials ist optional, wenn Sie über das Signieren und Widerrufen von Zertifikaten lernen möchten. Wenn Sie sich entscheiden, diese Übungsschritte durchzuführen, benötigen Sie einen zweiten Debian-10-Server oder Sie können Ihren eigenen lokalen Linux-Computer verwenden, auf dem Debian oder Ubuntu oder davon abgeleitete Distributionen ausgeführt werden.

      Schritt 1 — Installieren von Easy-RSA

      Die erste Aufgabe in diesem Tutorial besteht darin, den Skriptsatz easy-rsa auf Ihrem CA-Server zu installieren. easy-rsa ist ein Verwaltungswerkzeug für Zertifizierungsstellen, mit dem Sie einen privaten Schlüssel und ein öffentliches Stammzertifikat erzeugen, die Sie dann zum Signieren von Anfragen von Clients und Servern verwenden, die auf Ihre CA angewiesen sind.

      Melden Sie sich bei Ihrem CA-Server als der non-root sudo user an, den Sie während der anfänglichen Einrichtungsschritte erstellt haben, und führen Sie Folgendes aus:

      • sudo apt update
      • sudo apt install easy-rsa

      Sie werden aufgefordert, das Paket herunterzuladen und zu installieren. Drücken Sie y, um zu bestätigen, dass Sie das Paket installieren möchten.

      An dieser Stelle haben Sie alles Nötige eingerichtet und sind bereit, Easy-RSA zu verwenden. Im nächsten Schritt werden Sie eine Public-Key-Infrastruktur erstellen und dann mit dem Erstellen Ihrer Zertifizierungsstelle beginnen.

      Schritt 2 – Vorbereiten eines Public-Key-Infrastrukturverzeichnisses

      Nachdem Sie nun easy-rsa installiert haben, ist es an der Zeit, eine grundlegende Public-Key-Infrastruktur (PKI) auf dem CA-Server zu erstellen. Stellen Sie sicher, dass Sie immer noch als non-root user angemeldet sind und erstellen Sie ein easy-rsa-Verzeichnis. Stellen Sie sicher, dass Sie sudo nicht verwenden, um einen der folgenden Befehle auszuführen, da Ihr normaler Benutzer die CA ohne erhöhte Berechtigungen verwalten und mit ihr interagieren sollte.

      Dadurch wird ein neues Verzeichnis namens easy-rsa in Ihrem Home-Ordner erstellt. Wir werden dieses Verzeichnis verwenden, um symbolische Links zu erstellen, die auf die easy-rsa-Paketdateien verweisen, die wir im vorigen Schritt installiert haben. Diese Dateien befinden sich im Ordner /usr/share/easy-rsa auf dem CA-Server.

      Erstellen Sie die Symlinks mit dem Befehl ln:

      • ln -s /usr/share/easy-rsa/* ~/easy-rsa/

      Anmerkung: Während andere Leitfäden Sie möglicherweise anweisen, die Dateien des easy-rsa-Pakets in Ihr PKI-Verzeichnis zu kopieren, verfolgt dieses Tutorial einen Symlink-Ansatz. Infolgedessen werden alle Aktualisierungen des easy-rsa-Pakets automatisch in den Skripten Ihrer PKI wiedergegeben.

      Um den Zugriff auf Ihr neues PKI-Verzeichnis einzuschränken, stellen Sie sicher, dass nur der Eigentümer mit dem Befehl chmod darauf zugreifen kann:

      • chmod 700 /home/sammy/easy-rsa

      Anschließend initialisieren Sie die PKI innerhalb des easy-rsa-Verzeichnisses:

      • cd ~/easy-rsa
      • ./easyrsa init-pki


      init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: /home/sammy/easy-rsa/pki

      Nachdem Sie diesen Abschnitt abgeschlossen haben, haben Sie ein Verzeichnis, das alle Dateien enthält, die zur Erstellung einer Zertifizierungsstelle benötigt werden. Im nächsten Abschnitt werden Sie den privaten Schlüssel und das öffentliche Zertifikat für Ihre CA erstellen.

      Schritt 3 – Erstellen einer Zertifizierungsstelle

      Bevor Sie den privaten Schlüssel und das Zertifikat Ihrer CA erstellen können, müssen Sie eine Datei namens vars erstellen und mit einigen Standardwerten füllen. Zuerst werden Sie cd in das Verzeichnis easy-rsa, dann werden Sie die Datei vars mit nano oder Ihrem bevorzugten Texteditor erstellen und bearbeiten:

      Sobald die Datei geöffnet ist, fügen Sie die folgenden Zeilen ein und bearbeiten Sie jeden hervorgehobenen Wert so, dass er Ihre eigenen Organisationsinformationen widerspiegelt. Wichtig dabei ist, dass Sie keinen der Werte leer lassen:


      set_var EASYRSA_REQ_COUNTRY "US" set_var EASYRSA_REQ_PROVINCE "NewYork" set_var EASYRSA_REQ_CITY "New York City" set_var EASYRSA_REQ_ORG "DigitalOcean" set_var EASYRSA_REQ_EMAIL "" set_var EASYRSA_REQ_OU "Community"

      Wenn Sie dies abgeschlossen haben, speichern und schließen Sie die Datei. Wenn Sie nano verwenden, können Sie dies durch Drücken von STRG+X, dann Y und ENTER zur Bestätigung tun. Sie sind nun bereit, Ihre CA zu erstellen.

      Um das öffentliche und private Stammschlüsselpaar für Ihre Zertifizierungsstelle zu erstellen, führen Sie den Befehl ./easy-rsa erneut aus, diesmal mit der Option build-ca:

      In der Ausgabe sehen Sie einige Zeilen über die OpenSSL-Version und werden dazu aufgefordert, eine Passphrase für Ihr Schlüsselpaar einzugeben. Achten Sie darauf, eine starke Passphrase zu wählen, und notieren Sie sie an einem sicheren Ort. Sie müssen die Passphrase jedes Mal eingeben, wenn Sie mit Ihrer CA interagieren müssen, zum Beispiel zum Signieren oder Widerrufen eines Zertifikats.

      Sie werden auch gebeten, den Common Name (CN) für Ihre CA zu bestätigen. Der CN ist der Name, der verwendet wird, um im Kontext der Zertifizierungsstelle auf diesen Computer zu verweisen. Sie können eine beliebige Zeichenfolge für den Common Name der CA eingeben, aber drücken Sie der Einfachheit halber ENTER, um den Standardnamen zu akzeptieren.


      . . . Enter New CA Key Passphrase: Re-Enter New CA Key Passphrase: . . . Common Name (eg: your user, host, or server name) [Easy-RSA CA]: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /home/sammy/easy-rsa/pki/ca.crt

      Anmerkung: Wenn Sie nicht bei jeder Interaktion mit Ihrer CA zur Eingabe eines Passworts aufgefordert werden möchten, können Sie den Befehl build-ca mit der Option nopass wie folgt ausführen:

      • ./easyrsa build-ca nopass

      Sie haben nun zwei wichtige Dateien – ~/easy-rsa/pki/ca.crt und ~/easy-rsa/pki/private/ca.key – die die öffentlichen und privaten Komponenten einer Zertifizierungsstelle bilden.

      • ca.crt ist die öffentliche Zertifikatsdatei der CA. Benutzer, Server und Clients verwenden dieses Zertifikat, um zu überprüfen, ob sie Teil desselben vertrauenswürdigen Webs sind. Jeder Benutzer und Server, der Ihre CA verwendet, muss eine Kopie dieser Datei haben. Alle Parteien verlassen sich auf das öffentliche Zertifikat, um sicherzustellen, dass sich nicht jemand als System ausgibt und einen Man-in-the-middle-Angriff durchführt.

      • ca.key ist der private Schlüssel, den die CA zum Signieren von Zertifikaten für Server und Clients verwendet. Wenn ein Angreifer Zugriff auf Ihre CA und damit auf Ihre ca.key-Datei erhält, müssen Sie Ihre CA vernichten. Deshalb sollte sich Ihre Datei ca.key nur auf Ihrem CA-Computer befinden und Ihr CA-Computer im Idealfall als zusätzliche Sicherheitsmaßnahme offline bleiben, wenn keine Zertifikatanforderungen signiert werden.

      Damit ist Ihre CA vorhanden und bereit, zum Signieren von Zertifikatanforderungen und zum Widerrufen von Zertifikaten verwendet zu werden.

      Schritt 4 – Verteilen des öffentlichen Zertifikats Ihrer Zertifizierungsstelle

      Nun ist Ihre CA konfiguriert und bereit, als Vertrauensgrundlage für alle Systeme zu fungieren, die Sie für ihre Verwendung konfigurieren möchten. Sie können das Zertifikat der CA zu Ihren OpenVPN-Servern, Webservern, Mail-Servern usw. hinzufügen. Jeder Benutzer oder Server, der die Identität eines anderen Benutzers oder Servers in Ihrem Netzwerk überprüfen muss, sollte eine Kopie der Datei ca.crt haben, die in den Zertifikatsspeicher ihres Betriebssystems importiert ist.

      Um das öffentliche Zertifikat der CA in ein zweites Linux-System wie einen anderen Server oder einen lokalen Computer zu importieren, besorgen Sie sich zunächst eine Kopie der ca.crt-Datei von Ihrem CA-Server. Sie können den Befehl cat verwenden, um sie in einem Terminal auszugeben, und sie dann kopieren und in eine Datei auf dem zweiten Computer, der das Zertifikat importiert, einfügen. Sie können auch Tools wie scp, rsync verwenden, um die Datei zwischen Systemen zu übertragen. Wir werden in diesem Schritt jedoch Kopieren und Einfügen mit nano verwenden, da dies auf allen Systemen funktioniert.

      Führen Sie als non-root user auf dem CA-Server den folgenden Befehl aus:

      • cat ~/easy-rsa/pki/ca.crt

      Es wird eine Ausgabe in Ihrem Terminal geben, die der folgenden ähnelt:



      Kopieren Sie alles, einschließlich der Zeilen -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- und der Bindestriche.

      Verwenden Sie auf Ihrem zweiten Linux-System nano oder Ihren bevorzugten Texteditor, um eine Datei namens /tmp/ca.crt zu öffnen:

      Fügen Sie den Inhalt, den Sie gerade vom CA-Server kopiert haben, in den Editor ein. Wenn Sie dies abgeschlossen haben, speichern und schließen Sie die Datei. Wenn Sie nano verwenden, können Sie dies durch Drücken von STRG+X, dann Y und ENTER zur Bestätigung tun.

      Nachdem Sie nun eine Kopie der Datei ca.crt auf Ihrem zweiten Linux-System haben, ist es an der Zeit, das Zertifikat in den Zertifikatsspeicher des Betriebssystems zu importieren.

      Führen Sie auf Debian- und Ubuntu-basierten Systemen die folgenden Befehle aus, um das Zertifikat zu importieren:

      Debian and Ubuntu derived distributions

      • cp /tmp/ca.crt /usr/local/share/ca-certificates/
      • update-ca-certificates

      Um das Zertifikat des CA-Servers auf einem CentOS-, Fedora- oder RedHat-basierten System zu importieren, kopieren Sie den Inhalt der Datei und fügen Sie ihn wie im vorherigen Beispiel in das System in eine Datei namens /tmp/ca.crt ein. Kopieren Sie als Nächstes das Zertifikat nach /etc/pki/ca-trust/source/anchors/ und führen Sie dann den Befehl update-ca-trust aus.

      CentOS, Fedora, RedHat distributions

      • sudo cp /tmp/ca.crt /etc/pki/ca-trust/source/anchors/
      • update-ca-trust

      Nun wird Ihr zweites Linux-System auf jedes Zertifikat vertrauen, das vom CA-Server signiert wurde.

      Anmerkung: Wenn Sie Ihre CA mit Web-Servern verwenden und Firefox als Browser verwenden, müssen Sie das öffentliche Zertifikat ca.crt direkt in Firefox importieren. Firefox verwendet nicht den Zertifikatsspeicher des lokalen Betriebssystems. Einzelheiten dazu, wie Sie das Zertifikat Ihrer CA in Firefox hinzufügen können, finden Sie in diesem Support-Artikel von Mozilla über das Einrichten von Zertifizierungsstellen (CAs) in Firefox.

      Wenn Sie Ihre CA zur Integration in eine Windows-Umgebung oder in Desktop-Computer verwenden, lesen Sie bitte die Dokumentation über die Verwendung von certutil.exe zur Installation eines CA-Zertifikats.

      Wenn Sie dieses Tutorial als Voraussetzung für ein anderes Tutorial verwenden oder mit dem Signieren und Widerrufen von Zertifikaten vertraut sind, können Sie hier aufhören. Wenn Sie mehr zum Thema Signieren und Widerrufen von Zertifikaten erfahren möchten, dann wird im folgenden optionalen Abschnitt jeder Vorgang im Detail erklärt.

      (Optional) – Erstellen von Zertifikatsignieranforderungen und Widerrufen von Zertifikaten

      Die folgenden Abschnitte des Tutorials sind optional. Wenn Sie alle vorherigen Schritte abgeschlossen haben, verfügen Sie über eine vollständig konfigurierte und funktionierende Zertifizierungsstelle, die Sie als Voraussetzung für andere Tutorials verwenden können. Sie können die Datei ca.crt Ihrer CA importieren und Zertifikate in Ihrem Netzwerk überprüfen, die von Ihrer CA signiert wurde.

      Wenn Sie üben und mehr über das Signieren von Zertifikatanforderungen und das Widerrufen von Zertifikaten erfahren möchten, dann werden diese optionalen Abschnitte erklären, wie beide Prozesse funktionieren.

      (Optional) – Erstellen und Signieren einer Übungs-Zertifikatanforderung

      Nachdem Sie nun eine einsatzbereite CA haben, können Sie das Erzeugen eines privaten Schlüssels und einer Zertifikatanforderung üben, um sich mit dem Signier- und Verteilungsprozess vertraut zu machen.

      Eine Zertifikatsignieranforderung (Certificate Signing Request, CSR) besteht aus drei Teilen: einem öffentlichen Schlüssel, dem Identifizieren von Informationen über das anfordernde System und einer Signatur der Anforderung selbst, die mit dem privaten Schlüssel der anfragenden Partei erstellt wird. Der private Schlüssel wird geheim gehalten und wird zum Verschlüsseln von Informationen verwendet, die jeder mit dem signierten öffentlichen Zertifikat dann entschlüsseln kann.

      Die folgenden Schritte werden auf Ihrem zweiten Linux-System Debian, Ubuntu oder einer Distribution, die von einem dieser Systeme abgeleitet ist, ausgeführt. Es kann sich um einen anderen Remote-Server oder einen lokalen Linux-Rechner wie einen Laptop oder einen Desktop-Rechner handeln. Da easy-rsa nicht standardmäßig auf allen Systemen verfügbar ist, verwenden wir das Tool openssl zum Erstellen eines privaten Übungsschlüssels und -zertifikats.

      openssl ist normalerweise standardmäßig auf den meisten Linux-Distributionen installiert, aber um sicherzugehen, führen Sie die folgenden Schritte auf Ihrem System aus:

      • sudo apt update
      • sudo apt install openssl

      Wenn Sie zur Installation von openssl aufgefordert werden, geben Sie y ein, um mit den Installationsschritten fortzufahren. Nun sind Sie bereit, eine Übungs-CSR mit openssl zu erstellen.

      Der erste Schritt, den Sie zum Erstellen einer CSR ausführen müssen, ist die Erzeugung eines privaten Schlüssels. Um einen privaten Schlüssel mit openssl zu erstellen, erstellen Sie ein Verzeichnis practice-csr und erzeugen Sie darin einen Schlüssel. Wir werden diese Anfrage für einen fiktiven Server namens sammy-server stellen, im Gegensatz zur Erstellung eines Zertifikats, das zur Identifizierung eines Benutzers oder einer anderen CA verwendet wird.

      • mkdir ~/practice-csr
      • cd ~/practice-csr
      • openssl genrsa -out sammy-server.key


      Generating RSA private key, 2048 bit long modulus (2 primes) . . . . . . e is 65537 (0x010001)

      Da Sie nun über einen privaten Schlüssel verfügen, können Sie eine entsprechende CSR erstellen, wiederum mit dem Dienstprogramm openssl. Sie werden aufgefordert, eine Reihe von Feldern wie Land, Bundesland und Stadt auszufüllen. Wenn Sie ein Feld leer lassen möchten, können Sie einen . eingeben. Beachten Sie jedoch, dass es am besten ist, die richtigen Werte für Ihren Standort und Ihre Organisation zu verwenden, wenn es sich um eine reale CSR handelt:

      • openssl req -new -key sammy-server.key -out sammy-server.req


      . . . ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:New York Locality Name (eg, city) [Default City]:New York City Organization Name (eg, company) [Default Company Ltd]:DigitalOcean Organizational Unit Name (eg, section) []:Community Common Name (eg, your name or your server's hostname) []:sammy-server Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

      Wenn Sie diese Werte automatisch als Teil des openssl-Aufrufs statt über die interaktive Eingabeaufforderung hinzufügen möchten, können Sie das Argument -subj an OpenSSL übergeben. Achten Sie darauf, die hervorgehobenen Werte so zu bearbeiten, dass sie mit dem Standort, der Organisation und dem Servernamen für die Übung übereinstimmen:

      • openssl req -new -key sammy-server.key -out server.req -subj
      • /C=US/ST=New York/L=New York City/O=DigitalOcean/OU=Community/CN=sammy-server

      Zur Überprüfung des Inhalts einer CSR können Sie eine Anforderungsdatei mit openssl einlesen und die darin enthaltenen Felder untersuchen:

      • openssl req -in sammy-server.req -noout -subject


      subject=C = US, ST = New York, L = New York City, O = DigitalOcean, OU = Community, CN = sammy-server

      Wenn Sie mit dem Thema Ihrer Übungs-Zertifikatanforderung zufrieden sind, kopieren Sie die Datei sammy-server.req mit scp auf Ihren CA-Server:

      • scp sammy-server.req sammy@your_ca_server_ip:/tmp/sammy-server.req

      In diesem Schritt haben Sie eine Zertifikatsignieranforderung für einen fiktiven Server namens sammy-server erzeugt. In einem realen Szenario könnte die Anfrage z. B. von einem Staging- oder Entwicklungs-Webserver kommen, der ein TLS-Zertifikat zum Testen benötigt; oder sie könnte von einem OpenVPN-Server kommen, der ein Zertifikat anfordert, damit sich Benutzer mit einem VPN verbinden können. Im nächsten Schritt fahren wir mit dem Signieren der Zertifikatsignieranforderung unter Verwendung des privaten Schlüssels des CA-Servers fort.

      (Optional) – Signieren einer CSR

      Im vorherigen Schritt haben Sie eine Übungs-Zertifikatanforderung und einen Übungsschlüssel für einen fiktiven Server erstellt. Sie kopierten sie in das Verzeichnis /tmp auf Ihrem CA-Server und emulierten damit das Verfahren, das Sie verwenden würden, wenn Sie echte Clients oder Server hätten, die Ihnen CSR-Anfragen senden würden, die signiert werden müssen.

      Um mit dem fiktiven Szenario fortzufahren, muss der CA-Server nun das Übungszertifikat importieren und signieren. Sobald eine Zertifikatanforderung von der CA validiert und an einen Server zurückgesendet wird, können Clients, die der Zertifizierungsstelle vertrauen, auch dem neu ausgestellten Zertifikat vertrauen.

      Da wir innerhalb der PKI der CA arbeiten werden, in der das Dienstprogramm easy-rsa verfügbar ist, werden die Signierungsschritte das Dienstprogramm easy-rsa verwenden. Dies vereinfacht die Dinge im Gegensatz zur direkten Verwendung von openssl, wie wir es im vorherigen Beispiel getan haben.

      Der erste Schritt zum Signieren der fiktiven CSR besteht darin, die Zertifikatanforderung mithilfe des Skripts easy-rsa zu importieren:

      • cd ~/easy-rsa
      • ./easyrsa import-req /tmp/sammy-server.req sammy-server


      . . . The request has been successfully imported with a short name of: sammy-server You may now use this name to perform signing operations on this request.

      Jetzt können Sie die Anfrage signieren, indem Sie das Skript easyrsa mit der Option sign-req ausführen, gefolgt vom Anfragetyp und dem Common Name, der in der CSR enthalten ist. Der Anfragetyp kann entweder Client, Server oder ca sein. Da wir mit einem Zertifikat für einen fiktiven Server üben, stellen Sie sicher, dass Sie den Anfragetyp Server verwenden:

      • ./easyrsa sign-req server sammy-server

      In der Ausgabe werden Sie zur Überprüfung aufgefordert, ob die Anfrage von einer vertrauenswürdigen Quelle stammt. Geben Sie yes ein, und drücken Sie dann zur Bestätigung ENTER:


      You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a server certificate for 3650 days: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes . . . Certificate created at: /home/sammy/easy-rsa/pki/issued/sammy-server.crt

      Wenn Sie Ihren CA-Schlüssel verschlüsselt haben, werden Sie an dieser Stelle zur Eingabe Ihres Passworts aufgefordert.

      Nach Abschluss dieser Schritte haben Sie die CSR sammy-server.req mit dem privaten Schlüssel des CA-Servers in /home/sammy/easy-rsa/pki/private/ca.key signiert. Die resultierende Datei sammy-server.crt enthält den öffentlichen Verschlüsselungsschlüssel des Übungsservers sowie eine neue Signatur des CA-Servers. Der Sinn der Signatur besteht darin, jedem, der der CA vertraut, mitzuteilen, dass auch dem sammy-server-Zertifikat vertraut werden kann.

      Wenn es sich bei dieser Anfrage um einen echten Server wie einen Web- oder VPN-Server handelt, würde der letzte Schritt auf dem CA-Server darin bestehen, die neuen Dateien sammy-server.crt und ca.crt vom CA-Server an den Remote-Server zu verteilen, der die CSR-Anfrage gestellt hat:

      • scp pki/issued/sammy-server.crt sammy@your_server_ip:/tmp
      • scp pki/ca.crt sammy@your_server_ip:/tmp

      Zu diesem Zeitpunkt könnten Sie das ausgestellte Zertifikat mit beispielsweise einem Webserver, einem VPN, einem Konfigurationsmanagement-Tool, einem Datenbanksystem oder für die Client-Authentifizierung verwenden.

      (Optional) – Widerrufen eines Zertifikats

      Gelegentlich kann es erforderlich sein, ein Zertifikat zu widerrufen, um zu verhindern, dass ein Benutzer oder Server es verwendet. Vielleicht wurde ein Laptop gestohlen, ein Webserver kompromittiert, oder ein Mitarbeiter oder ein Auftragnehmer hat Ihr Unternehmen verlassen.

      Zum Widerrufen eines Zertifikats folgt der allgemeine Vorgang diesen Schritten:

      1. Widerrufen Sie das Zertifikat mit dem Befehl ./easyrsa revoke client_name.
      2. Erzeugen Sie eine neue CRL mit dem Befehl ./easyrsa gen-crl.
      3. Übertragen Sie die aktualisierte Datei crl.pem auf den oder die Server, die sich auf Ihre CA verlassen, und kopieren Sie sie auf diesen Systemen in das oder die erforderlichen Verzeichnisse für Programme, die auf sie verweisen.
      4. Starten Sie alle Dienste, die Ihre CA und die CRL-Datei verwenden, neu.

      Mit diesem Vorgang können Sie alle Zertifikate, die Sie zuvor ausgestellt haben, jederzeit widerrufen. In den folgenden Abschnitten gehen wir jeden Schritt im Detail durch, beginnend mit dem Befehl revoke.

      Widerrufen eines Zertifikats

      Um ein Zertifikat zu widerrufen, navigieren Sie zum Verzeichnis easy-rsa auf Ihrem CA-Server:

      Führen Sie als Nächstes das Skript easyrsa mit der Option revoke aus, gefolgt von dem Client-Namen, den Sie widerrufen möchten. Dem obigen Übungsbeispiel folgend lautet der Common Name des Zertifikats sammy-server:

      • ./easyrsa revoke sammy-server

      Sie werden dazu aufgefordert, das Sperren durch Eingabe von yes zu bestätigen:


      Please confirm you wish to revoke the certificate with the following subject: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Continue with revocation: yes . . . Revoking Certificate 8348B3F146A765581946040D5C4D590A . . .

      Beachten Sie den hervorgehobenen Wert in der Zeile Revoking Certificate. Dieser Wert ist die eindeutige Seriennummer des Zertifikats, das widerrufen wird. Sie benötigen diesen Wert, wenn Sie die Widerrufsliste im letzten Schritt dieses Abschnitts prüfen möchten, um zu verifizieren, dass das Zertifikat darin enthalten ist.

      Nach der Bestätigung der Aktion wird die CA das Zertifikat widerrufen. Entfernte Systeme, die sich auf die CA verlassen, haben jedoch keine Möglichkeit zur Überprüfung, ob Zertifikate widerrufen wurden. Benutzer und Server können das Zertifikat weiterhin verwenden, bis die Zertifikatswiderrufsliste (Certificate Revocation List, CRL) der CA an alle Systeme verteilt wird, die sich auf die CA verlassen.

      Im nächsten Schritt erzeugen Sie eine CRL oder aktualisieren eine bestehende crl.pem-Datei.

      Erzeugen einer Zertifikatswiderrufsliste

      Nachdem Sie ein Zertifikat widerrufen haben, ist es jetzt wichtig, die Liste der widerrufenen Zertifikate auf Ihrem CA-Server zu aktualisieren. Sobald Sie über eine aktualisierte Widerrufsliste verfügen, können Sie feststellen, welche Benutzer und Systeme in Ihrer CA über gültige Zertifikate verfügen.

      Um eine CRL zu erzeugen, führen Sie den Befehl easy-rsa mit der Option gen-crl aus, während Sie sich noch im Verzeichnis ~/easy-rsa befinden:

      Wenn Sie bei der Erstellung Ihrer Datei ca.key eine Passphrase verwendet haben, werden Sie aufgefordert, diese einzugeben. Der Befehl gen-crl erzeugt eine Datei namens crl.pem, die die aktualisierte Liste der widerrufenen Zertifikate für diese CA enthält.

      Als Nächstes müssen Sie jedes Mal, wenn Sie den Befehl gen-crl ausführen, die aktualisierte Datei crl.pem an alle Server und Clients übertragen, die auf diese CA angewiesen sind. Andernfalls können die Clients und Systeme weiterhin auf Dienste und Systeme zugreifen, die Ihre CA verwenden, da diese Dienste über den widerrufenen Status des Zertifikats informiert sein müssen.

      Übertragen einer Zertifikatswiderrufsliste

      Nachdem Sie nun eine CRL auf Ihrem CA-Server erzeugt haben, müssen Sie sie an Remote-Systeme übertragen, die sich auf Ihre CA verlassen. Um diese Datei auf Ihre Server zu übertragen, können Sie den Befehl scp verwenden.

      Anmerkung: In diesem Tutorial wird erklärt, wie eine CRL manuell erzeugt und verteilt wird. Es gibt zwar robustere und automatisierte Methoden zur Verteilung und Überprüfung von Widerrufslisten wie OCSP-Stapling, aber die Konfiguration dieser Methoden sprengt den Rahmen dieses Artikels.

      Stellen Sie sicher, dass Sie bei Ihrem CA-Server als non-root user angemeldet sind, und führen Sie die folgenden Schritte aus, wobei Sie an Stelle von your_server_ip Ihre eigene Server-IP oder Ihren eigenen DNS-Namen eingeben:

      • scp ~/easy-rsa/pki/crl.pem sammy@your_server_ip:/tmp

      Da sich die Datei nun auf dem Remote-System befindet, besteht der letzte Schritt darin, alle Dienste mit der neuen Kopie der Widerrufsliste zu aktualisieren.

      Aktualisierung von Diensten, die eine CRL unterstützen

      Die Liste der Schritte, die Sie zur Aktualisierung von Diensten verwenden müssen, die die Datei crl.pem verwenden, geht über den Umfang dieses Tutorials hinaus. Im Allgemeinen müssen Sie die Datei crl.pem an den Speicherort kopieren, den der Dienst erwartet, und sie dann mit systemctl neu starten.

      Sobald Sie Ihre Dienste mit der neuen crl.pem-Datei aktualisiert haben, sind Ihre Dienste in der Lage, Verbindungen von Clients oder Servern abzulehnen, die ein widerrufenes Zertifikat verwenden.

      Überprüfen und Verifizieren der Inhalte einer CRL

      Wenn Sie eine CRL-Datei überprüfen möchten, z. B. um eine Liste widerrufener Zertifikate zu bestätigen, verwenden Sie den folgenden openssl-Befehl aus Ihrem easy-rsa-Verzeichnis auf Ihrem CA-Server:

      • cd ~/easy-rsa
      • openssl crl -in pki/crl.pem -noout -text

      Sie können diesen Befehl auch auf jedem Server oder System ausführen, auf dem das openssl-Tool mit einer Kopie der Datei crl.pem installiert ist. Wenn Sie beispielsweise die Datei crl.pem auf Ihr zweites System übertragen haben und überprüfen möchten, ob das Zertifikat sammy-server widerrufen wurde, können Sie einen openssl-Befehl wie den folgenden verwenden, wobei Sie die Seriennummer, die Sie zuvor beim Widerruf des Zertifikats notiert haben, an Stelle der hier markierten verwenden:

      • openssl crl -in /tmp/crl.pem -noout -text |grep -A 1 8348B3F146A765581946040D5C4D590A


      Serial Number: 8348B3F146A765581946040D5C4D590A Revocation Date: Apr 1 20:48:02 2020 GMT

      Beachten Sie, wie der Befehl grep verwendet wird, um die eindeutige Seriennummer zu überprüfen, die Sie im Widerrufsschritt notiert haben. Jetzt können Sie den Inhalt Ihrer Zertifikatswiderrufsliste auf jedem System überprüfen, das darauf angewiesen ist, den Zugriff auf Benutzer und Dienste einzuschränken.


      In diesem Tutorial haben Sie eine private Zertifizierungsstelle mit dem Easy-RSA-Paket auf einem eigenständigen Debian 10-Server erstellt. Sie haben gelernt, wie das Vertrauensmodell zwischen Parteien funktioniert, die sich auf die CA verlassen. Sie haben auch eine Zertifikatsignieranforderung (Certificate Signing Request, CSR) für einen Übungsserver erstellt und signiert und dann gelernt, wie man ein Zertifikat widerruft. Abschließend haben Sie erfahren, wie Sie eine Zertifikatwiderrufsliste (Certificate Revocation List, CRL) für jedes System erstellen und verteilen, das auf Ihre CA angewiesen ist, um sicherzustellen, dass Benutzer oder Server, die nicht auf Dienste zugreifen sollen, daran gehindert werden.

      Jetzt können Sie Zertifikate für Benutzer ausgeben und sie mit Diensten wie OpenVPN verwenden. Sie können Ihre CA auch verwenden, um Entwicklungs- und Staging-Webserver mit Zertifikaten zu konfigurieren, um Ihre Nicht-Produktionsumgebungen zu sichern. Die Verwendung einer CA mit TLS-Zertifikaten während der Entwicklung kann dazu beitragen, sicherzustellen, dass Ihr Code und Ihre Umgebungen so gut wie möglich zu Ihrer Produktionsumgebung passen.

      Wenn Sie mehr über die Verwendung von OpenSSL erfahren möchten, bietet unser Tutorial OpenSSL-Grundlagen: Arbeiten mit SSL-Zertifikaten, privaten Schlüsseln und CSRs viele zusätzliche Informationen, die Ihnen helfen, sich mit den OpenSSL-Grundlagen vertraut zu machen.

      Source link

      How To Set Up and Configure a Certificate Authority (CA) On Ubuntu 20.04


      A Certificate Authority (CA) is an entity responsible for issuing digital certificates to verify identities on the internet. Although public CAs are a popular choice for verifying the identity of websites and other services that are provided to the general public, private CAs are typically used for closed groups and private services.

      Building a private Certificate Authority will enable you to configure, test, and run programs that require encrypted connections between a client and a server. With a private CA, you can issue certificates for users, servers, or individual programs and services within your infrastructure.

      Some examples of programs on Linux that use their own private CA are OpenVPN and Puppet . You can also configure your web server to use certificates issued by a private CA in order to make development and staging environments match production servers that use TLS to encrypt connections.

      In this guide, we’ll learn how to set up a private Certificate Authority on an Ubuntu 20.04 server, and how to generate and sign a testing certificate using your new CA. You will also learn how to import the CA server’s public certificate into your operating system’s certificate store so that you can verify the chain of trust between the CA and remote servers or users. Finally you will learn how to revoke certificates and distribute a Certificate Revocation List to make sure only authorized users and systems can use services that rely on your CA.


      To complete this tutorial, you will need access to an Ubuntu 20.04 server to host your CA server. You will need to configure a non-root user with sudo privileges before you start this guide. You can follow our Ubuntu 20.04 initial server setup guide to set up a user with appropriate permissions. The linked tutorial will also set up a firewall, which is assumed to be in place throughout this guide.

      This server will be referred to as the CA Server in this tutorial.

      Ensure that the CA Server is a standalone system. It will only be used to import, sign, and revoke certificate requests. It should not run any other services, and ideally it will be offline or completely shut down when you are not actively working with your CA.

      Note: The last section of this tutorial is optional if you would like to learn about signing and revoking certificates. If you choose to complete those practice steps, you will need a second Ubuntu 20.04 server or you can also use your own local Linux computer running Ubuntu or Debian, or distributions derived from either of those.

      Step 1 — Installing Easy-RSA

      The first task in this tutorial is to install the easy-rsa set of scripts on your CA Server. easy-rsa is a Certificate Authority management tool that you will use to generate a private key, and public root certificate, which you will then use to sign requests from clients and servers that will rely on your CA.

      Login to your CA Server as the non-root sudo user that you created during the initial setup steps and run the following:

      • sudo apt update
      • sudo apt install easy-rsa

      You will be prompted to download the package and install it. Press y to confirm you want to install the package.

      At this point you have everything you need set up and ready to use Easy-RSA. In the next step you will create a Public Key Infrastructure, and then start building your Certificate Authority.

      Step 2 — Preparing a Public Key Infrastructure Directory

      Now that you have installed easy-rsa, it is time to create a skeleton Public Key Infrastructure (PKI) on the CA Server. Ensure that you are still logged in as your non-root user and create an easy-rsa directory. Make sure that you do not use sudo to run any of the following commands, since your normal user should manage and interact with the CA without elevated privileges.

      This will create a new directory called easy-rsa in your home folder. We’ll use this directory to create symbolic links pointing to the easy-rsa package files that we’ve installed in the previous step. These files are located in the /usr/share/easy-rsa folder on the CA Server.

      Create the symlinks with the ln command:

      • ln -s /usr/share/easy-rsa/* ~/easy-rsa/

      Note: While other guides might instruct you to copy the easy-rsa package files into your PKI directory, this tutorial adopts a symlink approach. As a result, any updates to the easy-rsa package will be automatically reflected in your PKI’s scripts.

      To restrict access to your new PKI directory, ensure that only the owner can access it using the chmod command:

      • chmod 700 /home/sammy/easy-rsa

      Finally, initialize the PKI inside the easy-rsa directory:

      • cd ~/easy-rsa
      • ./easyrsa init-pki


      init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: /home/sammy/easy-rsa/pki

      After completing this section you have a directory that contains all the files that are needed to create a Certificate Authority. In the next section you will create the private key and public certificate for your CA.

      Step 3 — Creating a Certificate Authority

      Before you can create your CA’s private key and certificate, you need to create and populate a file called vars with some default values. First you will cd into the easy-rsa directory, then you will create and edit the vars file with nano or your preferred text editor:

      Once the file is opened, paste in the following lines and edit each highlighted value to reflect your own organization info. The important part here is to ensure that you do not leave any of the values blank:


      set_var EASYRSA_REQ_COUNTRY "US" set_var EASYRSA_REQ_PROVINCE "NewYork" set_var EASYRSA_REQ_CITY "New York City" set_var EASYRSA_REQ_ORG "DigitalOcean" set_var EASYRSA_REQ_EMAIL "" set_var EASYRSA_REQ_OU "Community" set_var EASYRSA_ALGO "ec" set_var EASYRSA_DIGEST "sha512"

      When you are finished, save and close the file. If you are using nano, you can do so by pressing CTRL+X, then Y and ENTER to confirm. You are now ready to build your CA.

      To create the root public and private key pair for your Certificate Authority, run the ./easy-rsa command again, this time with the build-ca option:

      In the output, you’ll see some lines about the OpenSSL version and you will be prompted to enter a passphrase for your key pair. Be sure to choose a strong passphrase, and note it down somewhere safe. You will need to input the passphrase any time that you need to interact with your CA, for example to sign or revoke a certificate.

      You will also be asked to confirm the Common Name (CN) for your CA. The CN is the name used to refer to this machine in the context of the Certificate Authority. You can enter any string of characters for the CA’s Common Name but for simplicity’s sake, press ENTER to accept the default name.


      . . . Enter New CA Key Passphrase: Re-Enter New CA Key Passphrase: . . . Common Name (eg: your user, host, or server name) [Easy-RSA CA]: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /home/sammy/easy-rsa/pki/ca.crt

      Note: If you don’t want to be prompted for a password every time you interact with your CA, you can run the build-ca command with the nopass option, like this:

      • ./easyrsa build-ca nopass

      You now have two important files — ~/easy-rsa/pki/ca.crt and ~/easy-rsa/pki/private/ca.key — which make up the public and private components of a Certificate Authority.

      • ca.crt is the CA’s public certificate file. Users, servers, and clients will use this certificate to verify that they are part of the same web of trust. Every user and server that uses your CA will need to have a copy of this file. All parties will rely on the public certificate to ensure that someone is not impersonating a system and performing a Man-in-the-middle attack.

      • ca.key is the private key that the CA uses to sign certificates for servers and clients. If an attacker gains access to your CA and, in turn, your ca.key file, you will need to destroy your CA. This is why your ca.key file should only be on your CA machine and that, ideally, your CA machine should be kept offline when not signing certificate requests as an extra security measure.

      With that, your CA is in place and it is ready to be used to sign certificate requests, and to revoke certificates.

      Step 4 — Distributing your Certificate Authority’s Public Certificate

      Now your CA is configured and ready to act as a root of trust for any systems that you want to configure to use it. You can add the CA’s certificate to your OpenVPN servers, web servers, mail servers, and so on. Any user or server that needs to verify the identity of another user or server in your network should have a copy of the ca.crt file imported into their operating system’s certificate store.

      To import the CA’s public certificate into a second Linux system like another server or a local computer, first obtain a copy of the ca.crt file from your CA server. You can use the cat command to output it in a terminal, and then copy and paste it into a file on the second computer that is importing the certificate. You can also use tools like scp, rsync to transfer the file between systems. However we’ll use copy and paste with nano in this step since it will work on all systems.

      As your non-root user on the CA Server, run the following command:

      • cat ~/easy-rsa/pki/ca.crt

      There will be output in your terminal that is similar to the following:



      Copy everything, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines and the dashes.

      On your second Linux system use nano or your preferred text editor to open a file called /tmp/ca.crt:

      Paste the contents that you just copied from the CA Server into the editor. When you are finished, save and close the file. If you are using nano, you can do so by pressing CTRL+X, then Y and ENTER to confirm.

      Now that you have a copy of the ca.crt file on your second Linux system, it is time to import the certificate into its operating system certificate store.

      On Ubuntu and Debian based systems, run the following commands as your non-root user to import the certificate:

      Ubuntu and Debian derived distributions

      • sudo cp /tmp/ca.crt /usr/local/share/ca-certificates/
      • sudo update-ca-certificates

      To import the CA Server’s certificate on CentOS, Fedora, or RedHat based system, copy and paste the file contents onto the system just like in the previous example in a file called /tmp/ca.crt. Next, you’ll copy the certificate into /etc/pki/ca-trust/source/anchors/, then run the update-ca-trust command.

      CentOS, Fedora, RedHat distributions

      • sudo cp /tmp/ca.crt /etc/pki/ca-trust/source/anchors/
      • sudo update-ca-trust

      Now your second Linux system will trust any certificate that has been signed by the CA server.

      Note: If you are using your CA with web servers and use Firefox as a browser you will need to import the public ca.crt certificate into Firefox directly. Firefox does not use the local operating system’s certificate store. For details on how to add your CA’s certificate to Firefox please see this support article from Mozilla on Setting Up Certificate Authorities (CAs) in Firefox.

      If you are using your CA to integrate with a Windows environment or desktop computers, please see the documentation on how to use certutil.exe to install a CA certificate.

      If you are using this tutorial as a prerequisite for another tutorial, or are familiar with how to sign and revoke certificates you can stop here. If you would like to learn more about how to sign and revoke certificates, then the following optional section will explain each process in detail.

      (Optional) — Creating Certificate Signing Requests and Revoking Certificates

      The following sections of the tutorial are optional. If you have completed all the previous steps then you have a fully configured and working Certificate Authority that you can use as a prerequisite for other tutorials. You can import your CA’s ca.crt file and verify certificates in your network that have been signed by your CA.

      If you would like to practice and learn more about how to sign certificate requests, and how to revoke certificates, then these optional sections will explain how both processes work.

      (Optional) — Creating and Signing a Practice Certificate Request

      Now that you have a CA ready to use, you can practice generating a private key and certificate request to get familiar with the signing and distribution process.

      A Certificate Signing Request (CSR) consists of three parts: a public key, identifying information about the requesting system, and a signature of the request itself, which is created using the requesting party’s private key. The private key will be kept secret, and will be used to encrypt information that anyone with the signed public certificate can then decrypt.

      The following steps will be run on your second Ubuntu or Debian system, or distribution that is derived from either of those. It can be another remote server, or a local Linux machine like a laptop or a desktop computer. Since easy-rsa is not available by default on all systems, we’ll use the openssl tool to create a practice private key and certificate.

      openssl is usually installed by default on most Linux distributions, but just to be certain, run the following on your system:

      • sudo apt update
      • sudo apt install openssl

      When you are prompted to install openssl enter y to continue with the installation steps. Now you are ready to create a practice CSR with openssl.

      The first step that you need to complete to create a CSR is generating a private key. To create a private key using openssl, create a practice-csr directory and then generate a key inside it. We will make this request for a fictional server called sammy-server, as opposed to creating a certificate that is used to identify a user or another CA.

      • mkdir ~/practice-csr
      • cd ~/practice-csr
      • openssl genrsa -out sammy-server.key


      Generating RSA private key, 2048 bit long modulus (2 primes) . . . . . . e is 65537 (0x010001)

      Now that you have a private key you can create a corresponding CSR, again using the openssl utility. You will be prompted to fill out a number of fields like Country, State, and City. You can enter a . if you’d like to leave a field blank, but be aware that if this were a real CSR, it is best to use the correct values for your location and organization:

      • openssl req -new -key sammy-server.key -out sammy-server.req


      . . . ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:New York Locality Name (eg, city) [Default City]:New York City Organization Name (eg, company) [Default Company Ltd]:DigitalOcean Organizational Unit Name (eg, section) []:Community Common Name (eg, your name or your server's hostname) []:sammy-server Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

      If you would like to automatically add those values as part of the openssl invocation instead of via the interactive prompt, you can pass the -subj argument to OpenSSL. Be sure to edit the highlighted values to match your practice location, organization, and server name:

      • openssl req -new -key sammy-server.key -out server.req -subj
      • /C=US/ST=New York/L=New York City/O=DigitalOcean/OU=Community/CN=sammy-server

      To verify the contents of a CSR, you can read in a request file with openssl and examine the fields inside:

      • openssl req -in sammy-server.req -noout -subject


      subject=C = US, ST = New York, L = New York City, O = DigitalOcean, OU = Community, CN = sammy-server

      Once you’re happy with the subject of your practice certificate request, copy the sammy-server.req file to your CA server using scp:

      • scp sammy-server.req sammy@your_ca_server_ip:/tmp/sammy-server.req

      In this step you generated a Certificate Signing Request for a fictional server called sammy-server. In a real-world scenario, the request could be from something like a staging or development web server that needs a TLS certificate for testing; or it could come from an OpenVPN server that is requesting a certificate so that users can connect to a VPN. In the next step, we’ll proceed to signing the certificate signing request using the CA Server’s private key.

      (Optional) — Signing a CSR

      In the previous step, you created a practice certificate request and key for a fictional server. You copied it to the /tmp directory on your CA server, emulating the process that you would use if you had real clients or servers sending you CSR requests that need to be signed.

      Continuing with the fictional scenario, now the CA Server needs to import the practice certificate and sign it. Once a certificate request is validated by the CA and relayed back to a server, clients that trust the Certificate Authority will also be able to trust the newly issued certificate.

      Since we will be operating inside the CA’s PKI where the easy-rsa utility is available, the signing steps will use the easy-rsa utility to make things easier, as opposed to using the openssl directly like we did in the previous example.

      The first step to sign the fictional CSR is to import the certificate request using the easy-rsa script:

      • cd ~/easy-rsa
      • ./easyrsa import-req /tmp/sammy-server.req sammy-server


      . . . The request has been successfully imported with a short name of: sammy-server You may now use this name to perform signing operations on this request.

      Now you can sign the request by running the easyrsa script with the sign-req option, followed by the request type and the Common Name that is included in the CSR. The request type can either be one of client, server, or ca. Since we’re practicing with a certificate for a fictional server, be sure to use the server request type:

      • ./easyrsa sign-req server sammy-server

      In the output, you’ll be asked to verify that the request comes from a trusted source. Type yes then press ENTER to confirm this:


      You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a server certificate for 3650 days: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes . . . Certificate created at: /home/sammy/easy-rsa/pki/issued/sammy-server.crt

      If you encrypted your CA key, you’ll be prompted for your password at this point.

      With those steps complete, you have signed the sammy-server.req CSR using the CA Server’s private key in /home/sammy/easy-rsa/pki/private/ca.key. The resulting sammy-server.crt file contains the practice server’s public encryption key, as well as a new signature from the CA Server. The point of the signature is to tell anyone who trusts the CA that they can also trust the sammy-server certificate.

      If this request was for a real server like a web server or VPN server, the last step on the CA Server would be to distribute the new sammy-server.crt and ca.crt files from the CA Server to the remote server that made the CSR request:

      • scp pki/issued/sammy-server.crt sammy@your_server_ip:/tmp
      • scp pki/ca.crt sammy@your_server_ip:/tmp

      At this point, you would be able to use the issued certificate with something like a web server, a VPN, configuration management tool, database system, or for client authentication purposes.

      (Optional) — Revoking a Certificate

      Occasionally, you may need to revoke a certificate to prevent a user or server from using it. Perhaps someone’s laptop was stolen, a web server was compromised, or an employee or contractor has left your organization.

      To revoke a certificate, the general process follows these steps:

      1. Revoke the certificate with the ./easyrsa revoke client_name command.
      2. Generate a new CRL with the ./easyrsa gen-crl command.
      3. Transfer the updated crl.pem file to the server or servers that rely on your CA, and on those systems copy it to the required directory or directories for programs that refer to it.
      4. Restart any services that use your CA and the CRL file.

      You can use this process to revoke any certificates that you’ve previously issued at any time. We’ll go over each step in detail in the following sections, starting with the revoke command.

      Revoking a Certificate

      To revoke a certificate, navigate to the easy-rsa directory on your CA server:

      Next, run the easyrsa script with the revoke option, followed by the client name you wish to revoke. Following the practice example above, the Common Name of the certificate is sammy-server:

      • ./easyrsa revoke sammy-server

      This will ask you to confirm the revocation by entering yes:


      Please confirm you wish to revoke the certificate with the following subject: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Continue with revocation: yes . . . Revoking Certificate 8348B3F146A765581946040D5C4D590A . . .

      Note the highlighted value on the Revoking Certificate line. This value is the unique serial number of the certificate that is being revoked. If you want to examine the revocation list in the last step of this section to verify that the certificate is in it, you’ll need this value.

      After confirming the action, the CA will revoke the certificate. However, remote systems that rely on the CA have no way to check whether any certificates have been revoked. Users and servers will still be able to use the certificate until the CA’s Certificate Revocation List (CRL) is distributed to all systems that rely on the CA.

      In the next step you’ll generate a CRL or update an existing crl.pem file.

      Generating a Certificate Revocation List

      Now that you have revoked a certificate, it is important to update the list of revoked certificates on your CA server. Once you have an updated revocation list you will be able to tell which users and systems have valid certificates in your CA.

      To generate a CRL, run the easy-rsa command with the gen-crl option while still inside the ~/easy-rsa directory:

      If you have used a passphrase when creating your ca.key file, you will be prompted to enter it. The gen-crl command will generate a file called crl.pem, containing the updated list of revoked certificates for that CA.

      Next you’ll need to transfer the updated crl.pem file to all servers and clients that rely on this CA each time you run the gen-crl command. Otherwise, clients and systems will still be able to access services and systems that use your CA, since those services need to know about the revoked status of the certificate.

      Transferring a Certificate Revocation List

      Now that you have generated a CRL on your CA server, you need to transfer it to remote systems that rely on your CA. To transfer this file to your servers, you can use the scp command.

      Note: This tutorial explains how to generate and distribute a CRL manually. While there are more robust and automated methods to distribute and check revocation lists like OCSP-Stapling, configuring those methods is beyond the scope of this article.

      Ensure you are logged into your CA server as your non-root user and run the following, substituting in your own server IP or DNS name in place of your_server_ip:

      • scp ~/easy-rsa/pki/crl.pem sammy@your_server_ip:/tmp

      Now that the file is on the remote system, the last step is to update any services with the new copy of the revocation list.

      Updating Services that Support a CRL

      Listing the steps that you need to use to update services that use the crl.pem file is beyond the scope of this tutorial. In general you will need to copy the crl.pem file into the location that the service expects and then restart it using systemctl.

      Once you have updated your services with the new crl.pem file, your services will be able to reject connections from clients or servers that are using a revoked certificate.

      Examining and Verifying the Contents of a CRL

      If you would like to examine a CRL file, for example to confirm a list of revoked certificates, use the following openssl command from within your easy-rsa directory on your CA server:

      • cd ~/easy-rsa
      • openssl crl -in pki/crl.pem -noout -text

      You can also run this command on any server or system that has the openssl tool installed with a copy of the crl.pem file. For example, if you transferred the crl.pem file to your second system and want to verify that the sammy-server certificate is revoked, you can use an openssl command like the following, substituting the serial number that you noted earlier when you revoked the certificate in place of the highlighted one here:

      • openssl crl -in /tmp/crl.pem -noout -text |grep -A 1 8348B3F146A765581946040D5C4D590A


      Serial Number: 8348B3F146A765581946040D5C4D590A Revocation Date: Apr 1 20:48:02 2020 GMT

      Notice how the grep command is used to check for the unique serial number that you noted in the revocation step. Now you can verify the contents of your Certificate Revocation List on any system that relies on it to restrict access to users and services.


      In this tutorial you created a private Certificate Authority using the Easy-RSA package on a standalone Ubuntu 20.04 server. You learned how the trust model works between parties that rely on the CA. You also created and signed a Certificate Signing Request (CSR) for a practice server and then learned how to revoke a certificate. Finally, you learned how to generate and distribute a Certificate Revocation List (CRL) for any system that relies on your CA to ensure that users or servers that should not access services are prevented from doing so.

      Now you can issue certificates for users and use them with services like OpenVPN. You can also use your CA to configure development and staging web servers with certificates to secure your non-production environments. Using a CA with TLS certificates during development can help ensure that your code and environments match your production environment as closely as possible.

      If you would like to learn more about how to use OpenSSL, our OpenSSL Essentials: Working with SSL Certificates, Private Keys and CSRs tutorial has lots of additional information to help you become more familiar with OpenSSL fundamentals.

      Source link