Error registering

[milan0v]

curl -v -H "Content-Type: application/json" -X POST --data '{"redirectUris":["https://dev-api-symblepay.io/register"],"roles":["PSP_AI","PSP_PI"],"name":"dev-api-symblepay.io"}' --cacert C:/Users/User/Downloads/cacert.pem --cert qwac.crt --key qwac.key https://sandbox.openbanking.prod.lunar.app/tpp

Trying 52.209.139.169... TCP_NODELAY set Connected to sandbox.openbanking.prod.lunar.app (52.209.139.169) port 443 (#0) ALPN, offering h2 ALPN, offering http/1.1 Enter PEM pass phrase: Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@strength successfully set certificate verify locations: CAfile: C:/Users/User/Downloads/cacert.pem CApath: none TLSv1.2 (OUT), TLS handshake, Client hello (1): TLSv1.2 (IN), TLS handshake, Server hello (2): TLSv1.2 (IN), TLS handshake, Certificate (11): TLSv1.2 (IN), TLS handshake, Server key exchange (12): TLSv1.2 (IN), TLS handshake, Request CERT (13): TLSv1.2 (IN), TLS handshake, Server finished (14): TLSv1.2 (OUT), TLS handshake, Certificate (11): TLSv1.2 (OUT), TLS handshake, Client key exchange (16): TLSv1.2 (OUT), TLS handshake, CERT verify (15): TLSv1.2 (OUT), TLS change cipher, Client hello (1): TLSv1.2 (OUT), TLS handshake, Finished (20): TLSv1.2 (IN), TLS handshake, Finished (20): SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 ALPN, server accepted to use h2 Server certificate: subject: CN=sandbox.openbanking.prod.lunar.app start date: Jun 7 10:56:56 2023 GMT expire date: Sep 5 10:56:55 2023 GMT subjectAltName: host "sandbox.openbanking.prod.lunar.app" matched cert's "sandbox.openbanking.prod.lunar.app" issuer: C=US; O=Let's Encrypt; CN=R3 SSL certificate verify ok. Using HTTP2, server supports multi-use Connection state changed (HTTP/2 confirmed) Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 Using Stream ID: 1 (easy handle 0x256cf7d4110) POST /tpp HTTP/2 Host: sandbox.openbanking.prod.lunar.app User-Agent: curl/7.55.1 Accept: / Content-Type: application/json Content-Length: 104

Connection state changed (MAX_CONCURRENT_STREAMS updated)! We are completely uploaded and fine < HTTP/2 400 < date: Thu, 13 Jul 2023 11:27:23 GMT < content-type: text/html < content-length: 208 <

400 Bad Request The SSL certificate error nginx * Connection #0 to host sandbox.openbanking.prod.lunar.app left intact

[milan0v]

I also tried wget and I'm getting --2023-07-19 11:18:27-- (try: 2) https://tpp.openbanking.prod.lunar.tech/tpp Connecting to tpp.openbanking.prod.lunar.tech (tpp.openbanking.prod.lunar.tech)|52.214.160.186|:443... connected. Unable to establish SSL connection.

I have the pfx certificate and I tried extracting the crt and key with those two sets of commands and both don't work:

openssl pkcs12 -in qwac.pfx -out qwac2.key -passin pass:somepass-passout pass:somepass openssl pkcs12 -in qwac.pfx -nokeys -out qwac2.crt -passin pass:somepass-passout pass:somepass

openssl pkcs12 -in qwac.pfx -nocerts -out qwac2.key -passin pass:somepass-passout pass:somepass openssl pkcs12 -in qwac.pfx -clcerts -nokeys -out qwac2.crt -passin pass:somepass-passout pass:somepass

Are there any requirements what should those crt and key files contain?

[hoeg]

Hi @milan0v, would it be possible for you to share your certificate with us? this way we can easily rule out of the issue is in the cert or if we have a bug on our end :)

[milan0v]

We prefer not to share it, are there any steps we might take in order to make sure?

[hoeg]

We only need the public information of the certificate. We do not want your private key or anything like that! The public certificate is the only thing we need. There are multiple places this can break so letting me run it on our side will massively speed up the process :) If you could make it available somewhere we can get it and run our checks on it.

[milan0v]

Can I send it to peter.steffensen@gmail.com ?

[milan0v]

Hey @hoeg, I sent the certificate long ago but I have no answer. I sent another email on Tuesday. Can you take a look? Thanks

[hoeg]

Your certificate does not seem to be valid for PSD2 access production access. Please provide a valid QWAC certificate to get access.

[milan0v]

Hi @hoeg, this is a test certificate issued by Microsec that is a European validated eidas issuer. Why it's not valid?

[hoeg]

I appreciate that Microsec is a validated EIDAS issuer, but that does not mean that all certificates issued by them are EIDAS certificates. They must be issued by specific CAs that Microsec controls.

Issuer
  C  = HU
  L  = Budapest
  O  = Microsec Ltd.
  OU = e-Szigno CA
  CN = e-Szigno Test CA3

is not on the list of trusted certificates that are valid as QWAC certificate issuers. Please consult the Trusted Services list here: https://eidas.ec.europa.eu/efda/tl-browser/#/screen/tl/HU/2

[milan0v]

Just to clarify everything: We are trying to connect to your sandbox environment before going to your production environment. We have a EiDAS issued cert from Microsec for testing purposes. This has CN = e-Szigno Test CA3 Then we have a EiDAS issues cert from Microsec for production. This has CN = Qualified e-Szigno TLS CA 2018 For your production environment, I understand I should use this endpoint: https://tpp.openbanking.prod.lunar.tech/tpp For sandbox your documentation specify I should use this https://sandbox.openbanking.prod.lunar.app/ But it returns a 400 nginx error. Can you please answer the following: Are the endpoints above correct and can you confirm that they should work. When connecting to your sandbox environment do you require a QWAC cert issued for production and present on this list: https://eidas.ec.europa.eu/efda/tl-browser/#/screen/tl/HU/2 or do you just require it to be a valid EiDAS cert.

[milan0v]

@hoeg, can you collaborate on this?

[hoeg]

The sandbox url is https://tpp.openbanking-sandbox.prod.lunar.tech, I can see we have an issue with the docs there. We require a valid QWAC certificate that is on the trusted list.

[milan0v]

Hi @hoeg, I tried with our production certificate and this is what I get:

[Crevil]

Hi @milan0v .

Great level of detail you provide 👍 It looks as if you are not hitting the right path on that request. Notice the /tpp endpoint should be targeted as documented.

We acknowledge that this is not super clear from the documentation and will release an update shortly making this more clear.

Can I get you to retry on the correct path?

[milan0v]

Hi @Crevil, same result:

[Crevil]

We can see the request but reject it due to an unknown signing authority. It must contain the complete certificate chain specifically it must contain leaf, intermediate, and root in that order.

Can I get you to forward the contents of the provided certificate in argument --certificate? Either here or to me directly at bso@lunar.app. Either way, it is the public certificate so should not be a problem to share.

[milan0v]

I have a pfx file and I'm trying to generate the .crt with openssl commands, do you know any tool that can help me with that ?

[Crevil]

I'm afraid that is out of scope for the support I can provide you. Hopefully, you can find someone with knowledge of that specific format to assist you elsewhere.

Please circle back when you have the certificates ready for sharing and we will look in to it.

[milan0v]

I've sent you the certificate that I'm trying to use, can you take a look?

[Crevil]

Thank you for the additional details and certificate.

We have verified your provided certificate and we can confirm that you are not providing the full certificate chain. This is required before we can verify the authenticity of it. As mentioned earlier:

It must contain the complete certificate chain specifically it must contain leaf, intermediate, and root in that order.

[milan0v]

Hi @Crevil, I've sent you a new certificate, can you confirm that it has all needed info?

[Crevil]

Thank you. We have reviewed your information. This file also only contains a single leaf certificate.

As a hint there should be several -----BEGIN CERTIFICATE----- lines in the PEM file. One for leaf, intermediate, and root. 🙏

[milan0v]

Hi @Crevil, I've sent you a new certificate file, can you review it? Thanks

[Crevil]

@milan0v I have not received anything yet. Can you confirm it was sent to bso@lunar.app?

[Crevil]

Thank you for the provided details. From a brief look, this looks correct. Please attempt a new registration to see if it works as expected. Please post any details including timestamps for requests if the problem persists.

[milan0v]

[Crevil]

Hi @milan0v,

We believe we are making progress. We have made a change on our end that hopefully fixes your issue. Can I get you to try again?

[milan0v]

Hi @Crevil, nothing changed:

[Crevil]

Hi 👋

We will do some more digging. As we are in the holiday season we might not get back to you before the week of January 1st, 2024.

[Crevil]

Hi @milan0v

I hope you've had time to rest during the holiday season and happy new year 🎉

We have investigated your issue further and come to the following conclusion. It seems that when using the wget tool you need to specify the CA in a separate argument --ca-certificate.

‘--ca-certificate=file’
Use file as the file with the bundle of certificate authorities (“CA”) to verify the peers. The certificates must be in PEM format.

Without this option Wget looks for CA certificates at the system-specified locations, chosen at OpenSSL installation time.

You can test this out by pointing it to the same all.pem file you are using for --certificate although the more correct setup would be to split this into two files.

wget --certificate=all.pem --ca-certificate=all.pem ...

If you want to use minimal files you will ned to split up the all.pem file to have the leaf certificate in one file leaf.pem and the intermediate and root in another inter-root.pem. You would then be able to run it like this.

wget --certificate=leave.pem --ca-certificate=inter-root.pem ...

Please let us know if the issue persists after applying above.

[milan0v]

Hi @Crevil, Happy New Year!

[Crevil]

I can see that your arguments are using a full path in the certificate arg and a relative path in ca-certificate. Is that on purpose?

[milan0v]

It doesn't matter:

[Crevil]

All right. Thanks. We are making progress. The 400 Bad Request means that the certificate chain is now valid and accepted. 🎉 Let me get back to you on what the error is. The 400 could mean several things so I'll get back to you.

[Crevil]

Could you attempt to set the --debug flag? That will show you more about what might be wrong.

[milan0v]

[Crevil]

It looks as if your shell is somehow not providing the payload correctly to wget. We notice the debug information shows:

---request end---
[BODY data: '{redirectUris:[

That means your payload does literally contain ' as the first character. It should look like this according to some internal tests we did with wget.

[BODY data: {"redirectUris":[

We don't know what shell environment you are using so this is somewhat hard for us to assist in. One idea is to avoid the ' character and escape your JSON instead.

wget --post-data="{\"redirectUris\":...

[milan0v]

[Crevil]

Hurray 🎉 You have now registered correctly in the sandbox environment.

It seems wget saves your credentials in a tpp file somewhere based on your screenshot. The response body of that request contains your client id and secret.

[milan0v]

Woo-hoo, I found them, thanks a lot. 🥳

[Crevil]

Great. 🤘 Happy hacking 🎉