ssl-rev666.patch
ssl.patch
[QFJ-188] SSL connections don't support sending a certifcate to outgoing connections Created: 02/Jun/07 Updated: 04/Jul/07 Resolved: 16/Jun/07 |
|
| Status: | Closed |
| Project: | QuickFIX/J |
| Component/s: | Networking |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.2.0 |
| Type: | Bug | Priority: | Default |
| Reporter: | Toli Kuznets | Assignee: | Toli Kuznets |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
ssl-rev666.patch
ssl.patch
|
| Description |
|
Some brokers require to send SSL certificates for outgoing connections (ie from QFJ client to SSL FIX destination on the server side) Currently, as of 1.1.0, QFJ only supports sending certs on the "accepting" side of a connection, but not on a intiating side. I'm attachinga patch that allows for the initiating connection to send out certs as well, ie to specify a keystore name/password for the initating SSL context. |
| Comments |
| Comment by Toli Kuznets [ 02/Jun/07 ] |
|
proposed patch with changes to be applied in core. |
| Comment by Toli Kuznets [ 08/Jun/07 ] |
|
First patch is a diff to 1.1.0 codebase |
| Comment by Toli Kuznets [ 11/Jun/07 ] |
|
Initial set of code checked in with rev 675. need to add more acceptance tests |
| Comment by Jörg Thönnes [ 15/Jun/07 ] |
|
Toli, did you made any progress with your acceptance tests? Cheers, Jörg |
| Comment by Jörg Thönnes [ 15/Jun/07 ] |
|
Toli, did you made any progress with your acceptance tests? Cheers, Jörg |
| Comment by Toli Kuznets [ 15/Jun/07 ] |
|
not yet, sorry, got sidetracked by things at work. |
| Comment by Jörg Thönnes [ 15/Jun/07 ] |
|
never mind, toli. Actually I get always "sidetracked" by things at work. Since I need some of the planned 1.1.1 feature for a customer installation, I am eager to see it released. Cheers, Jörg |
| Comment by Toli Kuznets [ 16/Jun/07 ] |
|
So i think it's not an acceptance test that we need but another testcase in quickfix.mina.ssl.SecureSocketTest that verifies that the "client" initiator also sets up a valid SSL context that has the specified keystore/pwd. the SecureSocketTest does go through the new code i've written. the major change to fix this bug was to have the initiator code to create an SSLContext with the keyManager instead of null as before, and the SecureSocketTest goes through this code. The test i ended up writing is a bit of an anti-test. There's no easy to get into the data structures of the client initiator code to verify that the right SSL context is created. so instead, i supply a bogus password that causes an error during the client initiator start since the SSL context can't be initialized. That verifies that the code goes through the same codepath of using/initializing the keystoreManagers when creating the SSL context (which was the change) so i think that may be enough. Steve, let me know if you can think of better ways to test this. checked in rev |
| Comment by Toli Kuznets [ 16/Jun/07 ] |
|
unit test checked in rev 679 |