Skip to content

Issue 85: SSLContext configurable#92

Merged
nakomis merged 1 commit intomasterfrom
issue-85
Jan 23, 2019
Merged

Issue 85: SSLContext configurable#92
nakomis merged 1 commit intomasterfrom
issue-85

Conversation

@aledsage
Copy link
Member

No description provided.

@nakomis
Copy link
Contributor

nakomis commented Jan 23, 2019

LGTM; Will merge along with other PRs shortly

@nakomis nakomis merged commit a172a58 into master Jan 23, 2019
EXTERNALCOREWORKS pushed a commit to EXTERNALCOREWORKS/winrm4j that referenced this pull request May 9, 2019
…uncycastle (in addition to the common JKS) as the provider.

On winrm4j 0.6.1, new changes were introduced by your team:
Due to this issue: cloudsoft#80
Commits: cloudsoft#92
cloudsoft#93
Which allowed us to propagate the:
* SSLContext (which mostly contains the protocols and as well as the security provider being defined, either JKS or bouncycastle or whatever, vital for FIPS compliance) and the 
* SSLSocketFactory (which contains the cipher suites to use, vital for FIPS compliance).   
So when we tried to do it by just passing over both the SSLContext and the SSLSocketFactory, we encountered the following open issue which we had already reported to your team: cloudsoft#97
So in order to fix it:
-Based on the SSLSocketFactory (if present), we are just propagating out of it, the cipher suites to the Apache cxf TLSClientParameters class which later on will use such ciphers along with the provider for the secure communication.
- Based on the SSLContext, we are passing over the whole SSLContext to the TLSClientParameters, but we are also passing the protocols in the Apache CXF TLSClientParameters, so that the communication can be established successfully and FIPS compliant.
There could be better ways to propagate only those parameters (like allowing to pass the ciphers and protocols as new params besides the SSLContext and the SSLSocketFactory), but the fact that how it got implement in 0.6.1 was not stable enough is true, meaning that by incorporating this changes, the client application should only care to propagate both the SSLContext and the SSLSocketFactory and the winrm4j library will use only what's really needed :).
Hope you can absorb this changes that will benefit a lot your API, there is no single API similar like yours (like overthere or so) that actually supports FIPS, so this will be a great WIN for your software.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants