Skip to content

Neuerungen auf ITrig - HTTPS und Serendipity mit PHP7

HTTPS

Wie angekündigt ist ITrig nun auch via HTTPS erreichbar. Das Zertifikat stammt von Lets Encrypt und sollte somit von jedem Browser erkannt werden.
Diese Zertifikate sind momentan nur 90 Tage gültig und müssen danach erneuert werden.

lets-encrypt

Mit Hilfe eines Script lässt sich die Aktualisierung leicht automatisieren. Es gibt von offizieller Seite eine Hilfestellung für Nginx Server, siehe Nginx Blog.

#!/bin/sh

cd /opt/letsencrypt/
./letsencrypt-auto --config /etc/letsencrypt/configs/my-domain.conf certonly

if [ $? -ne 0 ]
 then
        ERRORLOG=`tail /var/log/letsencrypt/letsencrypt.log`
        echo -e "The Let's Encrypt cert has not been renewed! \n \n" \
                 $ERRORLOG
 else
        nginx -s reload

fi

exit 0

Weitere Varianten für Apache und Co sind bei letsencrypt im Forum zu finden (Link).

php


PHP 7 und Serendipity

Seit Ende letzten Jahres steht PHP7 zur Verfügung. Aus diesem Grund habe ich vor einigen Tagen testweise auf die neuen PHP Version umgestellt. Nach der Umstellung gab es Probleme mit dem Cache_Lite Plugin. Die letzte stabile Version (1.7.16) stammt aus dem Jahr 2014 und hat mit PHP7 so seine Probleme.

Durch das Anpassen der Datei lite.php zu finden unter "/serendpity/bundled-libs/" konnte ich die entstehenden Fehler mit der s9y JavaScript Library beheben.

Fehlermeldung s9y PHP7

<script>
if(typeof errorHandlerCreateDOM == "function") {
var fragment = window.top.errorHandlerCreateDOM("Error redirect: == SERENDIPITY ERROR == <p>Methods with the same name as their class will not be constructors in a future version of PHP; Cache_Lite has a deprecated constructor in /home/www/blog/bundled-libs/Cache/Lite.php on line 29</p>");
document.body.insertBefore(fragment, document.body.childNodes[0]);
}
</script>
<noscript> == SERENDIPITY ERROR == <p>Methods with the same name as their class will not be constructors in a future version of PHP; Cache_Lite has a deprecated constructor in /home/www/blog/bundled-libs/Cache/Lite.php on line 29</p></noscript>
/ Dynamically fetched templates/2k11/admin/serendipity_editor.js.tpl on , called from: include/plugin_api.inc.php:external_plugi
n /

Lösung

Anpassen der Funktion in der lite.php

function Cache_Lite($options = array(NULL))

zu

function __construct($options = array(NULL))

Danach konnte das s9y Backend mit PHP 7.0.3 ohne Probleme geladen werden. Details sind im s9y Forum zu finden.

Selbstsignierte Zertifikate mit Subject Alternative Names (SANs) für Apache, Nginx oder Tomcat erstellen

Um Zertifikate und deren Erstellung oder Einbindung gab es auf ITrig schon öfters Beiträge (siehe SHA-256Tomcat, 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.

SANs
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.

tomcat

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

Elastix - Neues Zertifikat erstellen und einbinden

Ein neues Zertifikat für eine Elastix Maschine ist hin und wieder fällig. Bekanntlich handelt es sich dabei um ein CentOS System mit Apache, welches somit recht einfach mit einem neuen Zertifikat versehen werden kann. Praktisch geht das sogar mit einem Oneliner.

openssl req -x509 -nodes -sha256 -days 1825 -newkey rsa:4096 -keyout /etc/pki/tls/private/localhost.key -out /etc/pki/tls/certs/localhost.crt
-subj "
/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/ CN=localhost.localdomain/emailAddress=root@localhost.localdomain"

Damit erzeugt ihr ein neues Zertifikat, welches auch gleich richtig eingebunden wird, aber Vorsicht, die vorhandenen Zertifikate werden mit diesem Befehl überschrieben.

Elastix

Solltet ihr andere Dateinamen verwenden, dann muss der Pfad in der Konfiguration zusätzlich angepasst werden

sudo nano /etc/httpd/conf.d/ssl.conf

 SSLCertificateFile /ich/bin/der/pfad/neues_cert.crt

sudo service httpd restart 

Linux Script - Selbstsigniertes SSL Zertifikat mit SHA256 erstellen und ausgeben

Anfang des Jahres hatte ich euch ein Skript bereitgestellt, welches selbst signierte Zertifikate generiert (siehe Artikel).

Nicht erst seit gestern ist es jedoch sinnvoll auf SHA2 umzustellen. Denn das alte SHA1 gilt seit einiger Zeit als unsicher. 

Übersicht SHA Funktionen

uebersicht_sha

Für euch heißt dies in Zukunft bei der Zertifikatsgenerierung auf SHA2 zu achten.

Selbstsigniertes SSL Zertifikat mit SHA256 erstellen

Im Prinzip muss der alte Befehl nur um einen weiteren Schlüssel "SHA256" oder "SHA512" ergänzt werden.

Unten seht ihr den Befehl, der eine privaten Serverschlüssel mit Zertifikatsanfrage erstellt und im gleichen Zug selbst signiert.

sudo openssl req -x509 -nodes -sha256 -days 1825 -newkey rsa:4096 -keyout server_256.key -out server_256.crt

Generating a 4096 bit RSA private key

...........................++

......................................................................++

writing new private key to 'server_256.key'

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:DE

State or Province Name (full name) [Some-State]:NRW

Locality Name (eg, city) []:ITrig

Organization Name (eg, company) [Internet Widgits Pty Ltd]:ITrig

Organizational Unit Name (eg, section) []:Itrig

Common Name (eg, YOUR name) []:itrig.de

Email Address []:

Zertifikat auf SHA2 überprüfen

Natürlich lassen sich vorhandene oder soeben erzeugte Schlüssel auch auf ihren Inhalt überprüfen. In diesem Fall interessiert uns der SHA Wert.

sudo openssl x509 -noout -text -in server_256.crt

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            fc:f8:7d:d9:cd:f7:e7:b5

        Signature Algorithm: sha256WithRSAEncryption

        Issuer: C=DE, ST=NRW, L=ITrig, O=ITrig, OU=Itrig, CN=itrig.de

        Validity

            Not Before: Dec 18 13:20:41 2014 GMT

border: none; padding: 0px;">

            Not After : Dec 17 13:20:41 2019 GMT

Damit ihr euch die Eingaben alle sparen könnt, hab ich das Script auf SHA256 angepasst, zusätzlich werden alle Daten am Ende zur Kontrolle ausgegeben.

SHA 256 Skript

9 praktische Keytool Befehle - Zertifikatsmanagement unter Java

Das leidige Thema Zertifikate hatte ich auf dem Blog nun schon öfters, vielleicht erinnert ihr euch ja noch an das selbstsignierte Tomcat Zertifikat.

Damals wurde anders als bei der klassischen Variante mit Apache/OpenSSL auf Keytool zurückgegriffen. Sozusagen das Pendant unter Java.

Heut möchte ich euch ein paar weitere praktische Befehle dazu zeigen. Zunächst muss das Keytool aber gefunden werden.

Unter Windows befindet es sich meist im Bin-Ordner der Java Installation, beispielsweise "C:\Program Files\Java\jre7\bin"

Unter Linux genügt ein einfaches "whereis keytool", um den gewünschten Pfad, beispielsweise "/usr/bin/keytool" zu finden.

9 praktische Keytool Befehle

Einen Keystore und ein Schlüsselpaar erzeugen

keytool -genkey -alias domain -keyalg RSA -keystore keystore -keysize 2048

Eine Zertifikatsanfrage erstellen

keytool -certreq -alias domain -keystore keystore -file anfrage.csr

Ein signiertes Zertifikat in den Keystore importieren

keytool -import -trustcacerts -alias domain -file domain.crt -keystore keystore

Ein vorhandenes Zertifikat exportieren

keytool -export -alias meincert -file meinexportiertescert.crt -keystore keystore

Ein selbstsigniertes Zertifikat erstellen

keytool -genkey -keyalg RSA -alias selfsigned -validity 3600 -keysize 2048

Ein Vorhandenes Zertifikat auslesen 

keytool -printcert -v -file meincert.crt

Welche Zertifikate befinden sich im Keystore?

keytool -list -v -keystore keystore

Liste die vertraulichen CAs auf

keytool -list -keystore "C:\Program Files\...\...\lib\security\cacerts"

Lösche ein Zertifikat aus dem Keystore

keytool -delete -alias domain -keystore keystore