In java we have javax.net.ssl.SSLContext.getDefault() which is described as: Returns the default SSL context.

This makes me think on the following questions:

1. When is the Default SSL Context created? Does this happen only while calling setDefault(SSLContext context)? What about the case where we pass -Djavax.net.ssl.keyStore=mykeystore.jks? Is the default ssl context created based on this keystore? Also what happens in the case of a server environment like Tomcat? Does Tomcat set the default ssl context based on what is configured in keystoreFile="/keystore/tomcatkeystore.jks?

2. When we try to consume any https endpoint is the Default Context the one that is used?

3. When dealing with secure connections that require different set of keystores/configuration can we create new SSL Contexts without affecting what is already configured for the default ssl Context?

Thanks for your help.

CodePudding user response：

When is the Default SSL Context created? Does this happen only while calling setDefault(SSLContext context)?

No. If you use setDefault (which IME is pretty rare) you need to distinguish two 'levels' of default:

• the object returned by .getDefault -- this could be called the 'current default'. It can be set by .setDefault in which case you control the object set and its creation, or it can be created automatically, see next.

• the object created automatically and internally when .getDefault is called WITHOUT previously setting a value. This could be called the 'created default', or maybe the 'default default' (!) Once created this object is set as the default, so a second call to .getDefault goes back under the first bullet.

Most programs don't use .setDefault so if they use .getDefault at all (which they might not) then the first call goes to the second bullet and subsequent calls to the first.

Note .getDefault is called implicitly by many libraries, platforms, and middleware, so you can't assume that just because you don't write such a call it doesn't happen (and maybe invoke the second bullet).

What about the case where we pass -Djavax.net.ssl.keyStore=mykeystore.jks? Is the default ssl context created based on this keystore?

In the second bullet -- when you don't set a default and the default is automatically created, yes. More exactly, that 'created default' uses sysprops javax.net.ssl.keyStore* and ...trustStore* if set; if not it defaults the truststore to the file JRE/lib/security/cacerts (or jssecacerts if it exists, which is rare) and the keystore to none/empty.

If you set the default explicitly, you control what goes in it; you may use those sysprops if you choose to.

Does Tomcat set the default ssl context based on what is configured in keystoreFile="/keystore/tomcatkeystore.jks?

No. It sets a context (there may be more than one) used to handle incoming HTTPS connections, but that is (or those are) not the default context.

When we try to consume any https endpoint is the Default Context the one that is used?

Maybe. There are thousands of ways to 'consume ... https' and they can all be different. Some of them may always use the default context; many will sometimes use the default and sometimes not; some might never use the default. Without a much more specific question it is impossible to say.

When dealing with secure connections that require different set of keystores/configuration can we create new SSL Contexts without affecting what is already configured for the default ssl Context?

Absolutely, and that is exactly what you should do. Note that some connection methods use the SSLContext directly, while some (mostly to be more compatible with non-SSL/TLS connections) use an [SSL]SocketFactory or [SSL]ServerSocketFactory created from and linked to the SSLContext. These accomplish the same result, but your code is slightly different.