I have an FB app, when I enter as the deauthorization callback URL my development box address, the box is pinged with this request after app removal on FB:
POST /facebook/deauthorize HTTP/1.1
Host: bashman.org
Accept: */*
Content-Length: 261
Content-Type: application/x-www-form-urlencoded
Connection: close
fb_sig_uninstall=1&fb_sig_locale=de_DE&fb_sig_in_new_facebook=1&fb_sig_time=1322732591.2685&fb_sig_added=0&fb_sig_user=1476224117&fb_sig_country=de&fb_sig_api_key=e39a74891fd234bb2575bab75e8f&fb_sig_app_id=32352348363&fb_sig=f6bbb27324aedf337e5f0059c4971
(The keys are fake here)
BUT! when I enter my production box URL in the deauthorization callback URL, the POST request is never made. Tested it with Tcpdump. No request on my production machine, why?
I checked with mtr the route from my production box to the IP address the request came from, all is OK, 0% packet lost.
The hostname port and path is correct, tested it 1k times, no firewall, IDS, or other systems blocking my ethernet slot.
Why is the Post callback not called? (How can I fix it?)
How I can debug this to determine what the issue is?
You can try using the facebook URL Debugger and see if facebook's servers are able to reach your callback URL...
Viewing the information facebook IS able to retrieve might help you debug this issue.
I had the same issue with NGINX and after hours of debugging I found this solution in NGINX documentation:
Some browsers may complain about a certificate signed by a well-known
certificate authority, while other browsers may accept the certificate
without issues. This occurs because the issuing authority has signed
the server certificate using an intermediate certificate that is not
present in the certificate base of well-known trusted certificate
authorities which is distributed with a particular browser. In this
case the authority provides a bundle of chained certificates which
should be concatenated to the signed server certificate. The server
certificate must appear before the chained certificates in the
combined file:
$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt
The resulting file should be used in the ssl_certificate directive:
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.chained.crt;
ssl_certificate_key www.example.com.key;
...
}
In short, you just need to concatenate the certificate and the bundle and use the result as your ssl_certificate.
I am receiving the post requests from Facebook now.
Related
I want to configure Haproxy so that it only requires client certificate when specific URL accessed? Ex:
www.test.com - it proceeds normally.
www.test.com/secure - haproxy requires the client certificate.
To understand why this isn't directly possible requires an understanding of how TLS (SSL) works. TLS encrypts the connection before the HTTP request is sent (over the now-encrypted connection). By the time the URL is known by HAProxy, the time for requiring a client certificate has already passed.
For practical reasons, an endpoint (HAProxy frontend or listen) needs to either require a certificate for connections, or not... however, using verify optional it might be possible to achieve what you want. Using verify optional means that the proxy will ask for a client cert upon connection, and if either the client offers no cert or if the cert is valid according to the ca-file, the client will be allowed to connect. Invalid certs will result in disconnection.
Then, the ssl_c_used fetch could be used to deny requests for that path for clients who didn't present the "optional" certificate, earlier.
http-request deny if { path_beg /secure } ! { ssl_c_used }
The viability of this solution depends on how gracefully browsers behave when asked for a certificate that they would not have -- and all connecting browsers will be asked for a certificate.
But there is no way of doing exactly what you are asking, either in HAProxy or on any other platform since, by design, the path is unknown until after TLS negotiation is already complete.
We procured standard ssl certificate to mydomain.net from godadday.
We shutdown live server mydomain.com, configured new server mydomain.net with ssl, everything works fine.
We have added redirect records in DNS for mydomain.com to mydomain.net
www.mydomain.com redirecting properly to www.mydomain.net
We are experiencing a issue, when any request to https //www.mydomain.com
redirection happening but with untrusted certificate error message.
www.mydomain.com uses an invalid certificate.
The certificate is valid for the following names:
www.mydomain.net , mydomain.net
(Error code: ssl_error_bad_cert_domain)
Godaddy india support not able to resolve the issue, escalated to US support no update from US support.
Please suggest me how to resolve this issue?
Thanks,
ItsR
Redirection inside a HTTPS connection from domain A to domain B needs a proper certificate for domain A too, which does not seem to be in your case. This is because the redirection happens inside the TLS connection, i.e. the TLS connection needs to be established first which needs the proper certificate.
I'm trying to do this:
https://dummiesite.com --> http://dummiesite.com
and
http://dummiesite.com --> http://new.dummiesite.com
and
http://new.dummiesite.com --> https://new.dummiesite.com
So no matter what site the user goes, it will allways be redirected to https://new.dummiesite.com
The problem:
With I have a wildcard certificate for *.site.com. But it is only valid for all the subdomains of site.com, not for site.com itself. With lighttpd I cannot use more than one certificate per IP (I have only one), so when the user goes to https://dummiesite.com, it gets an error because the certificate is not valid.
That is why I'm trying to redirect https://dummiesite.com to http://dummiesite.com. How can I do it without a valid certificate and without showing the user errors?
Thanks for your help
You can't with the current certificate. HTTPS is HTTP inside an SSL tunnel, so before you can do the redirect at the HTTP level the SSL connection has to be established. But this fails because your certificate does not match the hostname. You need to get a certificate which includes both *.dummiesite.com and dummiesite.com (yes, this is possible).
Recently, the company I work for changed their name, and therefore is changing its domain name. Previously, we redirected all requests on port 80 of our web server to https : //www .olddomain.com, so that all pages were sent over SSL. Now that we have changed, our SSL certificate for www. olddomain.com has expired, and we want to redirect all requests for https : //www. olddomain.com to https : //www. newdomain.com (in case anyone bookmarked us as https : //.....).
I have tried every redirection method I know, mod_rewrite, DNS forwarding, etc, but I cannot get https : //www.olddomain.com to redirect to https : //www.newdomain.com, it says that the site is untrusted.
We are running Apache 2.2 on linux.
Any help would be appreciated.
Thanks!
Not to dive into unnecessary details - if certificate itself has expired, you won't be able to make trusted connection with it, browser will always warn. To make it transparent, you'd have to renew/buy valid certificate for old domain, or force any possible website user to first download, install and trust your own RootCA certificate (obviously impossible). Theoretically there are some browser-supported HTTPS protocol extensions to deal with original construction of https, but even if they were implemented it still won't "help" for outdated certificate. It is problem with certificate itself, not really with virtual server hostname / certificate common name recognition and matching for which such protocol extensions are conceptually planned/designed.
You should have been performing domain migration during time when old certificate was still valid. Have a look here CNAME SSL certificates as well.
I have an FB app, when I enter as the deauthorization callback URL my development box address, the box is pinged with this request after app removal on FB:
POST /facebook/deauthorize HTTP/1.1
Host: bashman.org
Accept: */*
Content-Length: 261
Content-Type: application/x-www-form-urlencoded
Connection: close
fb_sig_uninstall=1&fb_sig_locale=de_DE&fb_sig_in_new_facebook=1&fb_sig_time=1322732591.2685&fb_sig_added=0&fb_sig_user=1476224117&fb_sig_country=de&fb_sig_api_key=e39a74891fd234bb2575bab75e8f&fb_sig_app_id=32352348363&fb_sig=f6bbb27324aedf337e5f0059c4971
(The keys are fake here)
BUT! when I enter my production box URL in the deauthorization callback URL, the POST request is never made. Tested it with Tcpdump. No request on my production machine, why?
I checked with mtr the route from my production box to the IP address the request came from, all is OK, 0% packet lost.
The hostname port and path is correct, tested it 1k times, no firewall, IDS, or other systems blocking my ethernet slot.
Why is the Post callback not called? (How can I fix it?)
How I can debug this to determine what the issue is?
You can try using the facebook URL Debugger and see if facebook's servers are able to reach your callback URL...
Viewing the information facebook IS able to retrieve might help you debug this issue.
I had the same issue with NGINX and after hours of debugging I found this solution in NGINX documentation:
Some browsers may complain about a certificate signed by a well-known
certificate authority, while other browsers may accept the certificate
without issues. This occurs because the issuing authority has signed
the server certificate using an intermediate certificate that is not
present in the certificate base of well-known trusted certificate
authorities which is distributed with a particular browser. In this
case the authority provides a bundle of chained certificates which
should be concatenated to the signed server certificate. The server
certificate must appear before the chained certificates in the
combined file:
$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt
The resulting file should be used in the ssl_certificate directive:
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.chained.crt;
ssl_certificate_key www.example.com.key;
...
}
In short, you just need to concatenate the certificate and the bundle and use the result as your ssl_certificate.
I am receiving the post requests from Facebook now.