Chrome under Windows 7 and 8 cannot connect to emb

We're using Jetty 9.2.x in the embedded mode in conjunction with Restlet 2.3.1 to develop our application sever. Recently we've enabled support for HTTPS, which utilises a certificated signed by a self-established CA.

Everything seemed to be working correctly when connecting to this server from various web browsers under Linux and Mac operating systems. However, when we expended out testing to machines running Windows 7 and 8 (all machines are on the same LAN), we've discovered that the Chrome browser (ver. 42.x) would not establish a connection, reporting

This web page is not available

ERR_FAILED

The webpage at https://host_name:9999/ might be temporarily down or it may have moved permanently to a new web address.

Trying to analyse TCP/IP messages between the browser and the server suggests that HTTPS handshake does not succeed. Surprisingly, everything works correctly under Windows XP.

Unfortunately, we're not sure how to proceed any further in trying to solve this problem. Any suggestions as to a possible cause or a solution to the described situation?

It has also beed observed that Firefox under Windows 7/8 was able to establish the connection, but did not render the page due to lack of HTML5 imports support. This was confirmed by observing the page source from Firefox.

Edit: Configuring Jetty to use a self-signed certificate resolved the connectivity problem. This suggests that there is some issue with signing a certificate by a self-established CA, which seems to be specific to an operating system/web browser combination.

It has been identified that the originally used certificate was at fault. More specifically, its Common Name contained a value, which was not recognised as a suitable domain name. Generating a new certificate, signed with a self-established CA, but providing a suitable (albeit not registered) domain name in property Common Name has solved the problem.

The very original intent for thus issued certificate was to use it for internal development purposes and not for public consumption. Thus, the Common Name property was entered to reflect the local nature of the certificate (e.g. application-name.local).