[
https://issues.apache.org/jira/browse/MTOMCAT-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13729584#comment-13729584
]
Aaron Pelton edited comment on MTOMCAT-221 at 8/5/13 3:49 PM:
--------------------------------------------------------------
Has there been any progress on this? I too am encountering this issue where our
environment requires client-auth, and therefore the tomcat7-maven-plugin must
be capable of doing a deploy/redeploy goal with a -Djavax.net.ssl.keyStore
argument passed to maven. With ssl debug on, I see that the keystore is never
accessed. I'm currently using Maven 3.0.4 and saw another post about this
maven version having issues with SSL arguments. Chris mentions above that
3.0.5 did not work either. I see that 3.1.0 is now available, however, it says
it's using wagon 2.4 which Maven 3.0.5 was doing. I see that this plugin is
using Apach HTTP Client under the covers. I don't have much experience with
that library, but from what I saw in the source code, it has it's own
SocketFactory implementation different from the default one that ships with
Java. Additionally, it appears by default it does not respect Java System
Properties. There is a different constructor to take Keystore information which
may need to be called out explicitly? Or, somewhere before TomcatManager enters
into the HTTPClient code, you may need to provide some flag to use the
SSLSocketFactory.createSystemSSLContext() rather than the default
createSSLContext()? For the time being, as a work around, I can only think to
have Jenkins run a shell script to SCP over the new artifact, and then SSH and
move it to the tomcat webapps folder.
Using JDK 1.7 and CentOS x64
was (Author: apelton):
Has there been any progress on this? I too am encountering this issue where
our environment requires client-auth, and therefore the tomcat7-maven-plugin
must be capable of doing a deploy/redeploy goal with a -Djavax.net.ssl.keyStore
argument passed to maven. With ssl debug on, I see that the keystore is never
accessed. I'm currently using Maven 3.0.4 and saw another post about this
maven version having issues with SSL arguments. Chris mentions above that
3.0.5 did not work either. I see that 3.1.0 is now available, however, it says
it's using wagon 2.4 which Maven 3.0.5 was doing. I see that this plugin is
using Apach HTTP Client under the covers. I don't have much experience with
that library, but from what I saw in the source code, it has it's own
SocketFactory implementation different from the default one that ships with
Java. Additionally, it appears by default it does not respect Java System
Properties. There is a different constructor to take Keystore information which
may need to be called out explicitly? Or, somewhere before TomcatManager enters
into the HTTPClient code, you may need to provide some flag to use the
SSLSocketFactory.createSystemSSLContext() rather than the default
createSSLContext()? For the time being, as a work around, I can only think to
have Jenkins run a shell script to SCP over the new artifact, and then SSH and
move it to the tomcat webapps folder.
> Deploy fails if server requires client-auth
> -------------------------------------------
>
> Key: MTOMCAT-221
> URL: https://issues.apache.org/jira/browse/MTOMCAT-221
> Project: Apache Tomcat Maven Plugin
> Issue Type: Bug
> Components: tomcat7
> Affects Versions: 2.0, 2.1
> Environment: Ubuntu 12.04, OpenJDK1.6
> Reporter: Chris Owens
> Assignee: Olivier Lamy (*$^¨%`£)
> Labels: certificate, deploy, maven, ssl
>
> The tomcat7-maven-plugin fails to deploy to a server that requires client
> authentication. Running with -Djavax.net.ssl.debug=all reveals that maven
> never opens the keystore file.
> Tried: Maven 3.0.4 and 3.0.5, both as distributed and with the replacement
> wagon-lightweight-http jar mentioned in WAGON-372. Tried with versions 2.0
> ad 2.1 of the tomcat7-maven-plugin.
> Very likely related: https://jira.codehaus.org/browse/WAGON-372
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
