SSL Zertifikat für Server erstellen

Zur Bestätigung der digitalen Signatur von Diensten sind SSL-Zertifikate notwendig, diese können über verschieden Anbieter bezogen werden. Die folgende Anleitung bezieht sich dabei auf InterSSL, kann aber in ähnlicher Form für alle gängigen Anbieter erwartet werden.

Zertifikat verlängern

Um mehrere Geräte oder Dienste mit einem Zertifikat zu schützen ist ein sogenanntes Wildcard SSL-Zertifikat notwendig, bei InterSSL ist das konkret das „Comodo PositiveSSL Wildcard“. Einem solchen Zertifikat sind in der Regel folgende Infos zugeordnet:

SSL StatusActive
ProduktnameComodo PositiveSSL Wildcard
SSL ID3050448
SSL Order ID405734137
Vendor Statusvalid
SSL TokenE6EFD82598MzA1MDQ0OA2#!c7k7pb7uqurilc1cglt7
SSL Ausstellungsdatum21.08.2021
SSL Ablaufdatum22.09.2022
Order Expiry Date16.11.2023
Domain(s)*.dachs.blog

Technisch dürfen SSL-Zertifikate nur 13 Monate gültig sein und müssen danach neu ausgestellt werden, daher ist häufig das Ablaufdatum des Zertifikates nicht mit dem Ende des bestellten Zeitraumes identisch. Beim Neuausstellen wird ein „Certificate Signing Request“ (CSR) an den Aussteller übermittelt, die Daten dazu werden als Base64-Text übermittelt und sind liegen von der ursprünglichen Beantragung noch vor oder sind anzugeben. Im Falle von InterSSL werden die Daten automatisch übernommen.

Ein CSR wird grundsätzlich folgende Form aufweisen:

-----BEGIN CERTIFICATE REQUEST-----
MIIE4DCCAsgCAQAwgZoxCzAJBgNVBAYTAkRFMRQwEgYDVQQIDAtCcmFuZGVuYnVy
...
k/F4uQ==
-----END CERTIFICATE REQUEST-----

Neben dem CSR muss der Typ des gewünschten Servers angegeben werden, hier stehen meist verschiedene Anbieter von (Web-) Servern zur Verfügung:

  • AOL
  • Apache + MOD SSL
  • Apache + SSLeay
  • C2Net Stronghold
  • Cobalt Series
  • Covalent Server Software
  • Cpanel   Ensim   Hsphere
  • IBM HTTP
  • IBM Internet Connection Server
  • iPlanet Server 4.1
  • Java Web Server (Javasoft / Sun)
  • Lotus Domino 4.6+
  • Lotus Domino Go 4.6.2.51
  • Microsoft IIS 4.0
  • Microsoft IIS 5.0
  • Netscape Enterprise/FastTrack
  • Netscape FastTrack
  • Java Web Server (Javasoft / Sun)
  • Oracle   Plesk
  • Quid Pro Quo
  • R3 SSL Server
  • Raven SSL
  • RedHat Linux
  • SAP Web Application Server
  • Zeus v3+
  • Other  

Zur Verwendung für RDP-Sitzungen und Apache 2 sollte hier „Other“ gewählt werden. Der Signatur-Algorithmus ist mit SHA2 fest vorgegeben.

Um die Berechtigung für das Zertifikat zu prüfen, muss die Identität geprüft werden, am einfachsten erfolgt dies über fest vorgegebenen E-Mail-Adressen, die zu jeder Domain vorhanden sind. Es muss dann ein Bestätigungslink aufgerufen werden, der dann den eigentlichen Ausstellungsvorgang anstößt. Die Zustellung des Zertifikates erfolgt dann als ZIP-Datei, die folgende (oder ähnliche) Dateien enthält:

  • AAACertificateServices.crt
  • SectigoRSADomainValidationSecureServerCA.crt
  • STAR_dachs_blog.crt
  • USERTrustRSAAAACA.crt

Daneben müssen von der ursprünglichen Beantragung noch die folgenden Dateien vorliegen, die bei einer Neuausstellung nicht mit übermittelt werden:

  • wildcard.dachs.blog.csr
  • wildcard.dachs.blog.key

Zertifikat umwandeln

Um das so ausgestellte Zertifikat für eine RDP-Sitzung oder den Plex-Media-Server nutzen zu können, muss es in zwei weitere Formate umgewandelt werden, beides können über die InterSSLSSL-Tools erstellt werden:

Mit Hilfe der Konverter werden die folgenden beiden Dateien erstellt, auf die weitere Blog-Beiträge verweisen werden:

  • STAR_dachs_blog.pem
  • STAR_dachs_blog.pfx

Wird bei der Installation ein Intermediate-Zertifikat benötigt, muss häufig die Datei „SectigoRSADomainValidationSecureServerCA.crt“ genutzt werden, nicht „AAACertificateServices.crt“.

This post is also available in: Deutsch

Schreibe einen Kommentar