wiki:Server/SSL

SSL-Zertifikate bei PhysikOnline

Diese Wiki-Seite soll SSL-Zertifikate, wie sie für HTTPS, also das verschlüsselte Surfen, benutzt werden, erklären. Dabei soll eine Übersicht gegeben werden, wie Zertifikate bei PhysikOnline eingesetzt werden.

Grundsätzlich ist zu sagen, dass bei PhysikOnline seit "PO2", also dem Start von ILIAS auf der eigenen VM, ein großes Augenmerk auf Übertragungssicherheit gelegt wird. SSL-Verschlüsselung ist obligatorisch, sobald man Benutzer auffordert werden, ihre sensiblen (HRZ-)Benutzer- und Passwortdaten einzugeben.

Gemeinsames Zertifikat mit dem ITP

Seit PhysikOnline3 nutzt die Adresse https://elearning.physik.uni-frankfurt.de/ ein gemeinsames Multidomain-Zertifikat mit einigen anderen Domain-Namen, die ebenso vom zentralen ITP-Webserver bedient werden. Im übrigen kann das ITP aus technischen Gründen nicht auf den DFN-Zertifikatsdienst zugreifen #256. Dies liegt aber alles außerhalb unseres Wirkungsbereichs.

Bei dem Zertifikat, welches das ITP auf seinem zentralen Webserver benutzt, handelt es sich um eines von COMODO RSA Organization Validation Secure Server CA. Es hat in den subjectAltNames eine Liste von Addressen stehen. Mit Stand Januar 2016 sind das derzeit:

Nicht kritisch
DNS-Name: fias.uni-frankfurt.de
DNS-Name: astro.uni-frankfurt.de
DNS-Name: bccn2009.org
DNS-Name: compeng.uni-frankfurt.de
DNS-Name: compstar.uni-frankfurt.de
DNS-Name: csc.uni-frankfurt.de
DNS-Name: elearning.physik.uni-frankfurt.de
DNS-Name: fias-frankfurt.de
DNS-Name: figss.uni-frankfurt.de
DNS-Name: hgs-hire.de
DNS-Name: itp.uni-frankfurt.de
DNS-Name: th.physik.uni-frankfurt.de

Nur, wenn der ITP-Webserver unter einer exakt dieser Addressen aufgerufen wird, wird das Zertifikat von Browsern als gültig erklärt. Ansonsten gibt es eine Fehlermeldung! Ein Beispiel dafür ist https://www.elearning.physik.uni-frankfurt.de/.

Eigene Zertifikate

Wir besitzen einen Haufen eigener SSL-Zertifikate, die ich ab 2011 von der Certificate Authority des HRZ geholt habe. Kurz zum Hintergrund: Das Deutsche Forschungsnetz (DFN) hat ein Class 2-Rootzertifikat von der Deutschen Telekom. Diverse Universitäten in Deutschland vergeben darüber als dritte Instanz wiederum SSL-Zertifikate, sodass sich folgende Zertifikatskette bildet:

  • Deutsche Telekom Root CA 2
    • DFN Verein PCA Global
      • UNI-FFM CA
        • ILIAS-PhysikOnline-Zertifikat
        • POKAL-Zertifikat
        • Podcast-Wiki-Zertifikat

Der Service ist kostenlos (was wirklich hervorragend ist, weil man in der Regel für SSL-Zertifikate dreistellige Summen pro Jahr bezahlt), eigene Zertifikatanfragen können eingereicht werden und werden nach allen Regeln der Kunst beantwortet. Das bedarf der Benutzung kompliziert anmaßender OpenSSL-Befehle, allerdings gibt es unzählige Anleitungen im Netz und wenn man einmal Public-Key-Infrastrukturen verstanden hat, ist das System selbsterklärend.

Einzige Besonderheit bei der UNI-FFM CA: Sie unterschreiben keine Wildcard-Zertifikate. Alle Einträge im subjectAltName im CSR werden ignoriert, stattdessen übermittelt man dem CA-Zuständigen (damals Reinhard Meyer) eine Liste der gewünschten Domainnames im subjectAltName per Hand, er fügt sie dann dem Zertifikat hinzu.

Wichtig ist auch: Von der Uni gibt es Zertifikate nur für Domains die auf uni-frankfurt.de enden.

Momentane Zertifikate

Alle PhysikOnline-Zertifikate sind ausgestellt auf

Johann Wolfgang Goethe-Universitaet
Physik Online, ITP
Frankfurt am Main
Hessen
DE

Sie haben alle eine Gültigkeit von 5 Jahren, sind also alle ca. bis 2016/2017 gültig.

Folgende 2048bit-RSA-Serverzertifikate haben wir (mit subjectAltNames):

  1. CN=elearning.physik.uni-frankfurt.de - Kommt nicht mehr zum Einsatz
      DNS:elearning.physik.uni-frankfurt.de,
      DNS:elearning.th.physik.uni-frankfurt.de,
      DNS:www.elearning.physik.uni-frankfurt.de,
      DNS:dev.elearning.physik.uni-frankfurt.de,
      DNS:test.elearning.physik.uni-frankfurt.de
    
  1. CN=pokal.uni-frankfurt.de #41 #865
    pokal.uni-frankfurt.de
    www.pokal.uni-frankfurt.de
    test.pokal.uni-frankfurt.de
    test2.pokal.uni-frankfurt.de
    dev.pokal.uni-frankfurt.de
    cloud.pokal.uni-frankfurt.de
    cloud2.pokal.uni-frankfurt.de
    
  1. CN=podcast-wiki.physik.uni-frankfurt.de #228 - Kommt nicht zum Einsatz
      DNS:podcast-wiki.physik.uni-frankfurt.de
    
  1. CN=uniphi.uni-frankfurt.de #870 - Derzeit nicht im Einsatz (Juni 2014)
    uniphi.uni-frankfurt.de
    www.uniphi.uni-frankfurt.de
    test.uniphi.uni-frankfurt.de
    test2.uniphi.uni-frankfurt.de
    dev.uniphi.uni-frankfurt.de
    cdn.uniphi.uni-frankfurt.de
    cloud.uniphi.uni-frankfurt.de
    login.uniphi.uni-frankfurt.de
    
  1. CN=sagecell.uni-frankfurt.de (Mai 2015)
    sagecell.uni-frankfurt.de
    
  1. CN=cloud.physikonline.uni-frankfurt.de #1275 (Januar 2016)
    cloud.physikonline.uni-frankfurt.de
    www.cloud.physikonline.uni-frankfurt.de
    elearning-owncloud.th.physik.uni-frankfurt.de
    cloud.po.uni-frankfurt.de
    

Zertifikate erstellen

Das Erstellen von Zertifikaten machen wir immer mit dem Programm openssl auf der Linux-Kommandozeile. Die Wiki-Seite Intern/SSL-Zertifikate erzeugen hat eine ausführliche Anleitung parat. In 1:ticket:1275 ist der typischer Arbeitsablauf mit Domainregistrierung und Zertifikatregistrierung auch dargelegt.

Zertifikate für andere Anwendungen als Webseiten

SSL-Zertifikate werden noch für viel mehr als Transportverschlüsselung von Webseiten verwendet. Siehe https://pki.pca.dfn.de/uni-frankfurt-ca/pub/cacert/chain.txt für die Zertifikatschain der Uni-Frankfurt PKI/Deutsches Forschungsnetz/Telekom.

SSL-Zertifikate verwenden wir beispielsweise auch exzessiv für SSH (Secure Shell). Bei SSH handelt es sich aber nicht um eine X.509 Public-Key-Infrastruktur.

Prinzipiell könnte man SSL-Zertifikate auch für den passwortlosen Login auf Webseiten einsetzen, davon machen wir aber derzeit (Anfang 2016) überhaupt nicht Gebrauch bei PhysikOnline.

Auch zum verschlüsselten Übertragen von E-Mails (siehe Server/Mail) verwenden wir natürlich SSL. Für unsere eigenen Server kommen oben genannte Zertifikate zum Einsatz. Für ITP-E-Mail-Server natürlich die Zertifikate vom ITP (siehe zB. Allgemein/Mailidentity? für STARTSSL bzw. STARTTLS als Verweis auf SSL). Für externe E-Mail-Addresen klappt das oft nicht, etwa bei RiedbergTV, siehe 1:ticket:1244.

OpenVPN basiert ebenfalls auf SSL. Wir verwenden hier das VPN vom ITP/FIAS, siehe Intern/ITP-VPN für die Konfiguration.

SSL und Domains

Seit Januar 2016 gibt es mit https://letsencrypt.org/ die Möglichkeit, seriöse kostenlose SSL-Zertifikate zu bekommen. Bislang (Januar 2016) haben wir davon noch keinen Gebrauch gemacht. Wir finden die DFN-Zertifikate grundsätzlich seriöser. Sie gibt es aber ausschließlich auf Addressen, die auf uni-frankfurt.de enden, gemäß Auskunft im Juni 2014 von der HRZ-Abteilung:

/Server-/Maschinenzertifikate:/ Der CN eines Serverzertifikats muss immer den voll qualifizierten Hostnamen (FQDN), z.B. server1.uni-musterstadt.de enthalten. Die Second-Level-Domain (im Beispiel uni-musterstadt) muss offiziell bei einer Domain-Registratur (z.B. DENIC) registriert sein und der Einrichtung, die das Zertifikat beantragt, gehören.

Hier reicht es also nicht aus, das z.B. Sie als Mitarbeiter Inhaber der Domain sind, sondern das entsprechende Institut o.ä., oder die Domain über uns (HRZ Nameservice) registriert wird.

Zum Thema Domains siehe auch Server/Domain und insbesondere Server/Domain/Uni-Frankfurt.

Last modified 22 months ago Last modified on Feb 10, 2016 10:26:43 PM