4

I've implemented a Deauthorize Callback for my canvas app. It would appear that Facebook is unable to ping the Deauthorize Callback over https, but it has no problem with http. I'm logging all connections and there is no record of pinging the callback from Facebook, though if I ping it myself it is logged. Further, if I have Facebook ping the callback via the URL debugging tool (https://developers.facebook.com/tools/debug) it is successful.

Given that https does not work, I'm assuming Facebook's servers don't care for my certificate's issuer / authority. Is there a definitive list of certificate authorities that will work with Facebook's back end processes? Alternatively, is there a way to submit a new authority to Facebook for inclusion in their list of accepted certificate authorities?

Edit: My SSL certificate was issued by "Starfield Technologies" which I believe is a simple DBA of GoDaddy. I normally avoid GoDaddy, but this SSL was cheap. Maybe I'm getting what I've paid for, as it were.

CasaDeRobison
  • 377
  • 2
  • 12
  • 1
    To ensure this is an issue with certificate you can simply pass `HTTPS` link for any OpenGraph object located on your domain to [URL Linter](http://developers.facebook.com/tools/debug). Or subscribe to Real-time updates just to check that callback is reached... If this is issue with certificate file a bug. – Juicy Scripter Apr 29 '12 at 05:50
  • 2
    I agree with Juicy. If realtime can get to the https but not the deauth callback, then file a bug with Facebook. Report it back here so others who stumble across this stackoverflow question knows it's a logged bug. FWIW, I don't think it is an issue with the cert, otherwise no one would be able to get to HTTPS. – DMCS May 01 '12 at 21:30
  • I don't have any OpenGraph objects in my domain at this time, but if I pass the deauth callback link to URL Linter (as mentioned above) it is able to access the link and shows the output, noting it couldn't access an OpenGraph object. And obviously my logs show the access from Facebook at that point. For this reason I believe the problem exists on whatever back end server pings the deauth callback. I've adequately worked around it by making just my deauth callback an HTTP link vs HTTPS. I'll see about reporting it (if I can find a reporting method that is actually monitored by a human). – CasaDeRobison May 07 '12 at 00:40
  • Just to keep track, here is a [facebook bug report](https://developers.facebook.com/bugs/431790076871933) describing the issue – zentralmaschine Aug 14 '12 at 09:23

1 Answers1

3

I finally figured out what the problem was with this, and wanted to document it so that other people can benefit from my stupidity.

My abilities are in software development. I'm not a skilled website administrator. I know just enough to get by. The problem was due to the SSL configuration of my web server.

When I bought my certificate two years ago, I installed it incompletely. I created and installed a PEM file for my domain, but never configured the web server to know about the certificate authority bundle (sf_bundle.crt in my case).

The direct consequence of this is, if you access the secure deauth callback from your web browser, and your web browser is configured with all the needed root and intermediate certificates, you will successfully "deauth" the application.

However, if a web client (such as the Facebook backend computers that ping your deauth callback) tries to access the web server in question and it does not already have all the intermediate certificates available, the SSL handshaking will fail because the client can't authenticate the certificate all the way back to a root CA certificate.

I hope this makes sense. As I said, web administration is not my strong suit, and I missed a step. If you install the CA bundle in your web server configuration properly, the Facebook backend computer will be able to authenicate your site and successfully ping your deauth callback.

If anything here is unclear, please don't hesitate to ask. I'll help if I can.

CasaDeRobison
  • 377
  • 2
  • 12