[
https://issues.apache.org/jira/browse/JCLOUDS-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14044985#comment-14044985
]
Ignasi Barrera commented on JCLOUDS-617:
----------------------------------------
Have you been able to test using such a signature algorithm with other tools,
to verify that the Chef Server (community and hosted) accepts it?
If it is accepted, instead of adding specific JCE provider algorithms in
jclouds-chef, what do you think about making the {{EncryptingPayload}}
implementation plugable, so users can set a custom one when creating the
context?
> Unable to use Chef API with JCE provider with default RSA transformation
> padding other than PKCS1
> -------------------------------------------------------------------------------------------------
>
> Key: JCLOUDS-617
> URL: https://issues.apache.org/jira/browse/JCLOUDS-617
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-chef
> Affects Versions: 1.7.2
> Reporter: Jaroslav Kylberger
> Priority: Critical
>
> After adding JSafe JCE povider to java.security I get HTTP response code 401
> and the message "Invalid signature for user or client '<chefClient>'" from
> chef server when trying to connect using jclouds-chef api. The reason is that
> this provider generates the signature using RSA algortihm with different mode
> and/or padding that is used for decryption on chef server (and standard
> SunJCE). The generated signature is then considered bad by the chef server.
> The problem is in method org.jclouds.chef.filters.SignedHeaderAuth#sign which
> uses org.jclouds.io.payloads.RSAEncryptingPayload from jcloud-core. This
> class does not specify the mode and padding of RSA transformation and thus
> provider defaults are used.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
