SSL certificate problem - again

[dpickerel]

Hi,

This is the same problem as last year.
http://community.developer.authorize.net/t5/Integration-and-Testing/Intermittent-SSL-errors-with-AIM...

I'm using PHP and curl() to connect. With the CURLOPT_SSL_VERIFYPEER option set to true I'm failing with a

"cURL error: SSL certificate problem, verify that the CA cert is OK.
Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed" error.

I've connected to other servers via SSL and our side verifies fine It's just https://secure.authorize.net/gateway/transact.dll

Last time it was apparently a new server with a bad cert..

-Don-

[RichardH]

Hello @dpickerel 

What OS are you using and have you recently installed any patches or updates to the environment you are using?

The SSL certificate on secure.authorize.net is not new—we’ve had it in place for a year and it’s good for another year.

Richard

[dpickerel]

Sorry, I keep forgetting to reply. But i've had another site on the same server break today with the error
"cURL error: SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed"

This is a Redhat linux server running a version of Apache 2.2 and php 5.3. The curious thing is that this server has several ecommerce sites wiht certificates (each on it's own ip) but only one site at a time breaks.

I don't have root on this server, but the hosting company has excellent sys-admins and reported no new patches last time.

Turning off CURLOPT_SSL_VERIFYPEER allows transactions to go through but is clearly not a fix.

-Don Pickerel-

[Lilith]

That should have been a temporary issue--we had the new EnTrust certificate chain installed but apparently not all merchants support the new certificate chain.

While we've added the old certificate chain for EnTrust, we do recommend merchants install the new certificate chain as well. The old chain expires in 2017 but installing the new chain soon is recommended.

[dominic108]

I don't think that the current SSL situation  is a temporary issue that do not require action from Authorize,net.  On the contrary, it is going to get worst.   The root (sha1 thumbprint: 99 a6 9b e6 1a fe 88 6b 4d 2b 82 00 7c b8 54 fc 31 7e 15 39) of the current chain certificate for https://secure.authorize.net/gateway/transact.dll uses an unsecure 1024 bits RSA key.  Mozilla has removed this certificate from its list of trusted certificates :  https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/   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, I know that 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 insert the old certificate (2048 bits)   in my CA bundle to solve the problem.  I did not insert the root certificate, which uses the 1024 bits key.  However, I remain concerned that perhaps this old certificate was compromised.  I discuss the issue here :   

 http://stackoverflow.com/questions/29103613/how-comes-authorize-net-uses-a-certificate-that-is-signe...

[RichardH]

Please see http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Authorize-Net-Begins-In... for more details.

Richard

[subimage]

We've just started seeing this in production yesterday on our Debian Wheezy machines that have been upgraded to the latest openSSL.

What has been changed? When will this be fixed? It's affecting our customers trying to process payments with Authorize.net

[Lilith]

@subimage Could you check your Debian install's ca-certificates for updates, please? I suspect you got a recent update to that package that removed the EnTrust 1024-bit CA cert, which we currently use and are working to replace.

If ca-certificates was updated, I believe these commands should let you re-install the EnTrust 1024-bit CA cert for the time being, in this order:

1. sudo curl -o /usr/local/share/ca-certificates/entrust_ssl_ca.crt https://www.entrust.net/downloads/binary/entrust_ssl_ca.cer
2. sudo update-ca-certificates

[subimage]

My servers are updated to the latest. Running the commands you've given changes nothing for me unfortunately. Still getting the same error with my code that accesses Authorize.net.

What's the timeframe for replacing the outdated certificate — so that my code starts working again and my customers can actually use Authorize.net to process payments? Our software is responsible for hundreds of Authorize.net merchants' ability to get paid from their customers.

Moreover, getting this output from "update-ca-certificates"

$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs... WARNING: Skipping duplicate certificate Entrust.net_Secure_Server_CA.pem
WARNING: Skipping duplicate certificate Entrust.net_Secure_Server_CA.pem
2 added, 1 removed; done.
Running hooks in /etc/ca-certificates/update.d....
Adding debian:Entrust.net_Secure_Server_CA.pem
Adding debian:entrust_ssl_ca.pem
Removing debian:Entrust.net_Secure_Server_CA.pem
done.
done.

[Lilith]

There are infrastructure concerns that isn't going to allow us to rush certificate updates. Please check to make sure your solution has the EnTrust 1024-bit CA Certificate installed, anywhere your solution might use it.