WebBox per TLS läuft in Timeout

Hallo,

Systemumgebung:
Windows Server 2012
Tobit David FX 12

Es gibt leider Probleme beim Zugriff auf die Webbox per HTTPS
Über HTTP funktioniert alles wunderbar.

Eingerichtet ist ein eigenes Zertifikat (Apps\Webbox\Code\wbcert.pem). Es dürfte auch korrekt eingerichtet sein, da bei einem Neustart des Webbox-Dienstes eine Gutmeldung im Monitor kommt:

WebBox ActiveTLS initialisation successfulWebBox SSL Active

Um andere Ursachen auszuschließen, teste ich aktuell im internen Netz per Browser den Aufruf der Webbox.
Per HTTP bekomme ich den kleinen Anmeldebildschirm "Zugriff von [IP] am [DATUM]..."
Klicke ich nun auf [Start] ohne den Haken bei "Sichere Verbindung über TLS nutzen ", kann ich mich korrekt anmelden und sehe im WebBox Status Monitor den Zugriff .

New Connection [IP] Accepted: 00000540Processing New Connection: 00000540Start Get & Parse TCP MessageSuccessfully got & parsed TCP MessageParse TCP Message successfull.....

Mit einem Haken bei "TLS", läuft die Verbindung jedoch in ein Timeout.
Im Monitor wird parallel dazu kein Eintrag gezeigt!

Parallel habe ich eine Android App (Nine) getestet, die bisher ohne HTTPS per HTTP problemlos funktioniert hat. Angebunden per ActiveSync.
Hake ich im David-Admin die Option "Sichere Verbindung über SSL erzwingen" an, kann die App keine neuen Nachrichten mehr abholen.
Im Monitor finde ich nur das hier als Ansatzpunkt: AS:Only secure connections permitted

New Connection [IP] Accepted: 00000836
Processing New Connection: 00000836
Start Get & Parse TCP Message
Successfully got & parsed TCP Message
Parse TCP Message successfull
ReqURI POST /Microsoft-Server-ActiveSync
Param  [STRING]
Path   
MyHost [HOST]
User-Agent: Nine-kminiltexx/LMY47X
Host: [HOST]
Connection: Keep-Alive
x-att-deviceid: kminiltexx/LMY47X
X-MS-WL: Nine/2.2.2
Authorization: Basic [STRING]
Content-Type: application/vnd.ms-sync.wbxml
Accept-Encoding: gzip
Content-Length: 86
AS: Only secure connections permitted
(00000836) Tx shutdown
(00000836) close
Connection Terminated

Über die Command-Line von Windows habe ich auch die Ports geprüft:
netstat -ano | find /i "Abhören"

Im Ergebnis wird mir auf dem http Port 80 und auf https 443 die selbe PID gezeigt. Der Dienst sollte also korrekt auf dem Port 443 "hören".

Vielen Dank für eure Hilfe.

kurz und knapp. Ticket ist gelöst.

Die Windows Firewall war Schuld. Manchmal kann es so einfach sein.