-
Enhancement
-
Resolution: Not an Issue
-
P4
-
None
-
8, 9
-
generic
-
generic
A DESCRIPTION OF THE REQUEST :
SNI (Server Name Indication) is a protocol used by SSL (Secure Sockets Layer) (aka HTTPS (Hypertext Transfer Protocol over SSL (Secure Socket Layer)): or TLS (Transport Layer Security)) servers to allow them to serve several websites, each with its own SSL certificate all from the same IP. If you want to talk to an SSL server that supports SNI, you usually need to do a
System.setProperty( "jsse.enableSNIExtension", "true" );
first. If you want to talk to an SSL server than does not support SNI, you usually need to do a
System.setProperty( "jsse.enableSNIExtension", "false" );
first. Unfortunately, there is no setting that will always work for both. You have to keep track. Most sites do not support it.
JUSTIFICATION :
Each HTTPS: website wants SNI on, or SNI off or it does not care. You have to maintain a database for each site to track its preference.
You can find out its preference by trial and error, or by using the Comodo SSL Certificate Analyser.
setProperty is a global static method, not a method of HttpURLConnection (each session). Therefore you can’t have more than one thread going at a time processing SSL streams.
The way I get around this is to create two batches, one of sites with SNI on and another with SNI off. I can then run simultaneous threads within each batch, but I can’t run the two batches simultaneously.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Here is how I would like Oracle to fix the situation to make handling SNI easier:
Create a method HttpURLConnection.setSNI( boolean ) so you can control SNI
on a session/thread basis.
Have HttpURLConnection figure out for itself which SNI setting to use.
If there is an error from using the wrong SNI setting, HttpURLConnection should quietly retry with the opposite setting. It should be possible with a system property to suppress this behaviour.
ACTUAL -
global property
---------- BEGIN SOURCE ----------
this is an RFE not a bug
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
The way I get around this is to create two batches, one of sites with SNI on and another with SNI off. I can then run simultaneous threads within each batch, but I can’t run the two batches simultaneously.
SNI (Server Name Indication) is a protocol used by SSL (Secure Sockets Layer) (aka HTTPS (Hypertext Transfer Protocol over SSL (Secure Socket Layer)): or TLS (Transport Layer Security)) servers to allow them to serve several websites, each with its own SSL certificate all from the same IP. If you want to talk to an SSL server that supports SNI, you usually need to do a
System.setProperty( "jsse.enableSNIExtension", "true" );
first. If you want to talk to an SSL server than does not support SNI, you usually need to do a
System.setProperty( "jsse.enableSNIExtension", "false" );
first. Unfortunately, there is no setting that will always work for both. You have to keep track. Most sites do not support it.
JUSTIFICATION :
Each HTTPS: website wants SNI on, or SNI off or it does not care. You have to maintain a database for each site to track its preference.
You can find out its preference by trial and error, or by using the Comodo SSL Certificate Analyser.
setProperty is a global static method, not a method of HttpURLConnection (each session). Therefore you can’t have more than one thread going at a time processing SSL streams.
The way I get around this is to create two batches, one of sites with SNI on and another with SNI off. I can then run simultaneous threads within each batch, but I can’t run the two batches simultaneously.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Here is how I would like Oracle to fix the situation to make handling SNI easier:
Create a method HttpURLConnection.setSNI( boolean ) so you can control SNI
on a session/thread basis.
Have HttpURLConnection figure out for itself which SNI setting to use.
If there is an error from using the wrong SNI setting, HttpURLConnection should quietly retry with the opposite setting. It should be possible with a system property to suppress this behaviour.
ACTUAL -
global property
---------- BEGIN SOURCE ----------
this is an RFE not a bug
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
The way I get around this is to create two batches, one of sites with SNI on and another with SNI off. I can then run simultaneous threads within each batch, but I can’t run the two batches simultaneously.