Trusted Certificate Service (TCS)

Als Teilnehmer von ACOnet haben wir die Möglichkeit Zertifikate (Server, Code-Signing und E-Mail) gratis zu beziehen.
Grundsätzlich basiert das Service auf einem Vertrag zwischen [ab April 2020] Sectigo Ltd. (Roseland, NJ, USA) und GÉANT (früher TERENA), dem Verband europäischer Wissenschaftsnetze (den sog. NRENs), den auch ACOnet (der Betreiber des österreichischen Wissenschaftsnetzes und somit Provider der TU Graz) unterzeichnet hat.
Bestehende Zertifikate von DigiCert bleiben weiter gültig, wenn Sie aber neue Zertifikate einspielen, müssen Sie auch das entsprechende Zertifikat von Sectigo und das dazugehörende Intermediate-Zertifikat von GÉANT einspielen!

Dabei gilt:

  • Für Zertifikate, die auf diesem Weg ausgestellt werden, fallen für den Endbenutzer keine Kosten an.
    Für die TU Graz, als ACOnet-Teilnehmer, gilt dies für alle Server in der Domain tugraz.at; weiters verwalten wir Zertifikate für Server im VCG.
  • Weitere Domains wären prinzipiell möglich, aber nur, wenn wir die Domain auch verwalten (was wir i. Allg. aber nicht machen).
  • Die Zertifikate dürfen nicht für kommerzielle Zwecke genutzt werden (z. B. für ein Webshop o. ä.)
  • Die Zertifikate dürfen zwar für Finanztransaktionen (z. B. Übermittlung von Kreditkartendaten bei Tagungsanmeldungen) verwendet werden - beachten Sie aber, daß diese Daten danach auch sicher verarbeitet und verschlüsselt gespeichert werden müssen, Sie haften sonst im Falle eines Datenlecks eventuell für Schäden!
    Wir raten daher dringend davon ab ohne professionelle Verarbeitungssoftware Kreditkartendaten abzufragen und zu verarbeiten!
  • Vertragspartner ist immer die TU Graz, Institute müssen die ACOnet-Zusatzvereinbarung also nicht unterzeichnen!

Bis auf E-Mail-Zertifikate werden alle Zertifikate nur auf Antrag von EDV-Beauftragten ausgestellt, für OV-Multidomain-SSL-Zertifikate für Institute steht dafür ein Webinterface zur Verfügung.

Anmerkung

Die Verschlüsselung (z. B. HTTPS) sagt nichts über die Sicherheit der Daten an sich aus und auch nichts darüber, was z. B. der Empfänger mit den Daten tun wird (unverschlüsselt speichern, veröffentlichen, verkaufen, …), sondern nur etwas darüber, wie die Daten vom Client (z. B. Ihrem Browser) zum Server (z. B. einer Bank-Webseite) übertragen werden.

Und auch bei HTTPS gibt es unterschiedliche Sicherheitsniveaus, die Sie sich anschauen sollten.

Das bedeutet aber, daß es eine ganze Reihe von Angriffspunkten gibt:

  • Das Schloßsymbol sagt nichts aus - das Zertifikat kann wirklich gültig sein - überprüfen Sie die Domain (z. B. tugraz.al statt tugraz.at oder tugrɑz.at statt tugraz.at) und auf wen das Zertifikat ausgestellt ist!
  • Die Daten können auf Ihrem Rechner (z. B. im Browser oder im Betriebssystem) schon vor der Übertragung manipuliert werden, wenn Sie sich Malware eingefangen haben:
    Wenn Ihr Browser oder Ihre Grafikkarte Ihnen ein anderes Konto anzeigt, als dann tatsächlich übermittelt wird, können Sie das kaum überprüfen.
  • Die Übertragung findet vielleicht gar nicht zum richtigen Server statt:
    Der Nameserver, den Sie verwenden, wurde manipuliert und Sie verbinden sich daher gar nicht zum richtigen Server mybank.at, dieser Server hat aber selbst auch ein (scheinbar) gültiges Zertifikat (weil z. B. die CA kompromittiert wurde).
  • Die eingesetzte Verschlüsselung könnte bereits geknackt sein: Überprüfen Sie, ob Ihr Programm nur sichere oder auch unsichere Methoden unterstützt.
  • Die Daten können nach der Übertragung manipuliert werden:
    Der Server der Bank wurde „gehackt“ und Ihre Daten werden manipuliert oder …

SSL- bzw. TLS-Server-Zertifikate

SSL- bzw. TLS-Server-Zertifikate werden u. a. zur Verschlüsselung der Kommunikation mit Webservern (https statt http) benötigt.
Neben einfachen Zertifikaten für einzelne Server gibt es auch Multi-Domain-Zertifikate (ein Zertifikat für mehrere virtuelle Server auf einer gemeinsamen Hardware), aber auch Wildcard-Zertifikte (in der Art *.institut.tugraz.at).

Wie Sie einen CSR erstellen (den Sie zur Beantragung eines Zertifikates benötigen) und das Zertifikat dann installieren, ist z. B. bei DigiCert beschrieben.

Neue Vorgaben

Apple wird ab September 2020 nur mehr Zertifikate unterstützen, die maximal 13 Monate gültig sind!

Aufgrund von Vorgaben durch das CA/B-Forum (ein Verband von Browser-Herstellern) gibt es 3 Arten von Server-Zertifikaten:

  1. DV-Zertifikate
  2. OV-Zertifikate
  3. EV-Zertifikate

Da EV-Zertifikate in der Browserdarstellung keinen Vorteil mehr gegenüber OV-Zertifikaten bieten, werden von uns nur mehr OV-Zertifikate unterstützt.

Bestellung

Die Bestellung der Zertifikaten führen EDV-Beauftragte über https://ssl.tugraz.at/ durch, der dort angegebene Link darf nicht weiter gegeben werden, da die Anträge automatisch validiert werden.

Unser neuer Anbieter unterstützt auch das (von Let's Encrypt bekannte) ACME-Protokoll, wenn Sie das mit Certbot nutzen möchten, wenden Sie sich bitte an die TCS-Administratoren.

Installation

Am Beispiel Apache:

  1. Generieren Sie sich einen privaten Schlüssel und einen CSR z. B. mit OpenSSL.
  2. Den privaten Schlüssel speichern Sie am Server z. B. unter /etc/ssl/certs/myserver.key ab.
    Sollten Sie ein anderes Tool zur Erstellung des CSR verwenden, dann muß es in diesem Tool auch eine Möglichkeit geben, den privaten Schlüssel (private key) zu exportieren!
  3. Mit dem CSR bestellen Sie sich nun ein Serverzertifikat, die CSR-Datei brauchen Sie dann nicht mehr.
  4. Entweder speichern Sie dann das Serverzertifikat und die zugehörige Zertifikatskette z. B. unter /etc/ssl/certs/myserver.crt bzw. /etc/ssl/certs/chain.pem (alte Version) ab oder sie verwenden die komplette Zertifikatskette inkl. Serverzertifikat (neue Version) und speichern das unter /etc/ssl/certs/wholechain.pem ab.
  5. Tragen Sie nun die Zertifikatsdateien in die Konfig-Datei des Apache ein, z. B. (alte Version):
    SSLCACertificateFile /etc/ssl/certs/chain.pem
    SSLCertificateFile /etc/ssl/certs/myserver.crt
    SSLCertificateKeyFile /etc/ssl/certs/myserver.key
    oder (neue Version):
    SSLCertificateFile /etc/ssl/certs/wholechain.pem
    SSLCertificateKeyFile /etc/ssl/certs/myserver.key
    In der Datei mit der kompletten Chain (neue Version) ist es wichtig, dass das Serverzertifikat in der Datei wholechain.pem vor den anderen Zertifikaten steht, aktuell liefert Sectigo das nicht in dieser Reihenfolge aus!

    Sie können das z. B. mit openssl folgendermaßen überprüfen:
    openssl crl2pkcs7 -nocrl -certfile Ihre_Datei | openssl pkcs7 -print_certs -text -noout | grep 'Subject:'
    Wenn Ihr Server nicht an erster Stelle erscheint, dann müssen Sie die Reihenfolge ändern.

  6. Starten Sie den Apache neu.

Das zugehörige Root-Zertifikat sollte der Browser dann schon kennen.

Bei Problemen

Falls Browser das Root-Zertifikat nicht kennen, kann man es von der GÉANT-Homepage heruntergeladen und im Client installieren - wenn am Server die „Certificate-Chain“ (Server- und Intermediate- bzw. Root-Zertifikat) stimmt, dann sollte das Server-Zertifikat dann vom Client (dem Browser bzw. dem E-Mail-Programm etc.) akzeptiert werden.

Smartphones

Falls Ihr Smartphone dem Root-Zertifikat nicht vertraut, können Sie dieses Zertifikat installieren, indem Sie von Ihrem Mobiltelefon aus ebenfalls die GÉANT-Seite mit den Root-Zertifikaten öffnen und von dort das Root-Zertifikat herunter laden. Je nach Betriebssystem des Mobiltelefons müssen Sie dann das Zertifikat noch von der SD-Karte installieren (und z. B. einem WLAN-Profil zuweisen).

Server

Auf der DigiCert-Homepage gibt es Tools zum Testen der Installation.

top

Code Signing-Zertifikate

Code Signing-Zertifikate müssen Sie über die TCS-Admins bestellen, indem Sie einen CSR an die TCS-Admins übermitteln.

top

E-Mail-Zertifikate

Man kann als Angehöriger der TU Graz (Personen mit Dienst-/Rechtsverhältnis bzw. Studierende) gratis persönliche E-Mail-Zertifikate über das TCS beantragen, um E-Mails per S/MIME signieren oder auch verschlüsseln zu können. Verfügbar sind diese Zertifikate allerdings nur für ausgewiesene Personen der TU Graz, d. h. Personen, bei denen in TUGRAZonline hinterlegt ist, daß von der Personalabteilung oder dem Studienservice ein Ausweis kontrolliert wurde - dies trifft für alle Personen zu, die in ihrer TUGRAZonline-Visitenkarte den Punkt „E-Mail-Zertifikat“ finden. Weiters dürfen wir (durch den Vertrag geregelt) Zertifikate nur für E-Mail-Adressen ausgeben, für die wir zentral die Zuordnung E-Mail-Adresse ⇆ Person garantieren können, das trifft nur für Adressen auf den beiden zentralen E-Mail-Servern der TU Graz zu.
Falls sowohl eine Studierenden- als auch eine Bedienstetenadresse im System hinterlegt sind, dann kann (derzeit) nur für die Bedienstetenadresse ein Zertifikat beantragt werden.

Warum verwenden?

Eine normale Übertragung einer E-Mail läuft über viele Punkte, hier schematisch und vereinfacht dargestellt:

PC Switch Server Router Internet Router Server Switch Server Switch PC
Abs.   Switch   SMTP   Router   Internet   Router   MX   Switch   IMAP   Switch   Empf.

Ist die E-Mail weder verschlüsselt noch signiert, dann kann sie bei jedem der Zwischenpunkte gelesen und auch verändert werden. Ist sie wenigstens signiert, dann kann man nachweisen, ob die E-Mail wirklich vom Absender stammt und ob sie verändert wurde.
Wird beim Versenden verschlüsseltes SMTP und zum Abholen z. B. verschlüsseltes IMAP verwendet, dann ist die E-Mail vom Absender bis zum ersten Server (SMTP) und vom letzten Server (IMAP) bis zum Empfänger auch gegen das unautorisierte Lesen sicher, dazwischen aber angreifbar und auch am Server des Absenders (Gesendet-Ordner) und des Empfängers (Inbox) liegt die E-Mail im Klartext vor.
Verwendet der SMTP-Server des Absenders (wie an der TU Graz) ESMTP/TLS und unterstützt das auch der MX-Server des Empfängers (das können Sie als Absender aber nicht kontrollieren!) , dann ist die E-Mail auch am Weg vom SMTP-Server des Absenders bis zum MX-Server des Empfängers (also auch im Internet) sicher (als Empfänger können Sie das im Header einer E-Mail überprüfen: in den Received:-Zeilen steht dann etwas mit TLS - dies garantiert aber nicht, daß das bei der nächsten E-Mail auch so sein wird).
Unterstützt nun auch noch der IMAP-Server des Empfängers ESMTP/TLS, dann ist die E-Mail auf allen Teilstrecken zwischen den Servern (nicht aber auf den Servern SMTP, MX und IMAP selbst) sicher - diese an der TU bereits seit vielen Jahren eingesetzte Kombination von Standards wird seit 2013 in Deutschland von einigen Anbietern als „E-Mail made in Germany“ beworben:

  1. Sicher vom Absender bis zu seinem SMTP-Server (secure SMTP),
  2. sicher vom SMTP-Server bis zum MX-Server (ESMTP/TLS),
  3. sicher vom MX-Server zum IMAP-/Exchange-Server (ESMTP/TLS) und
  4. sicher vom IMAP-/Exchange-Server zum Empfänger (secure IMAP/EAS).

Beim Absender (Gesendet-Ordner) und beim Empfänger (Inbox) liegen die E-Mails aber noch immer am Server im Klartext vor und teilweise auch im Cache des verwendeten Clients und auch bei den anderen betroffenen Servern (SMTP, MX) könnten die E-Mails im Klartext gelesen und auch modifiziert werden.

Obwohl die TU Graz in ihrem Teilbereich überall Verschlüsselung unterstützt (bzw. auch verlangt), ist die E-Mail nur bei einer End-to-End-Verschlüsselung wirklich sicher - wie sicher hängt dann aber natürlich noch vom verwendeten Verfahren (S/MIME, PGP oder einem symmetrischen Verfahren) ab und wie man inzwischen weiß, haben Geheimdienste wie die NSA eventuell Zugriff auf die S/MIME-Zertifikate von kommerziellen Anbietern, insofern ist die derzeit sicherste asymmetrische Methode vermutlich die Open-Source-Variante von PGP (also GnuGP).

Als Absender haben Sie - wenn Sie keine End-to-End-Verschlüsselung verwenden - nur auf die erste Wegstrecke Einfluß, beim Rest sind Sie von den Einstellungen der Provider abhängig!

Zusammengefaßt

Vorteile:
  1. Signierung ermöglicht dem Empfänger zu überprüfen, ob die E-Mail tatsächlich vom vermeintlichen Sender kommt (Urheberschaft) und ob die E-Mail verändert wurde (Unversehrtheit).
  2. Verschlüsselung verhindert, daß Dritte unbefugten Zugriff auf den Inhalt bekommen (Vertraulichkeit).
Zum Signieren brauche ich selbst ein Zertifikat, zum Verschlüsseln brauche ich (bei asymmetrischer Verschlüsselung) das Zertifikat des Kommunikationspartners.

Nachteile:

  1. Wenn ich meinen privaten Key verliere (Rechnertausch etc.), dann kann ich (auch früher) verschlüsselt an mich geschickte E-Mails nicht mehr lesen!
  2. Verschlüsselte E-Mails können serverseitig weder auf Spam noch auf Malware untersucht werden!

Lesen Sie auch den c't-Artikel „Mail-Verschlüsselung auf dem Rechner und mobil“.

top