I have to do requests to some APIs with 2-way-ssl, so every request has to by signed with our cert and private key. We uploaded our certificate to 3rd party servers which provide these APIs.
When we do request, it looks like server doesnāt know how to process it. Because their api should response error in json format and we got only this:
I tried make request with Postman (NodeJS) with same certificate and private key and it works without problem.
Any ideas where can be problem? I asked on slack and @voltone gave me some good advice but Iām a little bit lost and looks like I did something wrong.
I was thinking about the same root cause: missing intermediate certificates for the client cert. But in that case I would expect the ācert.pemā file to contain more than one certificate, and that would cause the pattern match on the first line to fail.
@quatermain are these the exact files you used with Postman? Or is there another file with additional CA certificates to go with your client certificate?
Hmm, so in that case it wouldnāt be an issue of missing intermediates.
The serverās response is not very helpful. If you make a request without client certificate at all, does the server throw a TLS alert, or do you get the same HTML error? Iām trying to understand whether the server is configured to handle mutual TLS auth issues at a higher protocol layer. Most (but not all) servers would reply with a TLS alert. Maybe everything is fine on the TLS layer, and you have a missing HTTP header (āAccept: application/jsonā ?).
There isnāt anything to try here if you do not have any intermediate CA certificatesā¦
Also you may try with curl, setting verbosity level to its maximum (-v) to determine:
if TLS client authentication is optional or disabled
if TLS client authentication actually happens
if not (which means TLS client authentication is optional), why it fails
Feel free to post it here, itās usually quite informative. Beware before posting results here, Iām donāt remember whether the debug messages contain the private key or not.
You are the winner. Their API documentation and Sandbox API use for all api calls āapplication/x-www-form-urlencodedā and their Production API use āapplication/jsonā but only for auth api call. Others look like use www-form.
FYI - API owner is group of banks, about 7 countries and 7 banks in EU. Soā¦ I will write horror/comedy book after all my NDA will end.
Update: not done, I got json response with message ID and status code 400, no other information. I thought itās working because I need id from this response. But I need consent id and not message id. But it looks like problem with their system. Not sure where can be problem when I got error with:
env:Receiverfault:MessageBlocked
or another error with message id.
So this pain is still there and I will have to resolve it ASAP . I contacted support last week so I hope they will get us something this week.
Update: support gave answer. Sandbox api use another API than production. We got new documentation for production API, so we have to update our code and test it on production.
we had to fix it. I didnāt want to change language and itās for our new product for PSD2 application. Currently we are first in country with license and a lot of customers ask for it for last year. So we have big line of customers waiting for it. Big thanks for community which help us a lot.
I like Mint and Mojito looks very good. But we are not done yet, unfortunately. We have to struggle with custom implementation of Oauth2 for every bank and make it works. We need 10 banks for beginning. Some have same API, just changed endpoint and others have custom implementations. There are about 4 main standards (Berlin Group Standard, Poland Standard, Slovakia standard,ā¦) which we have to implement to cover our regions. We hired new junior and I gave him test project where he has to implement Mint with OpenStreet Map API, so he has to learn messaging and so on. Itās very good for him to use Mint.