Dies ist die archivierte Version des Blogs vom 05.01.2017. Aktuelle Beiträge findest du unter thomas-leister.de
 

In Zeiten der Vollüberwachung durch die NSA und andere Geheimdienste weltweit sind auch die bekannten Certificate Authorities (CA) wie z.B. Verisign nicht mehr wirklich vertrauenswürdig. Man kann davon ausgehen, dass die NSA auch Zugriff auf die Schlüssel dieser CAs hat, sodass sie gefälschte Zertifikate ausstellen kann. Diese können dann dazu dienen, Datenverkehr zu manipulieren und mitzuschneiden. So ist die Verschlüsselung natürlich nutzlos und private Daten gelangen in falsche Hände.

Wer sich unabhängig von den großen, offiziellen Certificate Authorities machen will, kann ganz einfach seine eigene eröffnen. Dazu braucht es nicht mehr als eine Ubuntu / Linux – Installation und das OpenSSL Paket, das alles mitbringt, was wir für das Erzeugen der Zertifizierungsstelle und das Signieren von Serverzertifikaten brauchen. Diese selbst erstellten Zertifizierungsstellen und die von ihnen signierten Zertifikate sind natürlich nicht von Browsern und Betriebssystemen anerkannt, sodass diese Warnmeldungen ausgeben. Das kann man aber verhindern, indem man auf diesen Computern das CA Root Zertifikat installiert.

Anmerkung zu diesem Beitrag:

Diese Anleitung ist bereits etwas älter. Ich habe eine einfachere, schnellere Möglichkeit gefunden, eine CA zu verwirklichen, mit der sich eigene Zertifikate ausstellen lassen. Bitte folgt diesem Link, um zu meiner aktualisierten Anleitung zu gelangen:

https://legacy.thomas-leister.de/eine-eigene-openssl-ca-erstellen-und-zertifikate-ausstellen/

 

Es folgt die veraltete Anleitung.

 

 

Stellt zuerst sicher, dass OpenSSL installiert ist:

sudo apt-get install openssl

Ihr solltet euch gerade im Homeverzeichnis befinden. Dort erstellen wir jetzt einen Ordner für unsere Zertifizierungsstelle, in dem sich später alle benötigten Dateien befinden werden.

mkdir ca
cd ca
mkdir certs newcerts private

In diesem CA Ordner werden außerdem drei weitere Ordner erstellt. „certs“ und „private“ enthalten später das Root-Zertifikat der Certificate Authority und „private“ die streng geheime private Schlüsseldatei. Diese wird besonders gut geschützt:

chmod 700 private

Damit das Script zur Generierung der Certificate Authority funktioniert, werden außerdem noch zwei Dateien benötigt, die so erzeugt werden:

echo '01' > serial
touch database.txt

Die Dateistruktur im Homeverzeichnis sollte jetzt so aussehen:

  • Home
    • ca
      • certs
      • newcerts
      • private
      • serial
      • database.txt

 

CA Konfiguration erstellen

Als nächstes muss die Konfigurationsdatei „caconfig.cnf“ erstellt werden, in die die Einstellungen für die Zertifizierungsstelle geschrieben werden:

nano caconfig.cnf

Inhalt der Datei:

[ ca ]
default_ca = CA_default

[ CA_default ]
dir = ./
certs = $dir/certs
crl_dir = $dir/crl
database = $dir/database.txt
new_certs_dir = $dir/newcerts
certificate = $dir/certs/cacert.pem
serial = $dir/serial
private_key = $dir/private/cakey.pem
x509_extensions = usr_cert
default_days = 3650
default_md = sha1
preserve = no
policy = policy_match

[ policy_match ]
countryName = match
stateOrProvinceName = match
localityName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

[ req ]
default_bits = 4096
default_keyfile = cakey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca
string_mask = utf8only
req_extensions = v3_req

[ req_attributes ]

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = DE
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Germany
localityName = Locality Name (city, district)
organizationName = Organization Name (company)
organizationalUnitName = Organizational Unit Name (department, division)
commonName = Common Name (hostname, FQDN, IP, or your name)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 40

[ usr_cert ]
basicConstraints= CA:FALSE
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
nsComment = ''OpenSSL Generated Certificate''
subjectAltName=email:copy
issuerAltName=issuer:copy

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:TRUE

Die Konfiguration könnt ihr so 1:1 übernehmen.

 

Certificate Authority generieren

… die Generierung der CA beginnt mit der Erzeugung eines Private Keys, der unter private/cakey.pem gespeichert wird.

openssl req -new -x509 -days 3650 -config caconfig.cnf -keyform PEM -keyout private/cakey.pem -outform PEM -out certs/cacert.pem

Dieser Befehl erzeugt Zertifikate mit einer Gültigkeitsdauer von 10 Jahren. Das sollte erst einmal reichen ;)
Ihr werdet nach verschiedenen Daten gefragt. Zuerst müsst ihr eine PEM Passphrase vergeben, mit der die Cert. Auth.  vor unbefugten Zugriffen geschützt wird. Dieses Passwort sollte möglichst lang und komplex sein.
Danach werdet ihr nach verschiedenen Attributen gefragt, die die CA haben soll.  Dazu gehören Länderkürzel, Land, Stadt, Firmen- oder Organisationsname, Name des Erstellers der Zertifizierungsstelle und E-Mail Adresse. Ihr könnt hier eintragen, was ihr wollt. Seid kreativ!

Das war’s auch schon. Die Certificate Authority ist jetzt erstellt und Root-Zertifikat und der dazugehörige Private Key liegen in den entsprechenden Ordnern, die wir vorher angelegt haben. Das öffentliche Root-Zertifikat liegt jetzt in „certs“ und der private Schlüssel in „private“. An dieser Stelle ist es sinnvoll, ein Backup von beiden Dateien zu machen. Gehen die Dateien verloren, kann man mit dieser CA keine Zertifikate mehr erstellen und muss eine neue CA aufbauen. Dabei müssen dann ggf. auch alle bisher ausgestellten Serverzertifikate erneuert werden. Also: Unbedingt den CA Ordner sichern!

Das öffentliche Zertifikat (certs/cacert.pem) muss später auf alle Rechner importiert werden, auf denen man später keine SSL Warnungen bekommen will. Wie zu Beginn schon erklärt, ist die selbst erstellte CA nämlich nicht von Betriebssystemen und Browsern anerkannt, sodass es zu Warnmeldungen kommt. Installiert man dagegen das Root-Zertifikat der CA, ist auch die selbst erstellte CA Browsern und Betriebssystem bekannt und wird akzeptiert.

Unser Root-Zertifikat liegt im .pem Format vor. Windows beispielsweise nimmt aber nur Zertifikate im DER Format an, sodass man das .pem Zertifikat konvertieren muss:

openssl x509 -in certs/cacert.pem -outform der -out certs/cacert.crt

Jetzt liegen Zertifikate beider Typen im Ordner „certs“ und können auf andere Computer übertragen werden, wo man sich dann importieren kann.
(CA Root Zertifikate können in Mozilla Firefox über „Einstellungen => Erweitert => Verschlüsselung => Zertifikate anzeigen => Zertifizierungsstellen => Importieren“ importiert werden.)

 

Serverzertifikate generieren

Die Zertifizierungsstelle ist jetzt fertig und einsatzbereit. Fehlen noch die Zertifikate, die dann von der Certificate Authority signiert werden können und schließlich zum Einsatz kommen. Mit diesen Zertifikaten kann dann beispielsweise ein Webserver abgesichert werden.

Für die Arbeit mit den Serverzertifikaten wird ein weiteres Verzeichnis „myssl“ neben dem „ca“ Verzeichnis erstellt:

mkdir myssl
cd myssl

Innerhalb dieses myssl Ordners gibt es zwei Unterordner „private“ und „public“. Wie die Namen schon vermuten lassen, enthält der „private“ Ordner den privaten, geheimen Schlüssel, der später zum öffentlichen Zertifikat passt, welches sich in „public“ befinden wird. Dieser private Schlüssel, von dem die Rede ist, ist übrigens ein ganz anderer, als der der Zertifizierungsstelle. CA und Serverzertifikate müssen streng getrennt betrachtet werden. Wir sind hier gerade mit den Serverzertifikaten beschäftigt.

Erstellen wir also die eben angesprochenen Unterordner:

mkdir private public

Wie bei der Generierung der CA muss auch hier ein zufälliger Private Key erzeugt werden:

openssl genrsa -out private/privkey.pem 4096

… der ebenfalls gut geschützt wird:

chmod -R 700 private/privkey.pem

Im nächsten Schritt wird eine Zertifikatsanfrage gestellt, welche dann von der CA verarbeitet werden wird:

openssl req -new -key private/privkey.pem -out cert-req.pem

Wieder werden einige Attribute zum Zertifikat abgefragt. Mit einem Unterschied: Das Feld „Common Name / FQDN“ muss den Domainnamen enthalten, für den das SSL Zertifikat gelten soll. Will ich also meine Domain meinedomain.tld absichern, muss das so eingegeben werden. Ohne Protokoll; einfach nur „meinedomain.tld“. Subdomains wie z.B. „rss.meinedomain.tld“ kann man mit einem Wildcard-Zertifikat absichern, das dann für alle Subdomains gilt (auch www.meinedomain.tld). Dazu schreibt man „*.meinedomain.tld“.

Schließlich erhält man die Zertifikatsanfrage „cert-req.pem“.

Um die Anfrage zu bearbeiten und das Zertifikat von der Certificate Authority signieren zu lassen, wechseln wir wieder in das CA Verzeichnis:

cd ../ca/

… und führen folgenden Befehl aus:

openssl x509 -days 3650 -CA certs/cacert.pem -CAkey private/cakey.pem -req -in ../myssl/cert-req.pem -outform PEM -out ../myssl/public/cert.pem -CAserial serial

Man wird nach der PEM Passphrase der Certificate Authority gefragt und muss den Vorgang zwei mal mit „y“ bestätigen. Damit wird das öffentliche Zertifikat für die angegebene Domain erzeugt und landet in myssl/public/cert.pem

Die Zertifikatsanfrage kann jetzt wieder gelöscht werden; sie wird nicht mehr benötigt:

cd ../myssl/
rm cert-req.pem

Nach jedem Unterzeichnungsvorgang kann dann das fertige, öffentliche Zertifikat (myssl/public/cert.pem) zusammen mit dem immer gleich bleibendem private Key (myssl/private/privkey.pem) exportiert werden und auf einem Webserver benutzt werden. Dazu auch: Webserver absichern mit SSL. (Artikel ab Aktivierung von mod_ssl) Danach kann man das öffentliche Zertifikat ebenfalls löschen.

rm public/cert.pem

Für alle weiteren Zertifikate, die erstellt werden sollen verfährt man genauso. Nur der Private Key muss nicht mehr erzeugt werden. Der Ablauf für jedes weitere Zertifikat ist also wie folgt:

  1. Zertifikatsanfrage stellen und Daten eingeben (Auf Domainnamen achten!)
  2. Zertifikatsanfrage von der Certificate Authority verarbeiten lassen
  3. cert.pem und eine Kopie von privkey.pem auf den Webserver kopieren, wo SSL genutzt werden soll
  4. Zertifikatsanfrage und öffentliches Zertifikat können wieder gelöscht werden.

Der Ordner für die Zertifizierungsstelle bleibt unverändert. Hier also bitte nichts löschen ;)

 


Post published on 6. August 2013 | Last updated on 1. September 2014
Tags:           

Diesen Blog unterstützen

Wenn Dir der Beitrag gefallen hat, freue ich mich über einen kleinen Obolus :-) Bitcoin QR Code

PayPal-Seite: https://www.paypal.me/ThomasLeister
Meine Bitcoin-Adresse: 15z8 QkNi dHsx q9WW d8nx W9XU hsdf Qe5B 4s

Siehe auch: Unterstützung

Informationen zum Autor

Thomas Leister

Geb. 1995, Kurzhaar-Metaller, Geek und Blogger. Nutzt seit Anfang 2013 ausschließlich Linux auf Desktop und Servern. Student der Automobilinformatik an der Hochschule für angewandte Wissenschaften in Landshut.

38 thoughts on “Eigene OpenSSL Certificate Authority (CA) erstellen und Zertifikate ausstellen

  • Hallo, das ist der Artikel, auf den ich gewartet habe….
    Leider bleibe ich an einer Stelle stecken: Zur Nutzung des gerade erstellten Zertifikats verweist Du auf den ‚Webserver absichern mit SSL‘ . Dort wird aber mit Dateien ‚xx.key‘ und ‚xx.crt‘ hantiert, wie sie beim SelfCert ohne CA entstehen.
    Was muss ich in der Konfiguration zu meinem Virtual Host eintragen, wenn ich die beiden .pem Dateien habe?

    Merci, Wolfgang

  • Hi,
    scheitere leider beim generieren der Certificate Authority, nachdem ich die pass phrase zwei mal eingegeben habe kommt der Fehler:

    unable to find 'distinguished_name' in config
    problems making Certificate Request
    140426476439232:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c:335:group=req name=distinguished_name

    Benutze Ubuntu 13.04 und bin als root angemeldet.

    Vielen dank schon mal!

  • Hi Thomas,

    genau was ich gesucht habe.
    Vielen Dank für Deinen Beitrag und Deine Mühen.

    Mein Server läuft jetzt mit eigenem Zertifikat. :-)

    Gruß
    Uwe

  • Mit den Rechten 600 für das private-Verzeichnis kommt es zu diesem Fehler:

    openssl req -new -x509 -days 3650 -config caconfig.cnf -keyform PEM -keyout private/cakey.pem -outform PEM -out certs/cacert.pem
    Generating a 4096 bit RSA private key
    …………………………………………………………………………………………………………………………………………………………………………………………………………………………………………..++
    ………………………….++
    writing new private key to ‚private/cakey.pem‘
    private/cakey.pem: Permission denied
    5141:error:0200100D:system library:fopen:Permission denied:bss_file.c:356:fopen(‚private/cakey.pem‘,’w‘)
    5141:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:358:

    Nach „chmod 700 private“ funktioniert es.

    Dafür reicht für die cakey.pem auch ein 400

  • Hi,

    der Befehl

    echo '01' > serial

    spuckt bei mir die folgende Meldung aus:

    -bash: serial: Keine Berechtigung

    Gibt es einen Tip für mich?

    LG Chris

  • Großartiges Tutorial. Thanks for sharing!! :)

  • Was noch fehlt ist die Erzeugung einer p12-Datei für den Import in den Windows Zertifikatsspeicher, etwa:

    openssl pkcs12 -export -in servercert.pem -inkey serverkey.pem -certfile cacert.pem -name „p12-cert“ -out cacert.p12

  • Und wie wird ein entsprechendes Zertifikat mit openssl chiper ecdhe-rsa-aes256-gcm-sha384 erzeugt?
    Ansonsten super Tutorial

  • Guter Beitrag,
    kleiner Hinweis noch bei der Rechtevergabe. Für das Verzeichnis „ca/private“ wird 600 gesetzt die darin enthaltene Datei übernimmt die Rechte aber nicht rekursiv bzw. vererbt. Besser nach Generierung der keys die „private“-Key Verzeichnisse mit

    chmod -R 600 private

    anpassen.

  • Hallo Thomas,

    schönes Tutorial, vielleicht noch ein kleiner Zusatz:
    Wer sicher gehen will, dass die Verbindung zwischen Client (Browser) und Webserver AES 256 Bit verschlüsselt ist, der muss zwei Zeilen in der Webserver config hinzufügen.
    Unter httpd.conf (bei Plesk Installationen und vhosts zusätzlich zur httpd.conf eine vhost_ssl.conf Datei erstellen, im Unix Format und ANSI Kodierung, da Plesk bei jeder Änderung eine neue xxxxx_http.conf erstellt).
    Wer noch SSLv3 Unterstützung verwenden möchte kann hinter SSLProtocol -ALL auch noch +SSLv3 setzen.

    SSLCipherSuite AES256-SHA
    SSLProtocol -ALL +TLSv1

    Natürlich noch ggf. die neue config aktivieren mit /usr/local/psa/admin/bin/httpdmng –reconfigure-all
    Anschließend Webserver neustarten.

  • Coole Anleitung.
    Bleibt für mich nur die Frage wie bitte dem Seitenbesucher auf Vertrauenswürdigem Weg das Root Zertifikat übergeben werden soll.
    Für den Gebrauch in den eigenen vier Wänden mag das ja funktionieren, aber sobaldman das auch für andere Seitenbesucher alsnur man selbst braucht fällt mir keine wirklich praktikable Möglichkeit ein zu gewährleisten, dass kein „man in the middle“ Angriff möglich ist.

  • Hallo Thomas,

    wenn ich richtig verstanden habe, müsste ich dann für den Server aus dem privkey.pem folgendes erstellen:

    openssl req -new -key privkey.pem -out server.csr
    openssl x509 -req -days 3650 -in server.csr -signkey privkey.pem -out server.crt

    oder erstelle ich es aus public/cert.pem?

    • Ok ich glaub, ich kapiere das jetzt

      In der anderen Einleitung heißen die Dateien:
      server.crt server.csr server.key
      Das entspricht den Namen in dieser Einleitung:
      server.crt = public/cert.pem
      server.key = private/privkey.pem

      Und die Datei server.csr muss durch den Befehl angelegt werden:

      openssl req -new -key private/privkey.pem -out server.csr

      Und das wars auch schon, oder?

      • Leider funktioniert das nicht.
        Mein Browser sagt: „Es kann keine sichere Verbindung zum Server hergestellt werden. Möglicherweise liegt ein Problem mit dem Server vor oder es ist ein Client-Authentifizierungszertifikat erforderlich, das Sie nicht haben.“
        Fehlercode: ERR_SSL_PROTOCOL_ERROR

        Ich habe den Schlüssel allerdings bei mir auf dem Mac erfolgreich importiert.

        Laut /var/log/apache2/error.log:
        [warn] RSA server certificate wildcard CommonName (CN) `*.blubladomain.de‘ does NOT match server name!?
        [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)

        Was ist falsch?

        • Der Apache Log sagt es eigentlich schon. ;) es wird ein Zertifikat genutzt, das für Subdomains von blubladomain.de gültig ist, aber nicht für andere Domains oder die blubladomain.de-Domain an sich. Bist du sicher, dass du eine Subdomain bzw www. vor blubladomain.de stehen hast, wenn du die Seite via Browser aufrufst?

          LG Thomas

          • Hi Thomas,
            ich habe zwei Subdomains (zwei Vhosts) angelegt. Daher habe ich ja Wildcard-Zertifikat für *.blubladomain.de erstellt, damit alle Subdomains über das gleiche Zertifikat verschlüsselt werden. Im Moment versuche ich die Verschlüsselung wenigstens für einen Vhost (seafile) zum Laufen zu bringen.
            Vielleicht sind meine Vhosts falsch angelegt. Ich blick langsam nicht mehr durch bei allen Einleitungen die ich so gelesen habe, wie vhosts richtig anzulegen sind.
            Hier meine Config. Hast Du evtl. einen Tipp woran es liegen könnte?

            ServerName seafile.blubladomain.de
            ServerAdmin webmaster@blubladomain.de
            DocumentRoot /var/www/web0/html/seafile/
            SuexecUserGroup web0 www-data

            SSLEngine on
            SSLCertificateKeyFile /pfad/mycert/privkey.pem
            SSLCertificateFile /pfad/mycert/cert.pem
            ServerSignature On

            SSLProtocol All -SSLv2 -SSLv3
            # SSLCompression off
            SSLHonorCipherOrder On
            SSLCipherSuite EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
            Header add Strict-Transport-Security „max-age=15768000“

            FCGIWrapper /var/www/web0/html/seafile/conf_seafile .php

            SetHandler fcgid-script

            Options +ExecCGI
            Order allow,deny
            allow from all

            ErrorLog /etc/apache2/seafile_log/error.log
            LogLevel warn
            CustomLog /etc/apache2/seafile_log/access.log combined

            Alias /media /var/www/web0/html/seafile/seafile-server-latest/seahub/media

            RewriteEngine On

            Require all granted

            #
            # seafile httpserver
            #
            ProxyPass /seafhttp http://127.0.0.1:8082
            ProxyPassReverse /seafhttp http://127.0.0.1:8082
            RewriteRule ^/seafhttp – [QSA,L]

            #
            # seahub
            #
            RewriteRule ^/(media.*)$ /$1 [QSA,L,PT]
            RewriteCond %{REQUEST_FILENAME} !-f
            RewriteRule ^(.*)$ /fcgi/seahub.fcgi$1 [QSA,L,E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

  • Super Anleitung. Kleine Ergänzung: für erhöhte Sicherheit sollte beim Signieren besser SHA256 statt SHA1 verwendet werden (Paramter -sha256).

  • Hi Thomas,

    auch meinerseits vielen Dank für dieses ausführliche Tutorial! Eine Frage noch: wofür ist der Ordner „newcerts“? Er wird in deinem Tut scheinbar nicht verwendet.

  • Auch von mir ein großes Danke für die guten Erklärungen.

    Aber auch ich habe noch ein kleines Problemchen: Zertifikate usw. alle nach Anleitung erstellt und das CA Zertifikat mit update-ca-certificates korrekt integriert. Allerdings schmeißt mein firefox noch die folgende Fehlermeldung bezüglich des Zertifikats:

    The certificate is not trusted because no issuer chain was provided. (Error code: sec_error_unknown_issuer)

    Was habe ich falsch gemacht oder vergessen?

    (arch linux, openssl 1.0.1.h, firefox 30.0)

  • die Zeile cd ../ca/ ist nicht korrekt: cd ../ wäre richtig

    lg Jürgen Bambusch

  • Die Zeile
    „openssl x509 -days 3650 -CA certs/cacert.pem -CAkey private/cakey.pem -req -in ../myssl/cert-req.pem -outform PEM -out ../myssl/public/cert.pem -CAserial serial“

    sollte richtig heißen

    „openssl x509 -days 3650 -CA certs/cacert.pem -CAkey private/cakey.pem -req -in ./myssl/cert-req.pem -outform PEM -out ./myssl/public/cert.pem -CAserial serial“

    — da sind ein paar Pkt zu viel :–) aber sonst eine sehr gute Anleitung

    LG J. Bambusch

  • die Zeile
    cd ../myssl sollte cd ./myssl sein

    LG J. Bambusch

  • in der Zeile sind auch punkte zu viele drin:

    openssl x509 -days 3650 -CA certs/cacert.pem -CAkey private/cakey.pem -req -in ../myssl/cert-req.pem -outform PEM -out ../myssl/public/cert.pem -CAserial serial

    LG J. Bambusch

  • Hallo,
    kann ich mit denen durch das Tutorial erstellten Zertifikaten alles absichern? bsp( iDrac, switches, firewall) und
    So wie ich das verstanden habe laufen die Zertifikate ja alle durch das selbe Verzeichnis das man mit einem Pw schützen kann. Ich möchte eine einheitliche Struktur/ein Verzeichnis, das ich dem Browser hinzufügen kann und somit alle internen Zertifikate akzeptiert werden. Ist diese Anleitung dafür die Richtige?

    Liebe grüße
    Johanna

  • Vielen Dank :)
    Das hilft mir sehr.

    Liebe Grüße
    Johanna

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.