ITrig

Um Zertifikate und deren Erstellung oder Einbindung gab es auf ITrig schon öfters Beiträge (siehe SHA-256, Tomcat, Nginx oder Apache). Heute soll es um die Einbindung von so genannten Alternativen Namen in das Zertifikat gehen.
Das heißt ein so erstelltes Zertifikat ist für mehr als eine Adresse, Subdomain oder IP gültig (Wildcard) gültig.

So eine Vorgehensweise bietet sich an, da mit einem Zertifikat mehrere Subdomainadressen erschlagen werden können.

Beispiel
Hauptdomain donald.entenhausen.stadt
Subdomain1 tick.entenhausen.stadt
Subdomain1 trick.entenhausen.stadt
Subdomain1 track.entenhausen.stadt

Gleiches lässt sich alternativ für IP Adressen eintragen

IP1 313.entenhausen.stadt

Alle oben erwähnten Einträge, egal ob IP oder DNS werden mit einem Zertifikat, welches auf  "donald.entenhausen.stadt" ausgestellt wurde, als gültig angesehen.

Folgende Einträge werden bei Subject Alternative Names unterstützt E-Mail, URI, DNS, RID, IP, dirName und otherName

Erstellung von SANs Einträgen in SSL Zertifikaten für Apache oder Nginx

Prinzipiell muss bei der Verwendung von OpenSSL und SANs eine Konfigurationsdatei angelegt oder die vorhandene angepasst werden.

Ist ersteres der Fall, muss diese beim Ausführen per Befehl mitgegeben werden.
Bei der zweiten Option, welche hier Verwendung findet, wird die OpenSSL Config Datei direkt bearbeitet. 

Hier sollte darauf geachtet werden, vorher eine Sicherung zu erstellen und die Änderungen nach dem Erstellen wieder in den Originalzustand zurückzuführen, da sie sonst bei Folgeaktionen weiterhin greifen.

Folgende Werte (fett markiert) müssen in einer Konfigurationsdatei oder direkt in der OpenSSL Config gesetzt werden.

cp /etc/ssl/openssl.cnf /home/user/openssl.cnf.orig

sudo nano /etc/ssl/openssl.cnf

# Festlegen der gewünschten Zusatzeintraege, egal ob IP, DNS oder Mail, die Eintraege muessen nummeriert werden
[ alternate_names ]
DNS.1        = tick.entenhausen.stadt
DNS.2        = trick.entenhausen.stadt
DNS.3        = track.entenhausen.stadt
IP1             = 313.313.313.313

# Damit bei der Zertifikats Anfrage ebenfalls Ruecksicht auf die neuen Werte genommen wird, muss unter [req] der Wert req_extensions = v3_req hinterlegt werden.

#Fuer ein selbstsigniertes Zertifikat ist das nicht noetig
[ req ]
default_bits            = 1024
default_keyfile         = privkey.pem
distinguished_name      = req_distinguished_name
attributes              = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
req_extensions = v3_req

# Im jeweiligen Bereich muss ein Verweis hinterlegt werden
[ v3_req ]
subjectAltName          = @alternate_names

# Im jeweiligen Bereich muss ein Verweis hinterlegt werden
[ v3_ca ]
subjectAltName      = @alternate_names

Als kurze Erinnerung hier noch einmal die Vorgehensweise, wie ein Schlüssel oder eine Anfrage erstellt werden.
Sollte die Konfiguration in eine Extra Datei geschrieben worden sein, darf die Angabe "-config /pfad/zur/config/sanconf.cnf" im Befehl nicht fehlen.
In unserem Beispiel werden die Werte direkt von der openssl.conf geladen.

Schlüssel erstellen

sudo openssl genrsa -out /etc/ssl/private/ssl.key.pem 4096

CSR erstellen

sudo openssl req -new -x509 -sha256 -key /etc/ssl/private/ssl.key.pem -out /etc/ssl/certs/ssl.cert.pem -days 3650  

Selbstsigniertes Zertifikat mit SAN Einträge erstellen

sudo openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:4096 -keyout /etc/ssl/private/ssl.key.pem -out /etc/ssl/certs/ssl.cert.pem

Bei dieser Art der Erstellung erhaltet ihr ein Abfrage für die Daten, es lassen sich aber auch alle Informationen direkt mit geben:

sudo openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:4096 -keyout /etc/ssl/private/ssl2.key.pem -out /etc/ssl/certs/ssl2.cert.pem -subj "/C=DE/ST=Unknown/L=Unknown/O=Unknown EG/OU=Unknown/CN=donald.entenhausen.stadt"

 

Zertifikat ausgeben und prüfen

Eine Überprüfung des Ergebnisses sollte nie fehlen.

openssl x509 -in /etc/ssl/certs/ssl.cert.pem -noout -text

                    ce:47:8e:f2:80:45:48:f0:9d:e2:34:a4:07:22:31:
                    34:48:59:47:20:2b:c2:58:5e:c8:6b:0c:c2:90:eb:
                    12:96:9e:da:4c:aa:63:a3:8c:9d:09:29:40:b9:20:
                    93:9c:8a:fc:9d:a5:c7:5e:43:7d:cd:69:6d:0c:56:
                    a5:da:99
                Exponent: 62237 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:tick.entenhausen.stadt, DNS:trick.entenhausen.stadt, DNS:track.entenhausen.stadt,IP Address:313.313.313.313
            X509v3 Subject Key Identifier:
                45:7E:30:3D:BC:62:AF:4C:20:6C:F1:48:C0:4C:DE:64:
            X509v3 Authority Key Identifier:
                keyid:45:7E:00:3D:BC:62:AF:4C:20:6C:F1:48:C0:4C:DE

Zertifikate umwandeln

Falls das PEM Format nicht beliebt, kann es jederzeit umgewandelt werden.

PEM zu DER umwandeln

openssl x509 -outform der -in ssl.cert.pem -out ssl.cert.der

PEM zu P7B umwandeln

openssl crl2pkcs7 -nocrl -certfile ssl.cert.cer -out ssl.cert.p7b

PEM zu PFX umwandeln

openssl pkcs12 -export -out ssl.cert.pfx -inkey pssl.key.pem -in ssl.cert.crt

---

Subject Alternative Names auf Tomcat Server erstellen und mit Keytool einbinden

Bei Tomcat Servern ist das Vorgehen leicht anders, da hier das Zertifikat in den Keystore geladen werden muss.

Am einfachsten kreiert sich ein selbsigniertes Zertifikat mit einem einzigen Befehl in dem die gewünschten SAN Einträge mitgegeben werden. Hier im Beispiel mit nur einem zusätzlichen DNS Eintrag und einer extra IP.

keytool -genkeypair -keystore keystoreName -validity 3650 -dname "CN=donald.entenhausen.stadt, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown"  -storepass xxxx -keyalg RSA -alias tomcat -ext SAN=dns:trick.entenhausen.stadt,ip:313.313.313.313

Zur Kontrolle können auch hier Zertifikate aus dem Keystore angezeigt werden.

keytool -list -v -keystore keystoreName

Vor einiger Zeit hatte ich gezeigt, wie es mit Jitsi Meet möglich ist einen eigenen WebRTC Server aufzusetzen. Die Kommunikation findet hier im Allgeminen über den Browser statt, dieser muss allerdings auch eine Unterstützung für Audio, Video, usw. mitbringen.

Ob der Browser der Wahl WebRTC voll unterstützt lässt sich auf test.webrtc.org prüfen.

Die Seite bietet zusätzlich die Möglichkeit einen Report zu erzeugen, welchen ihr euch auf die Platte laden könnt.

 

Die letzten Wochen ging es teilweise um die Analyse von SSL Verbindungen, heute soll es mal wieder um die dazugehörigen Einstellungen gehen.
Ich hatte in der Vergangenheit zwar schon Artikel zu SSL Einstellungen für Nginx, Apache oder Postfix geschrieben. Dennoch will ich mal auf den Mozilla SSL Konfigurations Generator hinweisen.
Das Webtool bietet zusammen mit dem ausführlichen Wiki Artikel über Server Side TLS Security  genau die richtige Kombination, um Webserver mit SSL zu konfigurieren.

SSL Einstellungen per Klick erzeugen

Der webbasierte Mozilla SSL Konfigurator unterstützt neben den am weitesten verbreiteten Servern Apache und Nginx auch HA Proxy. 
Ich persönlich vermisse eine Option für Postfix, da es sich dabei aber um keinen reinen Webserver handelt, ist das auch nachvollziehbar.

Das Tool stellt neben verschiedenen Server und SSL Varianten drei Auswahlmöglichkeiten in puncto Sicherheit zur Verfügung (modern, intermediate und old).
Praktischerweise wird bei jedem Modus auch die Unterstützung für Browser oder Systeme eingeblendet. So weiß jeder Anwender direkt, ob die enthaltenen CypherSuites für das eigene Projekt nützlich sind oder nicht.
Welche SSLCipherSuites genau in der jeweiligen Einstellung verwendet werden, lässt sich in dem oben erwähnten Mozilla Wiki Artikel nachlesen.

Leider müssen einzelne Server Versionen von Hand eingegeben werden, der Konfigurator erkennt diese aber ohne Probleme. 
Wie Stichproben gezeigt haben, nimmt das Tool OCSP Stapling automatisch aus der Config, wenn ein Wechsel von Apache 2.4 zu 2.2 erfolgt. (Diese Funktion wird erst seit 2.3 unterstützt).

Wie der Name des Tools vermuten lässt, wird nur eine Konfiguration generiert, diese muss in die geweilige ".conf" Datei auf einem Server kopiert werden.

Fazit

Nicht nur Administratoren finden mit dem Tool eine praktische Hilfe, wenn es um die Konfiguration von TLS auf einem Server geht. 
Auch der Heimanwender, kann sich mit Hilfe des dazugehörigen Wiki Artikel das nötige Wissen zu TLS/SSL aneignen und mit dem SSL Konfigurator schnell und einfach umsetzen. 

Vor ein paar Tagen hatte ich das Python Script SSLyze vorgestellt, mit welchem es möglich ist SSL Einstellungen von Servern zu testen. In eine leicht andere Richtung schlägt das Firefox Add-on Calomel SSL Validation.

Calomel SSL Validation - Die Sicherheitsampel für den Browser

Das Add-on überprüft die Sicherheit der SSL Verbindung zwischen Browser und Webseite. Je nach Sicherheitsstufe wird eine Ampel neben der Adressleiste grün, blau, gelb oder rot dargestellt. 

Dies hat den Vorteil, das der Anwender schnell erkennen kann, ob beispielsweise eine Verbindung zu einer Bankenwebseite mangelhafte Sicherheit stellt.

Als Beispiel eine nicht ganz so sichere Verbindung

Die Sicherheit erreicht laut Addon nur einen Anteil von 33%, was unter anderem auf ein nicht aktiviertes Perfect Forward Secrecy zurückzuführen ist. Diese Einstellung würde das nachträgliche Entschlüsseln verhindern, ist also durchaus relevant. Aber auch auf die verwendete TLS Version, die mit TLS 1.0 nicht die aktuellste, aber auch nicht zu den veralteten und sehr unsicheren wie SSL 2/3 zählt, wird bemängelt.

Ein großer Punkteabzug wir ebenfalls durch die Verwendung von RSA verbucht. Laut FAQ würde Calomel hier ECDHE, DHE oder ECDH besser passen, denn mit Diffie Hellmann und Eliptischen Kurven wäre Schnelligkeit und  PFS gewährleistet.

Als Gegenansicht nun ein positives Beispiel

Hier wird zwischen Server und Client eine sichere Verbindung mit ECDHE zum Schlüsselaustausch hergestellt, das aktivierte PFD sammelt zusätzlich Punkte, was zu einer grünen Ampel und 100% Sicherheit führt. 100% Sicherheit ist hier wohl etwas schlecht formuliert, maximal mögliche Sicherheit würde wohl besser passen.

Fazit

Das Tool informiert sehr gut über eine bestehende SSL Verbindung zu einem Server und stellt dank der Farbunterscheidung auch für Laien gut erkennbar die gegebene Sicherheit dar. Gleiches gilt für die Punktewertung, die auch ohne tiefere Kenntnis Aussagen zur Sicherheit darstellt.

Dennoch sollte bedacht werden, dass die Verbindung zwischen Server und Browser nicht wirklich etwas über die Sicherheit des Servers selbst aussagt, sondern nur über die Verbindung ansich.

Eine blaue Ampel heißt nicht, dass der Server selbst schlecht konfiguriert ist, es kann sich genauso um einen alten Server handeln, der neue Techniken noch nicht unterstützt und dennoch für seine Verhältnisse die maximale Sicherheitseinstellungen aufweist.

Als Ergänzung zu anderen Tools, welche SSL Verbindungen oder Einstellungen unter die Lupe nehmen, ist Calomel SSL Validation eine willkommene Erweiterung.

Heute wird ein kleiner Ausflug in die Datenbank Welt gemacht.
Grund dafür ist die neue Version der Open Source Datenbank PostgreSQL Version 9.4., welche Ende 2014 veröffentlicht wurde.
Neben zahlreichen Verbesserungen bietet diese mit "ALTER SYSTEM" die Möglichkeit die Systemkonfiguration direkt aus der SQL Konsole vorzunehmen.
Mit dieser Neuerung lassen sich alle Systemeinstellungen der postgresql.conf mit Hilfe einer postgresql.conf.auto überschreiben.
Die postgresql.auto.conf wird beim Start als letztes geladen und enthält die mit "ALTER SYSTEM" gesetzten Werte.

Zunächst ist aber etwas Vorarbeit notwendig.
Referenzsystem ist wie immer Ubuntu Server 14.04

Installieren des PostgreSQL Servers 9.4

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs`-pgdg main" >> /etc/apt/sources.list.d/pgdg.list'
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
sudo apt-get update
sudo apt-get install postgresql

Einloggen in die PostgreSQL Konsole

Zunächst sollte das Passwort geändert werden

sudo -u postgres psql postgres
postgres=#
             \password
                        Enter new password:
                        Enter it again:
            \q

Erfolgt ein Login nicht direkt auf dem Localhost, sind weitere Konfiguration notwendig

Die Konfiguration der Zugriffsrechte erfolgen unter "/etc/postgresql/9.4/main/pg_hba.conf"

Verbindungsinformationen anzeigen

postgres=# \conninfo
You are connected to database "postgres" as user "postgres" via socket in "/var/run/postgresql" at port "5432".

Anlegen eines neuen Benutzers mit Superuser Rechten

Dieser Schritt dient der Übersicht, für die Verwendung des SYSTEM ALTER Befehls kann auch der Standardbenutzer "postgres" verwendet werden.
Superuser Rechte sind aber zwingend notwendig.

sudo -u postgres createuser -s -D -P yolo

Erklärung der Befehle

• -D, --no-createdb         role cannot create databases (default)
• -P, --pwprompt            assign a password to new role
• -s, --superuser              role will be superuser

Alternativ kann ein Benutzer auch interaktiv angelegt werden

sudo -u postgres createuser --interactive yolo2

Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n

Datenbank in PostgreSQL anlegen

Auch dieser Schritt dient nur der Übersicht. Für die Systemkonfiguration muss dies vorgenommen werden.

sudo -u postgres createdb -O yolo datenbank

Erklärung des Befehls

• -O, --owner=OWNER            database user to own the new database

Eingerichtete Benutzer und Rechte anzeigen

postgres=# \du

List of roles
 Role name |                   Attributes                   | Member of
-----------+------------------------------------------------+-----------
 postgres  | Superuser, Create role, Create DB, Replication | {}
 yolo      | Superuser                                      | {}

   

---

PostgreSQL mit ALTER SYSTEM konfigurieren

Nach ein paar Grundlagen nun der Schritt zur Konfiuration via ALTER SYSTEM
Im Folgenden möchte ich ein paar Werte setzen, die bei einer Grundinstallation gerne anfallen.
Als Grundlage habe ich pgTune genommen (siehe Artikel)

Folgende Werte sollen mit SQL Kommandos angepasst werden

max_connections = 200
shared_buffers = 512MB
effective_cache_size = 1536MB
work_mem = 2621kB
maintenance_work_mem = 128MB
checkpoint_segments = 64
checkpoint_completion_target = 0.9
wal_buffers = 16MB

Zunächst muss ein Login erfolgen, danach können Befehle mit der Kombination ALTER SYSTEM SET abgesetzt werden.

sudo -u postgres psql postgres

postgres=# ALTER SYSTEM SET max_connections TO 200;
postgres=# ALTER SYSTEM SET shared_buffers TO 512;
postgres=# ALTER SYSTEM SET effective_cache_size = '1536MB';
postgres=# ALTER SYSTEM SET work_mem = '2621kB';
postgres=# ALTER SYSTEM SET checkpoint_segments TO 64;
postgres=# ALTER SYSTEM SET wal_buffers ='16MB';
postgres=# ALTER SYSTEM SET checkpoint_completion_target TO 0.9;
postgres=# ALTER SYSTEM SET wal_buffers = '16MB';

Neuladen der Konfiguration

Wichtig: Die Änderungen werden erst wirksam, sobald die Konfiguration neu eingelesen wurde.

Die Konfiguration lässt sich mit dem folgenden Kommando neu einlesen, ohne das ein Datenbankverbindung verloren geht.

postgres=# SELECT pg_reload_conf();

Hier ist zu bedenken das manche Einstellungen, wie z.B. "max_connections" einen richtigen Server Neustart benötigen, bevor sie greifen

sudo service postgres restart

Kontrolle der vorhanden Werte

Gesetzte Konfigurationen lassen sich ebenfalls schnell und einfach per SQL Kommando auslesen. Der Aufruf vor und nach einer Änderung bietet sich an.

postgres=# SHOW shared_buffers;
 shared_buffers
----------------
 400MB
(1 row)

Einzelne Systemwerte auf Standard zurücksetzen

postgres=# SHOW checkpoint_completion_target;
 checkpoint_completion_target
------------------------------
 0.9
(1 row)

postgres=# ALTER SYSTEM SET checkpoint_completion_target TO DEFAULT;
ALTER SYSTEM

postgres=# SELECT pg_reload_conf();
 pg_reload_conf
----------------
 t
(1 row)

postgres=# SHOW checkpoint_completion_target;
 checkpoint_completion_target
------------------------------
 0.5
(1 row)

Alle Werte der postgresql.auto.conf zurücksetzen

postgres=# ALTER SYSTEM RESET ALL;

Wie bereits oben erwähnt, werden die gesetzten Konfigurationen in eine postgresql.auto.conf geschrieben.
Diese befindet sich nicht im Verzeichnis der postgresql.conf sondern unter

nano /var/lib/postgresql/9.4/main/postgresql.auto.conf

    # Do not edit this file manually!
    # It will be overwritten by ALTER SYSTEM command.
    wal_level = 'hot_standby'
    shared_buffers = '512'
    max_connections = '200'
    effective_cache_size = '1536MB'
    work_mem = '2621kB'
    checkpoint_segments = '64'
    wal_buffers = '16MB'

Troubleshooting

Im Log taucht folgende Meldung auf:

LOG:  parameter "wal_buffers" cannot be changed without restarting the server
LOG:  configuration file "/var/lib/postgresql/9.4/main/postgresql.auto.conf" contains errors; unaffected changes were applied

Wie die Fehlermeldung selbst erklärt, ist ein Neustart des Servers mit "sudo service postgresql restart" notwendig.

Fazit

Die neue Möglichkeit in 9.4 ein System im laufenden Betrieb zu konfigurieren, ist wirklich praktisch, besonders für diejenigen die eine SQL Konsole ihre Heimat nennen. Dennoch ist Vorsicht geboten, denn auf den ersten Blick ist nicht ersichtlich, ob eine postgresql.auto.conf geladen wird und Konfigurationen in der postgresql.conf nicht beachtet werden.