Saturday 15 August 2015

How comes authorize.net uses a certificate that is signed with a CA that is not in the well known curl.haxx.se/ca/cacert.pem list? -


URL for transaction with authorize.net, if we go to this URL and observe the certificate, then We can see that it is signed by the CN = Entrust Certification Authority - L1E with the intermediary certificate, valid till 10 December 201 9 17:25:43. However, if you go to the entrustrite site, you will see that their intermediate certificates are valid with the same NN on 11 November 2021 23:00:59 - so this is a more recent version. These two intermediary certificates do not share the same root certificate. In my case, there was a problem because in the famous list used by Curls in my configuration settings, the root version of the certificate was not included in the certificate. It includes only the root certificate for the new version. When I manually added the root certificate to the old version in the file, the problem was resolved. However, I have to understand what really happened wrong. Should there be a root certificate for both versions in the list? Authorize.net should update its certificate so that it matches the more updated CA bundle?

Update: Now it should not be required because

< P> You can stop it from working all the time because the Ubuntu ca-certificates package has dropped support for them. The most recent update:

My colleagues and I had to face this with the client one day - their donation stopped working suddenly.

The real solution is that Authorize.net needs to update its certificate. However, in the meantime, you can only add a missing certificate, I simultaneously noted how it is here in Ubuntu:

I also have a root certificate (though unsafe However, on this), again, my hope is that it should be a short-term solution until it only gets a new certificate, but it will be a good interval.


No comments:

Post a Comment