Powershell – Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden…

Beim Abfragen von Webservices über Powershell kommt es immer wieder mal zu folgender Fehlermeldung:

PS N:\> Invoke-Webrequest -Uri https://tls-v1-2.badssl.com:1012/
Invoke-Webrequest : Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden..
In Zeile:1 Zeichen:1
+ Invoke-Webrequest -Uri https://tls-v1-2.badssl.com:1012/
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
eption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

So wirklich schlau wird man aus der Meldung „Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden..“ jetzt auf den ersten Blick nicht. (In Englisch: The underlying connection was closed: An unexpected error occurred on a send..)
Der Fehler tritt bei Problemen mit der TLS Verschlüsselung auf. Speziell wenn der Client (also die Powershell in diesem Fall) mit einer nicht unterstützten TLS Version beim Server ankommt.
Bei Windows Server 2016, 2012R2 oder älteren Windows Client Betriebssystemen ist die Standard Verschlüsselung TLS 1.1/1.0 welche von vielen Betreibern von Websites mittlerweile wegen der Sicherheit deaktiviert wurde.
Bein Windows Server 2019 und Windows 10 (1909) hatte ich bei Tests mit dem Powershell Invoke-Webrequest standardmäßig TLS 1.2 vorgefunden.

Wie kann man per Powershell die TLS Verschlüsselung ändern?

Über folgende Befehle vor dem Invoke-Webrequest bzw. Invoke-RestMethod kann die TLS Version gesteuert werden.

TLS 1.2

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

TLS 1.1

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls11

TLS 1 ( 1.0 )

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls

Beispiel

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$a = Invoke-Webrequest -Uri https://tls-v1-2.badssl.com:1012/

Dies kann man über folgende URL’s auch direkt testen (Quelle: Stackexchange.com):

This subdomain and port only supports TLSv1.2

https://tls-v1-2.badssl.com:1012/

This subdomain and port only supports TLSv1.1

https://tls-v1-1.badssl.com:1011/

This subdomain and port only supports TLSv1.0

https://tls-v1-0.badssl.com:1010/

Nützliche Links

IISCrypto

Mit dem kostenfreien Tool IISCrypto lässt sich speziell der IIS aber auch die Grundlegenden Systemstandards und TLS Protokolle definieren.

Cipherlist

Unter Cipherlist bekommt man jeweils immer die aktuellen SSL Einstellungen für viele Webserver, wie apache2, nginx, oder auch andere Dienste.

Ähnliche Fehlermeldungen

Auch bei der PowerShell Gallery muss man mittlerweile TLS 1.2 einsetzen. Ansonsten bekommt ihr folgende Fehlermeldung:

Install-Module -Name SqlServer
WARNUNG: Unable to resolve package source 'https://www.powershellgallery.com/api/v2'.
PackageManagement\Install-Package : Für die angegebenen Suchkriterien und den Paketnamen "SqlServer" wurde keine
Übereinstimmung gefunden. Verwenden Sie Get-PSRepository, um alle verfügbaren, registrierten Paketquellen anzuzeigen.
In C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1772 Zeichen:21
+ ... $null = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Ex
ception
+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

SSL-Zertifikat des Unifi Wifi Controller austauschen

Wer den Ubiquiti Unifi Wlan Controller nutzt wird vielleicht schon über das mitgelieferte, selbsterstellte Zertifikat gestolpert sein. Das ganze führt auf der Adminoberfläche zu einer kleinen Fehlermeldung die soweit aber noch nicht so dramatisch ist. Nutzt man noch das Gästeportal bekommen jedoch auch alle Clients mit ihrem Smartphone eine Fehlermeldung, wenn auf die Loginseite mit HTTPS weitergeleitet wird.
Leider gibt es noch keine Möglichkeit das Zertifikat über die Admin Oberfläche auszutauschen. Jedoch per Kommandozeile, wie ich hier kurz beschreibe. Ich verwende den Windows Controller. Die Prozedur sollte unter Linux bis auf die Pfade nicht viel anders sein.
Ausgangslage ist ein bereits erstelltes Zertifikat was in Form eines PFX vorliegt. (Der Windows-Standard, wenn man ein Zertifikat exportiert.)
[stextbox id=’alert‘]Vorher unbedingt eine Sicherungskopie des Keystore machen und den Unifi Controller beenden.
(C:\Users\Dein-User\Ubiquiti UniFi\data\keystore)[/stextbox]

Alias des Zertifikats anzeigen lassen:

cd C:\Users\constey\Ubiquiti UniFi\data\
"C:\Program Files\Java\jre1.8.0_131\bin\keytool" -list -keystore mein-eigenes-zertifikat.pfx -storetype pkcs12
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 1 entry
1, 16.05.2017, PrivateKeyEntry,
Certificate fingerprint (SHA1): 97:CE:EE:22:3A:B4:1C:76:C5:D5:A6:7A:FB:17:EB:60:
7B:C3:E2:E3

Die erste Zahl (1, 16.05.2017) gibt an welcher Alias das Zertifikat in dem PFX hat. In meinem Fall ist in dem PFX nur ein Zertifikat enthalten, evtl. kann aber z.B. noch das Root Zertifikat enthalten sein – dann muss man die Fingerabdrücke vergleichen und den korrekten Alias auswählen.

cd C:\Users\constey\Ubiquiti UniFi\data\
"C:\Program Files\Java\jre1.8.0_131\bin\keytool" -importkeystore -srcstoretype pkcs12 -srcalias 1 -srckeystore mein-eigenes-zertifikat.pfx -keystore keystore -destalias unifi
Enter destination keystore password:
Enter source keystore password:
Existing entry alias 1 exists, overwrite? [no]: yes

Das Passwort für den keystore lautet: aircontrolenterprise
Zum Abschluss den Unifi Controller wieder starten.

VMware SSL Automation Tool – Erleichterung beim Verteilen von SSL-Zertifikaten?

VMware hat gestern ein nettes Tool veröffentlicht, was den Aufwand beim Austauschen der SSL-Zertifikate (die mittlerweile immer mehr Bedeutung haben…) etwas minimieren soll.
Um das einzelne erstellen jedes Zertifikates kommt man allerdings noch nicht herum. Eine ausführliche Anleitung wie man zu den SSL-Zertifikaten kommt schrieb ich schon vergangenes Jahr.
Allerdings werden mit dem vCenter Certificate Automation Tool die Zertifikate automatisch hochgeladen bzw. ausgetauscht und die dazugehörigen Dienste automatisch neugestartet.
Es wird natürlich auch ein Backup der alten Zertifikate gemacht – und für den Notfall gibt es den Rollback Modus.
Unterstützt werden folgende Dienste / Server:
1. vCenter Server
2. vCenter Single Sign On
3. vCenter Inventory Service
4. vSphere Web Client
5. vCenter Log Browser
6. VMware Update Manager (VUM)
7. vCenter Orchestrator (VCO)
Noch mal ausdrücklich erwähnt: Das austauschen von Zertifikaten für ESXi Hosts wird NICHT unterstützt. Muss man klassisch machen.
Es wird empfohlen das Tool auszuführen nachdem man vom vCenter 4.x oder 5.0 zu 5.1 aktualisiert hat, oder bereits vCenter 5.1 im Einsatz hat und plant seine Zertifikate zu updaten.
Von VMware gibt es solch eine Anleitung ebfenfalls in Englisch: Generating certificates for use with the VMware SSL Certificate Automation Tool (2044696)
2041600_tool_session
Download gibts beim VMware hier: vCenter Certificate Automation Tool
Was man ebenfalls in naher Zukunft auf dem Radar behalten sollte ist der vCert Manager von vsslabs.

Diese wollen sich in Form eines Plugins im vCenter einnisten und ebenfalls den Prozess der Erneuerung von Zertifikaten komfortabler machen und beschleunigen. Ich habe mich bereits letztes Jahr schon in das „early adopter“ Programm eingeschrieben, aber bis heute noch keine Rückmeldung bekommen.
Mal schauen wann die Jungs die erste Beta veröffentlichen.
Einen ausführlichen Beitrag findet ihr hier: http://longwhiteclouds.com/2012/09/15/vcert-manager-changing-vmware-ssl-certs-made-easy/

Vmware Update Manager (Fehler nach SSL-Update)

Nachdem ich heute mal wieder ein paar SSL-Zertifikate aktualisiert hatte, wollte der Update Manager nicht mehr so recht.
Er spuckte folgende Fehlermeldung aus:

update manager vim.fault.invalidlogin

Im Log (C:\ProgramData\VMware\VMware Update Manager\Logs) machte das sich so deutlich:

[05036 warning 'Libs'] SSLVerifyIsEnabled: failed to read registry value. Falling back to default behavior: verification off. LastError = -2146885628

Mh komisch, google hat auch nicht wirklich geholfen – die Registry Einträge die angeblich unter:
HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Infrastructure\Update Manager liegen sollen existieren nicht….. (Scheint, dass ab Version 5 diese nicht mehr existieren? Verbessert mich ggf.)
Also kurzerhand den Update Manager neu installiert, und dabei bin ich auch direkt auf den Fehler des Problems gestoßen.
Das Zertifikat war logischerweise auf den FQDN ausgestellt. Beim Setup des UPDMGR kann man auswählen wie sich dieser identifizieren soll: a) Durch die IP oder b) durch den FQDN….
Hier hatte ich bei der Installation die IP angegeben, weshalb das Zertifikat logischerweise nicht gültig war.

Howto – Zertifikat unter Ubuntu erstellen und mit Windows CA zertifizieren

Servus zusammen,
hier mal ein kleines Tutorial, wie man unter Ubuntu ein Zertifikat erstellt und dieses mit einem Windows-CA Server zertifiziert.
Anschließend noch kurz angeschnitten, wie man das Zertifikat in den Apache2 als SSL-Zertifikat einbinden kann.
1. Keyfile generieren
Hierbei wichtig, worüber ich zuerst gestolpert bin. Erstellt man ein Keyfile mit Passwort, so muss dieses jedes mal beim Neustart des Apache2 Server eingegeben werden. Deshalb empfehle ich die 2. Variante.

openssl genrsa -des3 -out webserver.key //  openssl genrsa -out webserver.key 2048
Generating RSA private key, 2048 bit long modulus
...............................................................................................+++......+++
unable to write 'random state' e is 65537 (0x10001)

2. Request erstellen
Nun können wir den eigentlichen Request erstellen:

openssl req -new -key webserver.key -out webserver-request.csr

Anschließend müssen die std. Werte für das Zertifikat eingegeben werden.
Common Name = Ausgestellt für, also in unserem Fall servername.domaine.de
3. Request anzeigen lassen
Damit wir uns den Request nicht umständlich per SCP o.ä saugen müssen, schauen wir ihn uns einfach an:

openssl req -in svdrm115.csr
-----BEGIN CERTIFICATE REQUEST-----
.................................
-----END CERTIFICATE REQUEST-----

4. Zertifikat Erstellen
Nun können wir unser Zertifikat beim CA-Server beantragen. Dazu auf den CA-Server gehen http://caserver/certsrv

Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file. 

Per Hand kopieren wir nun den obigen Inhalt des Zertifikats in , Template = Webserver (in unserem Fall)
5. Zertifikat in PEM Format umwandeln
Damit der Apache was mit unserem Zertifikat anfangen kann müssen wir es zuerst in ein .pem File konvertierten:

openssl x509 -in /tmp/1/zertifikat-der.cer -inform DER -out /tmp/1/zertifikat.pem -outform PEM

6. Testen ob Zertifikat korrekt ist:

openssl verify zertifikat.cer/pem

Hier sollte ein „OK“ zurückkommen.
7. Zertifikat im Apache2 einbinden
Dazu in der /etc/apache2/sites-available/default-ssl eintragen:

SSLCertificateKeyFile /etc/apache2/ssl/zertifikat.key
SSLCertificateFile /etc/apache2/ssl/zertifikat.pem

8. Apache neustarten

sudo service apache2 restart

Das wars auch schon. Gruß
Constey