[
https://issues.apache.org/jira/browse/WSS-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17414897#comment-17414897
]
Tor Ranfelt edited comment on WSS-688 at 9/15/21, 9:25 AM:
-----------------------------------------------------------
[~coheigea]
Normally errors will be printed without logging-level DEBUG, but I tried
adding <logger name="org.apache.wss4j.common.crypto" level="DEBUG"/> to my
log-configuration.
No errors presented itself even though I got a handful of "DEBUG
o.apache.wss4j.common.crypto.Merlin". (EDIT: with nothing relevant)
I can only repeat that invalid signatures are created, and that a certificate
that works in one run where it was the second unique certificate used will not
work in another run where it was the third unique certificate used. If an
invalid signature has been created with certificate X in a run then invalid
signatures will keep being created with certificate X until the program is
restarted (probably due to some cache). The first certificate being "tainted"
seems to always be either #3 or #4 (as in the third and fourth unique
certificate used).
By not reusing Merlin, but instead creating a new Merlin every time, the
problem is circumvented.
was (Author: tor):
[~coheigea]
Normally errors will be printed without logging-level DEBUG, but I tried addingÂ
<logger name="org.apache.wss4j.common.crypto" level="DEBUG"/> to my
log-configuration.
No errors presented itself even though I got a handful of "DEBUG
o.apache.wss4j.common.crypto.Merlin".
I can only repeat that invalid signatures are created, and that a certificate
that works in one run where it was the second unique certificate used will not
work in another run where it was the third unique certificate used. If an
invalid signature has been created with certificate X in a run then invalid
signatures will keep being created with certificate X until the program is
restarted (probably due to some cache). The first certificate being "tainted"
seems to always be either #3 or #4 (as in the third and fourth unique
certificate used).
By not reusing Merlin, but instead creating a new Merlin every time, the
problem is circumvented.
> Signatures created with Merlin start being invalid after changing key-store a
> few times
> ---------------------------------------------------------------------------------------
>
> Key: WSS-688
> URL: https://issues.apache.org/jira/browse/WSS-688
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Core
> Affects Versions: 2.3.2
> Environment: Java 11 (version 11.0.11.0.9)
> org.apache.cxf:cxf-rt-frontend-jaxws:3.4.4
> org.apache.cxf:cxf-rt-ws-security:3.4.4
> org.apache.cxf:cxf-rt-transports-http:3.4.4
> org.apache.cxf:cxf-rt-features-logging:3.4.4
> javax.xml.ws:jaxws-api:2.3.1
> javax.jws:javax.jws-api:1.1
> com.sun.xml.messaging.saaj:saaj-impl:1.5.3
> Reporter: Tor Ranfelt
> Assignee: Colm O hEigeartaigh
> Priority: Major
>
> In our system we can't use a static certificate because it's a service that
> many users use, and they need to use their own certificate to communicate
> with a third-party SOAP-service.
> I used to be able to change Merlin's keystore whenever a new certificate was
> needed, but after upgrading from Apache CXF 3.3.7 to 3.4.4 (and other third
> party libraries that CXF depends on) a problem arose:
> Signatures created by some certificates would be invalid. It was never the
> certificate that was the problem, but which number of replacing key-store it
> was put into.
> So for instance number 1 and 2 would be fine, but 3 would fail, and 4 would
> be fine. - After which any new key-store with either certificate 1, 2 and 4
> would keep working, but 3 would fail every time. Probably due to some cache.
> I have circumvented the problem by creating a new Merlin instance every time,
> instead of just a new key-store instance. This works because the problem
> never manifest with the first key-store.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
