I recently installed a SSL certificate on my domain and now Facebook is unable to scrape my webpages for open graph content.
When I go to https://developers.facebook.com/tools/debug/og/object/ and scrape the site: https://genesispetaluma.com, I get an error "Error parsing input URL, no data was cached, or no data was scraped." When I click to see what the scraper sees, I get a message "document returned no data" at this link: https://developers.facebook.com/tools/debug/og/echo?q=https%3A%2F%2Fgenesispetaluma.com%2F. This worked perfectly before the installation of the SSL Certificate. Because I do not have a wildcard SSL certificate, I tried to scrape a site on my subdomain: http://blog.genesispetaluma.com and this passes and delivers the following information: https://developers.facebook.com/tools/debug/og/object?q=blog.genesispetaluma.com.
I have verified with the server logs that Facebook is making a request to my server: 69.171.237.115 - - [22/Aug/2014:09:44:13 -0700] "GET / HTTP/1.1" 206 6512 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"
I ran a test with www.ssllabs.com and it appears that the certificate is installed correctly, with all of the intermediate certificates installed as well. My hosting company has verified that the certificate is installed correctly as well.
Any ideas why this is not working or how I can troubleshoot this? I posted this issue in the Facebook Developer forum and they have not been able to figure it out.
Any ideas why this is not working or how I can troubleshoot this?
There's one small problem that I see that might be causing the problem. The CA certificate is being sent in the chain. The CA certificate is the third certificate shown below.
You should not send the CA in the chain. Rather, the client needs to already have it and use it as a trust anchor.
Another potential issue is that the web app located at https://developers.facebook.com does not use the AddTrust External CA Root certificate as a trust anchor. If Facebook is missing the trust anchor, or does not trust the CA, then there's nothing you can do.
The final potential issue is an SSL/TLS interception proxy is at work. But I doubt Facebook is intercepting the traffic leaving their network.
There's another small problem with the server certificate. The server certificate provides a DNS name in the Common Name (CN). Placing a DNS in the Common Name is deprecated by both the IETF and CA/Browser forums. Though its deprecated, its not forbidden.
DNS names should be placed in the Subject Alternate Name (SAN), and both genesispetaluma.com and www.genesispetaluma.com are there. So that looks OK.
$ openssl s_client -connect genesispetaluma.com:443 -CAfile addtrustexternalcaroot.crt | openssl x509 -text -noout
depth=2 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = PositiveSSL CA 2
verify return:1
depth=0 OU = Domain Control Validated, OU = Hosted by A Small Orange LLC, OU = PositiveSSL, CN = genesispetaluma.com
verify return:1
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
86:c2:2e:29:7b:68:f7:f3:16:5d:18:27:84:1f:e4:98
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=PositiveSSL CA 2
Validity
Not Before: Mar 3 00:00:00 2014 GMT
Not After : Mar 3 23:59:59 2015 GMT
Subject: OU=Domain Control Validated, OU=Hosted by A Small Orange LLC, OU=PositiveSSL, CN=genesispetaluma.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:e1:16:f6:78:f8:10:29:e8:96:e6:3b:f1:2f:36:
3f:da:2f:cf:b8:f3:ab:cb:3b:8c:a6:09:0a:a6:3a:
f3:e9:ad:7f:d7:30:c4:ac:b3:9b:98:e0:ec:f0:2a:
75:31:e4:0b:92:76:cc:a3:49:b6:bc:35:77:29:ed:
aa:51:20:b5:c1:b0:1f:ed:ee:23:84:29:99:d4:a2:
6c:c5:5e:66:dc:7e:cf:b7:9d:88:c8:75:1a:46:ec:
ce:34:db:da:06:4e:b0:8d:21:ec:2c:db:88:8e:1f:
9b:13:76:ca:30:8c:4b:60:d5:02:f4:91:a9:d6:b3:
3b:c8:46:2d:0d:90:04:c5:39:ca:e7:e2:20:fe:57:
95:bc:40:9b:af:52:9b:fd:95:54:a6:82:f9:d7:ea:
ac:e5:08:1a:53:c2:7b:59:2b:23:a2:12:41:58:4c:
6c:f0:fe:56:77:ed:ae:0f:9a:5d:b5:32:1c:51:3b:
46:56:d2:60:a4:ad:91:56:11:a6:f4:fc:1b:94:22:
84:9f:a2:c0:80:92:01:48:58:9a:d1:01:11:5f:99:
95:05:c8:18:23:dc:72:e4:d8:01:24:f0:c6:26:23:
be:b3:09:ea:22:94:f6:04:c4:9a:67:3c:15:b1:25:
24:49:7d:60:31:5c:60:a5:f9:7b:65:9d:45:91:fd:
a4:f3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:99:E4:40:5F:6B:14:5E:3E:05:D9:DD:D3:63:54:FC:62:B8:F7:00:AC
X509v3 Subject Key Identifier:
3E:E8:E1:02:B6:36:96:64:7F:9A:84:2E:DD:17:F9:D9:C5:88:A7:EF
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.6449.1.2.2.7
CPS: http://www.positivessl.com/CPS
Policy: 2.23.140.1.2.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.comodoca.com/PositiveSSLCA2.crl
Authority Information Access:
CA Issuers - URI:http://crt.comodoca.com/PositiveSSLCA2.crt
OCSP - URI:http://ocsp.comodoca.com
X509v3 Subject Alternative Name:
DNS:genesispetaluma.com, DNS:www.genesispetaluma.com
Signature Algorithm: sha1WithRSAEncryption
53:20:9f:af:fd:c4:20:78:ed:56:ed:53:8d:29:38:3b:16:00:
ff:7f:39:fd:75:21:b1:d7:af:27:e5:08:d2:c5:77:5e:52:09:
fd:38:ba:03:a3:8c:4d:e9:8f:6e:a7:12:c4:26:b2:1f:02:96:
f8:24:94:0c:c4:74:2a:2d:2e:b4:d6:4c:ee:5f:2d:e1:b6:91:
a3:eb:d0:9a:46:fa:f5:c1:da:a0:13:11:63:56:64:08:e3:f2:
2c:7a:80:19:1f:a1:4e:ae:9e:ab:1e:27:71:ed:55:da:dc:2b:
b0:52:73:ed:e7:1b:c2:2f:5d:6a:17:90:ee:32:b2:36:ee:9c:
8e:57:5b:70:bd:08:55:1c:a2:f4:ca:ee:f4:0b:0e:d7:1a:e3:
e8:de:14:eb:d0:62:24:9a:8b:7c:c6:ab:65:35:e1:5d:a0:2f:
1f:7a:d2:96:e7:0c:12:cc:d8:e7:ff:1c:58:0c:ce:db:6d:cc:
e8:f7:09:17:57:a8:cc:b7:90:4e:f3:0a:2e:d3:56:ad:44:12:
ce:b1:4c:9b:2a:5c:3f:1e:19:95:41:7a:f9:2c:15:c5:48:c6:
bd:49:ad:f6:95:15:21:69:58:a2:0e:c2:9f:9f:c4:a9:d7:83:
a4:6f:5b:07:c5:28:65:8e:fe:fa:83:5f:5f:10:12:36:c8:c9:
f0:55:7a:a0
I tried to scrape a site on my subdomain: http://blog.genesispetaluma.com and this passes
This is odd. The certificate above does not certify blog.genesispetaluma.com. This should fail validation.
If you want to use OpenSSL's s_client to verify the chain, then go to [Root] AddTrust External CA Root and download the AddTrust External CA Root certificate. Then use the CAfile option and you should receive Verify return code: 0 (ok):
$ openssl s_client -connect genesispetaluma.com:443 -showcerts \
-CAfile addtrustexternalcaroot.crt
...
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: A171C87253621808B164BAA1399B07D776E28EBCB8A5AB3A81D65DD66505E3AF
Session-ID-ctx:
Master-Key: 559289812A3602C49FEC4C6FEDC714D4D7B107BDB4E9AD5A811DD0606EF5114D
4DD2624EE141508E92092CF23D946185
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - f4 67 cf 21 46 b8 f9 ae-ba ec da f4 2a 24 9f 5b .g.!F.......*$.[
...
00b0 - b8 97 35 30 cf c6 83 a6-14 a6 b7 16 b1 6c 50 b6 ..50.........lP.
Start Time: 1408754636
Timeout : 300 (sec)
Verify return code: 0 (ok)
Here's the certificate chain with the CA certificate:
$ openssl s_client -connect genesispetaluma.com:443 -showcerts -CAfile addtrustexternalcaroot.crt
CONNECTED(00000003)
depth=2 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = PositiveSSL CA 2
verify return:1
depth=0 OU = Domain Control Validated, OU = Hosted by A Small Orange LLC, OU = PositiveSSL, CN = genesispetaluma.com
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=Hosted by A Small Orange LLC/OU=PositiveSSL/CN=genesispetaluma.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
-----BEGIN CERTIFICATE-----
MIIFNTCCBB2gAwIBAgIRAIbCLil7aPfzFl0YJ4Qf5JgwDQYJKoZIhvcNAQEFBQAw
czELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxGTAXBgNV
BAMTEFBvc2l0aXZlU1NMIENBIDIwHhcNMTQwMzAzMDAwMDAwWhcNMTUwMzAzMjM1
OTU5WjB+MSEwHwYDVQQLExhEb21haW4gQ29udHJvbCBWYWxpZGF0ZWQxJTAjBgNV
BAsTHEhvc3RlZCBieSBBIFNtYWxsIE9yYW5nZSBMTEMxFDASBgNVBAsTC1Bvc2l0
aXZlU1NMMRwwGgYDVQQDExNnZW5lc2lzcGV0YWx1bWEuY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4Rb2ePgQKeiW5jvxLzY/2i/PuPOryzuMpgkK
pjrz6a1/1zDErLObmODs8Cp1MeQLknbMo0m2vDV3Ke2qUSC1wbAf7e4jhCmZ1KJs
xV5m3H7Pt52IyHUaRuzONNvaBk6wjSHsLNuIjh+bE3bKMIxLYNUC9JGp1rM7yEYt
DZAExTnK5+Ig/leVvECbr1Kb/ZVUpoL51+qs5QgaU8J7WSsjohJBWExs8P5Wd+2u
D5pdtTIcUTtGVtJgpK2RVhGm9PwblCKEn6LAgJIBSFia0QERX5mVBcgYI9xy5NgB
JPDGJiO+swnqIpT2BMSaZzwVsSUkSX1gMVxgpfl7ZZ1Fkf2k8wIDAQABo4IBtzCC
AbMwHwYDVR0jBBgwFoAUmeRAX2sUXj4F2d3TY1T8Yrj3AKwwHQYDVR0OBBYEFD7o
4QK2NpZkf5qELt0X+dnFiKfvMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAA
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBQBgNVHSAESTBHMDsGCysG
AQQBsjEBAgIHMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cucG9zaXRpdmVzc2wu
Y29tL0NQUzAIBgZngQwBAgEwOwYDVR0fBDQwMjAwoC6gLIYqaHR0cDovL2NybC5j
b21vZG9jYS5jb20vUG9zaXRpdmVTU0xDQTIuY3JsMGwGCCsGAQUFBwEBBGAwXjA2
BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20vUG9zaXRpdmVTU0xD
QTIuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wNwYD
VR0RBDAwLoITZ2VuZXNpc3BldGFsdW1hLmNvbYIXd3d3LmdlbmVzaXNwZXRhbHVt
YS5jb20wDQYJKoZIhvcNAQEFBQADggEBAFMgn6/9xCB47VbtU40pODsWAP9/Of11
IbHXryflCNLFd15SCf04ugOjjE3pj26nEsQmsh8ClvgklAzEdCotLrTWTO5fLeG2
kaPr0JpG+vXB2qATEWNWZAjj8ix6gBkfoU6unqseJ3HtVdrcK7BSc+3nG8IvXWoX
kO4ysjbunI5XW3C9CFUcovTK7vQLDtca4+jeFOvQYiSai3zGq2U14V2gLx960pbn
DBLM2Of/HFgMztttzOj3CRdXqMy3kE7zCi7TVq1EEs6xTJsqXD8eGZVBevksFcVI
xr1JrfaVFSFpWKIOwp+fxKnXg6RvWwfFKGWO/vqDX18QEjbIyfBVeqA=
-----END CERTIFICATE-----
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
-----BEGIN CERTIFICATE-----
MIIE5TCCA82gAwIBAgIQB28SRoFFnCjVSNaXxA4AGzANBgkqhkiG9w0BAQUFADBv
MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF
eHRlcm5hbCBDQSBSb290MB4XDTEyMDIxNjAwMDAwMFoXDTIwMDUzMDEwNDgzOFow
czELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxGTAXBgNV
BAMTEFBvc2l0aXZlU1NMIENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDo6jnjIqaqucQA0OeqZztDB71Pkuu8vgGjQK3g70QotdA6voBUF4V6a4Rs
NjbloyTi/igBkLzX3Q+5K05IdwVpr95XMLHo+xoD9jxbUx6hAUlocnPWMytDqTcy
Ug+uJ1YxMGCtyb1zLDnukNh1sCUhYHsqfwL9goUfdE+SNHNcHQCgsMDqmOK+ARRY
FygiinddUCXNmmym5QzlqyjDsiCJ8AckHpXCLsDl6ez2PRIHSD3SwyNWQezT3zVL
yOf2hgVSEEOajBd8i6q8eODwRTusgFX+KJPhChFo9FJXb/5IC1tdGmpnc5mCtJ5D
YD7HWyoSbhruyzmuwzWdqLxdsC/DAgMBAAGjggF3MIIBczAfBgNVHSMEGDAWgBSt
vZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUmeRAX2sUXj4F2d3TY1T8Yrj3
AKwwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAow
CDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0
LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDCBswYIKwYBBQUHAQEEgaYw
gaMwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9BZGRUcnVz
dEV4dGVybmFsQ0FSb290LnA3YzA5BggrBgEFBQcwAoYtaHR0cDovL2NydC51c2Vy
dHJ1c3QuY29tL0FkZFRydXN0VVROU0dDQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRw
Oi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCcNuNOrvGK
u2yXjI9LZ9Cf2ISqnyFfNaFbxCtjDei8d12nxDf9Sy2e6B1pocCEzNFti/OBy59L
dLBJKjHoN0DrH9mXoxoR1Sanbg+61b4s/bSRZNy+OxlQDXqV8wQTqbtHD4tc0azC
e3chUN1bq+70ptjUSlNrTa24yOfmUlhNQ0zCoiNPDsAgOa/fT0JbHtMJ9BgJWSrZ
6EoYvzL7+i1ki4fKWyvouAt+vhcSxwOCKa9Yr4WEXT0K3yNRw82vEL+AaXeRCk/l
uuGtm87fM04wO+mPZn+C+mv626PAcwDj1hKvTfIPWhRRH224hoFiB85ccsJP81cq
cdnUl4XmGFO3
-----END CERTIFICATE-----
2 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
-----BEGIN CERTIFICATE-----
MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs
IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt
H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9
uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX
mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX
a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN
E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0
WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD
VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0
Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU
cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx
IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN
AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH
YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5
6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX
c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
-----END CERTIFICATE-----
---
Server certificate
subject=/OU=Domain Control Validated/OU=Hosted by A Small Orange LLC/OU=PositiveSSL/CN=genesispetaluma.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
---
No client certificate CA names sent
---
SSL handshake has read 4373 bytes and written 434 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: A171C87253621808B164BAA1399B07D776E28EBCB8A5AB3A81D65DD66505E3AF
Session-ID-ctx:
Master-Key: 559289812A3602C49FEC4C6FEDC714D4D7B107BDB4E9AD5A811DD0606EF5114D4DD2624EE141508E92092CF23D946185
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - f4 67 cf 21 46 b8 f9 ae-ba ec da f4 2a 24 9f 5b .g.!F.......*$.[
0010 - d3 01 c1 21 60 54 8b 1a-8f 5f 5f d5 16 e5 97 11 ...!`T...__.....
0020 - 0f 63 22 5a d3 59 f3 96-a1 3a 35 93 b9 7c 40 9d .c"Z.Y...:5..|#.
0030 - 1d 15 3c 03 04 30 7b 0c-fa fd 69 fc cf ac 32 8c ..<..0{...i...2.
0040 - e2 f2 91 48 37 9b 11 ca-f6 b4 e8 65 5f f2 90 31 ...H7......e_..1
0050 - 8c 2c 7a 74 2e 9a ab de-1f 31 05 b6 a7 6e 42 8b .,zt.....1...nB.
0060 - 6d 36 10 38 38 9f f5 1f-c8 e3 ac ce ba 95 21 4f m6.88.........!O
0070 - 21 3f 38 ef 20 33 f4 b8-86 6a 61 4b e9 cc 00 4d !?8. 3...jaK...M
0080 - ab f3 c6 24 33 3c c5 44-1c 4a f9 71 9b 3c 25 74 ...$3<.D.J.q.<%t
0090 - af 63 73 d7 b3 1b 4f cc-fe 05 76 75 02 db 5b 12 .cs...O...vu..[.
00a0 - 8d 2c 5e 7a 98 ca 95 1c-1a 04 df 6e 22 c3 f2 55 .,^z.......n"..U
00b0 - b8 97 35 30 cf c6 83 a6-14 a6 b7 16 b1 6c 50 b6 ..50.........lP.
Start Time: 1408754636
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
The Facebook team was able to determine the source of the problem. Facebook will not scrape the page unless the og:url has the protocol as well.
For example, this does not work:
meta property="og:url" content="//genesispetaluma.com/"
But this does:
meta property="og:url" content="**https:**//genesispetaluma.com/"
They should to clarify the error in the debugger so people know what's wrong.
Related
I have a self managed Kubernetes cluster consisting of one master node and 3 worker nodes. I use the Cluster Network Interface flannel within the cluster.
On all my machines I can see the following kind of kernel messages:
Apr 12 04:22:24 worker-7 kernel: [278523.379954] iptables[6260]: segfault at 88 ip 00007f9e69fefe47 sp 00007ffee4dff356 error 4 in libnftnl.so.11.3.0[7f9e69feb000+16000]
Apr 12 04:22:24 worker-7 kernel: [278523.380094] Code: bf 88 00 00 00 48 8b 2f 48 39 df 74 13 4c 89 ee 41 ff d4 85 c0 78 0b 48 89 ef 48 8b 6d 00 eb e8 31 c0 5a 5b 5d 41 5c 41 5d c3 <48> 8b 87 88 00 00 00 48 81 c7 78 00 00 00 48 39 f8 74 0b 85 f6 74
Apr 12 05:59:10 worker-7 kernel: [284329.182667] iptables[13978]: segfault at 88 ip 00007fb799fafe47 sp 00007fff22419b36 error 4 in libnftnl.so.11.3.0[7fb799fab000+16000]
Apr 12 05:59:10 worker-7 kernel: [284329.182774] Code: bf 88 00 00 00 48 8b 2f 48 39 df 74 13 4c 89 ee 41 ff d4 85 c0 78 0b 48 89 ef 48 8b 6d 00 eb e8 31 c0 5a 5b 5d 41 5c 41 5d c3 <48> 8b 87 88 00 00 00 48 81 c7 98 00 00 00 48 39 f8 74 0b 85 f6 74
Apr 12 08:29:25 worker-7 kernel: [293343.999073] iptables[16041]: segfault at 88 ip 00007fa40c7f7e47 sp 00007ffe04ba9886 error 4 in libnftnl.so.11.3.0[7fa40c7f3000+16000]
Apr 12 08:29:25 worker-7 kernel: [293343.999165] Code: bf 88 00 00 00 48 8b 2f 48 39 df 74 13 4c 89 ee 41 ff d4 85 c0 78 0b 48 89 ef 48 8b 6d 00 eb e8 31 c0 5a 5b 5d 41 5c 41 5d c3 <48> 8b 87 88 00 00 00 48 81 c7 98 00 00 00 48 39 f8 74 0b 85 f6 74
I narrowed it down that the messages originated in the kube-flannel-ds pods. I have log messages like this one:
Failed to ensure iptables rules: Error checking rule existence: failed to check rule existence: running [/sbin/iptables -t filter -C FORWARD -s 10.244.0.0/16 -j ACCEPT --wait]: exit status -1:
Failed to ensure iptables rules: Error checking rule existence: failed to check rule existence: running [/sbin/iptables -t nat -C POS TROUTING -s 10.244.0.0/16 ! -d 224.0.0.0/4 -j MASQUERADE --random-fully --wait]: exit status -1:
Can someone explain what this kind of messages are indicating? Can this be a hardware problem? Does it make sense to switch form flannel to another kuberentes container network interface (CNI) - e.g. Calico?
As already mentioned in the comments debian buster uses nftables backed instead of iptables:
NOTE: iptables is being replaced by nftables starting with Debian Buster - reference here
Unfortunately the nftables are not compatible at this moment with kubernetes.
In Linux, nftables is available as a modern replacement for the kernel’s iptables subsystem. The iptables tooling can act as a compatibility layer, behaving like iptables but actually configuring nftables. This nftables backend is not compatible with the current kubeadm packages: it causes duplicated firewall rules and breaks kube-proxy. You could try to switch to legacy option like described here but I'm not sure about this solution as I don't have a way to test it with your Os. I solved similar case with debian with this here.
Alternative way would to switch to Calico which actually supports nftbacked with FELIX_IPTABLESBACKEND. This parameter controls which variant of iptables binary Felix uses. Set this to Auto for auto detection of the backend. If a specific backend is needed then use NFT for hosts using a netfilter backend or Legacy for others. [Default: Auto].
When installing calico with containerd please also have a look a this case.
I have a problem for 2 days with eclipse console for payara that is not working anymore.
After I restart the server the only thing that is displayed is:
2018-08-25T05:28:01.959+0000|Info: Running Payara Version: Payara Server 4.1.2.174 #badassfish (build 192)
2018-08-25T05:28:01.961+0000|Info: Server log file is using Formatter class: com.sun.enterprise.server.logging.ODLLogFormatter
2018-08-25T05:28:02.587+0000|Info: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
2018-08-25T05:28:02.594+0000|Info: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
2018-08-25T05:28:02.599+0000|Info: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.
2018-08-25T05:28:02.694+0000|Info: Authorization Service has successfully initialized.
2018-08-25T05:28:02.776+0000|Info: Registered org.glassfish.ha.store.adapter.cache.ShoalBackingStoreProxy for persistence-type = replicated in BackingStoreFactoryRegistry
2018-08-25T05:28:02.809+0000|Info: Grizzly Framework 2.3.31 started in: 86ms - bound to [/0.0.0.0:8080]
2018-08-25T05:28:02.937+0000|Info: Grizzly Framework 2.3.31 started in: 24ms - bound to [/0.0.0.0:8181]
2018-08-25T05:28:02.954+0000|Info: Registered fish.payara.ha.hazelcast.store.HazelcastBackingStoreFactoryProxy for persistence-type = hazelcast in BackingStoreFactoryRegistry
2018-08-25T05:28:02.956+0000|Info: Registered Hazelcast BackingStoreFactory with persistence-type = hazelcast
2018-08-25T05:28:03.027+0000|Info: Grizzly Framework 2.3.31 started in: 14ms - bound to [/0.0.0.0:4848]
2018-08-25T05:28:03.154+0000|Info: Grizzly Framework 2.3.31 started in: 6ms - bound to [/0.0.0.0:3700]
2018-08-25T05:28:03.356+0000|Info: Created HTTP listener http-listener-1 on host/port 0.0.0.0:8080
2018-08-25T05:28:03.364+0000|Info: Created HTTP listener http-listener-2 on host/port 0.0.0.0:8181
2018-08-25T05:28:03.367+0000|Info: Created HTTP listener admin-listener on host/port 0.0.0.0:4848
2018-08-25T05:28:03.417+0000|Info: Created virtual server server
2018-08-25T05:28:03.421+0000|Info: Created virtual server __asadmin
2018-08-25T05:28:03.756+0000|Severe: The SSL certificate has expired: [
[
Version: V3
Subject: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 1024 bits
modulus: 135786214035069526348186531221551781468391756233528066061569654028671100866720352830303278016129003918213826297308054231261658522889438712013757624116391437358730449661353175673177742307421061340003741057138887918110217006515773038453829253517076741780039735595086881329494037450587568122088113584549069375417
public exponent: 65537
Validity: [From: Sat Aug 22 16:41:51 GMT 1998,
To: Wed Aug 22 16:41:51 GMT 2018]
Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
SerialNumber: [ 35def4cf]
Certificate Extensions: 7
[1]: ObjectId: 1.2.840.113533.7.65.0 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 0D 30 0B 1B 05 56 33 2E 30 63 03 02 06 C0 ..0...V3.0c....
[2]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 48 E6 68 F9 2B D2 B2 95 D7 47 D8 23 20 10 4F 33 H.h.+....G.# .O3
0010: 98 90 9F D4 ....
]
]
[3]: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]
[4]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[CN=CRL1, OU=Equifax Secure Certificate Authority, O=Equifax, C=US]
Despite the fact that Payara log (server.log) is populated after this with details, eclipse console not.
The used woraround was to use a tail -f server.log
PS: that happens to everybody in the office. So I guess it's something related with payara ssl expired certificate.
I'm using:
Payara Server 4.1.2.174 #badassfish (build 192) and Eclipse Java EE IDE for Web Developers. Version: Oxygen.3a Release (4.7.3a) Build id: 20180405-1200
I think You can simply remove the failing certificate from the keystore. For me the failing certificate had alias: equifaxsecureca and was stored in cacerts.jks
I used the following command:
keytool.exe -delete -alias equifaxsecureca -keystore cacerts.jks -storepass <your pass>
BTW. There is also another one that is failing: gtecybertrustglobalca
I am currently attempting the Raspberry Pi iBeacon tutorial posted by RadiusNetworks at
http://developer.radiusnetworks.com/2013/10/09/how-to-make-an-ibeacon-out-of-a-raspberry-pi.html
but I am having issues with the connection timing out after a few seconds. I have performed a fresh build of raspbian, and have tried with 2 different dongles (AZIO V400 and IOGEAR GBU521), and I have tried with Bluez 5.8 per the tutorial as well as Bluez 5.11, both on fresh Raspbian loads.
When I call the start script I see:
pi#piBlueTest ~ $ ./start
Launching virtual iBeacon...
LE set advertise enable on hci0 returned status 12
< HCI Command: ogf 0x08, ocf 0x0008, plen 44
1E 02 01 1A 1A FF 4C 00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60
D0 F5 A7 10 96 E0 00 00 00 00 C9 00 00 00 00 00 00 00 00 00
00 00 00 00
> HCI Event: 0x0e plen 4
01 08 20 00
Complete
This triggers an "Entered" event on the iPhone using the "Locate iBeacon" app, and shows a distance in meters for a few seconds. It then shows "Distance: unknown" as the range for several more seconds, followed by an "exit" event occurring. When I run the sequence with "hcidump" running, I get
HCI sniffer - Bluetooth packet analyzer ver 5.11
device: hci0 snap_len: 1500 filter: 0xffffffff
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
> HCI Event: Command Complete (0x0e) plen 4
LE Set Advertise Enable (0x08|0x000a) ncmd 1
status 0x0c
Error: Command Disallowed
< HCI Command: LE Set Advertising Data (0x08|0x0008) plen 44
> HCI Event: Command Complete (0x0e) plen 4
LE Set Advertising Data (0x08|0x0008) ncmd 1
status 0x00
< HCI Command: LE Set Advertising Parameters (0x08|0x0006) plen 15
min 1280.000ms, max 1280.000ms
type 0x00 (ADV_IND - Connectable undirected advertising) ownbdaddr 0x00 (Public)
directbdaddr 0x00 (Public) 00:00:00:00:00:00
channelmap 0x07 filterpolicy 0x00 (Allow scan from any, connection from any)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
status 0x00
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
> HCI Event: Command Complete (0x0e) plen 4
LE Set Advertise Enable (0x08|0x000a) ncmd 1
status 0x00
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x00 handle 64, role slave
bdaddr B8:F6:B1:1C:15:C8 (Public)
> ACL data: handle 64 flags 0x02 dlen 11
ATT: Read By Type req (0x08)
start 0x0001, end 0xffff
type-uuid 0x2a00
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 64 reason 0x13
Reason: Remote User Terminated Connection
It appears that the iPhone is trying to initiate a connection to the pi, and then fails at negotiating that connection which then ends the advertisement.
I have completed the steps from the tutorial to the letter, and cannot seem to determine what is causing the disconnect. I have tried changing bluez versions, and tried different hardware, but to no avail. Any ideas what step I may be missing? I have searched everything I can think of for clues, but have not found the answer yet. Thanks in advance for any advice!
Try setting the device to "advertise and not-connectable" (3 instead of 0) instead of "advertise and connectable"
sudo hciconfig $BLUETOOTH_DEVICE leadv 3
We suddenly had a beacon going down after a few seconds due to a laptop trying to connect. Setting the device to not-connectable solved the problem.
Looks like you have it solved but I'll go ahead and post for others that may have the same problem I did and find this thread.
Like Chris, I completed the steps from the tutorial with the exception of using bluez 5.11. After some experimentation I had to change the order of the steps in the "start" script. Not sure why but this seems to be the only order in which it will work correctly. Maybe I did something wrong?
#!/bin/sh
. ./ibeacon.conf
echo "Launching virtual iBeacon..."
sudo hciconfig $BLUETOOTH_DEVICE up
sudo hciconfig $BLUETOOTH_DEVICE noleadv
sudo hciconfig $BLUETOOTH_DEVICE leadv 0
sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 $UUID $MAJOR $MINOR $POWER 00 00 00 00 00 00 00 00 00 00 00 00 00
echo "Complete"
Perhaps you can stop this from happening by making whatever device is attempting a connection stop doing so. This is not normal for iOS. Did you tell it to attempt a connection? Are you sure it is the iOS device doing this? Perhaps it is your computer?
Alternately, if you cannot get it working yourself, I can provide a free .iso file with the exact code we put on the units we sell preassembled. This could eliminate a build problem. Please send a note through our sales contact if you want to try this.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I'm trying to configure my Windows 7 PC to wake on lan (S4 and S5), but it just doesn't work. I have followed all the steps.
Changed my network adapter settings to wake on magic packet
Opened UDP port 7 on my windows firewall
Port forwarded my router on UDP port 7 to my PC
Configured BIOS (my motherboard - Intel DH67BL) to wake on LAN
I'm sending the magic packet through an android app (name: wake on lan). I used a sniffer utility on my PC to check if it was receiving the magic packet. Below is the packet details. I have a doubt here, the packet details show MAC address (as below). But, my adapter's MAC address is different. And I have set the correct MAC address while sending the magic packet. Is the app changing the MAC address before sending? Please help!
---------------------------Wake-On-LAN Magic Packet---------------------------
Time received:
09/15/12 12:13:34
UDP Header:
|-Source IP : 157.56.106.184
|-Destination IP : 192.168.1.2
|-Source Port : 3544
|-Destination Port : 52146
|-UDP Length : 117
|-UDP Checksum : 675
MAC Address:
FF FF 00 00 00 00
Raw Data (109 bytes):
00 01 00 00 8C 37 59 92 1E 68 49 48 00 00 00 34
4D 8A 27 66 D1 60 00 00 00 00 30 3A FF FE 80 00
00 00 00 00 00 80 00 F2 27 62 C7 95 47 FE 80 00
00 00 00 00 00 00 00 FF FF FF FF FF FE 86 00 64
9D 00 00 00 00 00 00 3A 98 00 00 07 D0 03 04 40
40 FF FF FF FF FF FF FF FF 00 00 00 00 20 01 00
00 9D 38 6A B8 FF 00 00 00 00 20 01 00
Thanks,
Sharath
3) Port forwarded my router on UDP port 7 to my PC
You need to forward UPD 7 and/or UDP 9 to LAN broadcast address, not to your PC's IP address.
The reason why is because when your PC is turned off, it doesn't have an IP address assigned, so the router does not have the binding with MAC address <=> IP adress in the ARP table, and can't forward the packet.
Reason: Because you don't Bind Your MAC to Your Local IP
Solution: Access to your router, use MAC Bing (or similar feature)
Note: if you use 2 or more router before your PC, you have to Mac binding and and Port forwarding on ALL router
I have added two certificates into my server's(jboss) keystore with domain name in both as "localhost". So now if a local client accesses the server which of the certificates will be sent to the client.
There is no error thrown in jboss, and it is working fine. I just want to know how jboss is choosing which certificate to send?
Listing the contents of the truststore used by java program.
Your keystore contains 2 entries
tomcat, 5 Mar, 2012, trustedCertEntry,
Certificate fingerprint (SHA1): B0:F0:98:5F:E5:D0:D6:24:58:B6:38:07:97:38:95:D5:
AB:28:E1:1E
tomcat1, 6 Mar, 2012, trustedCertEntry,
Certificate fingerprint (SHA1): C4:2B:E8:14:F9:85:5A:05:F2:1F:58:AE:65:FB:0E:8F:
DD:23:97:87
both tomcat and tomcat1 have the cn=localhost
Listing the contents of the keysttore used by jboss.
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries
tomcat, 5 Mar, 2012, PrivateKeyEntry,
Certificate fingerprint (SHA1): B0:F0:98:5F:E5:D0:D6:24:58:B6:38:07:97:38:95:D5:
AB:28:E1:1E
tomcat1, 6 Mar, 2012, PrivateKeyEntry,
Certificate fingerprint (SHA1): C4:2B:E8:14:F9:85:5A:05:F2:1F:58:AE:65:FB:0E:8F:
DD:23:97:87<br>
Displaying the keystore entry using th keytool's list "-v" option asper Kevin's request.
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries
Alias name: tomcat
Creation date: 5 Mar, 2012
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=localhost
Issuer: CN=localhost
Serial number: 5aaac34c
Valid from: Mon Mar 05 15:04:46 IST 2012 until: Sun Jun 03 15:04:46 IST 2012
Certificate fingerprints:
MD5: 6A:9D:10:37:4F:98:7F:85:D5:93:95:CC:C3:84:07:D8
SHA1: B0:F0:98:5F:E5:D0:D6:24:58:B6:38:07:97:38:95:D5:AB:28:E1:1E
SHA256: FB:F5:BC:9F:17:E9:28:8C:77:1B:40:17:8B:D3:12:71:05:0D:CF:9C
99:00:C4:25:76:46:CE:E0:0C:E6:6B
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: F6 B3 2E B5 A0 76 78 7E 9D B6 2A D6 4A 6A 8D 96 .....vx...*.Jj..
0010: FA 7D 47 9B ..G.
]
]
*******************************************
*******************************************
Alias name: tomcat1
Creation date: 6 Mar, 2012
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=localhost
Issuer: CN=localhost
Serial number: 4891416
Valid from: Tue Mar 06 06:41:21 IST 2012 until: Mon Jun 04 06:41:21 IST 2012
Certificate fingerprints:
MD5: B9:31:FE:75:E9:28:E6:BC:F2:94:60:93:7B:0C:00:63
SHA1: C4:2B:E8:14:F9:85:5A:05:F2:1F:58:AE:65:FB:0E:8F:DD:23:97:87
SHA256: 58:7B:D3:A1:2C:8E:C1:C9:26:0A:9F:A1:86:D1:79:76:34:D2:83:6A
88:0C:E1:36:F5:88:3F:DC:F7:D7:89
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: F1 BF 69 B4 CA D6 9E 72 AC C3 26 9F CD 57 58 7A ..i....r..&..WXz
0010: 62 19 8B B8 b...
]
]
*******************************************
*******************************************
By default, JBoss (or Apache Tomcat) will use the default settings the default X509KeyManager to choose which certificate to use: it will pick the first one it finds in the keystore that is valid for the type of key (e.g. RSA for an RSA-based cipher suite) and at the time of connection.
Failing that, if an alias is explicitly specified in keyAlias, it will pick the certificate in that alias (and it will fail if the key type isn't correct).
If, instead of this, the name of a custom class implementing SSLImplementation is given in the SSLImplementation attribute, it will be used to provide the SSLSocketFactory (so the alias choice will be done however its SSLContext/KeyManager is configured).
Support for Server Name Indication (SNI), which is what would allow the key manager to use the requested host name to help make a choice, was only introduced in Java 7, and only on the client side, so the JSSE cannot use it on the server side currently.
What exactly are you trying to achieve ? The certs are stored in the keystore and presented to the user based on hostname match. This is incorrect, please see below.
Logically speaking it would load only one of these which in turn will be served to the user.
--Edit--
Trying to simplify by pointing to another link
Say you specify "keyAlias" in your jboss configuration to "tomcat" ; then the tomcat alias will be picked up
If you do not specify an alias then the "first key read in the keystore will be used"