milux
commented
9 months ago Hello Christos,
since the CH is not in particularly high demand these days, we do support on an best-effort basis here.
It seems you invested quite some effort into debugging this, so I will try to invest some time to hopefully sort out this issue.
I share your assumption about the certificate/DAT problem. At least one root problem seems to lie here:
Caused by: de.fhg.aisec.ids.idscp2.api.error.DatException: Fingerprint of peer certificate (ad17e1788815205c21497e6d36a324461c69a1b7e5c558c378fb7df79c5f00a7) does not match any fingerprint from DAT ([bdc48d7e957b458639e02aa409cb9123956a4bb7565c97d6e03a59421208209c]).
This error indicates a mismatch between the fingerprint of the client certificate and the fingerprint that was embedded into the issued DAT. You can "override" this fingerprint with that one of your custom transport certificate within the DAPS driver configuration.
In the TC example XMLs you will find this:
<bean id="rootDaps" class="de.fhg.aisec.ids.idscp2.beans.AisecDapsDriverFactoryBean">
<property name="dapsUrl" value="${connector.daps-url}"/>
<property name="dapsSslParameters" ref="rootClientSslContext" />
<property name="transportCertificatesParameters" ref="rootClientSslContext" />
</bean>dapsSslParameters is used for authentication against the DAPS, whereas transportCertificatesParameters MAY refer to a different SSL context with your certificates for transport TLS. Typically, these are the same, but they can differ. In your case, they seem to do so, probably due to the changes you mentioned.
You also have to "activate" this bean this for the MP protocol within /etc/application.yml like so:
ids-multipart:
daps-bean-name: rootDapsWhen doing this properly, the AISEC DAPS driver should pick up your transport certificate and include its actual fingerprint into the DAT request, hopefully resulting in a DAT with the right fingerprint. Good luck!
christos-aslamatzidis
kragall
Hello, My name is Christos Aslamatzidis from European Dynamics S.A. We try to test and configure the Clearing House Service because of the need to explore it and implement it in a project called Enershare.
So far, we have followed the documentation and we have deployed the CH. Our docker-compose.yaml is this :
Running the above docker-compose all containers start without issues. Our next though was to test our deployment using the integration tests that were provided in Clearing House Processors following the documentation
Please note that we have changed the host from
Watching Closely the code of clearing house we observe that provider-core has been replaced with tc-core-server. After this modification we were able to reach in some point our CH installation ; however integrated tests fail.
below are the logs of our tests: The common error is this:
The logs of TC :
The logs of logging Service :
The above logs are indicative parts of the our actual logs.
If you need entire logs please inform me.
What we are missing to pass the tests successfully?
In some point I can understand that the errors are relevant with certificates.
In docker-compose, we use service-keystore.p12 and truststore.p12 existing under clearing-house-processor in intTest folder. Also we have try both https://daps-dev.aisec.fraunhofer.de/ and https://daps.aisec.fraunhofer.de/ in many versions (v3 ,v4).
We will appreciate your help for resolving this issue and your support to make the next steps to be closer to a production CH environment.
Thank you in advance.