We are trying to integrate Xero API in our web system, however, we are experiencing a particular problem which has not been responded at Xero forum pages, therefore, I had no choice to share it here.
It is a partner application integration and it requires to have some certain files & password within the software.
We have generated the .p12 and pfx files and addressed in the configuration file.
We have downloaded the wrapper solution from Github which is officially supported by Xero and all we did is to change the settings in the configuration file and run the Console App which is named "Xero.Api.Example.Counts" and OAuthTokens.css class throws an exception which is IIS 7.5 Detailed Error - 403.7 - Forbidden.
This response is generated from Xero API and we can retrieve more information in detail as "The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) client certificate that the Web server recognizes"
The certificates are confirmed by Xero and we are using the correct Consumer Key & Secret in the configuration file.
We have also tried some other simple solution which does talk to Xero API using the partner application that has got the same result.
Is there any advise that you can share with us? Thank you
Install the certificates on your client machine and then use them.
For Partner Application of Xero, you need
Xero Entrust Certificate - Called Partner Certificate (issues by Xero)
and Signing Certificate - Generated by yourself and registered with Xero.
The Client Machine where you are trying to connect, you need to install these certificates in the Certificate Store.
If it is Windows, you can find instructions to install certificates over here:
Instructions
Related
I want to be able to expose my local machine address to the internet to be able to work with:
Google OAuth2 flow;
Receiving Push-Notifications for changes in my calendars/events;
So that, I need some tool that will expose my local machine URLs to the Internet so Google will be able to use this web hooks.
I found that ngrok with basic(5$) subscription works for me. Free versions doesn't work since I need SSL as it's required by google:
This is your Webhook callback URL, and it must use HTTPS. Note that
the Google Calendar API will be able to send notifications to this
HTTPS address only if there is a valid SSL certificate installed on
your web server. Invalid certificates include: • Self-signed
certificates. • Certificates signed by an untrusted source.
• Certificates that have been revoked. • Certificates that have a
subject that doesn't match the target hostname.
The question is whether there is something else I haven't taken into account that will force me to buy more expensive type of subscription? Maybe some specific requirenments from Google that basic subscription can't work with.
Basic $5 subscription works perfectly. It fits all Google's requirements + it provides static URLs that make it possible to receive PUSH notifications even when you restart your ngrok or computer.
Here's my setup
an IdentityServer 4 as a stateless reliable ASP.NET Core service.
a WebAPI as a reliable ASP.NET Core service.
using them with a JS client, it is now working with HTTP. The problem is with HTTPS. The WebAPI needs to request the openID config via htttps [is4URL].well-known/openid-configuration. I'm getting this error
System.InvalidOperationException: IDX10803: Unable to obtain
configuration from:
'https://localhost:9999/.well-known/openid-configuration'. --->
System.IO.IOException: IDX10804: Unable to retrieve document from:
'https://localhost:9999/.well-known/openid-configuration'. --->
System.Net.Http.HttpRequestException: An error occurred while sending
the request. ---> System.Net.WebException: The underlying connection
was closed: Could not establish trust relationship for the SSL/TLS
secure channel. --->
System.Security.Authentication.AuthenticationException: The remote
certificate is invalid according to the validation procedure.
can anybody help me to make this work in localhost with the SF Local Cluster Manager?
Thanks
Here's my two cents worth but it will need to be verified...
I am assuming that you have created a self-signed certificate using following article or similar but the certificate has same properties.
https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-configure-ssl-certificate
This means that the certificate can not be verified via actual CA. Ofcourse with self-signed certificate this is not possible.
Now when you upload the certificate to Azure App Service it installs in CurrentUser - MyStore. With self-signed certificate, it also needs to be installed in LocalMachine Root store.
This is becouse then the machine's Certificate Authority can verify that certificate to be valid. (May be a security expert can correct me if I am wrong but thats my theory). I have got same setup on my locally hosted windows server where the self-signed certificate is installed in Root Certificate Store as well as Personal store and the app works. This is the reason I belive this happens.
So this part which needs to be verified. Following is the article which shows you how you can do this in Azure App service.
https://learn.microsoft.com/en-us/azure/cloud-services/cloud-services-configure-ssl-certificate-portal
AGAIN THIS IS JUST A THEORY THIS NEEDS TO BE VERIFIED. :)
EDIT:
I have just tested this and it is the case. In cloud services you can do as shown in second link above and create Web Job which install certificate in appropriate store.
For Azure App Service unfortunaltly you dont have access to root store. It has to be install in CurrentUser's personal store. Which means the self signed certificate will not work, and you have to purchase a real certificate. :( I think this is a real thumb down to Microsoft. Why should I need to pay for real certificate for my dev/test environment? (Rant Over)
For Service Fabric you will need to find out how to install certificate in Root Store as well as personal store (if thats possible at all). Here's Links that might be useful
http://ronaldwildenberg.com/running-an-azure-service-fabric-cluster-locally-on-ssl/
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security-update-certs-azure
Hope this helps.
I have the following setup:
A self signed certificate for development purposes
An OWIN hosted Web API, deployed on a local Azure Service Fabric Cluster as a ASF service. The Web API uses HTTPS facilitated with the dev certificate in question.
A simple .net client application that calls the Web API. In that application the ServicePointManager.ServerCertificateValidationCallback method is set so it always returns true (since the CA is not trusted)
Both the client application and the Web API are on the same local development machine. The certificate is installed in that same machine on the "machine store"
Now I am able to make calls to the web api using Fiddler by providing the required client certificate. However when I try to do the same via .net code (be it RestSharp or WebRequest) the client certificate is not present in the RequestContext object on the server side. This result in an Unauthorized response. I do not think the problem is with the client code, the certificate is loaded correctly and assigned to the http client or request. Fiddler shows encrypted tunneling to the server. However the client certificate does not seem to be present at the server side.
I am at a complete loss regarding what am I missing that could cause this behavior. Any help will be deeply appreciated.
Install the certificate into the 'Local Machine/Trusted People'.
The server needs to already trust the certificate before it asks. The CertificateRequest message that it sends lists the acceptable CAs that can sign the client certificate. If the client certificate's signer isn't in that message, it can't send it.
How you accomplish that in your environment is left as an exercise for the reader. In general now that SSL certificates are available free there is little reason to indulge in the time costs and administrative inconveniences of self-signed certificates. IMHO there wasn't even if you were paying for a CA signature.
I had a problem when a service called another service over HTTPS and it couldn't setup a secure connection. My problem was that since the service is running as NETWORK SERVICE, it couldn't find the certificate, because it was looking in the localmachine/my certificate store.
When I was running from my web browser it was working fine because then, my browser found the certificate in the currectuser/my certificate store.
Add the certificate to the machine/my store and see if it helps.
DocuSign documentation show that if using Embedded Signing or CONNECT, SSL need to implemented.
Security Certificates
If your integration uses Embedded Signing and/or DocuSign Connect Service, you may have to implement your SSL or X509 Certificate.
For Connect, please review our DocuSign Connect Service Guide, link provided below. You are required to provide a secure listener or an x509 Certificate.
If you use an x509 Certificate for Embedded Signing, please send your Account Manager the x509 Certificate’s Common Name, Issuer’s Name, Version, Serial Number, and Valid From and Valid To dates.
Does it mean that If i am not using the Embedded Signing or CONNECT then do I need to put the DocuSign root certificate into my server? I am just using the DocuSign Java Api that downloaded from Git.
If not which one to add? there are alot of certificates they have provided in this link DocuSign Trust
Docusign Connect sends HTTP POST messages to the endpoint you specify (i.e., to an endpoint on your server).
In the DocuSign demo environment (i.e., using your developer sandbox account), DocuSign Connect will send messages to either an HTTP or HTTPS endpoint.
However, in the DocuSign production environment (i.e., using a docusign.net account), DocuSign Connect requires that your endpoint be HTTPS. So when you're ready for your integration to 'go live' in the production environment, you'll need to ensure that the endpoint you've specified for Connect to send messages to is HTTPS (and if necessary, implement SSL to enable HTTPS for that endpoint).
Given what you said, and as long as you can make API calls (via HTTPS) without issue, then I would say you have no need to install any DocuSign certs.
Unfortunately that section of the document is out of date. Embedded signing does not require a customer to trust a DocuSign certificate.
I will work to get it updated.
I'm currently working on an automated deployment process for a hosted service for Windows Azure. The creation of the .cspkg and .cscfg files works perfectly using a call to msbuild. Now I'm writing a small .NET console app that should deploy these files to Azure using the Management REST API.
There is no problem concerning the API itself. I can send a request to the API using one of my management certificates. I upload the .cspkg file to Azure BLOB Storage and then try to call Upgrade Deployment. But every time I try, I get a "400 Bad Request" response stating that the certificate with thumbprint xy was not found. This certificate is the SSL certificate (not a management certificate) I'm using for HTTPS for my custom domain (DNS CNAME).
And now, the whole thing gets interesting:
When I deploy the files using the "Publish" command in my Visual Studio, there is no problem. (I compared the .cscfg/.cspkg files from VS and from my msbuild output: apart from a few GUIDs, they're identical). And furthermore, using the Silverlight Management thingy in my browser, I can even upload my generated files that could not be uploaded using the API.
When I retrieve a list of all certificates using the List Certificates call, the certificate which is said to be missing is apparently there. I can also retrieve its data using the Get Certificate call.
So why does Azure keep telling me that the certificate was not found when using the Upgrade Deployment call? Did anyone experience something similar? Has anyone the hint for me? Thanks in advance.
P.S.: This is what Azure says when I use the API:
<Error xmlns="http://schemas.microsoft.com/windowsazure" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<Code>BadRequest</Code>
<Message>The certitficate with thumbprint 7b232c4a2d6e3deadbeef120d5dbc1fe8049fbea was not found.</Message>
</Error>
P.P.S.: Yes, the word in the response is certitficate, not certificate.
OK, after using the List Subscription Operations API call to find out what Visual Studio calls to deploy apps, I found the solution.
Turns out that the URL I used for the API request was wrong, but: with all due respect, I blame Microsoft for lousily documenting its Azure Management API.
In their documentation, they write the URL to use is:
https://management.core.windows.net/<subscription-id>/services/hostedservices/<service-name>/deploymentslots/<deployment-slot>/?comp=upgrade
And the description is the following:
To generate the request URI, replace <subscription-id> with your subscription ID, <service-name> with the name of your service, <deployment-slot> with staging or production, and <deployment-name> with the unique name of your deployment.
What they forgot to mention is, that you have to use the DNS Name of your service, and not the Name! They could at least return an appropriate error message telling you that the service name is invalid, non-existent or doesn't belong to your subscription ID, instead of complaining about some certificate issue.
Thank you Microsoft, that cost me more than two days.
The error indicates that you have not uploaded that certificate into the hosted service's secret store. Visual Studio might be doing that automagically for you, but if you want to replicate it programmatically, then use the Add Certificate API call and upload the PFX into the deployment.
You can see '400 BadRequest - The certificate with thumbprint XYZ was not found.' appear in the CreateDeployment or UpgradeDeployment scenario for the following reason (which I just debugged):
You use the same certificate for subscription management as you do for e.g. SSL or Remote Desktop password encryption in your hosted service. You therefore will use the certificate with thumbprint XYZ to authenticate your service management REST call that creates the deployment.
When specifying your deployment parameters you pass in your CSCFG which references that same cert by its thumbprint, because it needs to configure Remote Desktop/SSL etc.
That cert is not yet added to your hosted service certs.
In this case the 400 Bad Request error really is telling you that you have a bad request, because the certificate in your CSCFG is not yet attached to your hosted service. The confusion arises (for me) because, since its a multi purpose cert, you misinterpret the error message as referring to the authentication of the request, even though you are not getting 401.