Closed GoogleCodeExporter closed 8 years ago
Additional comment: DefaultSecurityManagerProvider can be easily overriden by a
custom class, close the issue if that's the preferred way.
Original comment by josemre...@gmail.com
on 6 Feb 2013 at 9:23
Feel free to provide a patch Jose, we can discuss with JSIP Team to integrate
it so that you don't have to write and plug your own Provider here.
Original comment by jean.deruelle
on 6 Feb 2013 at 11:10
Patch attached.
Additionally the patch addresses the following:
- uses default key store type if none is specified (fixes
http://code.google.com/p/sipservlets/issues/detail?id=191)
- uses default algorithm provided by JVM, instead of forcing the use of
SunX509. With this patch non-HotSpot/non-OpenJDK can be used with the
DefaultSecurityManager and without explict configuration. Basic tests on IBM
JDK ran ok.
- explicit logging warnings when configuration misses parameters
Please review for acceptance.
Original comment by josemre...@gmail.com
on 10 Feb 2013 at 11:11
Attachments:
Hi Jose,
I reviewed the patch. It looks good. I just have one comment though. To avoid
breaking backward compatibility with existing applications that use only one
password for both KeyStore and TrustStore, and which would fail to init with
this patch, I would actually set the truststorepassword to the keystorePassword
if the former is null.
See code in the attached counterpatch starting from line 58 :
// required, could use default trustStore, but it is better practice to
explicitly specify
+ final String trustStoreFilename =
properties.getProperty("javax.net.ssl.trustStore");
+ // optional, if not specified using keyStorePassword
+ String trustStorePassword =
properties.getProperty("javax.net.ssl.trustStorePassword");
+ if(trustStorePassword == null) {
+ logger.logInfo("javax.net.ssl.trustStorePassword is null, using the
password passed through javax.net.ssl.keyStorePassword");
+ trustStorePassword = keyStorePassword;
+ }
Original comment by jean.deruelle
on 15 Feb 2013 at 4:28
Attachments:
I think that's fine, it reflects common practice too.
Original comment by josemre...@gmail.com
on 15 Feb 2013 at 7:46
There is documentation problem with protocols :
gov.nist.javax.sip.TLS_CLIENT_PROTOCOLS = String Comma-separated list of
protocols to use when creating outgoing TLS connections. The default is "SSLv3,
SSLv2Hello, TLSv1". Some servers do not support SSLv2Hello, so override to
"SSLv3, TLSv1".
as you can see space is between comma and TLSv1.
While adding spaces to list will cause an exception while initialing TLS channel
Original comment by oifa.yul...@gmail.com
on 4 Apr 2013 at 3:58
That's a differente issue.
See
http://code.google.com/p/jain-sip/issues/detail?id=93
Original comment by josemre...@gmail.com
on 4 Apr 2013 at 6:40
linking to http://java.net/jira/browse/JSIP-450
Original comment by jean.deruelle
on 16 Apr 2013 at 2:37
This issue was updated by revision d40b6c817ba7.
Issue 450
JAIN SIP Repo
commit addresses the following:
- uses default key store type if none is specified (fixes
http://code.google.com/p/sipservlets/issues/detail?id=191)
- uses default algorithm provided by JVM, instead of forcing the use of
SunX509. With this patch non-HotSpot/non-OpenJDK can be used with the
DefaultSecurityManager and without explict configuration. Basic tests on IBM
JDK ran ok.
- explicit logging warnings when configuration misses parameters
git-svn-id: https://svn.java.net/svn/jsip~svn/trunk@2278
8e71dc83-d81e-6649-80f2-80b843a9b2be
Original comment by jean.deruelle
on 16 Apr 2013 at 2:58
Original comment by jean.der...@telestax.com
on 18 Apr 2013 at 1:35
Original comment by jean.deruelle
on 13 Jun 2013 at 8:13
This issue was updated by revision e434bbc3b036.
Issue 450
JAIN SIP Repo
Backport to TelScale Branch
commit addresses the following:
- uses default key store type if none is specified (fixes
http://code.google.com/p/sipservlets/issues/detail?id=191)
- uses default algorithm provided by JVM, instead of forcing the use of
SunX509. With this patch non-HotSpot/non-OpenJDK can be used with the
DefaultSecurityManager and without explict configuration. Basic tests on IBM
JDK ran ok.
- explicit logging warnings when configuration misses parameters
(cherry picked from commit 9d3ba46c3881203c7e38272022804d1bc59332a4)
Original comment by jean.der...@telestax.com
on 19 Aug 2014 at 4:59
Original issue reported on code.google.com by
josemre...@gmail.com
on 5 Feb 2013 at 5:32