I'm setting up use of Dropbox webhooks in a web application. I'd like to do the development on my local machine. I can access my local machine via https from the Internet, but when I try to add the URL as a webhook URI in Dropbox App Console I found that it seems to require the SSL certificate to not be self-signed. Is there a way to do testing on a local machine with a self-signed certificate? The error message is below. After complaining about the cert it also says there is no response body, but I'm guessing this is because it didn't even get as far as checking the body (I've tested my URL by loading it directly in a browser and via wget from a remote server and the response contains the desired content).
Error: SSL certificate problem: self signed certificate
Request: GET
https://my.domain.com/dropbox-webhook?challenge=urFYi8g-jCkVM7aP676BAyYlH7Z3u04RAJH5Lu0AYLg
Response:(No headers)
Response Body (First 256 bytes):(No response body)
For local development, I leaned on https://github.com/dropbox/dropbox_hook pretty hard to test everything. It's what I would recommend for local development of dropbox webhooks.
Related
I have created a couple of API's and now I have to test them using Fiddler or any certificate friendly tools. The requests which are not having valid certificate must be rejected by the server.
Certificate Background
Here are the two certificate's issues by CA
I have one intermediate public certificate entitled as
MyIntermediate.cer
I have a private certificate for each device which will request my API to fetch data.
I have uploaded public certificate - MyIntermediate.cer to server [Azure APIM]
Now to test the API's, I have to use some tools like Fiddler or Postman or any other tool which supports certificate upload/reading from store
I do not see any options in these tools to upload or read from windows store. Here I need help
I see settings in postman but it seems like not for CA certificates because I do not have key file.
APIM Details
Azure API manager is the service provided by Microsoft. All the request will be processed by APIM. I have uploaded MyIntermediate.cer public certificate to APIM. So, to call GetCustomer someone has to have certificate which is trusted by MyIntermediate.cer.
You need to have "private certificate for each device" along with it's password (if it was saved with one) to make an authenticated call. If you want to rely on APIM's ability to validate certificate chain then you'll indeed need to upload intermediate certificate, and possible root certificate as well if it's not one of the public ones.
I was asked to secure my stateless api endpoint using cert based authentication. I read about the subject, and realized I needed to create a middleware to inspect the request, and then check for the x-ARR-ClientCert header, to check whether the certificate is valid or not, based on some thumbprint. So far, so good.
The problem is that I can't test the middleware, because I don't have idea on how to send such a header. I already have a self signed certificate(.crt) and a key(.key). I tried with postman, but I can't see the x-ARR-ClientCert being sent while debugging on VS2017.
Any Help?
Edit 1
I'm following this tutorial: https://blogs.msdn.microsoft.com/kaevans/2016/04/13/azure-web-app-client-certificate-authentication-with-asp-net-core-2/
I know it's a bit old, but at the end the writer shows the browser asking for a certificate, but I just can't manage for the browser to ask for the certificate.
One thing I forgot to mention here, is that my API is on a local Service Fabric Cluster, so that might be the problem
Edit 2
For Postman, I've followed this tutorial: Postman Tutorial, but had no luck: first I had to turn off ssl check, and then when added the certificate to Postman, the x-ARR-ClientCert header wasn't being sent.
I've also tried curl: > curl --cert cert.crt --key client.key https://localhost/api/values --insecure but still the x-ARR-ClientCert isn't being sent.
I am not sure what you are trying to accomplish...
In a mutual certificate authentication, the browser handles the authentication\certificate exchange, and when the user tries to access an endpoint secured by client certificate, the server tells the client(browser) that it requires a certificate to accept the connection and the browser popup a message to the user asking for a certificate to be used, there is a nice write about it here.
If the plan is to do it for automation, the postman blog has an article on how you setup client certificates for this scenario. The other option is trying to send the certificate using CURL as described here.
Secondly, you are reinventing the wheel, there are already some ready to use implementations in kestrel using HttpsConnectionAdapterOptions.ClientCertificateMode = RequireCertificate and some authorization middlewares here and here.
And finally, make sure that there is no proxy in the middle or that the proxy or gateway is not removing the certificate from the client connection.
I am trying to send out a WebRequest request like https://identityserver.github.io/Documentation/docsv2/advanced/clientCerts.html specifies with a handler containing the Client Certificate.
I've gotten to the point that i have determined that the ClientCertificate is just not being sent through fiddler, so it is not read in the ServerVariables["CERT_FLAGS"] when the Owin LoadCertificate is called.
So i have removed all the steps from the process except (IdentityServer3.Samples/source/Clients/ClientCertificateConsoleClient/Program.cs)
async Task<TokenResponse> RequestTokenAsync()
{
var cert = new X509Certificate2("Client.pfx");
var handler = new WebRequestHandler();
handler.ClientCertificates.Add(cert);
var client = new TokenClient(
Constants.TokenEndpoint,
"certclient",
handler);
return await client.RequestClientCredentialsAsync("read write");
}
but I am still not seeing in fiddler in the raw request the certificate. I have looked at the source code for HttpWebRequest and only see it handles the ClientCertificate in the GetConnectionGroupLine, and then its a hash code which i also don't see in fiddler. I'm working with Windows 7 and i have turned on the iis client certificate mapping authentication and enabled the setting in iis express applicationhost in the 2015 .vs subfolder and the primary one in my docuemnts. What am I missing here?
reference: https://social.msdn.microsoft.com/Forums/en-US/f88a23f2-3dbe-4202-baf2-a5b05b027fe6/httpwebrequest-not-sending-client-certificate-to-server?forum=netfxnetcom
https://github.com/IdentityServer/IdentityServer3/issues/3220 - can't really find this on stackoverflow..
TLDR: Your problem (at this point) is Fiddler not HttpWebRequest/dotnet. (Edited to clarify.)
Fiddler doesn't display TLS info including certs. Fiddler works on, and displays in numerous formats, the HTTP-level data (requests and responses, including application data). When HTTPS transports this HTTP data over SSL/TLS, Fiddler does not display the SSL/TLS-specific data, which in addition to server and optional client certificates (currently) includes version, suite, possibly compression, curve, format and next-protocol negotiation, nonces, ephemeral keys, renegotiation control, signature algorithm control, server name indication, ticket, and other crypto options like encrypt-then-mac and extended-master-secret. The "raw" tab displays all the HTTP data without interpretation, but not the SSL/TLS data.
Fiddler doesn't request client auth. An SSL/TLS session uses a client certificate to perform client authentication only when requested by the server, and when your client connects to the real IdentityServer it presumably requests this. But when Fiddler is used, there is one SSL/TLS session from the client to Fiddler, and an entirely separate SSL/TLS session from Fiddler to the server. On the session from your client to Fiddler, Fiddler does not request client authentication, so your client doesn't and can't send or use its certificate.
Client auth can't be relayed anyway. If Fiddler did request client auth on the session from your client, it couldn't use that information to authenticate the session to the real server. Client auth doesn't just send the client cert, it also uses the private key to sign the concatenation (called a transcript) of the handshake messages. Since the handshake between your client and Fiddler and between Fiddler and the server are quite different, this signature is invalid for the server-side handshake and sending it would (correctly) be rejected as invalid by the server.
Instead Fiddler can do the client auth. If you want to route HTTPS traffic using client auth through Fiddler, you need to instead configure Fiddler to do the client auth on the session with the server; for a fixed setting you can just drop the identifying certificate in Fiddler's config directory, for per-session settings you need to write some FiddlerScript. The private key (and chain) needs to be in the Windows cert store, not (just) in a file. See:
http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/RespondWithClientCert
https://www.fiddlerbook.com/fiddler/help/httpsclientcerts.asp
Fiddler: Respond to Requests Requiring a Client Certificate (on SO)
https://security.stackexchange.com/questions/72916/can-fiddler-decrypt-https-traffic-when-using-elliptic-curves-client-cert-authe
If your actual problem is getting the client to support client auth when NOT using Fiddler, you need to take Fiddler out of the situation and use other debugging tools like a network trace.
Is there a reason why Facebook doesn't allow LetsEncrypt signed certificates in their "app development" section?
I keep getting this error:
(For the untrained eye, this is me trying to setup a webhook for new messages notifications)
Blurred out the host, but it's a valid host and using chrome or firefox on Linux and Windows doesn't give any errors.
SSLLabs also says the site is perfectly valid.
Running curl https://... on my own host, sure enough I get the same error,
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
So my question is, why have Facebook (that openly supports LetsEncrypt) decided to use default curl CA bundle to verify the callback-url of an app? If that doesn't allow LetsEncrypt?
It appears to be counterproductive to me.
Is there a way around this?
SSLLabs also says the site is perfectly valid.
It shows a warning in orange, that the certificate chain is incomplete.
Your server should present all necessary intermediate certificates as well, in addition to the certificate issued for your domain. (Which was simply forgotten here by mistake.)
I have a PowerShell script that uploads a batch of files to lingq.com.
I created it the following way: I logged in to the site via browser, and made an upload manually through the web page. I grabbed the request in Fiddler, then duplicated it in PowerShell, including the authentication cookies. I'd just swap out the content of the request and send it. It wasn't pretty, but it worked and saved me an immense amount of time. The only downside was every time I had to log in to the site again, my authentication cookies got invalidated and I had to grab them again. But that I could live with.
They seem to have changed all their communication to https, because now instead of a request to
http://www.lingq.com/learn/ja/import/contents/?add
all I see in Fiddler is
"Tunnel to www.lingq.com/443"
Fiddler also gives me a warning that HTTPS decryption is disabled. When I enable it, and start capturing, Firefox gives me a certificate error when I try to access the site (or any other site that uses certificates, including Google):
www.lingq.com uses an invalid security certificate.
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)
My script is now completely useless, every request I send returns the login page. And because of Fiddler messing up the certificates, I can't further reverse engineer the site to mimic the requests correctly.
How can I make https decryption work in Fiddler? Alternatively, is there a way my script can properly authenticate itself on the site? I have tried the steps described here:
How to make an authenticated web request in Powershell?
It didn't work at all. My guess is some sort of federated authentication is in place, but frankly I'm completely out of my depth here.