Twitter Card: ERROR: Fetching the page failed because other errors

[DonWaterloo]

I’ve seen a lot of posts here on similar message:

Twitter Card: ERROR: Fetching the page failed because other errors

but they devolve down (usually) to an ssl issue.

I’ve tried curl -A Twitterbot, its ok (no robots.txt issue).
I’ve tried checking the SSL cert (https://www.ssllabs.com/ssltest/analyze.html?d=blog.donbowman.ca) its ok.
My cards were working until sept 5, and then stopped. I’m not aware of a change in my site (wordpress).

The URL I’m testing https://blog.donbowman.ca/2018/09/10/randomise-your-mac-address-to-deter-wifi-tracking/

I’m using ‘WP to Twitter Pro’

I’m not sure what to check. I just get the ‘fetching the page failed because other errors’.

Perhaps related, the older posts which a card was created for, they still show a card, but the image is no longer present.

Does anyone have a suggestion for how to debug?

[DonWaterloo]

OK a little more debugging.
No line shows in the access/error log of nginx when I use the validator.
But, on tcpdump, I do see traffic when i use the validator. Checking w/ wireshark, I see the client-hello as:

I then see a fatal: Handshake Failure. This is sent from server->client.

The SNI is present, and matches a name on the certificate.
I’m using nginx

I have a matching cipher: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

If I enable ‘debug’ on the nginx error log for this vhost, I get:

2018/09/14 08:54:59 [info] 11856#11856: *2864973 SSL_do_handshake() failed (SSL: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher) while SSL handshaking, client: 199.16.157.181, server: 0.0.0.0:443
2018/09/14 08:54:59 [debug] 11856#11856: *2864973 close http connection: 16
2018/09/14 08:54:59 [debug] 11856#11856: *2864973 event timer del: 16: 3523977525
2018/09/14 08:54:59 [debug] 11856#11856: *2864973 reusable connection: 0
2018/09/14 08:54:59 [debug] 11856#11856: *2864973 free: 000055DB95E51200, unused: 120
2018/09/14 08:54:59 [debug] 11856#11856: *2864975 SSL_do_handshake: -1
2018/09/14 08:54:59 [debug] 11856#11856: *2864975 SSL_get_error: 1

I only expose 3 ciphers:

ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384!AES128:!3DES';

I expose secp384r1, which is in the client hello as well.

So I think it must be a mismatch in signature hash algorithms.

[DonWaterloo]

ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:!3DES';

works. I had to remove a !AES128.

It seems that even though twitter connection has
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)

it won’t use it. I explicitly have ECDHE-ECDSA-AES256-GCM-SHA384 in my list, but the !AES128 later on prevents this from working.

Anyone know why? I would prefer not to enable AES128.

Edit: Seems like maybe https://github.com/openssl/openssl/issues/2237 ?

[LeutholdGroup]

I’m getting the same error on validate. I’ve gone through the [checklist] (Not Whitelisted, unable to render, or no image: READ THIS FIRST) and everything seems to be set up correctly.

https://advisors.leutholdgroup.com/research/research/2018/09/19/real-rates-and-the-federal-deficit.21177

My SSL is configured correctly. We don’t use java. I do not have the “!AES128” entry in my cipher list.

Any help would be appreciated

Thank you

[LeutholdGroup]

I’ve also verified that we are bundling our primary and intermediate certificate.

[DonWaterloo]

you are not using Java. But the twitter code which fetches the card is. I had to enable AES128 in my list.

if you turn on debug logging in your nginx (or other web server), do you see a connection that comes in that fails the ssl?

or else, do a tcpump capture on your server when you do the card test, and look at the capture in wireshark.

[LeutholdGroup]

you are not using Java. But the twitter code which fetches the card is. I had to enable AES128 in my list.

if you turn on debug logging in your nginx (or other web server), do you see a connection that comes in that fails the ssl?

or else, do a tcpump capture on your server when you do the card test, and look at the capture in wireshark.

I will check that out, thank you @DonWaterloo

[system]

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.