Derby
  1. Derby
  2. DERBY-2108

Implement SSL/TLS communication between client and server

    Details

    • Issue & fix info:
      Release Note Needed
    • Bug behavior facts:
      Security

      Description

      Implement SSL/TLS communication between client and server

      1. DERBY-2108-first-cut.diff
        7 kB
        Bernt M. Johnsen
      2. DERBY-2108-first-cut.stat
        0.3 kB
        Bernt M. Johnsen
      3. DERBY-2108-second-cut.diff
        8 kB
        Bernt M. Johnsen
      4. DERBY-2108-second-cut.stat
        0.4 kB
        Bernt M. Johnsen
      5. DERBY-2108-third-cut.diff
        20 kB
        Bernt M. Johnsen
      6. DERBY-2108-third-cut.stat
        1 kB
        Bernt M. Johnsen
      7. derby-2108-v1.diff
        28 kB
        Bernt M. Johnsen
      8. derby-2108-v1.stat
        0.8 kB
        Bernt M. Johnsen
      9. derby-2108-v2.diff
        50 kB
        Bernt M. Johnsen
      10. derby-2108-v2.diff
        50 kB
        Bernt M. Johnsen
      11. derby-2108-v2.stat
        1 kB
        Bernt M. Johnsen
      12. derby-2108-v3.diff
        64 kB
        Bernt M. Johnsen
      13. derby-2108-v3.stat
        2 kB
        Bernt M. Johnsen
      14. derby-2108-v4.diff
        65 kB
        Bernt M. Johnsen
      15. derby-2108-v4.stat
        2 kB
        Bernt M. Johnsen
      16. derby-2108-v5.diff
        65 kB
        Bernt M. Johnsen
      17. derby-2108-v5.stat
        2 kB
        Bernt M. Johnsen
      18. releaseNote.html
        5 kB
        Rick Hillegas
      19. releaseNote.html
        5 kB
        Bernt M. Johnsen
      20. releaseNote.html
        3 kB
        Bernt M. Johnsen
      21. releaseNote.html
        3 kB
        Bernt M. Johnsen
      22. SSLFuncSpect.txt
        3 kB
        Bernt M. Johnsen

        Issue Links

          Activity

          Hide
          Kristian Waagan added a comment -

          Closing old issue.

          Show
          Kristian Waagan added a comment - Closing old issue.
          Hide
          Rick Hillegas added a comment -

          Scrubbing release note so that it can be digested by the SAX parser in the release note generator: Replaced unbalanced <br> tags with <br/>

          Show
          Rick Hillegas added a comment - Scrubbing release note so that it can be digested by the SAX parser in the release note generator: Replaced unbalanced <br> tags with <br/>
          Hide
          Bernt M. Johnsen added a comment -

          Forgot the license... 3rd time today....

          Show
          Bernt M. Johnsen added a comment - Forgot the license... 3rd time today....
          Hide
          Bernt M. Johnsen added a comment -

          A more extensive version of the release notes.

          Show
          Bernt M. Johnsen added a comment - A more extensive version of the release notes.
          Hide
          Bernt M. Johnsen added a comment -

          Forgot to grant license...

          Show
          Bernt M. Johnsen added a comment - Forgot to grant license...
          Hide
          Bernt M. Johnsen added a comment -

          New version of release note.

          Show
          Bernt M. Johnsen added a comment - New version of release note.
          Hide
          Bernt M. Johnsen added a comment -

          Release note.

          Show
          Bernt M. Johnsen added a comment - Release note.
          Hide
          Bernt M. Johnsen added a comment -

          Hi Rick, sorry for the confusion.

          There's an updated spec attahced to DEBY-2356. That spec will change somewhat due to DERBY-2363. DERBY-2363 is, however, blocked by DERBY-2412, which is where I'm at for the momnet.

          Show
          Bernt M. Johnsen added a comment - Hi Rick, sorry for the confusion. There's an updated spec attahced to DEBY-2356. That spec will change somewhat due to DERBY-2363 . DERBY-2363 is, however, blocked by DERBY-2412 , which is where I'm at for the momnet.
          Hide
          Rick Hillegas added a comment -

          Hi Bernt,

          This is a great addition to Derby. I'm a little confused, however, about what's being built. It seems to me that DERBY-2363 changes the default behavior for the client. Should the functional spec be updated to reflect DERBY-2363? Or are you waiting to update the spec until after you finish your experiments and determine whether DERBY-2363 is the correct client experience? Thanks.

          Show
          Rick Hillegas added a comment - Hi Bernt, This is a great addition to Derby. I'm a little confused, however, about what's being built. It seems to me that DERBY-2363 changes the default behavior for the client. Should the functional spec be updated to reflect DERBY-2363 ? Or are you waiting to update the spec until after you finish your experiments and determine whether DERBY-2363 is the correct client experience? Thanks.
          Hide
          Daniel John Debrunner added a comment -

          FYI - Building under IBM JVMs worked for me after I added security.jar as indicated in BUILDING.txt.

          Show
          Daniel John Debrunner added a comment - FYI - Building under IBM JVMs worked for me after I added security.jar as indicated in BUILDING.txt.
          Hide
          Bernt M. Johnsen added a comment -

          Committed revision 507488.

          Show
          Bernt M. Johnsen added a comment - Committed revision 507488.
          Hide
          Bernt M. Johnsen added a comment -

          Ooops, thanks Dyre. Uploaded diff-2108-v5.diff where the conflicts are resovled (why can't I delete the faulty attachments?).

          Show
          Bernt M. Johnsen added a comment - Ooops, thanks Dyre. Uploaded diff-2108-v5.diff where the conflicts are resovled (why can't I delete the faulty attachments?).
          Hide
          Dyre Tjeldvoll added a comment -

          The changes look good, but did you try to build after creating the latest version of the patch? It seems to me that the latest version contains conflicts:

          dt136804@khepri29~$ egrep '\<\<\<|\>\>\>' /tmp/derby-2108-v4.diff
          +<<<<<<< .mine
          +>>>>>>> .r506910
          +<<<<<<< .mine
          +>>>>>>> .r506910
          +<<<<<<< .mine
          +>>>>>>> .r506910
          +<<<<<<< .mine
          +>>>>>>> .r506910
          +<<<<<<< .mine
          +>>>>>>> .r506910
          +<<<<<<< .mine
          +>>>>>>> .r506910
          +<<<<<<< .mine
          +>>>>>>> .r506910
          +<<<<<<< .mine
          +>>>>>>> .r506910
          +<<<<<<< .mine
          +>>>>>>> .r506910
          +<<<<<<< .mine
          +>>>>>>> .r506910
          +<<<<<<< .mine
          +>>>>>>> .r506910

          Seems rev 506910 introduced some changes that weren't compatible with yours.

          Show
          Dyre Tjeldvoll added a comment - The changes look good, but did you try to build after creating the latest version of the patch? It seems to me that the latest version contains conflicts: dt136804@khepri29~$ egrep '\<\<\<|\>\>\>' /tmp/derby-2108-v4.diff +<<<<<<< .mine +>>>>>>> .r506910 +<<<<<<< .mine +>>>>>>> .r506910 +<<<<<<< .mine +>>>>>>> .r506910 +<<<<<<< .mine +>>>>>>> .r506910 +<<<<<<< .mine +>>>>>>> .r506910 +<<<<<<< .mine +>>>>>>> .r506910 +<<<<<<< .mine +>>>>>>> .r506910 +<<<<<<< .mine +>>>>>>> .r506910 +<<<<<<< .mine +>>>>>>> .r506910 +<<<<<<< .mine +>>>>>>> .r506910 +<<<<<<< .mine +>>>>>>> .r506910 Seems rev 506910 introduced some changes that weren't compatible with yours.
          Hide
          Bernt M. Johnsen added a comment -

          Dyre, thanks for your comments. I have made a new patch, derby-2108-v4.diff, which have incorporated (most of) your commets.

          I think I'm ready for commit soon. I did a change to BULIDING.txt adding $

          {j14lib}

          /security.jar to java14compile.classpath in the description of how to build with IBM JDK. I have not verified that it works and hope someone would confirm that it's correct.

          Show
          Bernt M. Johnsen added a comment - Dyre, thanks for your comments. I have made a new patch, derby-2108-v4.diff, which have incorporated (most of) your commets. I think I'm ready for commit soon. I did a change to BULIDING.txt adding $ {j14lib} /security.jar to java14compile.classpath in the description of how to build with IBM JDK. I have not verified that it works and hope someone would confirm that it's correct.
          Hide
          Dyre Tjeldvoll added a comment -

          I think the patch is good, and represents a valuable addition to
          derby. I have a few comments, but they're all nits and should not
          delay a commit (but they prove that I have actually read through
          the patch :

          General: Some lines are longer than 80 chars

          Index: java/drda/org/apache/derby/impl/drda/ClientThread.java
          @@ -31,64 +31,96 @@
          + try { // Check for al other exceptions....
          <Missing l in 'all'>

          + // This is a shutdown (I hope, what about a check?),
          <I've noticed that some reviewers dislike comments like this
          because it supposedly creates uncertainty. Personally I think it is fine
          because it points to something (how exceptions are used) that is
          not in the scope of this patch, but that perhaps should be looked
          at...>

          Index: java/drda/org/apache/derby/impl/drda/NetworkServerControlImpl.java
          <space indentation, file has mostly tab indentation
          private int getSSLModeValue(String) has an empty javadoc
          comment. It is private so I don't think it really needs one, but
          since the comment block was added in the patch it looks like you
          meant to put something there.>

          Index: java/client/org/apache/derby/jdbc/ClientDriver.java
          @@ -172,7 +173,8 @@
          + key.equals(Attribute.PASSWORD_ATTR) ||
          + key.equals(Attribute.SSL_ATTR))
          <Modified line is tab indented, added line is space indented. But
          the file as a whole is mostly space indented, so what should one
          do?>

          Should SSL be mentioned in BUILDING.txt or release notes or some
          other file (apart from the documentation)?

          Show
          Dyre Tjeldvoll added a comment - I think the patch is good, and represents a valuable addition to derby. I have a few comments, but they're all nits and should not delay a commit (but they prove that I have actually read through the patch : General: Some lines are longer than 80 chars Index: java/drda/org/apache/derby/impl/drda/ClientThread.java @@ -31,64 +31,96 @@ + try { // Check for al other exceptions.... <Missing l in 'all'> + // This is a shutdown (I hope, what about a check?), <I've noticed that some reviewers dislike comments like this because it supposedly creates uncertainty. Personally I think it is fine because it points to something (how exceptions are used) that is not in the scope of this patch, but that perhaps should be looked at...> Index: java/drda/org/apache/derby/impl/drda/NetworkServerControlImpl.java <space indentation, file has mostly tab indentation private int getSSLModeValue(String) has an empty javadoc comment. It is private so I don't think it really needs one, but since the comment block was added in the patch it looks like you meant to put something there.> Index: java/client/org/apache/derby/jdbc/ClientDriver.java @@ -172,7 +173,8 @@ + key.equals(Attribute.PASSWORD_ATTR) || + key.equals(Attribute.SSL_ATTR)) <Modified line is tab indented, added line is space indented. But the file as a whole is mostly space indented, so what should one do?> Should SSL be mentioned in BUILDING.txt or release notes or some other file (apart from the documentation)?
          Hide
          Bernt M. Johnsen added a comment -

          I plan to commit V3 in the beginning of next week unless someone objects.

          Show
          Bernt M. Johnsen added a comment - I plan to commit V3 in the beginning of next week unless someone objects.
          Hide
          Bernt M. Johnsen added a comment -

          Thanks Andrew.

          Summary of message changes in java/drda/org/apache/derby/loc/drda/messages_en.properties: I have added a parameter to DRDA_ListenPort.S (and deleted the emssage from the other locales)., added the messages DRDA_SSLReady.I and DRDA_SSLClientAuthReady.I and changed DRDA_Usage[3-12].I.

          Show
          Bernt M. Johnsen added a comment - Thanks Andrew. Summary of message changes in java/drda/org/apache/derby/loc/drda/messages_en.properties: I have added a parameter to DRDA_ListenPort.S (and deleted the emssage from the other locales)., added the messages DRDA_SSLReady.I and DRDA_SSLClientAuthReady.I and changed DRDA_Usage [3-12] .I.
          Hide
          Andrew McIntyre added a comment -

          As for the localized messages, just change the English messages. The only exception is If you are adding a new parameter to an existing message, then remove the message from the other locales.

          Show
          Andrew McIntyre added a comment - As for the localized messages, just change the English messages. The only exception is If you are adding a new parameter to an existing message, then remove the message from the other locales.
          Hide
          Bernt M. Johnsen added a comment -

          Reattach with "Grant licence"

          Show
          Bernt M. Johnsen added a comment - Reattach with "Grant licence"
          Hide
          Bernt M. Johnsen added a comment -

          Fixed test issues so derbyall now runs with no errors. There are some changes to java/drda/org/apache/derby/loc/drda/messages_en.properties. How is this dealt with wrt. the localized versions?

          How to compile with jsse with the IBM JDK is not taken care of, not sure how that is done. Also: The eclipse plugin has no changes wrt SSL, so in that environment, everything should default to plaintext. Perhaps this should be opened as an separate issue?

          Any comments?

          Show
          Bernt M. Johnsen added a comment - Fixed test issues so derbyall now runs with no errors. There are some changes to java/drda/org/apache/derby/loc/drda/messages_en.properties. How is this dealt with wrt. the localized versions? How to compile with jsse with the IBM JDK is not taken care of, not sure how that is done. Also: The eclipse plugin has no changes wrt SSL, so in that environment, everything should default to plaintext. Perhaps this should be opened as an separate issue? Any comments?
          Hide
          Bernt M. Johnsen added a comment -

          If someone should happen to look at the patch: Note that there stil are some unresolved derbynet test issues: sysinfo, sysinfo_withproperties and testProperties does not run correctly.

          Show
          Bernt M. Johnsen added a comment - If someone should happen to look at the patch: Note that there stil are some unresolved derbynet test issues: sysinfo, sysinfo_withproperties and testProperties does not run correctly.
          Hide
          Bernt M. Johnsen added a comment -

          Additional comments to derby-2108-v1.diff: I rewrote ClientThread when I had to add handling of SSLException. I hope the new version is clearer. A also changed how the ClientThread is used in NetworkServerControlImpl since ClientThead isa subclass of Thread and not just a Runnable.

          Show
          Bernt M. Johnsen added a comment - Additional comments to derby-2108-v1.diff: I rewrote ClientThread when I had to add handling of SSLException. I hope the new version is clearer. A also changed how the ClientThread is used in NetworkServerControlImpl since ClientThead isa subclass of Thread and not just a Runnable.
          Hide
          Bernt M. Johnsen added a comment -

          The complete functionality is implemented with the exception of datasource objects.

          Changes from the write-up: The attribute on the client side is called "ssl" both in the URL and as a property, and is a boolean attribute.

          Additions to the writeup: the server command has got an option "-ssl" which may be "off", "on"/"true" and "clientAuth". This option is used both for start and the other commands (shutdown, sysinfo etc). When the NetworkServerControl is used as a client, specifying "on" or "clientAuth" is the same, and the javax.net.ssl properties must be set up in the same manner as for the client driver.

          Show
          Bernt M. Johnsen added a comment - The complete functionality is implemented with the exception of datasource objects. Changes from the write-up: The attribute on the client side is called "ssl" both in the URL and as a property, and is a boolean attribute. Additions to the writeup: the server command has got an option "-ssl" which may be "off", "on"/"true" and "clientAuth". This option is used both for start and the other commands (shutdown, sysinfo etc). When the NetworkServerControl is used as a client, specifying "on" or "clientAuth" is the same, and the javax.net.ssl properties must be set up in the same manner as for the client driver.
          Hide
          Bryan Pendleton added a comment -

          > Is it fair to compare Web browsers to Derby

          No, they're clearly different. I was basically probing to see whether there was any simplification possible; I don't feel that "ssl=on" is much of a problem. I agree with you that developers who embed client-side Derby in their apps can use their own judgement about how to expose this feature to their own end users.

          Thanks for the discussion!

          Show
          Bryan Pendleton added a comment - > Is it fair to compare Web browsers to Derby No, they're clearly different. I was basically probing to see whether there was any simplification possible; I don't feel that "ssl=on" is much of a problem. I agree with you that developers who embed client-side Derby in their apps can use their own judgement about how to expose this feature to their own end users. Thanks for the discussion!
          Hide
          Bernt M. Johnsen added a comment -

          Bryan: Is it fair to compare Web brosers to Derby in this case? Web browsers are for end users, while Derby is for application programmers. A well behaved application should wrap the SSL configuration in a "end-user-friendly" way. We should provide the tool the application programmer need in a "programmer-friendly" way.

          Show
          Bernt M. Johnsen added a comment - Bryan: Is it fair to compare Web brosers to Derby in this case? Web browsers are for end users, while Derby is for application programmers. A well behaved application should wrap the SSL configuration in a "end-user-friendly" way. We should provide the tool the application programmer need in a "programmer-friendly" way.
          Hide
          Bernt M. Johnsen added a comment -

          Thanks for the comments.

          Bryan: I am reluctant to tie use of ssl to wether e.g. javax.net.ssl.trustStore is defined, since jsse is provider based and that the chosen parameter may not be relevant for other providers than the one included in the JDK.

          On fallback to a clear-text connection: I think that should be up to the application to implement that, since we as DB implementors have no knowledge of the security requirements of the applictions that will use Derby.

          Dan: Since a plain text client talking to an SSL-listening server will receive some gibberish, you'll get some DRDA protocol error message from the client. I think that may be improved with a suggestion that it might be an SSL server on the other end, sinec it also may be some completely different application talking an arbitrary protocol.

          Making servers listening both on an SSL-port and an plaintext port should be a pretty straightforward to implement. It means that two different instances ClientThread is needed. Should not be much work to do such an enahancement, although from a security point of view, I think the feature is of limited value.

          Show
          Bernt M. Johnsen added a comment - Thanks for the comments. Bryan: I am reluctant to tie use of ssl to wether e.g. javax.net.ssl.trustStore is defined, since jsse is provider based and that the chosen parameter may not be relevant for other providers than the one included in the JDK. On fallback to a clear-text connection: I think that should be up to the application to implement that, since we as DB implementors have no knowledge of the security requirements of the applictions that will use Derby. Dan: Since a plain text client talking to an SSL-listening server will receive some gibberish, you'll get some DRDA protocol error message from the client. I think that may be improved with a suggestion that it might be an SSL server on the other end, sinec it also may be some completely different application talking an arbitrary protocol. Making servers listening both on an SSL-port and an plaintext port should be a pretty straightforward to implement. It means that two different instances ClientThread is needed. Should not be much work to do such an enahancement, although from a security point of view, I think the feature is of limited value.
          Hide
          Daniel John Debrunner added a comment -

          If the server is running with SSL enabled then what happens if a connection attempt is made without SSL?
          (and vice-versa).

          I could see future enhancements that allow a single server to support SSL and non-SSL connections, like web/application servers. This could also be enhanced to allow a database to specifiy it will only accept SSL connections. Just wondering if the implementation is designed so such enhancements could be made, or at least does not impede them?

          Show
          Daniel John Debrunner added a comment - If the server is running with SSL enabled then what happens if a connection attempt is made without SSL? (and vice-versa). I could see future enhancements that allow a single server to support SSL and non-SSL connections, like web/application servers. This could also be enhanced to allow a database to specifiy it will only accept SSL connections. Just wondering if the implementation is designed so such enhancements could be made, or at least does not impede them?
          Hide
          Bryan Pendleton added a comment -

          Thanks for the writeup, Bernt! It was very clear.

          Is it possible to require less configuration on the client side? Some ideas that occurred to me included:

          • don't require ssl=on; infer this from the JDK SSL parameters being set
          • when connecting, always first attempt an SSL connection; if that fails, fall back to a clear connection

          I don't think it's a problem to require configuration tasks on the server side, but it would be nice if the client had fewer knobs and settings, for two reasons:

          • in general, there are many more clients than there are servers (1 server, many clients)
          • clients may be deployed to environments where there is less availability of system administration resources

          In the past I've noticed that it is quite hard to get SSL configuration correct. Web browsers seem to have achieved reasonable success partly because the only thing they require, for many situations, is changing "http" to "https". It would be nice if we could come up with something that was equivalently trivial for the client to perform.

          Show
          Bryan Pendleton added a comment - Thanks for the writeup, Bernt! It was very clear. Is it possible to require less configuration on the client side? Some ideas that occurred to me included: don't require ssl=on; infer this from the JDK SSL parameters being set when connecting, always first attempt an SSL connection; if that fails, fall back to a clear connection I don't think it's a problem to require configuration tasks on the server side, but it would be nice if the client had fewer knobs and settings, for two reasons: in general, there are many more clients than there are servers (1 server, many clients) clients may be deployed to environments where there is less availability of system administration resources In the past I've noticed that it is quite hard to get SSL configuration correct. Web browsers seem to have achieved reasonable success partly because the only thing they require, for many situations, is changing "http" to "https". It would be nice if we could come up with something that was equivalently trivial for the client to perform.
          Hide
          Dyre Tjeldvoll added a comment -

          I don't know much about security or SSL but the func spec looked good to me. Maybe a deadline for making comments would motivate more people to present their views.

          Show
          Dyre Tjeldvoll added a comment - I don't know much about security or SSL but the func spec looked good to me. Maybe a deadline for making comments would motivate more people to present their views.
          Hide
          Bernt M. Johnsen added a comment -

          Uploaded SSL func.spec. Coments are welcome.

          Show
          Bernt M. Johnsen added a comment - Uploaded SSL func.spec. Coments are welcome.
          Hide
          Knut Anders Hatlen added a comment -

          Thank you for contributing this patch, Bernt! I think it is a great improvement. As you said, there is room for further improvement by integrating it into the user interfaces, but I think that the patch could be useful for many users even in its current state. When the build issues have been resolved, I would say +1 to check in these changes. The other improvements could come later if someone feels an itch.

          Show
          Knut Anders Hatlen added a comment - Thank you for contributing this patch, Bernt! I think it is a great improvement. As you said, there is room for further improvement by integrating it into the user interfaces, but I think that the patch could be useful for many users even in its current state. When the build issues have been resolved, I would say +1 to check in these changes. The other improvements could come later if someone feels an itch.
          Hide
          Bernt M. Johnsen added a comment -

          When DERBY-2120 and DERBY-2121 is fixed, I will make a patch which is independent of the optional JSSE package for JDK 1.3

          Show
          Bernt M. Johnsen added a comment - When DERBY-2120 and DERBY-2121 is fixed, I will make a patch which is independent of the optional JSSE package for JDK 1.3
          Hide
          Bernt M. Johnsen added a comment -

          Fixed error handling in the network server so that the user is able to see what the problem actually is.

          I won't do anything more with this issue until the JDK 1.3 build-dependencies are removed from the network server and client.

          Show
          Bernt M. Johnsen added a comment - Fixed error handling in the network server so that the user is able to see what the problem actually is. I won't do anything more with this issue until the JDK 1.3 build-dependencies are removed from the network server and client.
          Hide
          Bernt M. Johnsen added a comment -

          What's missing now is tests and documentation.

          Some possible enhancements:
          1) Integrate into the user interface of derby (derby proeprties, jdbc-url properties, parameters to network start etc.)
          2) Implement the possibility of choosing another SSLSocketfactory/SSLServerSocketfactory than the default factory.

          Show
          Bernt M. Johnsen added a comment - What's missing now is tests and documentation. Some possible enhancements: 1) Integrate into the user interface of derby (derby proeprties, jdbc-url properties, parameters to network start etc.) 2) Implement the possibility of choosing another SSLSocketfactory/SSLServerSocketfactory than the default factory.
          Hide
          Bernt M. Johnsen added a comment -

          Fixed the permissions. Now derbyall runs ok.

          Show
          Bernt M. Johnsen added a comment - Fixed the permissions. Now derbyall runs ok.
          Hide
          Bernt M. Johnsen added a comment -

          BTW: the test suite does not run with this patch due to missing java.util.PropertyPermission

          Show
          Bernt M. Johnsen added a comment - BTW: the test suite does not run with this patch due to missing java.util.PropertyPermission
          Hide
          Bernt M. Johnsen added a comment -

          I have implemented a first cut to SSL/TLS. This patch requires for jdk1.3 an implementation of javax.net and javax.net.ssl placed on java/tools. I used JSSE1.0.3 downloaded from http://java.sun.com/products/jsse/index-103.html

          From JDK1.4 on, JSSE is part of the JRE.

          To activate SSL I just check if system property javax.net.ssl.keyStore is defined on the server side javax.net.ssl.trustStore on the client side

          How to generate keystore and truststore with keygen is described in the JSSE Reference guide: http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.html

          I used the following commands when I generated keys and certificates, and ran with:
          keytool -genkey -alias derby -keyalg RSA -validity 7 -keystore keystore
          keytool -export -alias derby -keystore keystore -rfc -file derby.cert
          keytool -import -alias derbycert -file derby.cert -keystore truststore

          I ran my testapp the following way:

          java -Djavax.net.ssl.trustStore=truststore -Djavax.net.ssl.trustStorePassword=secret -cp derbyclient.jar:. TestApp

          and the client like this:

          java -Djavax.net.ssl.keyStore=keystore -Djavax.net.ssl.keyStorePassword=secret -jar derbyrun.jar server -p 22120 start

          The JSSE Reference defines a set of system properties which may be used to parameterize JSSE. I have so far anly used default settings.

          Feel free to experiment and comment.

          Show
          Bernt M. Johnsen added a comment - I have implemented a first cut to SSL/TLS. This patch requires for jdk1.3 an implementation of javax.net and javax.net.ssl placed on java/tools. I used JSSE1.0.3 downloaded from http://java.sun.com/products/jsse/index-103.html From JDK1.4 on, JSSE is part of the JRE. To activate SSL I just check if system property javax.net.ssl.keyStore is defined on the server side javax.net.ssl.trustStore on the client side How to generate keystore and truststore with keygen is described in the JSSE Reference guide: http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.html I used the following commands when I generated keys and certificates, and ran with: keytool -genkey -alias derby -keyalg RSA -validity 7 -keystore keystore keytool -export -alias derby -keystore keystore -rfc -file derby.cert keytool -import -alias derbycert -file derby.cert -keystore truststore I ran my testapp the following way: java -Djavax.net.ssl.trustStore=truststore -Djavax.net.ssl.trustStorePassword=secret -cp derbyclient.jar:. TestApp and the client like this: java -Djavax.net.ssl.keyStore=keystore -Djavax.net.ssl.keyStorePassword=secret -jar derbyrun.jar server -p 22120 start The JSSE Reference defines a set of system properties which may be used to parameterize JSSE. I have so far anly used default settings. Feel free to experiment and comment.

            People

            • Assignee:
              Bernt M. Johnsen
              Reporter:
              Bernt M. Johnsen
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development