Einige Anbieter wie Comodo, Thawte oder Geotrust benötigen für die Ausstellung eines SSL-Zertifikats eine CSR-Datei, die die wichtigsten Informationen zu Ihrem Zertifikat und Ihrer Firma enthält. Nicht alle Anbieter stellen die Möglichkeit, eine Zertifikatsanfrage online zu generieren zur Verfügung. Dieser Artikel erklärt, wie man mittels openssl eine Zertifikatsanfrage (CSR) für Multi-Domain-Zertifikate erstellen kann. Achtung: das beschriebene Vorgehen kann bei einigen Anbietern abweichen. Diese Anbieter benötigen einen CSR für ein Single-Domain-Zertifikate. Während des Enrollments erhalten Sie dann die Möglichkeit, die alternativen Namen anzugeben, unter denen der im Subject/Betreff des Zertifikates stehende Common Name/Domainname erreichbar ist.

1. Vorbereitungen

Melden Sie sich am (PC)System als root an oder übernehmen Sie mit su die Rechte des SuperUsers. In den folgenden Schritten wird die Erstellung einer *.conf, eines Private-Keys und einer CSR-Datei erklärt. Für die Bezeichnung der Files wähle ich persönlich den (Haupt-)Domain-Namen in Verbindung mit dem Erstellungsdatum (Monat.Jahr) und dem entsprechenden Dateinamens-Suffix. Somit behalte ich den Überblick, auch dann, wenn es einmal mehr zu tun gibt.
1.1 Die *.conf erstellen
Die Datei meinedomain.tld.2016.01.conf erstellen:
cd /etc/ssl && touch meinedomain.tld.2016.01.conf
nano /etc/ssl/meinedomain.tld.2016.01.conf
Wichtig: kopieren Sie die unteren Angaben in den Editor und ändern Sie diese Ihren Bedürfnissen entsprechend ab. Verwenden Sie keine Sonderzeichen!
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
C = AT
ST = Steiermark
L = Graz
O = Unternehmensbezeichnung oder Vor Nachname
OU = Abteilung
CN = meinedomain.tld
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.meinedomain.tld
DNS.2 = meinedomain.tld
DNS.3 = www.anderedomain.tld
DNS.4 = anderedomain.tld
Wichtig: tragen Sie bei den "alt-names" alle möglichen Varianten ein. Es werden zuerst die SAN-Einträge gecheckt und falls welche existieren, wird der CN nicht nochmal überprüft. Fazit: sollten SAN-Einträge existieren, wird der CN in manchen Fällen ignoriert. Im CN sollten Sie trotzdem immer die Haupt-Domain eintragen. Weitere Informationen unter RFC 6125.
1.2 Private Key erstellen
Der Private Key mit einer Schlüssellänge von 2048 Bit wird erstellt mittels der Eingabe
openssl genrsa -out meinedomain.tld.2016.01.key 2048
1.3 Das CSR erstellen
Das CSR wird unter Zuhilfenahme der erstellten meinedomain.tld.2016.01.conf ezeugt:
openssl req -new -out meinedomain.tld.2016.01.csr -key meinedomain.tld.2016.01.key -config meinedomain.tld.2016.01.conf 
Das CSR auslesen und kopieren mit
nano /etc/ssl/meinedomain.tld.2016.01.csr
multi-domain-CSR-mit-OpenSSL-erstellen-3
1.4 CSR online prüfen
Unter https://www.networking4all.com/en/support/tools/csr+check/ können Sie einen Online-Check durchführen. Kopieren Sie den gesamten Inhalt des CSR in das Eingabefeld... multi-domain-CSR-mit-OpenSSL-erstellen-2 ...und bestätigen Sie mit Check CSR multi-domain-CSR-mit-OpenSSL-erstellen-1.
1.5 CSR anwenden
Nun können Sie das CSR an den entsprechenden Dienstleister weitergeben und die Ausstellung des Zertifikats mit den von Ihnen angegebenen Daten kann erfolgen.
1.6 Weiterführende Links
https://www.thomas-krenn.com https://icertificate.eu https://ssl-trust.com [wdns_howto_callout class="info" headline="Anbieter kontaktieren"]Sollten Sie sich unsicher über die Art des benötigten CSR sein (Single-/Multi-Domain, empfehle ich, mit dem Anbieter (CA) Rücksprache zu halten.[/wdns_howto_callout]Zuletzt geändert: 2016-01-12 11:12:58

Weiterlesen

In dieser Anleitung zeige ich, wie Sie unter MS Windows 7 die Anwendung Win32 OpenSSL installieren und einrichten. Dazu werden wir die notwendigen Programmdateien downloaden und installieren sowie einige Anpassungen zur einfacheren Handhabung vornehmen. Diese Anleitung und die folgenden Screenshots beruhen auf MS Windows 7 - die Installation wird aber auch mit aktuelleren bzw. mit älteren Version des Betriebsystems funktionieren. Sie sollten jedoch beachten, dass die gezeigten Darstellungen geringfügig von der Benutzeroberfläche abweichen werden. Alle Installationsaktionen müssen mit den Rechten eines Administrators ausgeführt werden.

1. Vorbereitung

Zuerst laden wir das Installationspaket von Win32 OpenSSL von der offiziellen Seite des Herstellers Shining Light Productions herunter. Ich habe mich dabei für die 32-Bit Version (Win32 OpenSSL v1.0.2g) entschieden. Diese Version läuft sowohl auf 32 als auch auf 64 Bit MS Windows Systemen. Die Installation gestaltet sich recht einfach: ein Doppelklick auf die ausführbare EXE-Datei startet die Installation: openssl-win32-1 openssl-win32-2 openssl-win32-3 Damit ich in späterer Folge keine Fingerakkrobatik anwenden muss, ändere ich den Installationpfad auf C:\OpenSSL (wie in Abb. unten) openssl-win32-5 openssl-win32-6 openssl-win32-7 openssl-win32-8 Im vorletzten Schritt der Installation können Sie eine Spende zur Unterstützung des Projekts einreichen (wenn Sie möchten). Wenn Sie dazu gerade keine Zeit haben, entfernen Sie das Häckchen und bestätigen mit der Taste *Finish*: openssl-win32-9

2. Konfiguration

Damit die erstellten Zertifikate, Keys und CSRs einfach abgelegt und wiedergefunden werden können, wird dazu ein eigenes Verzeichnis erstellt: c:\OpenSSL-Data Für die  ordnungsgemäße Funktion benötigt Win32 OpenSSL zwei Umgebungsvariablen. Mittels Command-Prompt (DOS Eingabeaufforderung) werden folgende Befehle abgesetzt (eingegeben):
set RANDFILE=c:\OpenSSL-Data\.rnd
set OPENSSL_CONF=C:\OpenSSL\bin\openssl.cfg
Dabei sind die geänderten Pfadangaben zu berücksichtigen! openssl-win32-11 Nach einem Neustart von MS Windows ist die Anwendung bereit für den ersten Einsatz.  Zuletzt geändert: 2016-07-26 02:02:13

Weiterlesen

SSL (Secure Sockets Layer) ist ein Protokoll, mit dem eine verschlüsselte Übermittlung(Transportverschlüsselung) von Daten, z.B. vom Browser zum Webserver, erfolgt. Ein digitales Zertifikat ist ein digitaler Datensatz, der bestimmte Eigenschaften von Personen oder Objekten bestätigt und dessen Authentizität und Integrität durch kryptografische Verfahren geprüft werden kann. Transport Layer Security (TLS, deutsch Transportschichtsicherheit), weitläufiger bekannt unter der Vorgängerbezeichnung Secure Sockets Layer (SSL), ist ein hybrides Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet. Seit Version 3.0 wird das SSL-Protokoll unter dem neuen Namen TLS weiterentwickelt und standardisiert, wobei Version 1.0 von TLS der Version 3.1 von SSL entspricht. TLS-Verschlüsselung wird heute vor allem mit HTTPS eingesetzt. Die meisten Webserver unterstützen TLS 1.0, viele auch SSLv2 und SSLv3 mit einer Vielzahl von Verschlüsselungsmethoden, fast alle Browser und Server setzen jedoch bevorzugt TLS mit RSA- und AES- oder Camellia-Verschlüsselung ein. In aktuellen Browsern ist SSLv2 deaktiviert oder führt zu einer Sicherheitswarnung,[1] da diese Protokollversion eine Reihe von Sicherheitslücken[2][3] aufweist. Seit dem Bekanntwerden des Poodle-Angriffs auf die Verschlüsselung mit SSL gilt dies bei vielen Servern und Browsern auch für SSLv3. Die Weiterentwicklung TLS 1.1 wird von Google Chrome unterstützt, TLS 1.2 wird in der Standardkonfiguration von Internet Explorer, Firefox, Google Chrome, Opera und Apple iOS Safari verwendet (Stand 02/2014).[4] In Verbindung mit einem virtuellen Server, zum Beispiel mit HTTP (etwa beim Apache HTTP Server über den VHost-Mechanismus), ist es grundsätzlich als Nachteil zu werten, dass pro Kombination aus IP-Adresse und Port nur ein Zertifikat verwendet werden kann, da die eigentlichen Nutzdaten des darüber liegenden Protokolls (und damit der Name des VHosts) zum Zeitpunkt des TLS-Handshakes noch nicht übertragen wurden. Dieses Problem wurde mit der TLS-Erweiterung Server Name Indication im Juni 2003 durch die RFC 3546 behoben. Dabei wird bereits beim Verbindungsaufbau der gewünschte Servername mitgesendet. Die ursprüngliche Erweiterung wurde für TLS 1.0 beschrieben, aufgrund der Kompatibilität der einzelnen TLS-Versionen zueinander wird SNI auch bei TLS 1.1 und TLS 1.2 entsprechend der Empfehlung umgesetzt.

1.1 Wie funktioniert SSL

  1. Der Client baut eine Verbindung zum Server auf.
  2. Der Server authentisiert sich gegenüber dem Client mit einem Zertifikat.
  3. Der Client überprüft hierbei die Vertrauenswürdigkeit des X.509-Zertifikats und ob der Servername mit dem Zertifikat übereinstimmt. Optional kann sich der Client mit einem eigenen Zertifikat auch gegenüber dem Server authentisieren.
  4. Dann schickt entweder der Client dem Server eine mit dem öffentlichen Schlüssel des Servers verschlüsselte geheime Zufallszahl, oder die beiden Parteien berechnen mit dem Diffie-Hellman-Schlüsselaustausch ein gemeinsames Geheimnis.
  5. Aus dem Geheimnis wird dann ein kryptographischer Schlüssel abgeleitet. Dieser Schlüssel wird in der Folge benutzt, um alle Nachrichten der Verbindung mit einem symmetrischen Verschlüsselungsverfahren zu verschlüsseln und zum Schutz von Nachrichten-Integrität und Authentizität durch einen Message Authentication Code abzusichern.

1.2 Vorteile von SSL verschlüsselten Verbindungen

  • Schutz gegen Manipulation und unberechtigten Zugriff während der Übertragung.
  • Digitales Anhängen eines kryptografischen Schlüssels an Unternehmensdaten.
  • Sicherheit bei Kreditkartentransaktionen, Datenübertragung, Logins, u.v.m.
  • Validierung des Unternehmens, der Datei/Dokument und der Domain/Server.
  • u.v.m...

1.3 Validierungstypen

SSL-Zertifikate geben den an der Kommunikation beteiligten Parteien die Gewissheit, dass sie auf eine authentische Website zugreifen. Ein SSL-Zertifikat bestätigt die Identität einer Partei anhand eines spezifischen Validierungsprozesses vor der Austellungs des Zertifikates. Dieser Validierungsprozess ist abhängig von der Art und Weise, wie die Itentität eines Antragstellers durch die CA (Certificate Authority - Zertifizierungsstelle) durchgeführt wird. Anerkannte SSL-Validierungskategorien sind: Extended Validation (EV), Organization Validation (OV) und Domain Validation (DV).
1.3.1 Domain Validation (DV)
Domain Validation ist die einfachste Art der SSL-Zertifizierung. Domain Validation bestätigt, dass die Domain registriert ist und eine Person mit administrativen Vollmachten die Zertifizierungsanfrage genehmigt hat.
  • Validiert die Kontrolle über die Domain.
  • Zeigt im Browser ein Vorhängeschloss an.
  • Zeigt den Namen der Zertifizierungsstelle im Browser an.
1.3.2 Organization Validation (OV)
Organization Validation (OV) war bis vor einigen Jahren die höchste Stufe der Validierungen. OV validiert sowohl den Inhaber der Domain bzw. die Nutzungsberechtigung sowie die im Zertifikat enthaltenen Unternehmensinformationen (wie z.B. Unternehmensbezeichnung, Stadt und Land). Im Gegensatz zu SSL-Zertifikaten mit Extended Validation bietet Organization Validation keine grüne Adressleiste und der Name des Unternehmens wird nicht in der Adressleiste dargestellt. Organization Validation (OV) ist eine weniger starke und ausführliche Validierungsmethode stellt die einfache Unternehmensvalidierung dar.
  • Validiert Domain-Inhaberschaft.
  • Authentifiziert das jeweilige Unternehmen.
  • Erhält Nachweis über die Rechtmäßigkeit des Antrags.
  • Zeigt die Unternehmensinformationen im Zertifikat an.
1.3.3 Extended Validation (EV)
Extended Validation (EV) stellt den größten Aufwand bei der Validierung eines Antragstellers bzw. dessen Unternehmen dar. Die Validierungskriterien werden vom CA/Browser-Forum festgelegt. SSL-Zertifikate mit Extended Validation (EV) aktivieren im Browser die grüne Adressleiste und zeigen darin den Namen des Unternehmens und der Zertifizierungsstelle. Bei SSL-Zertifikaten mit Extended Validation überprüft die Zertifizierungsstelle zusätzlich die Domain-Inhaberschaft bzw. die Nutzungsrechte für die Domain sowie weitere Angaben des Unternehmens einschließlich der Rechtsform und die Berechtigung des Antragstellers, das Zertifikat im Namen des Unternehmens zu beantragen. Der Vorteil der Extended Validation (EV) liegt in einer höheren Vertrauenswürdigkeit.
  • Validiert Domain-Inhaberschaft.
  • Zeigt die grüne Adressleiste im Browser an.
  • Authentifiziert das jeweilige Unternehmen.
  • Erhält Nachweis über die Rechtmäßigkeit des Antrags.
  • Zeigt die Unternehmensinformationen im Zertifikat an.
  • Zeigt den Namen des Unternehmens und der Zertifizierungsstelle im Browser an.

1.4 Subject Alternative Names (SAN)

Bei SSL-Zertifikaten, welche die sog. Subject Alternative Names (SAN) unterstützen, handelt es sich um Zertifikatstypen, die mehrere Domainnamen in ein Zertifikat integrieren können. Diese Zertifikate werden auch Multi-Domain-Zertifikate genannt. SAN-fähige SSL-Zertifikate werden auch als Unified Communications-Zertifikate (UC) bezeichnet. SAN bietet ein Subject-Alternative-Name-Feld, in dem zusätzliche Domainnamen in nur einem Zeritifkat angegeben und geschützt werden können. Die Zertifikats-Kosten werden dadurch verringert, die Verwaltung des Zertifikats vereinfacht. Zuletzt geändert: 2016-01-12 16:42:11

Weiterlesen

In einem anderen Beitrag habe ich gezeigt, wie Sie Win32 OpenSSL installieren und einrichten. Hier erkläre ich den praktischen Einsatz von Win32 OpenSSL anhand eines Beispiels.

Praktischer Einsatz

Starten Sie Win32 OpenSSL von der Kommandozeile (cmd.exe). Dazu wechseln Sie in das Installationsverzeichnis c:\OpenSSL (lt. Anleitung oben). Sollten Sie einen anderen Installationsort verwendet haben, ist die Eingabe entsprechend anzupassen:
c:\OpenSSL\bin\openssl.exe

1. Private Key erstellen

Zuerst erstellen wir einen privaten Schlüssel mit einer Länge von 4096 Bit. Damit sich der Schlüssel bzw. die in Folge erstellten Dateien eindeutig zuordnen lassen, füge ich den Domain-/Hostname an den Namen der erstellten Dateien an. In diesem Beispiel erstelle ich Key und CSR für die Domain example.com. Ebenfalls hat sich die Angabe des Datums der Erstellungan den Dateinamen bewährt. Gespeichert werden die Dateien in dem zuvor erstellten Ordner c:\OpenSSL-Data. Daraus ergibt sich folgender Befehl:
genrsa -out c:\OpenSSL-Data\example.com-2016-04.key 4096
openssl-win32-12

2. Submit Certificate Request (CSR) erstellen

Das CSR enthält alle relevanten Angaben zum Zertifikatsinhaber und zum Domain-/Hostnamen, für den das Zertifikat gültig sein soll. Wichtig dabei ist die Angabe Common Name: Soll das Zertifikat zur Verbindungsverschlüsselung (SSL, TLS, STARTTLS, HTTPS) eingesetzt werden (Web-/FTP-/Mailserver), ist hier der Domain-/Hostname anzugeben. Bezugnehmend zu den Pfadangaben oben, setzt sich der dafür notwendige Befehl folgend zusammen:
req -new -key c:\OpenSSL-Data\example.com-2016-04.key -out c:\OpenSSL-Data\example.com-2016-04.csr
openssl-win32-13

3. Selbstsigniertes Zertifikat erstellen

Mit dem erstellten Private Key und dem CSR können wir ein selbstsigniertes Zertifikat mit einer Gültigkeit von einem Jahr (oder länger) erstellen:
req -new -x509 -key c:\OpenSSL-Data\example.com-2016-04.key -out c:\OpenSSL-Data\example.com-2016-04.crt -days 365
openssl-win32-16  

4. Root CA Certificate

Da wir in diesem Beispiel als eigene CA fungieren, wird ein sog. Root CA Certificate benötigt. Zu den obligatorischen Angaben muss zusätzlich eine Gültigkeitsdauer (in Tagen) angegeben werden. Ich bezeichne das Root Certificate mit ca.crt. Zuerst wird ein eigener Key erstellt, danach das Cert:
genrsa -out c:\OpenSSL-Data\ca.key 4096
req -new -x509 -days 3650 -key c:\OpenSSL-Data\ca.key -out c:\OpenSSL-Data\ca.crt
Durch diese Angaben wird ein Root CA Certificate mit einer Gültigkeit von 10 Jahren erstellt. openssl-win32-15      Zuletzt geändert: 2016-07-26 02:06:27

Weiterlesen

Services & Support

Self Service Portal: itsm.wdns.at
Uptime Monitoring: uptime.wdns.at

SLA Vertragskunden

Hotline: +43 664 732 84000
E-Mail: service@wdns.at
RSS-Assistant (Windows x86, x64): RSS-Assistant

Unsere Servicehotline ist von 00:00-24:00 Uhr für unsere Kunden erreichbar. Telefonische Dienstleistungen außerhalb unserer regulären AZ werden mit € 27.50 exkl. MWSt. je angebrochener Zeiteinheit verrechnet. ( 1 ZE entspricht 15 Minuten)