• Fix from docker-java 2.1.1 bug PrivateKeyInfo cannot be cast to PEMKeyPair #441 without tests.
• My Ecdsa fix that is covered with tests, but they neet to be ported from https://github.com/KostyaSha/yet-another-docker-plugin/tree/master/yet-another-docker-its
• methods more flexible for other use cases
• try-with-resources

This change is

Current coverage is 23.11%

Merging #529 into master will decrease coverage by -0.02% as of 64f1176

@@            master    #529   diff @@
======================================
  Files          295     295       
  Stmts         6102    6112    +10
  Branches       530     537     +7
  Methods          0       0       
======================================
+ Hit           1412    1413     +1
  Partial         83      83       
- Missed        4607    4616     +9

Review entire Coverage Diff as of 64f1176

Powered by Codecov. Updated on successful CI builds.

@marcuslinke how do you handle certs? I have shell scripts that generates server/client certs, but they should be tied to some hostname/address. I used 192.168.99.100 for my docker-machine but it not ideal.
It should be possible generate certs during container build and then attach volume to DIND + fetch client file from this DND and then try execute connection. Would it be right way?

@KostyaSha Currently I manage IP/certs manually in my local ~/.docker-java.properties. So when IP of docker-machine VM changes I have to modify it. So it looks something like this currently:

DOCKER_HOST=tcp://192.168.99.102:2376
DOCKER_CERT_PATH=/Users/marcus/.docker/machine/machines/docker-1.10.2

#DOCKER_HOST=tcp://192.168.99.105:2376
#DOCKER_CERT_PATH=/Users/marcus/.docker/machine/machines/docker-1.8.1

#DOCKER_HOST=tcp://192.168.99.106:2376
#DOCKER_CERT_PATH=/Users/marcus/.docker/machine/machines/docker-1.9.1

However when working with DIND we need to generate certs that are tied to the current DOCKER_HOST ip, right? This could be done when starting the DIND container I think. After that we could copy them via https://docs.docker.com/engine/reference/api/docker_remote_api_v1.22/#get-an-archive-of-a-filesystem-resource-in-a-container to our local java env. WDYT?

First of all i found that openssl tool may differ, so we should run generation in reproducible env.
Host would be hostname from outer dockerClient connection (i like @JunitRule/@ExternalResource instead of abstract subclasses).

dind easily runs, but i don't remember about port in cert validability... I could tre reimplement my tests.

And this wouldn't work because netty uses sslcontext now?

Found, it wrapped now.. Maybe let's merge without tests? Too much time left...