Some types of keystores do not require a file or an InputStream to be used. Indeed, Apple's KeychainStore is a keystore that can interact directly with the keychain in OSX. Other such keystores could be hardware tokens. For example, the following statements will load the default keychain keystore and delegate the task of prompting for a password to the underlying security infrastructure of OSX: KeyStore ks = KeyStore.getInstance("KeychainStore"); ks.load(null,null); However, Jetty's SslSocketConnector considers a null keystore parameter (<Set name="keystore"></Set> in the connector configuration) as an absent keystore (it doesn't even try to get the instance and load it). Here is a patch that should make possible to use a keystore that can have a null InputStream. It works on OSX (with the default keychain) using this configuration (in jetty-ssl.xml, for example): <Set name="keystoreType">KeychainStore</Set> <Set name="keystore"></Set> <Set name="password">-</Set> <Set name="keyPassword">-</Set> <Set name="truststoreType">KeychainStore</Set> <Set name="truststore"></Set> <Set name="trustPassword">-</Set> For some reason I ignore, although the password are in fact asked by the keychain mechanism of OSX, empty or null passwords do not work for getting a private key. Both keyStore.getKey(alias, "-".toCharArray()) and keyStore.getKey(alias, "whateveryoulike".toCharArray()) work (irrespectively of the actual password), but keyStore.getKey(alias, null) or keyStore.getKey(alias, "".toCharArray()) will fail. Hence, the passwords in the configuration above use a dummy non-empty value. (I submitted a similar patch for Tomcat if this may be relevant: http://issues.apache.org/bugzilla/show_bug.cgi?id=43094 )