Windows Zertifikat (PFX Format) in das PEM/CER/KEY Format (z.B. für Apache) konvertieren

Dies ist wieder mal so eine Notiz an mich selbst, damit ich nicht vergessen wie man PKCS#12-Dateien („.pfx“) in das Zertifikat (CER/PEM) und den private Key (KEY) zerlegt und konvertiert.

Apache braucht sowohl Privatekey als auch Zertifikat einzeln und beherrscht leider das PFX-Format nicht, das beides beinhaltet.

Daher muss diese Konvertierung sein.

openssl pkcs12 -in quelle.pfx -clcerts -nokeys -out ziel.cer
openssl pkcs12 -in quelle.pfx -nocerts -nodes  -out ziel.key
# rm -rf quelle.pfx

Das PEM „Format“ ist dasselbe wie ein CER (beides der private Key im DER-Format), wie man die Datei nennen möchte bleibt einem selbst überlassen.

Danach kann man die Schlüssel sofort in der Apache Site-Config verwenden:

<VirtualHost 192.168.0.1:443>
 ...
 SSLEngine on
 SSLCertificateFile /etc/apache2/ssl/ziel.cer
 SSLCertificateKeyFile /etc/apache2/ssl/ziel.key
 ...
</VirtualHost>

Postfix: ausgehende E-Mail via TLS pro Domain erzwingen

Problem

Es gibt eine (Management-)Richtlinie, die vorschreibt mit einem bestimmten Partner ausschliesslich über (TLS) verschlüsselte Verbindungen zu kommunizieren. Der ausgehende Mailserver ist ein Postfix (z.B. ein Smarthost). TLS mit den entsprechenden Zertifikaten ist hier schon korrekt eingerichtet. Es sollen nur sichere TLS-Verbindungen zu bestimmten Domain erzwungen werden.

Lösung

Standardmäßig verschlüsselt Postfix ausgehende E-Mails nicht. Sofern die Zertifikate richtig konfiguriert sind (Stichwort smtpd_tls_cert_file) lässt sich die ausgehende Verschlüsselung IMMER erzwingen:

Zum erzwingen von TLS In der Datei /etc/postfix/main.cf eintragen:

smtp_tls_security_level = encrypt

Viele Mail-Server akzeptieren aber auch heute noch keine TLS-Verbindungen. E-Mails an solche Mailserver werden daher nicht versendet. Als sinnvolle Alternativebietet sich daher an:

 smtp_tls_security_level = may

Bei dieser Einstellung wird die TLS-Verschlüsselung nur verwendet, wenn der Empfängerserver ebefalls TLS-Verbindungen akzeptiert. Verschlüsselt geht hier von iunverschlüsselt.

Nur für bestimmte Domains erzwingen

Es soll TLS für alle E-Mails erzwungen sein, die an *@denic.de gesendet werden. Der MX von denic.de zeigt auf mx1.denic.de und mx2.denic.de.

    • Mapping-Datei erstellen, z.B. „/etc/postfix/tls_policy“ mit diesem Inhalt:
      denic.de       encrypt
    • Mapping übernehmen
      [email protected]:/etc/postfix# postmap /etc/postfix/tls_policy
    • Tabelle in der main.cf in der TLS-Policy referenzieren
      # TLS erzwingen
      smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
    • Postfix reloaden
      [email protected]:/etc/postfix# /etc/init.d/postfix reload

Im Log lässt sich der Erfolg direkt danach prüfen, indem man nach dem Servernamen (oder der Adresse) und „STARTTLS“ grept:

postfix/smtp[61070]: > mx1.denic.de[2a02:568:102:211::1:1]:25: STARTTLS

Debian 9.0 Stretch feste IP-Adresse konfigurieren

Weil ich schon wieder einen Schritt vergessen hatte, hier die schnelle Checkliste um einem Debian eine fest IP-Adresse zu vergeben.

nano /etc/network/interfaces

Die Datei sollte (statisch) so aussehen:

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens192
# iface ens192 inet <- Das wäre DHCP
iface ens192 inet static
   address 192.168.0.44
   netmask 255.255.0.0
   gateway 192.168.1.50

Dann das Netzwerk neu starten, das Interface aktualisieren und die aktive Konfiguration anzeigen:

service networking restart
ifup ens192    <-- Name des Interfaces aus der interfaces, z.B. eth0
ip addr

Debian 9 (Stretch) Startzeit-Auswahl (Timeout) von Grub verändern

Problem

Ab und zu ist die Standardzeit der Grup-Menüauswahl beim starten von Debian nicht passend. Entweder die voreingestellten fünf Sekunden sind zu lang, oder deutlich zu kurz.

Lösung

  1. Als root die Datei /etc/default/grub bearbeiten
  2. Änderungen an eintrag „GRUB_TIMEOUT“ durchführen
  3. Mit update-grub die geänderte Konfigurationsdatei übernehmen

BIOS und EFI Version unter Windows anzeigen (ohne reboot)

Problem

Welche BIOS- oder EFI-Version hat der Server oder der PC oder der MAC?  Muss ich aktualisieren? Kann ich das nachschauen ohne gleich die ganze schöne Maschine zu rebooten und einen Monitor anzuschliessen und im richtigen Moment eine geheime magische Taste zu drücken?

Lösung

Kein Problem, mann auch unter Windows/Linux/MacOS die BIOS-Version anzeigen. Funktioniert praktisch überall, Ausnahmen bestätigen allerdings die Regel. Bleibt die Anzeige leer oder zeigt „????“ ist warscheinlich einfach nicht der richtige Chipsatz-Treiber geladen.

BIOS-Version unter Windows 8/8.1/10

An der Kommandozeile (CMD/PowerShell):

C:\> wmic bios get smbiosbiosversion

BIO-version-anzeigen-unter-windowsBIOS-Version unter Linux (Debian/RedHat/CentOS/SuSE/LFS)

An der Shell:

bldgrdian:~# dmidecode | grep Version

bios-version-anzeigen-unter-linux

BIOS-Version unter MacOS X (EFI und SMC PCs)

Die Auswahl via GUI starten: den System-Ordner „Programme“ öffnen > Dienstprogramme > Systeminformationen > Hardware (der Wurzelknoten ganz oben, unter den Auswahlpunkten wird die Version nicht mehr aufgeführt)

bios-version-anzeigen-unter-macosAchtung bei Apple-FW-Updates! Durch den bunten Chipsatz- und CPU-Zoo der schon ähnliche Außmaße annimmt wie bei DELL oder ASUS, gibt es einen unübersichtlich koplexen Abhängigkeitsbaum. „Einfach auf die letzte Version aktualisieren“ endet manchmal in einem nicht mehr startenden MacOS. Bewährt hat sich Step-by-Step updates mit jeweiligem OS-Boot und Update dazwischen.

Alternativ tut es oft auch

dmidecode

aber erst bei aktuellen Macs.

Debian: Es gibt keine öffentlichen Schlüssel für die folgenden Schlüssel-IDs …

Problem

apt-get update schlägt „seit neuestem“ mit seltsamen Schlüsselpaar-Fehlermeldungen fehl:

[email protected]:~# apt-get update
OK   http://security.debian.org wheezy/updates Release.gpg
OK   http://security.debian.org/ wheezy/updates/main Translation-en
OK   http://security.debian.org wheezy/updates Release
OK   http://security.debian.org wheezy/updates/main Sources
OK   http://ftp.at.debian.org wheezy Release.gpg
OK   http://ftp.at.debian.org/debian/ wheezy/main Translation-de
OK   http://ftp.at.debian.org/debian/ wheezy/main Translation-en
OK   http://ftp.at.debian.org wheezy-updates Release.gpg
OK   http://ftp.at.debian.org/debian/ wheezy-updates/main Translation-en
OK   http://security.debian.org wheezy/updates/main amd64 Packages
OK   http://ftp.at.debian.org wheezy Release
OK   http://ftp.at.debian.org wheezy-updates Release
OK   http://ftp.at.debian.org wheezy/main Sources
OK   http://ftp.at.debian.org wheezy/main amd64 Packages
OK   http://ftp.at.debian.org wheezy-updates/main Sources
Hole:1 http://ftp.at.debian.org wheezy-updates/main amd64 Packages/DiffIndex [1.012 B]
Es wurden 1.012 B in 0 s geholt (4.720 B/s)
Paketlisten werden gelesen... Fertig
W: Es gibt keine Öffentlichen Schlüssel für die folgenden Schlüssel-IDs:
9D6D8F6BC857C906
W: Es gibt keine Öffentlichen Schlüssel für die folgenden Schlüssel-IDs:
7638D0442B90D010
W: Es gibt keine Öffentlichen Schlüssel für die folgenden Schlüssel-IDs:
7638D0442B90D010

Alternativ jammert apt auch gerne auf English:

There is no public key available for the following key IDs: 8B48AD6246925553

Lösung

Die Schlüssel-IDs 9D6D8F6BC857C906 und 7638D0442B90D010 gehören zu den Debian Wheezy Update Package Repositorys und sind Teil des Keyring-Pakets (die Update-Pakete benötigen das Keyring-Archiv). Einfach den debian-keyring installieren:

[email protected]:~# apt-get install debian-keyring debian-archive-keyring

Dann läuft das nächste apt-get auch schon fehlerfrei durch:

[email protected]:~# apt-get update

(Referenz: http://gnuru.org/article/1486/debian-public-keys-error-2)

Tomcat liefert „ssl_error_weak_server_ephemeral_dh_key“ im Firefox

Problem

Firefox ab Version 39 zeigt bei von einem frischen Tomcat ausgelieferten Webseiten nur noch diese Alternativlose Fehlermeldung an:

Fehler: Gesicherte Verbindung fehlgeschlagen

Ein Fehler ist während einer Verbindung mit oputils.pflitsch.de aufgetreten.
SSL hat einen schwachen kurzlebigen Diffie-Hellman-Schlüssel in der Handshake-Nachricht
"Server-Schlüsselaustausch" empfangen.
(Fehlercode: ssl_error_weak_server_ephemeral_dh_key)

    Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.
    Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem zu informieren.

Lösung

Der unsichere DH/SSL Schlüsselaustausch ist anfällig für die „Logjam“ Attacke (https://weakdh.org), aber noch die Defaultkonfiguration für neue SSL-Connectoren im Tomcat.

In der server.xml kann man im Abschnitt <connector> die passenden Cipher-Suiten vorgaben. Bewährt hat sich diese Liste hier, weil sie auch noch die älteren aber sicheren SSL-Handshakes für den Internet-Explorer enthält.

<Connector
   port="443"
   protocol="HTTP/1.1"
   SSLEnabled="true"
   keystoreFile="uggliest.keystore"
[...]
   ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA"
/>