In einer Testumgebung teste ich Websocket-Verbindungen (wss://) und benutze dazu Ready!API von SmartBear mit SOAP UI Pro und WebSocket-Plugin. Soweit so gut. Nun haben wir ein Testenvironment mittels vagrant, ansible und VirtualBox aufgesetzt und was bisher lokal auf meiner Maschine funktionierte, indem ich die „self-signed“ Zertifikate auf CN=localhost in die JRE von Ready!API importierte (keytool -import -alias myalias -file <path_to>\localhost.crt -keystore cacerts -storepass changeit), funktionierte auch bestens mit einem Testnetzwerk im LAN (ohne den Import, da ein LoadBalancer wunderschön gültige Zertifikate lieferte).
Nun funktionierte es aber nicht mehr auf dem lokale „virtuellen“ VirtualBox-Netzwerk und auch Onkel Google (Chrome) verweigerte den Dienst mit
NET::ERR_CERT_COMMON_NAME_INVALID
Glücklicherweise war Onkel Google auskunftsfreudig und meinte das CN=<hostname> nicht mehr ausreiche, sondern man durch die „Extensions“ im Zertifikat möge man doch „alternative Namen“ mitgeben. Hä?
Tja, nicht der Zertifikats-Antragsteller muss die mit angeben, sondern die CA, die das Zertifikat signiert! D.h. beim Signierprozess in den Extensions
.... -ext san=dns:test1,ip:1xx.1xx.x.xAls hilfreiches Tool sei hier KeyStore Explorer 5.5.2 (Windows) erwähnt, denn dort kann man die notwendigen Eintragungen beim Signaturprozess vornehmen.