How comes authorize.net uses a certificate that is

Question

The URL for transactions with authorize.net is https://secure.authorize.net/gateway/transact.dll . If we visit this URL and inspect the certificate, we can see that it is signed by the intermediary certificate with CN = Entrust Certification Authority - L1E , valid to 10 décembre 2019 17:25:43. However, if you visit the Entrust site https://validev.entrust.net/, you see that their intermediary cert with the same CN is valid until 11 novembre 2021 23:00:59 - so it is a more recent version. These two intermediary certificates do not share the same root certificate. In my case, a problem occured because the well known list http://curl.haxx.se/ca/cacert.pem used by CURL in my configuration setting did not contain the root certificate for the previous version of the certificate. It contained only the root certificate for the new version. When I added the root certificate for the old version manually in the file, the problem was solved. However, I want to understand what exactly went wrong. Should have the list contained the root certificates for both versions? Should have Authorize.net updated its certificate so that it matches with the more up to date CA bundle?

Answer 1

The issue is that the root CA for https://secure.authorize.net (and perhaps other secure domains at authorize.net) is not included in the CA bundle http://curl.haxx.se/ca/cacert.pem , for good reason : if you visit the page and look at the details of the root CA in the certificate path you will note that the Sha1 thumbprint is 99 a6 9b e6 1a fe 88 6b 4d 2b 82 00 7c b8 54 fc 31 7e 15 39 . A search on the Internet will lead you to this page https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/ , which explains that this root certificate is not trusted anymore. It uses an unsecure 1024 bits RSA key. The certificate just below in the chain (sha1 thumbprint be e7 72 b3 19 0a c8 4b f8 31 f9 60 7d 98 89 ec 6a 96 6c 16 ) uses a 2048 RSA key, but it is not the most recent version. For example, Google switched to a more recent version (sha1 thumbprint: B3 1E B1 B7 40 E3 6C 84 02 DA DC 37 D4 4D F5 D4 67 49 52 F9) https://android.googlesource.com/platform/libcore.git/+/078e25d731728ba52e2940fbca31b3d6d7a56fad . From my own experience and as mentioned by Andrew, Ubuntu recently dropped support for certificates in this chain and curl would not connect to https://secure.authorize.net/gateway/transact.dll anymore. Unfortunately, Authorize.net still uses the old version. So, I was forced to use the old certificate (2048 bits) to solve the problem. I did not insert the root certificate, which uses the 1024 bits key. The temporary solution is to have CURL trusts the certificates below the root (not the unsafe root). To do that in Ubuntu, I followed instructions provided in the configuration file \etc\ca-certificates.conf .

# This file lists certificates that you wish to use
...
# Certificates should be installed under /usr/share/ca-certificates
# and files with extension '.crt' is recognized as available certs.

In my case, I added all the certificates below the root (after a careful check of their sha1 thumbprint), listed them in the config file as instructed and simply executed :

sudo update-ca-certificates –fresh

This adds the certificates in /etc/ssl/certs/. We need to make sure that CURL knows this location. So, I added the following options in the CURL script :

curl_setopt($ch, CURLOPT_CAPATH, "/etc/ssl/certs"); 

To verify that it works, you can execute

openssl verify -CApath /etc/ssl/certs /path/to/signed/certificate.crt

A similar question was asked here : Drupal Curl SSL Certificate Error

Answer 2

Update: this should no longer be necessary because Authorize.net has updated its production servers' certificates.

You may have found this to stop working all of a sudden because the Ubuntu ca-certificates package just dropped support for them in the most recent update:

http://changelogs.ubuntu.com/changelogs/pool/main/c/ca-certificates/ca-certificates_20141019ubuntu0.12.04.1/changelog

http://changelogs.ubuntu.com/changelogs/pool/main/c/ca-certificates/ca-certificates_20141019ubuntu0.14.04.1/changelog

My coworkers and I encountered this with a client just the other day--their donations suddenly stopped working.

The real solution is that Authorize.net needs to update their certificate. However, in the meantime, you can just add the one missing certificate. I put together notes on how to do this in Ubuntu here:

https://aghstrategies.com/content/SSL3_GET_SERVER_CERTIFICATE

I also stashed the one root certificate (insecure though it may be) at https://github.com/agh1/ca-certificate-for-authorize.net

Again, my hope is that this only needs to be a short-term solution until they get a new certificate, but this will be a good stop-gap.