Cannot create docker access object [extension (5) should not be presented in certificate_request]

[davidkarlsen]

Description

When doing a image build I get: Cannot create docker access object [extension (5) should not be presented in certificate_request]

Info

• d-m-p version : 0.33.0
• Maven version (mvn -v) : 3.6.3

• Docker version :
• If it's a bug, how to reproduce : run DIND like in attached pod yaml
• If it's a feature request, what is your use case :
• Sample project : [GitHub Clone URL]

runner.yaml.txt

Running docker cmdline (docker build, docker run etc) works fine, hence I see this as a problem with DMP.

This recently worked with the plugin, so I suspect the updated version of docker:stable-dind to affect this.

[davidkarlsen]

Might be related: https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021037.html

[davidkarlsen]

If works with dind 19.03.8-dind, and fails with 19.03.9-dind

[jepfp]

same problem here. cannot deploy anymore since version 19.03.9-dind. is there a workaround?

[knutwannheden]

For Java 11 use JDK 11.0.7+ to resolve the issue.

[jepfp]

thx @knutwannheden. Unfortunately I still got the same error message by using Oracle JDK 11.0.7

java 11.0.7 2020-04-14 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.7+8-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.7+8-LTS, mixed mode)

However: For now I was able to deploy by using TLSv1.2 (instead of TLSv1.3): set MAVEN_OPTS="-Djdk.tls.client.protocols=TLSv1.2"

[rhuss]

That's interesting, though not sure how we can fix that in the context of this plugin as it seems like a general TLS v1.3 Java support issue.

Any ideas ?

[davidkarlsen]

I haven't looked into the code but does the plugin fork a life cycle? Then we can pass system properties. Another hack might be to set sysprops and then restoring them after the ssl call

[suikast42]

For maven users <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>properties-maven-plugin</artifactId> <version>1.0.0</version> <executions> <execution> <goals> <goal>set-system-properties</goal> </goals> <configuration> <properties> <property> <!-- MAVEN_OPTS="-Djdk.tls.client.protocols=TLSv1.2"--> <name>jdk.tls.client.protocols</name> <value>TLSv1.2</value> </property> </properties> </configuration> </execution> </executions> </plugin>

[borramTAS]

I have a similar problem but with the plugin version greater than 0.33.0:

Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot create docker access object

Caused by: javax.net.ssl.SSLException: Unsupported or unrecognized SSL message

Java version: 11.0.6, vendor: AdoptOpenJDK,

<configuration> <dockerHost>tcp://127.0.0.1:22375</dockerHost> </configuration> <executions> <execution> <id>run-remote</id> <goals> <goal>run</goal> </goals>

[suikast42]

I have a similar problem but with the plugin version greater than 0.33.0:

Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot create docker access object

Caused by: javax.net.ssl.SSLException: Unsupported or unrecognized SSL message

Java version: 11.0.6, vendor: AdoptOpenJDK,

<configuration> <dockerHost>tcp://127.0.0.1:22375</dockerHost> </configuration> <executions> <execution> <id>run-remote</id> <goals> <goal>run</goal> </goals>

I don't think that's matters to fabric plugin version. It seems so that is the docker version.

[borramTAS]

I don't think that's matters to fabric plugin version. It seems so that is the docker version.

With version 0.33.0 of the fabric plugin it works fine.

[rhuss]

@borramTAS have you tried the workaround MAVEN_OPTS="-Djdk.tls.client.protocols=TLSv1.2" ? Does this help ?

[borramTAS]

Hi @rhuss, yes, I have already tried, but the result is the same, I wanted to point out that port 22375 is mapped to inner port 2375 (not TLS 2376) of a Vagrant box.

[borramTAS]

I have identified my problem (I think):

public class EnvUtil {
    ...
    public static final String DOCKER_HTTP_PORT = "2375";
    ...
    public static String convertTcpToHttpUrl(String connect) {
        String protocol = connect.contains(":" + DOCKER_HTTP_PORT) ? "http:" : "https:";
        return connect.replaceFirst("^tcp:", protocol);
    }
}

In my case the port is not the standard 2375, therefore 'tcp' is replaced with 'https', but it is not true that 22375 is in https.

[davidkarlsen]

I think this is fixed in go/java: https://github.com/golang/go/issues/35722 https://bugs.openjdk.java.net/browse/JDK-8236039