So generieren Sie ein selbstsigniertes SSL-Zertifikat unter Linux

SSL ist ein Protokoll, das zur Verschlüsselung und Authentifizierung von Daten in Netzwerken verwendet wird, in der Regel zwischen einem Server und einem Client. Das SSL-Protokoll und sein Nachfolger TLS verwenden eine asymmetrische Verschlüsselung, die auf zwei Schlüsseln basiert: einem privaten und einem öffentlichen. Ein SSL-Zertifikat bietet eine verschlüsselte Verbindung und schafft eine vertrauensvolle Umgebung, da es bescheinigt, dass die Website, mit der wir eine Verbindung herstellen, effektiv das ist, was wir beabsichtigen, und keine böswillige Partei versucht, sich als sie auszugeben. Gültige SSL-Zertifikate werden von einer CA (Certificate Authority) freigegeben, können aber auch selbst generiert werden. Selbstsignierte SSL-Zertifikate bieten zwar weiterhin Verschlüsselung, bieten aber keine Vertrauenswürdigkeit, da es sich bei dem Eigentümer und dem Aussteller um dieselbe Entität/Person handelt. Nichtsdestotrotz können sie in bestimmten Situationen nützlich sein: zum Beispiel zum Testen oder zur internen Anwendung. In diesem Tutorial erfahren Sie, wie Sie mit dem OpenSSL-Toolkit unter Linux ein selbstsigniertes SSL-Zertifikat und ein Schlüsselpaar generieren, wie Sie den Inhalt eines Zertifikats lesen und wie Sie den öffentlichen Schlüssel daraus extrahieren.

In diesem Tutorial lernen Sie:

So generieren Sie ein selbstsigniertes SSL-Zertifikat und ein Schlüsselpaar unter Linux
So lesen Sie den Inhalt eines SSL-Zertifikats
So extrahieren Sie den öffentlichen Schlüssel aus einem Zertifikat

Verwendete Softwareanforderungen und Konventionen

Installieren des OpenSSL-Toolkits

Das OpenSSL-Toolkit ist in den offiziellen Repositories der am häufigsten verwendeten Linux-Distributionen verfügbar. Es enthält eine Reihe von Dienstprogrammen und Bibliotheken, die Unterstützung für verschiedene Arten von Protokollen und Algorithmen bieten. Es gibt sehr hohe Änderungen, die das Toolkit bereits auf Ihrem System installiert hat, als Abhängigkeit von seinen Kernpaketen; Um es jedoch explizit zu installieren, können wir einfach den Paketmanager unserer bevorzugten Distribution verwenden. Auf Fedora und anderen Distributionen, die Teil der Red Hat-Familie sind, verwenden wir dnf:

sudo dnf install openssl

Auf Debian, Ubuntu und deren Derivaten können wir stattdessen den apt-Wrapper verwenden:

sudo apt install openssl

Wenn Archlinux unser täglicher Treiber ist, können wir das OpenSSL-Toolkit mit dem Paketmanager pacman installieren. Das Paket wird im "core"-Repository verwaltet:

sudo pacman -Sy openssl

Sobald das Toolkit installiert ist, können wir sehen, wie wir es verwenden können, um ein selbstsigniertes Zertifikat zu generieren.

Generieren eines selbstsignierten Zertifikats

Um ein selbstsigniertes Zertifikat zu generieren, können wir eines der vielen Dienstprogramme verwenden, die im OpenSSL-Toolkit enthalten sind: req. Dieses Tool wird auf folgende Weise gut beschrieben:

Der Befehl req erstellt und verarbeitet in erster Linie Zertifikatsanforderungen im PKCS#10-Format. Es kann
zusätzlich selbstsignierte Zertifikate erstellen, die z.B. als Root-CAs verwendet werden können.

Um unser Zertifikat zusammen mit einem privaten Schlüssel zu generieren, müssen wir req mit der Option -newkey ausführen. Sehen wir uns ein Beispiel für den Befehl an. Wir werden später darauf eingehen:

openssl req -newkey rsa:4096  -x509  -sha512  -days 365 -nodes -out certificate.pem -keyout privatekey.pem

Lassen Sie uns die verschiedenen Optionen analysieren, die wir im obigen Beispiel verwendet haben. Zuerst haben wir "req" mit der Option -newkey aufgerufen: Sie wird verwendet, um eine neue Zertifikatsanforderung und einen privaten Schlüssel zu erstellen. Es braucht ein Argument, das wir verwenden können, um den Typ des Schlüssels, den wir generieren möchten, zusammen mit seiner Größe anzugeben. Im Beispiel haben wir rsa:4096 verwendet, um einen RSA-Schlüssel mit 4096 Bit zu erstellen. Wenn wir die Schlüsselgröße weglassen, wird die Standardgröße (2048) verwendet.

Die zweite Option, die wir verwendet haben, ist -x509. Mit dieser Option wird lediglich das Verhalten des Programms so geändert, dass anstelle einer Zertifikatanforderung ein selbstsigniertes Zertifikat erstellt wird. Was ist der Unterschied zwischen den beiden? Eine Zertifikatanforderung wird auf dem Server erstellt, auf dem das Zertifikat installiert und an eine Zertifizierungsstelle gesendet werden muss, die das Zertifikat ausstellt. Ein selbstsigniertes Zertifikat hingegen ist, wie bereits erwähnt, im Besitz derselben Person oder Organisation und wird von ihr bereitgestellt. Es ist keine Zertifizierungsstelle an dem Prozess beteiligt: Aus diesem Grund bietet diese Art von Zertifikat kein Vertrauen.

Mit -sha512 haben wir den Message Digest angegeben, um die Anforderung/das Zertifikat zu signieren. Der Standarddigest wird wiederum in der OpenSSL-Konfigurationsdatei unter dem Schlüssel default_md angegeben und lautet sha256. Um die Liste aller verfügbaren Digests zu erhalten, können wir Folgendes ausführen:

openssl list --digest-commands

Wir sollten ein Ergebnis erhalten, das dem folgenden ähnelt:

blake2b512        blake2s256        gost              md2               
md4               md5               rmd160            sha1              
sha224            sha256            sha3-224          sha3-256          
sha3-384          sha3-512          sha384            sha512            
sha512-224        sha512-256        shake128          shake256          
sm3

Da wir ein selbstsigniertes Zertifikat generieren, können wir selbst entscheiden, wie lange es gültig ist. Die Gültigkeitsdauer wird in Tagen ausgedrückt (30 ist die Standardeinstellung); Die Anzahl der Tage, die als Argument an die Option -days übergeben werden. In diesem Fall haben wir unseren Zertifikatswert für ein ganzes Jahr festgelegt.

Mit der Option -nodes haben wir angegeben, dass wir den generierten privaten Schlüssel nicht verschlüsseln möchten. Die Verschlüsselung des privaten Schlüssels ist ohne Zweifel nützlich: Dies kann als Sicherheitsmaßnahme für den Fall gedacht sein, dass ihn jemand gestohlen hat, da für die Verwendung eine Passphrase angegeben werden muss. Nur als Beispiel: Wenn wir einen privaten Schlüssel mit Apache verwenden, müssen wir die Passphrase angeben, um ihn jedes Mal zu entschlüsseln, wenn wir den Daemon neu starten. Da wir in diesem Fall ein selbstsigniertes Zertifikat generieren, das wir zum Testen verwenden werden, können wir die Verschlüsselung des privaten Schlüssels vermeiden.

Schließlich haben wir die Optionen -out und -keyout verwendet, um die Dateinamen anzugeben, in die das Zertifikat bzw. der Schlüssel geschrieben werden soll. In diesem Fall wird das Zertifikat in der Datei certificate.pem und der private Schlüssel in der Datei privatekey.pem gespeichert. Warum haben wir ".pem" als Suffix für den Dateinamen verwendet? Dies liegt daran, dass sowohl das Zertifikat als auch der Schlüssel im PEM-Format erstellt werden. PEM steht für "Privacy Enhanced Mail": Es handelt sich im Grunde genommen um einen Container, der base64-formatierte Daten enthält.

Bereitstellen der Zertifikatsinformationen

Sobald wir den Befehl zum Generieren des Zertifikats ausgeführt haben, werden wir aufgefordert, eine Reihe von Informationen anzugeben. Unter den anderen:

Zwei Buchstaben, die den Ländernamen darstellen (z. B. US)
Der vollständige Name des Bundesstaates oder der Provinz (z. B. Kalifornien)
Der Name der Stadt (z. B. Los Angeles)
Der Name der Organisation oder des Unternehmens (Der offizielle Name des Unternehmens)
Der vollqualifizierte Name des Servers

Generating a RSA private key
.............................................++++
...........................++++
writing new private key to 'privatekey.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:California
Locality Name (eg, city) [Default City]:Los Angeles
Organization Name (eg, company) [Default Company Ltd]:.
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:www.fqdn.com
Email Address []:

Auslesen des Inhalts des Zertifikats

Am Ende des Prozesses sollten wir die beiden erstellten Dateien (certificate.pem und privatekey.pem) in unserem aktuellen Arbeitsverzeichnis finden. Wenn wir einen Blick auf unsere Zertifikatsdatei werfen, sollten wir einen Inhalt finden, der dem folgenden ähnelt:

Wie bereits erwähnt, ist das Zertifikat PEM-formatiert, daher können wir zum Lesen seines Inhalts den folgenden Befehl ausgeben:

openssl x509 -noout -in certificate.pem -text

Das Dienstprogramm x509 wird zum Anzeigen und Signieren von Zertifikaten verwendet. In diesem Fall haben wir es mit der Option -noout aufgerufen, um zu verhindern, dass die codierte Version des Zertifikats in die Ausgabe aufgenommen wird, -in, um die Datei mit dem Zertifikat anzugeben, das als Eingabe verwendet werden soll (in diesem Fall certificate.pem) und -text, um die Ausgabe des Zertifikats in Textform zu drucken. In diesem Fall wollten wir nur den Inhalt des Zertifikats in der Standardausgabe visualisieren. Um es in einer Datei zu speichern, hätten wir die Option -out verwenden und den Zieldateinamen als Argument angeben können, oder einfach die Shell-Umleitung verwenden. Hier ist die Ausgabe des Befehls:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0f:d2:5a:6c:99:74:37:2e:4b:3a:86:a3:d3:61:95:6a:03:85:04:71
        Signature Algorithm: sha512WithRSAEncryption
        Issuer: C = US, ST = California, L = Los Angeles, CN = www.fqdn.com
        Validity
            Not Before: Mar 21 11:03:48 2022 GMT
            Not After : Mar 21 11:03:48 2023 GMT
        Subject: C = US, ST = California, L = Los Angeles, CN = www.fqdn.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:b9:6a:fa:50:18:bb:3d:26:80:ef:a4:08:1d:8c:
                    11:14:c5:5e:81:73:d3:4d:32:b2:86:9a:c2:04:53:
                    44:74:b8:34:ca:99:42:71:01:30:ae:f3:ef:59:83:
                    fb:bc:8d:e6:ca:b4:7b:6c:82:fe:f5:19:0a:76:26:
                    d6:de:9e:33:62:52:74:a9:63:f9:09:f8:41:4f:9c:
                    68:0b:23:4c:62:61:ad:59:8e:f5:bc:e8:42:b3:1a:
                    3d:4e:19:6b:4d:20:b3:42:a5:ae:a1:6f:14:7e:c8:
                    d5:e9:1d:ac:6a:26:5d:ef:40:58:55:b7:21:a6:0d:
                    fb:94:76:a9:95:67:59:c4:2e:5a:42:0f:25:fa:b3:
                    c9:67:38:f2:2f:3b:84:62:d0:6c:1f:b1:ea:58:8b:
                    12:35:13:45:47:01:d9:66:04:b0:ed:39:cd:e7:ed:
                    17:a1:ea:bd:27:89:e7:b9:26:96:82:d1:d3:d8:75:
                    82:f6:f6:07:31:6b:d7:7a:59:87:24:61:0a:3b:29:
                    97:49:43:ef:26:a1:9e:98:f2:ff:ea:49:01:a0:bf:
                    9b:45:69:b1:b6:c2:2e:de:e5:e0:43:09:a3:82:46:
                    cf:64:84:d2:eb:dd:7d:08:92:f3:89:e3:51:97:25:
                    23:be:62:c6:f8:ff:b4:b5:ae:78:a9:ff:81:a8:76:
                    7b:79:c3:05:55:f0:ce:11:b4:38:00:ef:1f:bd:58:
                    bd:cf:2e:74:ce:30:38:94:d4:64:ab:fc:a9:98:24:
                    18:dc:e1:10:f8:67:b5:ef:b8:ec:81:60:5d:7a:f3:
                    1e:01:fe:87:2b:55:71:01:0c:7f:fc:4b:9a:3a:33:
                    3e:c8:28:33:e6:ad:18:ef:1d:98:33:1e:89:fb:4c:
                    0b:e8:d2:5a:9d:53:70:2a:12:29:ed:45:79:89:55:
                    30:4a:f6:5f:41:98:8d:d6:37:d5:a0:02:8a:75:3e:
                    07:c4:67:45:56:85:c9:8e:5f:25:fb:77:0c:48:94:
                    29:07:95:f0:07:39:fc:cd:09:02:9b:07:3d:11:8b:
                    62:4e:e8:5e:fc:c6:a0:41:aa:20:a1:c9:44:63:eb:
                    fd:db:4b:7c:62:1b:b1:46:93:08:37:30:d9:11:84:
                    0e:ad:97:0b:20:29:41:ba:89:b6:36:84:7d:b6:59:
                    47:06:86:5a:d6:04:48:b6:87:c8:9c:c7:c3:02:02:
                    6e:51:ea:11:46:db:d5:b1:9e:e9:75:46:26:5f:9f:
                    15:92:bc:9c:4b:e2:4d:1b:bc:d5:1b:2e:b0:56:71:
                    fb:4a:20:91:11:8b:31:ae:55:83:e7:e5:96:61:9f:
                    4d:46:08:02:d3:20:b6:b2:f2:ad:72:78:73:27:a8:
                    36:92:6f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                62:B1:F4:A8:E1:76:4E:DA:23:67:2D:4B:48:BC:DE:63:4D:7A:15:CB
            X509v3 Authority Key Identifier: 
                keyid:62:B1:F4:A8:E1:76:4E:DA:23:67:2D:4B:48:BC:DE:63:4D:7A:15:CB

            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: sha512WithRSAEncryption
         1d:67:0f:7e:5e:0f:13:7b:ce:80:cd:18:d7:01:ce:65:b7:b0:
         c7:6f:21:1c:41:1c:8b:d8:d1:53:1d:2b:4c:57:2a:60:30:62:
         d9:d1:1f:6d:ff:8e:56:d0:8b:0b:b1:83:ee:a9:b4:d6:84:cd:
         ca:c6:9c:f8:84:7c:47:7b:c6:08:6d:b2:20:9b:88:02:4b:5c:
         30:32:17:2d:37:a6:a3:de:24:14:fb:8c:d1:82:1d:bc:4e:2e:
         52:a4:87:8d:98:fc:4b:b1:e2:ac:2a:ed:f9:e9:21:36:bc:a0:
         90:f5:a3:f7:f5:5a:e7:5e:aa:a7:58:b6:97:b5:b0:73:f5:03:
         14:91:b1:fe:41:49:05:17:e4:fb:0d:be:07:38:86:9d:b4:5a:
         02:c7:91:e9:c0:c1:53:59:e5:3f:60:2c:cb:fe:15:94:30:67:
         f2:a9:1a:d9:a1:71:49:43:a9:45:cb:97:14:7f:e7:6a:9d:19:
         41:95:db:01:d9:ba:fc:5f:51:43:5b:cd:14:ff:4b:b0:63:7c:
         6b:76:54:86:b9:c6:a2:92:16:7c:22:09:eb:b6:4c:4a:85:40:
         e8:9f:fb:0a:40:ff:2d:c6:75:06:f9:67:ba:2e:63:4e:25:0e:
         bb:0d:e0:d4:05:9c:ce:c5:b4:36:19:58:db:87:f6:af:1c:4d:
         45:2b:de:ec:f2:9a:4a:e2:0e:63:5f:bb:fa:15:20:35:10:93:
         ce:23:35:33:16:f8:61:c0:6e:48:12:55:29:d2:5a:41:d1:9a:
         47:ef:d9:fd:54:91:15:a0:4b:83:b2:f6:78:1d:98:e5:71:03:
         2a:4b:eb:db:49:78:61:85:16:71:ea:a6:ed:8e:64:98:00:e0:
         73:9a:66:4b:4c:30:b7:d3:a7:0c:bb:af:09:cc:5c:c1:7a:ef:
         9c:42:19:1b:95:e4:25:37:ba:cf:db:74:1f:cd:a3:a9:84:11:
         39:27:62:59:60:7e:b4:82:e6:a0:33:bd:e9:32:6a:86:61:86:
         cf:dc:1e:f0:93:b7:42:7d:92:5d:39:df:c2:60:1b:5a:b4:0d:
         5e:20:92:7a:d4:09:4f:2e:87:81:34:bb:aa:75:97:b1:f8:23:
         bd:ff:63:12:fa:d2:3b:8b:8c:74:7c:1b:16:2b:0a:5b:94:69:
         22:58:45:d2:0f:75:16:26:60:d9:81:7b:e9:83:79:26:b0:c0:
         32:ca:46:80:07:eb:df:8e:00:c8:fa:17:a5:e1:e2:24:cc:2c:
         a6:13:a2:0d:35:d6:5a:1a:d1:5e:a2:d7:83:69:32:73:af:77:
         ed:6a:13:7b:60:d2:2c:78:f2:0d:4b:04:ec:c6:57:38:50:ee:
         a4:ab:c0:b0:24:4b:01:70

Extrahieren des öffentlichen Schlüssels aus einem Zertifikat

Wie wir gesehen haben, basiert SSL/TLS auf einer asymmetrischen Verschlüsselung und der Verwendung eines privaten und eines öffentlichen Schlüssels. Der private Schlüssel muss sicher auf dem Server bleiben, während der öffentliche Schlüssel zusammen mit dem Zertifikat an den Client gesendet wird. Wie können wir den darin enthaltenen öffentlichen Schlüssel extrahieren? Nun, es ist ein sehr einfacher Vorgang. Um diese Aufgabe zu erfüllen, müssen wir erneut den Befehl -x509 verwenden. Um den öffentlichen Schlüssel aus dem Zertifikat zu extrahieren, das wir in diesem Tutorial generiert haben, würden wir Folgendes ausführen:

openssl x509 -pubkey -noout -in certificate.pem

Wir haben x509 aufgerufen, diesmal mit der Option -pubkey, die dafür sorgt, dass der öffentliche Schlüssel des Zertifikats im PEM-Format gedruckt wird:

Abschließende Gedanken

In diesem Tutorial haben wir gelernt, wie man mit dem OpenSSL-Toolkit und dem Befehl "req" ein selbstsigniertes SSL-Zertifikat generiert. Wir haben gesehen, wie man die Zertifikatsinformationen bereitstellt und wie man ihre Gültigkeit in Tagen festlegt. Schließlich haben wir gesehen, wie man den Inhalt des Zertifikats ausliest und wie man den öffentlichen Schlüssel im PEM-Format daraus extrahiert.