Set-RDCertificate cert.PFX ist keine PFX-Datei

Problem

Ich hatte gerade bei einem RDS-Deployment einen interessanten WTF-Moment. Es wurde ein ganz frisches SSL-Zertifikat von einer öffentlichen CA bestellt und installiert. Blieb also nur noch, dieses in der RDS-Bereitstellung einzurichten. Sobald das Zertifikat als .PFX exportiert wurde, sollte das per Powershell auch ganz einfach gehen (z.B. für die Gateway-Rolle):

PS C:\> $pfxPassword = Read-Host -AsSecureString
*************
PS C:\> Set-RDCertificate -Role RDGateway -ImportPath C:\install\cert.PFX -Password $pfxPassword

Und schon begrüßt mich der rote Text auf schwarzem Hintergrund:

Set-RDCertificate : ImportPath-Wert "C:\install\cert.PFX" ist keine PFX-Datei.
In Zeile:1 Zeichen:1
...

Lösung

Scheinbar ist das Cmdlet bezüglich der PFX-Dateiendung Case-Sensitive:

PS C:\> Set-RDCertificate -Role RDGateway -ImportPath C:\install\cert.pfx -Password $pfxPassword

funktioniert sofort. Und ja, es reicht wenn man „pfx“ im Cmdlet-Aufruf klein schreibt – der eigentliche Dateiname ist hier nicht relevant (zumindest was Groß-Kleinschreibung angeht).

Dem Server-Manager ist das übrigens auch egal. Über die GUI klappt’s ebenfalls sofort.

GLS UniBox Linux Server Standard Passwort

Die GLS UniBox ist ein kleiner Linux-Server, beziehungsweise in der Regel heute eine virtuelle Appliance. Über diese kann man seine GLS Versandabwicklung steuern, einschliesslich Paketlabel-Erstellung und FTP-Datenübertragung an GLS.

Das UniBox Versandsystem basiert auf einem CentOS Linux und ist leicht angepasst. Leider sind alle dieser System mit einem Standardkennwort versehen dessen Änderung nicht vorgesehen ist. Immerhin ist zwar der Remote-Login ohne passendes Schlüsselpärchen verboten, aber das unangenehme Bauchgefühl von Standardzugangsdaten bleibt.

Soll ein solches System in ein Monitoring oder ein Security Information and Event Management (SIEM) eingefügt werden, braucht man in der Regel einen Agenten auf dem System. Dieses installiert man am besten als root.

GLS UniBox Default Password

UniBox Default Username: root
UniBox Default Password: Uni-Box-GLS

Die Millionen knapp verpasst

Da haben wir den „Eine-Millionen-Spam“ doch knapp verpasst, dabei wollen wir den eigentlich veröffentlichen 🙂

Danke Akismet, fail2ban und vielen findigen Admins, möge 2018 ebenfalls (möglichst) Spamfrei bleiben.

VW kann auch keine E-Mails schreiben

Neben den nicht-ganz-so-tollen Diesel-Motoren hat VW offenbar auch Problem mit der Konstruktion von (Massen-)E-Mails. Diese E-Mail sah genau so aus, enthielt keine Informationen und keinen einzigen Link. Nicht mal die Socialbullshitbuttons sind verlinkt. Abgesehen davon das ich auch sicher keine „car net“ E-Mails bestellt habe. Aber: Die Mail ist echt und kam tatsächlich von einem echten Carnet-Account.

Outlook 2013/2016 mit einer E-Mail crashen

Ein Kunde meldet sich:

Immer wenn ich diese E-Mail öffne, stürzt mein Computer ab.

Wir, als gestandene Admins, glauben natürlich erstmal nichts und schauen uns das an. Stellt sich raus: Der Kunde hat recht. Er hat eine Mail in seinem Posteingang, die seinen Outlook-Client immer crasht, wenn er die Mail anschaut. Wir leiten uns die Mail weiter (OWA ist nicht betroffen) und stellen fest: Outlook 2013 und 2016 lassen sich mit dieser Nachricht reproduzierbar und überall crashen. Unter jedem Windows. In der Voransicht (Standardmäßig eingeschaltet), beim anklicken, als MSG- oder EML-Datei, immer. Sehr schön!

Nach genauer Analyse stellt sich heraus: Es ist „nur“ der HTML-Word-Viewer. Dieser stolpert über eine einzige Zeile:

<style>table {mso-style-name:Standardowy; width:100%;}</style><br>

Wenn man also anderen Leuten das Outlook abschießen möchte verschickt einfach diese Zeile. Eine Beispiel-Crash-Mail.eml sieht zum Beispiel so aus:

From: Teleweed <[email protected]>
To: "Anonymous" <Anonymous>
Subject: This is an outlook crashing example
Date: Fri, 2 Jun 2017 2:22:22 -0200
Content-Type: text/html;

<style>table {mso-style-name:Standardowy; width:100%;}</style><br>

Leider konnten wir den Fehler nicht an Microsoft melden, weil das praktisch unmöglich ist. Weder ein MVP, unser PAM/PSX, die Social-Foren, noch das Feedback, noch die Security noch das Support-Team, noch der Partner-Support konnten oder wollten den Bug annehmen. Also liebe Welt: Happy shooting!

Vielleicht schickt ja mal jemand eine solche Mail an Rajesh Jha oder am besten gleich Satya Nadella 🙂

Update:

Mit dem Code lässt sich scheinbar auch Word an sich zum absturz bringen: Baut man folgendes in den Head eines html-Dokuments und versucht dann, selbiges mit Word zu öffnen kommt es ebenfalls zum Absturz.

<style>table {mso-style-name:Standardowy; width:100%;}</style>

Scheinbar ist das Ganze abhängig von der verwendeten Office-Sprache: Standardowy ist polnisch für „konventionell“. Ersetzt man es z.B. mit „Normale Tabelle“ (mit Anführungszeichen, wegen dem Leerzeichen) lässt es sich mit einem deutschen Word wieder Öffnen. Ein beliebige anderer String (z.B. auch „Table Normal“ aus einem englischsprachigen Word) verursacht den Absturz trotzdem.

Wichtig ist die Kombination aus „mso-style-name:<string>;“ und „width:<size>;“ -> Verwendet man z.B. „height“ gibt es keinen crash. Für <size> spielt es allerdings keine Rolle in welcher Einheit die Angabe erfolgt, Abstürzen tut Word auch mit z.B. 300px

Beispiele (proof of concept) gibt’s hier. („normale-tabelle_prozent.html“ sollte keinen Crash verursachen, der Rest allerdings schon.)

Danke @iSnackyCracky und @teleweed fürs finden und die langwierige Analyse.

Diesen KB Titel einmal genau lesen … das erklärt einiges


„A list of Microsoft Knowledge Base articles is available to help troubleshoot error messages that you may receive when you upgrade from Windows Vista to Windows“

Übersetzungsfehler, Tippfehler oder Absicht. Mehr Ursachen können wir uns für diesen schönen Satz kaum vorstellen 🙂