1

On Debian 8.4 (with ca-certificates package) openssl doesn't seem to know about CAs required to verify connections to Akamai signed by "GTE CyberTrust" and "Baltimore CyberTrust".

The GTE CyberTrust cert has been removed from Debian, but the second one is still present in /etc/ssl/certs/Baltimore_CyberTrust_Root.pem.

$ curl https://us12.api.mailchimp.com
curl: (60) SSL certificate problem: unable to get local issuer certificate

What do I need to configure to be able to securely connect to these hosts system-wide?

(i.e. not just by overriding CAs for that one curl command, but to make it work by default for everything that uses openssl).


Dump from openssl client:

# openssl s_client -showcerts -connect us12.api.mailchimp.com:443
CONNECTED(00000003)
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=GA/L=Atlanta/O=ROCKET SCIENCE GROUP/OU=Rocket Science Group/CN=*.api.mailchimp.com
   i:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
-----BEGIN CERTIFICATE-----
MIIFiDCCBHCgAwIBAgIURuinjSOLVC8VmOwDrapM4UemZC4wDQYJKoZIhvcNAQEL
…
ThF6LGDwvnUlPM6iio2H+pgS50ji0zgr317n0w==
-----END CERTIFICATE-----
 1 s:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
   i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
-----BEGIN CERTIFICATE-----
MIIFHzCCBAegAwIBAgIEByekazANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJJ
…
t8SjWfUWbF8+aVWAOfZ1UBQ+Mg==
-----END CERTIFICATE-----
 2 s:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
   i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
-----BEGIN CERTIFICATE-----
MIIEFTCCA36gAwIBAgIEByeO7TANBgkqhkiG9w0BAQUFADB1MQswCQYDVQQGEwJV
…
pN19+kSElK7XCQQidg9kUTWpJA/5C9sy2sL+wbkqXHonE8qxSDpx0EM=
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=GA/L=Atlanta/O=ROCKET SCIENCE GROUP/OU=Rocket Science Group/CN=*.api.mailchimp.com
issuer=/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
---
No client certificate CA names sent
---
SSL handshake has read 4444 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: CF5113EEB4AB191102C390311AAB919079CEDADD0E752BA60912317744FA12D4
    Session-ID-ctx:
    Master-Key: 89CE1A43C195D0175818D739E20E7484132F971C642BBB5AC11D0685E8494658BB8D574BCFBFFC26486EFF10DCE4E258
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 61 b6 3d 3e 95 8a de 3c-18 e9 c0 47 3b 0a 53 ea   a.=>...<...G;.S.
    0010 - a5 8c fb dc 66 6c 87 b1-2e 2b ca 93 20 2f 1e 77   ....fl...+.. /.w
    0020 - 81 e9 1c 45 ca d2 dd 8e-2d cb aa 86 00 c7 26 4a   ...E....-.....&J
    0030 - 2d 77 af 24 2f ea 33 64-f2 92 c0 da c1 49 72 47   -w.$/.3d.....IrG
    0040 - 44 b3 fe 4c 74 4d e7 7b-61 69 4e 16 69 5c 11 d1   D..LtM.{aiN.i\..
    0050 - a0 7c eb a3 04 71 8e 54-b8 00 7b e0 92 61 7c e1   .|...q.T..{..a|.
    0060 - 28 ee 73 f3 ac 04 54 5c-60 d0 95 fe 4a 79 fc 39   (.s...T\`...Jy.9
    0070 - 58 bd e9 3a 10 7f 18 58-50 9f 13 1b 56 20 70 91   X..:...XP...V p.
    0080 - 68 fa 3e 21 52 e4 5c 4f-03 8f 15 ec 7f be b0 ad   h.>!R.\O........
    0090 - 3c fe 35 2d 32 ef 9f dd-cd 06 8e 8a a7 8f af 59   <.5-2..........Y

    Start Time: 1461151140
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
1

I've found this is caused by a combination on two things:

  • a weak GTE CyberTrust certificate has been dropped from ca-certificates

  • Debian ships with old openssl 1.0.1, which has buggy certificate validation and can't handle cross-signing properly

Installing openssl 1.0.2 from unstable solves the problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.