Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jetty-dev] Jetty 9, SunPKCS11, NSS: KeyStorePath blank=no cipher suites in common

Hello,

I have tried to perform HTTPS decryption though an alternative Security Provider: the Sun wrapper "SunPKCS11", which itself would use the Mozilla Network Services (NSS) library, which is a PKCS#11 module.

In the Jetty configuration, if my setting "KeyStorePath" does not point on a readable file (any file, content does not matter; it is a hack), then I get from Jetty the following error message: " no cipher suites in common" when doing the TLS handshake (which fails). My configuration contained that:

  <New id="sslContextFactory" class="org.eclipse.jetty.util.ssl.SslContextFactory">
  	<Set name="keyStoreType">PKCS11</Set>	
	<Set name="KeyStorePath"></Set>
	<Set name="keyStoreProvider">SunPKCS11-nss-client</Set>
    <Set name="KeyStorePassword">password</Set>
 </New>

I could also remove the node "KeyStorePath" with the same result. So if I put the following setting, it works:

<Set name="KeyStorePath"><Property name="jetty.home" default="." />/etc/jetty.xml</Set>

In fact, the file is not really needed by this Security Provider, because the key store will not be configured in Jetty but in the configuration file associated to this "SunPKCS11" Security Provider. And if I use a Hardware Security Module instead to store my keys and perform decryption, then the path to a key store will be even less relevant.

More technical details:

In the Jetty code, the configuration is processed in the class "org.eclipse.jetty.util.ssl.SslContextFactory". If the settings for a key store are not provided, then a key manager "DummyX509KeyManager" is created, and when the handshake is done it fails (in my environment in "sun.security.ssl.ServerHandshakersetupPrivateKeyAndChain()" at the call to "km.chooseEngineServerAlias()") because the dummy manager is dummy :-).

If the key store path is provided, then Jetty will open the file and pass it as an InputStream to the KeyStore Java object. And in the case of SunPKCS11/NSS, it will do nothing with it I think.

Tomcat does accept configuration with no key store path. And it explicitly ignores this parameter if the type of provider is "PKCS11" ("org.apache.tomcat.util.net.jsse.JSSESocketFactory"). I think that Jetty should adopt the same behaviour. Do you think that I am correct?

Cheers,
Fabien



Information in this e-mail and any attachments is confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other binding commitment through the use of this electronic communication unless it is issued in accordance with the Experian Limited standard terms and conditions of purchase or other express written agreement between Experian Limited and the recipient. Although Experian has taken reasonable steps to ensure that this communication and any attachments are free from computer virus, you are advised to take your own steps to ensure that they are actually virus free. 

Companies Act information: Registered name: Experian Limited. Registered office: Landmark House, Experian Way, NG2 Business Park, Nottingham, NG80 1ZZ, United Kingdom. Place of registration: England and Wales. Registered number: 653331



Back to the top