We have a wildcard SSL certificate for our domains. If I setup the Secure Canvas URL, we get the dreaded empty response error. My understanding is that this is because Facebook has a problem with our SSL cert.
Is there any recommendations on how to figure out what is wrong with our SSL certificate?
I read this blog post: http://developers.facebook.com/blog/post/567/
I ran the test on the site they recommended, it looks pretty good to me. Could that Beast mode warning be causing this problem? Here are the results I get back:
Certificate Information
Common names *.mydomain.com
Alternative names *.mydomain.com mydomain.com
Prefix handling Not required for subdomains
Valid from Tue Jul 19 00:00:00 UTC 2011
Valid until Wed Jul 18 23:59:59 UTC 2012 (expires in 8 months and 18 days)
Key RSA / 2048 bits
Signature algorithm SHA1withRSA
Server Gated Cryptography Netscape Step-Up, Microsoft Server Gated Cryptography
Weak key (Debian) No
Issuer EssentialSSL CA
Next Issuer COMODO Certification Authority TRUSTED
Chain length (size) 2 (2581 bytes)
Chain issues None
Validation type Domain-validated (DV)
Revocation information CRL, OCSP
Revocation status Good (not revoked)
Trusted Yes
Protocols
TLS 1.2 No
TLS 1.1 No
TLS 1.0 Yes
SSL 3.0 Yes
SSL 2.0+ upgrade support Yes
SSL 2.0 Yes N
(*) N next to protocol version means the protocol has no cipher suites enabled
Cipher Suites (sorted by strength; server has no preference)
TLS_RSA_WITH_RC4_128_MD5 (0x4) 128
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits (p: 128, g: 1, Ys: 128) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 168
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) 168
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits (p: 128, g: 1, Ys: 128) 256
Miscellaneous
Test date Thu Nov 03 19:37:27 UTC 2011
Test duration 55.590 seconds
Server signature Apache
Server hostname dev.mydomain.com
Session resumption Yes
BEAST attack Vulnerable INSECURE (more info)
Secure Renegotiation Supported, with client-initiated renegotiation disabled
Insecure Renegotiation Not supported
Strict Transport Security No
TLS version tolerance 0x0304: 0x301; 0x0399: 0x301; 0x0499: fail
PCI compliant No
FIPS-ready No
Ephemeral DH 1024 bits (p: 128, g: 1, Ys: 128)
Are you missing the intermediate certificates? Check at http://www.sslshopper.com/ssl-checker.html to see if you have a full chain
Also good is the checker at https://www.ssllabs.com/
If the app is FBML Facebook is very strict about which certificates it will accept when connecting to your site to download the content - if your app uses iFrames it's mostly up to the user's browser settings and you'll get away with less strict checking
The quote from that blog post which seems to have tripped up most FBML apps is:
If you enable SSL for your FBML app, please make sure that your SSL certificate includes all intermediate certificates in the chain of trust as our SSL validation is strict. You can use third-party SSL analysis tools (e.g., https://www.ssllabs.com/index.html) to check your certificate status and fix any errors (and warnings). If your SSL certificate has problems, you may see "Empty response received" error when you load your FBML canvas app.
Related
I am new to learning about certificates & their use in cybersecurity. I was experimenting around with my browser's certificate issued by GTS which is google trust services.
Now, I am confused about what the signature algorithm field means. I tried to google search this and found that the signature algorithm refers to the algorithm used to sign the certificate. If that is the case, I don't understand why I see 3 different signature algorithm fields in my cert. Also, 2 of them have a key size associated with them while the first field does now.
The first signature algorithm is under the category of "Issuer" so I thought maybe this is the algorithm being used to sign the cert. The second & third fields, shown in the second image, are under the category of public key. So what are they being used to sign?
Also, I don't see any key associated with the first signature algorithm, so I am a bit confused with this. Any help is much appreciated! Thank you!
Meta: this is not a programming issue, but I can't fit this in a comment. I am not voting to close because it is inappropriate to do so after answering, but if I am notified the question is closed I will delete (or I authorize a mod to do so) to ensure Q can be deleted or roombad.
I don't know what program you are using to get that decode, or if you have modified it beyond the black-outs, but it appears to be seriously misleading. Here is a better decode from OpenSSL, which follows the ASN.1 structure, with <<# marks added by me:
(redacted)>openssl s_client -connect www.google.com:443 <NUL 2>NUL | openssl x509 -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
45:48:e6:58:30:39:c0:ad:0a:00:00:00:00:ff:65:fa
Signature Algorithm: sha256WithRSAEncryption <<#1A
Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
Validity
Not Before: Sep 13 04:06:57 2021 GMT
Not After : Nov 20 04:06:56 2021 GMT
Subject: CN = www.google.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d7:27:92:c3:bb:e0:95:f4:20:46:a4:1a:5f:96:
78:a7:58:9d:cb:7c:2a:9c:7c:cb:2d:be:30:e9:c1:
71:80:11:da:c3:57:c4:c1:74:5c:a6:26:64:c3:49:
53:7c:44:19:f2:b3:c4:b3:5f:fc:90:30:b3:d4:31:
d1:16:09:b2:97:44:43:99:d6:13:19:20:ef:92:9e:
6e:41:44:56:32:c8:1c:5b:54:48:38:6b:5d:c5:00:
a4:62:be:7e:51:76:26:f6:5b:9c:e0:ed:b3:b8:dd:
16:eb:c6:9d:fc:b6:16:c0:60:1a:84:d8:b1:a5:d1:
5d:1f:35:eb:40:08:f0:2b:a1:a8:e8:d0:93:8f:85:
c6:25:a3:63:d0:d8:09:2e:fa:d2:6f:12:73:4e:aa:
ad:6f:c6:cb:b0:24:b4:65:e3:e3:fd:03:f9:d4:64:
07:2a:4b:6b:df:6b:ae:b2:90:eb:7e:57:f0:a8:3e:
08:d1:07:06:e8:04:dc:a6:bd:02:ee:07:97:1f:cf:
41:2c:8a:b0:15:bc:de:c9:13:b9:0a:8f:38:78:4c:
03:d1:46:36:e6:54:e4:3b:5f:eb:f4:02:14:82:09:
d9:0e:60:ea:29:b4:e3:7e:81:8d:4c:81:ee:4b:6d:
6e:a8:7f:f5:79:39:21:20:01:eb:77:4d:ea:22:d8:
15:13
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
C0:43:06:E9:20:B5:1E:51:86:CF:27:BB:3B:91:D5:0B:AE:F8:99:A6
X509v3 Authority Key Identifier:
keyid:8A:74:7F:AF:85:CD:EE:95:CD:3D:9C:D0:E2:46:14:F3:71:35:1D:27
Authority Information Access:
OCSP - URI:http://ocsp.pki.goog/gts1c3
CA Issuers - URI:http://pki.goog/repo/certs/gts1c3.der
X509v3 Subject Alternative Name:
DNS:www.google.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.11129.2.5.3
X509v3 CRL Distribution Points:
Full Name:
URI:http://crls.pki.goog/gts1c3/QqFxbi9M48c.crl
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 7D:3E:F2:F8:8F:FF:88:55:68:24:C2:C0:CA:9E:52:89:
79:2B:C5:0E:78:09:7F:2E:6A:97:68:99:7E:22:F0:D7
Timestamp : Sep 13 05:06:59.644 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256 <<#2
30:45:02:21:00:84:00:48:E0:6F:E9:0F:D7:AF:A6:67:
22:C8:D3:D3:A8:E4:FB:38:11:3E:5B:C2:EF:AC:E2:54:
7A:94:AC:1A:47:02:20:1E:84:FB:69:49:C2:1B:2E:0B:
84:8C:AD:CA:13:FF:97:19:3C:57:8A:0A:AC:23:DD:61:
C2:AB:7F:07:46:45:65
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 94:20:BC:1E:8E:D5:8D:6C:88:73:1F:82:8B:22:2C:0D:
D1:DA:4D:5E:6C:4F:94:3D:61:DB:4E:2F:58:4D:A2:C2
Timestamp : Sep 13 05:06:59.161 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256 <<#3
30:45:02:21:00:D5:16:13:47:CE:39:C6:60:AF:11:24:
61:A3:D3:B6:50:BF:32:01:0D:6F:5F:5F:2E:37:E4:F8:
1E:60:9E:70:E6:02:20:09:6A:39:F4:15:FC:36:6C:5F:
9B:C7:E1:B5:48:64:7F:BC:FD:36:6E:1D:7B:E5:74:6A:
55:B0:6E:0F:AF:CF:FF
Signature Algorithm: sha256WithRSAEncryption <<#1B
3a:11:f4:ac:db:fe:63:eb:40:ae:09:4e:d2:3a:89:90:37:c2:
bd:f5:bf:8e:69:7b:48:4e:33:6a:35:46:35:50:bc:94:2e:c3:
87:b4:66:e4:d6:bd:2f:98:99:d4:ba:0f:56:04:de:20:44:86:
61:35:50:3f:66:95:fc:4a:2a:69:b7:3b:0c:70:0f:17:cc:60:
a4:fe:1d:b3:f8:90:0c:b9:fa:3d:69:d0:2f:a9:15:91:cd:89:
bb:92:7d:f5:c6:7f:2f:b8:89:0a:95:f3:71:93:1c:52:77:22:
e8:af:54:f1:b2:0f:9c:4f:9b:28:59:c4:de:ed:63:0f:7b:06:
69:ac:af:5d:bd:1c:52:ca:67:3a:db:52:10:f3:16:55:20:dd:
db:4c:e7:93:e5:d1:56:d1:1f:07:12:0c:da:8c:df:c8:d7:91:
98:5c:c2:f7:f4:dc:ff:66:6b:35:95:f8:b9:cc:cd:1d:0b:cf:
d1:99:5e:ce:1a:d9:97:f3:c5:85:65:e0:17:b9:88:c6:1e:5f:
51:01:97:21:4e:49:6b:a6:ed:3d:df:8d:95:b5:be:54:5a:e4:
58:0d:4c:50:64:5f:47:91:48:45:d4:2b:37:50:bf:d5:fb:cd:
54:f3:c5:a2:72:38:fd:44:da:f9:6f:6a:2a:45:2c:ac:c5:a5:
37:3f:e8:fe
#1A and #1B are the algorithm of the signature on the cert by the issuer, which is in the block following #1B. Yes, there are two copies of this AlgorithmIdentifier in the ASN.1 structure, at the places shown, because X.509 was designed back in the 1980s and people then were concerned about algorithm substitution attacks based on experience with symmetric/secret-key systems, which turned out not to be a significant problem for asymmetric/public-key systems. It is SHA256withRSA because the issuing CA, GTS CA 1C3, uses an RSA (2048-bit) key. Edit: found crossdupes https://security.stackexchange.com/questions/24788/signaturealgorithm-vs-tbscertificate-signature and https://security.stackexchange.com/questions/114746/why-is-the-signature-algorithm-listed-twice-in-an-x509-certificate .
#2 and #3 are the algorithms for signatures on the two Signed Certificate Timestamps (SCTs) embedded in the certificate to support Certificate Transparency. You can see each one is part of an indented block under a heading Signed Certificate Timestamp:. The SCTs are created and signed by various transparency log systems, identified by their logid, and the two log systems GTS CA 1C3 chose to use happen to both have used ecdsa-with-sha256 signatures with P-256 keys. (We can directly see only that the R,S values are 256 bits corresponding to some curve group with a 256-bit order, but RFC6962 confirms that the only acceptable ECDSA curve is P-256.)
Aside: I don't understand why you thought it necessary to black-out some information from a certificate that everyone in the world can easily get and look at. The entire purpose of a certificate (at least an Internet server certificate) is to be publicly known to everybody.
I have moved a PHP script to another server, and now fail to login to an IMAP (TLS) postbox:
TLS/SSL failure for mail.servername.de: SSL negotiation failed
It seems that the problem is caused by OpenSSL, because when I try to connect to the Mailserver from both servers, I get a connection in one case (the mailserver asking for input), but none in the other (the connection is closed, I am back to bash):
openssl s_client -crlf -connect mail.servername.de:993
The most obvious difference is here:
verify return:1
---
<snip>
-----END CERTIFICATE-----
subject=/CN=mail.servername.de
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 3398 bytes and written 483 bytes
Verification: OK
---
New, TLSv1.2, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
And on th other server (where no connection is made)
verify return:1
depth=0 CN = mail.servername.de
verify return:1
140410888582464:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2149:
---
<snip>
-----END CERTIFICATE-----
subject=CN = mail.servername.de
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
---
SSL handshake has read 3167 bytes and written 318 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Server public key is 2048 bit
On the mailserver dovecot is configured not to accept non-encrypted connections. But, I assume it already fails due to dh key too small, which seems to relate to cipher negotiation.
Now I simply fail to put the things together... Why does the SSL connection work from one server, but not from the other?
As I own the "remote end" myself, I was able to increase security. The solution is simple, and may be relevant for others as well ...
The dovecot version is 2.2.x, which is of some relevance for the DH parmaters (see Dovecot SSL configuration). In the configuration file /etc/dovecot/conf.d/10-ssl.conf you can simply add this line:
ssl_dh_parameters_length = 2048
And eventually, it may be necessary to add this here to the main configuration file /etc/dovecot/dovecot.conf at the end:
!include conf.d/*.conf
Finally, it is important not to reload, but to restart dovecot.
systemctl restart dovecot
And suddently, the weight, troubles, and frustration of several hours is gone. Great...
Further to the above, there's a change from dovecot 2.3.
ssl_dh_parameters_length is now not used, and ssl_dh must be used instead, to point to a file generated using
openssl dhparam 4096 > dh.pem
see https://doc.dovecot.org/configuration_manual/dovecot_ssl_configuration/ and scroll down to SSL Security Settings. That was the only change I had to make following the upgrade to get it to work properly again. I put the dh.pem file in /etc/dovecot, so my line in 10-ssh.conf is
ssl_dh=</etc/dovecot/dh.pem
TL;DR: your new host has a newer version of OpenSSL probably with higher security settings which prohibit connecting to the host for reasons explained below.
"dh key too small" comes from OpenSSL and because of too low security.
Things changed, and for example in newest Debian versions and with OpenSSL 1.1.1 (and I guess it is similar for newer versions), the security was enhanced.
The best and simplest explanation I have found is on Debian wiki at https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1
which says:
In Debian the defaults are set to more secure values by default. This
is done in the /etc/ssl/openssl.cnf config file. At the end of the
file there is:
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT#SECLEVEL=2
This can results in errors such as:
dh key too small
ee key too small
ca md too weak
Now the possible solutions in descending order of preference:
ask the remote end to generate better "DH" values ("Server Temp Key: DH, 1024 bits"); the best explanations are at https://weakdh.org/sysadmin.html; note specifically the "Administrators should use 2048-bit or stronger Diffie-Hellman groups with "safe" primes."
configure your end specifically for this connnection to not use the OS default and lower your settings; it should be enough to set ciphers to "DEFAULT#SECLEVEL=1" in the code that does the connection
(really, really, really not recommended) change the value of SECLEVEL from 2 to 1 in the global configuration file on your end. But this impacts all connections from your host not just this one so you are lowering the global security of your system just because of one low level of security from one remote node.
I am using Fiddler 5.0 to capture https requests of mobile app. It works fine except one app. Below is logs of Fiddler.
21:31:59:7072 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
21:31:59:7072 !SecureClientPipeDirect failed: System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. < 处理证书时,出现了一个未知错误。 for pipe (CN=ci.migudm.cn, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com).
21:31:59:7412 !SecureClientPipeDirect failed: System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. < 处理证书时,出现了一个未知错误。 for pipe (CN=ci.migudm.cn, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com).
21:31:59:7862 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
Have you checked out the link provided by the logs? There's a bunch of very relevant information there that I think might help you get what you need:
Some web servers are unable to process Client Hello messages longer than 255 bytes, even though such messages are allowed by the protocol. Although most Client Hello messages are shorter than this limit, with the use of Server Name Indications (SNI), Elliptic Curve extensions, and the increase in the number of supported suites, the size can easily go over.
Browsers are thought not to be affected, but some other tools may be. In particular, OpenSSL 1.0.1+ is known to be affected. If you are using the s_client tool, try to reduce the size of the handshake by disabling some of the suites offered by OpenSSL (this can be done by specifying the desired suites using the -cipher switch).
OpenSSL Bug #2771: Openssl 1.0.1 times out when connecting to Outlook Exchange 2007; sign in with guest/guest.
F5 tracks this problem under bug #376483 and it is fixed in BIG-IP LTM 10.2.4 (see [SOL14758: SSL client connections may fail if the ClientHello message is greater than 255 bytes and uses TLS 1.1 or 1.2] (https://support.f5.com/kb/en-us/solutions/public/14000/700/sol14758.html) for more details).
Michael Tschannen says:
The issue is fixed according to F5 in 10.2.4, they are however not mentioned in any release notes (I have >just checked until 11.x)
To debug the issue on an F5, the log level of "SSH" needs to be at least "Informational".
Example:
Mar 22 09:44:21 local/tmm info tmm[4696]: 01260013:6: SSL Handshake failed for TCP from x.x.x.x:443 to x.x.x.x:49549
Source: https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
If you've been through all of this information, could you please provide the F5 version, OpenSSL version, and log information from OpenSSL?
I recently scanned my system for PCI compliance test using NMAP.
NMAP reported following weak ciphers-
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D
TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
These all are reported on TLSv1.2 on Port 5061.
Port 5061 runs my secure SIP connection.
To resolve this, I disabled 3DES (Triple DES 168) from registry, also disabled, RC4 & MD5 ciphers completely from registry.
I also did set an SSL cipher Suite order which does not use DES/3DES/RC4 or MD5 but still, after each scan same vulnerabilities are being reported.
How can I resolve this & completely disable these ciphers?
Also, is there anyway to block cipher suite negotiation on any particular port?
Thanks.
P.S.- This is a Windows Server 2012 machine.
I am testing a sandbox version of the PayPal IPN system that worked previously, but is now not functioning. The IPN simulator says:
"IPN was not sent, and the handshake was not verified. Please review your information."
I reviewed the documentation about the Verisign G5 CA certificate and followed the instructions shown, but the following command:
openssl s_client -connect api-3t.sandbox.paypal.com:443 -showcerts -CApath /etc/ssl/certs/
Still produces this output: (Truncated)
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: 9E01CD86FA9E600EAD505F17E34C0F9BE07E7894E35B20BAF2946F88596BB047
Session-ID-ctx:
Master-Key: 90F662CD0BD319EB87ACFE89CDACEFED2327AC4C827ED74861166B86423B5404
587A70B65BCEA2FAC23F7DDAAA49F9DC
Key-Arg : None
Start Time: 1445624886
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
I verified that the G3 certificate is no longer in the certificate store, and even removed and reinstalled the new certificate many times. I have spent the last 10 hours on this with no end in sight.
I own my own servers, so there is no other administrator I can turn to... I need to figure out how to solve this myself, and am at my wits end. I know I do not know as much about SSL and certificate chains as I should, but theres no help for that part lol.
Can anyone who has performed this task give me a kick in the right direction, and/or let me know what additional information I can provide to help solicit a solution?
Thank you very much,
Dave
Here's how I did to import the G5 root cert into openssl:
Obtain a G5 root certificate from Verisign (Symantec) HERE (get it in PEM format, save the file with .pem extension)
Put the file into your openssl base dir (should be like "/usr/lib/ssl" on your server, but you may check the base dir by running openssl version -d)
Run the command to install the cert
openssl verify -CApath <ssl-base-dir>certs server-certificate-file
(replace <ssl-base-dir> with your openssl base dir, and replace server-certificate-file with your .pem file, the command would be something like openssl verify -CApath /usr/lib/ssl/certs G5.pem)
The response would be an G5.pem: OK for the installation
Try again with the connection command
openssl s_client -connect api-3t.sandbox.paypal.com:443 -showcerts -CApath /usr/lib/ssl/certs/
You will see Verify return code: 0 (ok) at the end of the response
I downloaded the VeriSign Class 3 Public Primary Certification Authority - G5.pem certificate file into a local directory, and ran the following command:
openssl s_client -connect api-3t.sandbox.paypal.com:443 -showcerts
-CAfile "ssl\VeriSign Class 3 Public Primary Certification Authority - G5.pem"
Openssl returned a successful result (truncated):
Server certificate
subject=/C=US/ST=California/L=San Jose/O=PayPal, Inc./OU=PayPal Production/CN=api-3t.sandbox.paypal.com
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 Secure Server CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 3379 bytes and written 344 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 9E01CD86FA9CEB77AD505F17E34C0B9B8A233BD98E30D705F2946F88596F077D
Session-ID-ctx:
Master-Key: 7AC616B7499ED70B6D75FAD3308C332A48B85987685A514365B7507297A3C6A70CD6E7503CE27A9A157045531B54149F
Key-Arg : None
PSK identity: None
PSK identity hint: None
Start Time: 1445867355
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
Note that I used the -CAfile option to directly reference the CA root certificate.