Certificate issues for different 3d secure server

[Dave Morley]

I bank with Santander. This is one of the biggest banks in Europe. However their 3d secure site will not allow access from Software center.

USC Version:
5.2.5

Steps to reproduce:
1. With a Santander Visa debit card open usc
2. Select an app to purchase
3. Click on Buy...
4. Fill out the Payment/Address form
5. Confirm the details are correct
6. Hit the SSL Handshake Error.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: software-center 5.2.5
ProcVersionSignature: Ubuntu 3.2.0-30.48-generic 3.2.27
Uname: Linux 3.2.0-30-generic x86_64
NonfreeKernelModules: fglrx
ApportVersion: 2.0.1-0ubuntu12
Architecture: amd64
Date: Wed Aug 29 15:34:00 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: software-center
UpgradeStatus: No upgrade log present (probably fresh install)

[Michael Vogt (mvo)]

Looks like this time gnutls is rather unhappy:

$ gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt --print-cert -p 443 www.securesuite.co.uk
Processed 153 CA certificate(s).
Resolving 'www.securesuite.co.uk'...
Connecting to '62.73.172.27:443'...
*** Verifying server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.

$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -port 443 -host www.securesuite.co.uk
...
    Verify return code: 0 (ok)

[Michael Vogt (mvo)]

The gnutls source code reports "GNUTLS_CERT_INVALID" (status 2) and it appears like its failing inside _gnutls_verify_certificate2() after "find_issuer()"is called on the second ceritificate in the chain.

[Michael Vogt (mvo)]

Subscribing the security team hoping to get some input as I'm (still!) not fluent in reading the output of gnutls-cli :/

[Marc Deslauriers (mdeslaur)]

Looks like the intermediate certificates are out of order, and gnutls doesn't like out of order certificates (cert #1 and cert #2 are inverted):

mdeslaur@mdlinux:~$ gnutls-cli --insecure --x509cafile /etc/ssl/certs/ca-certificates.crt --print-cert -p 443 www.securesuite.co.uk
Processed 153 CA certificate(s).
Resolving 'www.securesuite.co.uk'...
Connecting to '62.73.172.27:443'...
*** Verifying server certificate failed...
- Ephemeral Diffie-Hellman parameters
 - Using prime: 1024 bits
 - Secret key: 1022 bits
 - Peer's public key: 1024 bits
 - PKCS#3 format:

-----BEGIN DH PARAMETERS-----
MIGHAoGBAKUEMpwau6Vsvv2NV4gRFc/E5p0Gxydj2S/+3bqqc6CM7Uy1Y1eZeSC6
5FQLN04IIfusxDi5nX5DvC3CaD3u7899ixFFkBd7OsS7F1dIgTzr3+2rWicMULxV
T2RQE2y4wsvt1S47hxuDrxkUn0bFwO/KukaR5NRZ7L5Guj/VIG47AgEC
-----END DH PARAMETERS-----

- Certificate type: X.509
 - Got a certificate list of 3 certificates.
 - Certificate[0] info:
  - subject `C=US,ST=Massachusetts,L=Bedford,O=RSA Security LLC,OU=Verified by Visa,OU=Terms of use at www.verisign.com/rpa (c)05,CN=www.securesuite.co.uk', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)10,CN=VeriSign Class 3 International Server CA - G3', RSA key 2048 bits, signed using RSA-SHA1, activated `2011-08-22 00:00:00 UTC', expires `2017-08-20 23:59:59 UTC', SHA-1 fingerprint `771ef15fe1aae19c9c204a3bc59d14dea39bd85c'

-----BEGIN CERTIFICATE-----
MIIFvzCCBKegAwIBAgIQCvUKsRGxh1WyX91o6vTZ/TANBgkqhkiG9w0BAQUFADCB
vDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDE2MDQGA1UEAxMt
VmVyaVNpZ24gQ2xhc3MgMyBJbnRlcm5hdGlvbmFsIFNlcnZlciBDQSAtIEczMB4X
DTExMDgyMjAwMDAwMFoXDTE3MDgyMDIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMRYw
FAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHFAdCZWRmb3JkMRkwFwYDVQQK
FBBSU0EgU2VjdXJpdHkgTExDMRkwFwYDVQQLFBBWZXJpZmllZCBieSBWaXNhMTMw
MQYDVQQLFCpUZXJtcyBvZiB1c2UgYXQgd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp
MDUxHjAcBgNVBAMUFXd3dy5zZWN1cmVzdWl0ZS5jby51azCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANhFyovO7mVWLcoo0J+QBnyBXOU7+GnoFTn57LXe
dszbyfgkiFNFs88TxhqxXgYZvp5wPoTdIihfTznayRLTb5Lwvy5WSAO2DxQ+zAaG
wGdHAft0MZ4vntzWU2slJOP74BnERb0IF53DMOt78Ni2jRWjXYdAI185xzBL1+EA
yGG5qqO3k6BmIHLXL3rGE1/CHqBijUwUcrfO76J6nBVOcg+gKT8k7LXL7PQRC/P8
9rUHMngASpykUC7dj8z6SrEPTuei5RKJs6a1eOVVyGfQ8Lorr1JSFv2PRjRryImZ
BF/+tv0uTAI9f090g/kKFWkXBzIury1Hm56mnjW+y5tjmeMCAwEAAaOCAbMwggGv
MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgWgMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH
FwMwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTBB
BgNVHR8EOjA4MDagNKAyhjBodHRwOi8vU1ZSSW50bC1HMy1jcmwudmVyaXNpZ24u
Y29tL1NWUkludGxHMy5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUFBwMC
BglghkgBhvhCBAEwcgYIKwYBBQUHAQEEZjBkMCQGCCsGAQUFBzABhhhodHRwOi8v
b2NzcC52ZXJpc2lnbi5jb20wPAYIKwYBBQUHMAKGMGh0dHA6Ly9TVlJJbnRsLUcz
LWFpYS52ZXJpc2lnbi5jb20vU1ZSSW50bEczLmNlcjBuBggrBgEFBQcBDARiMGCh
XqBcMFowWDBWFglpbWFnZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BSOJsp
rEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYw
DQYJKoZIhvcNAQEFBQADggEBAIEUiWLnO3qU+OjC4d9u4QMfB9J30DB1vhGAwCjt
a6wRN62xKS3tAYr2z0nTb/RgkVdfVso2GGXziPgdxN6tj3ep6kkcYVqPCAyHqHqY
LxJ2FPKTj61Kot...

[Michael Vogt (mvo)]

A short note for people not fluent in reading the output (like me!) - courtesy to Marc for helping me with this:

Certificate[0] info says in the "issuer" line: CN=VeriSign Class 3 International Server CA - G3

Certificate[1] says in its "subject" line: CN=VeriSign Class 3 Public Primary Certification Authority - G5' and the issuer is a primary certificate (i.e. no CN line)

Certificate[2] has a "subject" line: CN=VeriSign Class 3 International Server CA - G3' and the "issuer" is CN=VeriSign Class 3 Public Primary Certification Authority - G5'

So either the gnutls should support out-of-order certificates or we must use openssl or the server fixes the ordering and sends the current Certificate[2] before it sends Certificate[1].

AIUI the relevant rfc does not allow out-of-order sending but many clients are tolerant (gnutls is not). Unfortuantely I could not find a reference to quote.

[Michael Vogt (mvo)]

Fwiw, the relevant rfc section: http://tools.ietf.org/html/rfc4346#section-7.4.2

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Michael Vogt (mvo)]

From the debian bugreport:
"""
Being liberal in what you accept for security protocol implementations
is almost always a bad idea in my experience.

The chain validation implementation in GnuTLS is far from perfect, and
I'd like to have one that would fully conform to RFC 5280. However,
sorting the chain sounds like a step in the wrong direction to me. This
issue is a rare problem, and working around the problem in GnuTLS
doesn't help: the server remains broken for any other implementations.
It seems better to me that you notice the problem as quickly as
possible, rather than much later when it can be more difficult to
understand what the problem is.

I'm tagging this bug as wontfix and retitling it, so others can find the
discussion easier. (I'm only speaking as upstream GnuTLS maintainer,
the debian GnuTLS maintainers could disagree and patch this problem in
the debian packages if they think it is a good idea to do so.)
"""

Similar replies on http://thread.gmane.org/gmane.network.gnutls.general/1383
(and http://thread.gmane.org/gmane.ietf.tls/3782).

[Michael Vogt (mvo)]

Closing the software-center task as there is really nothing that software-center itself can do here (short of not doing cert verification).

[Franck (alci)]

Well... this makes buying software on Ubuntu Software Center impossible for me too (was looking at Sacred Gold). I am using ING Direct bank...

[Franck (alci)]

Notice that there seem to be a workaround : running as sudoer...

gksudo software-center

and my 3D secure payment succeded.
Not sure why, if the problem is really with gnutls / incorrect ca chain... maybe my problem was not the same ?