We are trying to connect to an external api from our organisation via soap. When we do the connection via soap ui with the wsse security as binarysecuritytoken(using pfx certificate) it works fine and yields the expected output. Since we are going to call the API programmatically we are doing the same in C#(beginner level expertise) but the binarysecurity token we generate by exporting the pfx certificate doesnt match with the one generated by soapui. We are using the below code to generate the token..
When we try the below option the error is - ASN1 parse of PKIPath Failed
Option 1
var c= new X509Certificate2(PFXFilePath, CertificatePassword);
var export = c.Export(X509ContentType.Cert, CertificatePassword);
var base64 = Convert.ToBase64String(export);
Option 2
var c= new X509Certificate2(PFXFilePath, CertificatePassword).GetPublicKey();
var base64 = Convert.ToBase64String(c);
TOken generated by Option 2 is a subset of the token generated by SOAP UI
I have dugged around a lot into SO archives and couldnt find the correct solution for this. Please help
Related
I have an API that creates and exports certificates, I also have access to the UI to export them manually. The problem here is: when I export a cert using c# the API returns a well-formed base64 string, if I take this string and convert it to an X.509 object it still works, but, when I export this to a cert file it seems to be insecure. If I export the certificate manually it returns the exact base64 string, but it seems to be secure and well-formed.
So, what's the difference? or how could I export the base64 string to a cert file while avoiding insecurity issues?
Thanks in advance.
My current approach is:
File.WriteAllBytes("certification.cer", GetCertificate(base64).Export(System.Security.Cryptography.X509Certificates.X509ContentType.Cert));
And:
File.WriteAllBytes("certification.cer", Convert.FromBase64String(base64))
The thing I want to achieve is to generate a singedURL pointing CloudFront distribution which originates from S3 bucket.
I have managed to sign the URL which points directly to the S3 bucket as described in following AWS spec - Generate a Presigned Object URL Using AWS SDK for .NET and it worked fine.
But what I really need is to generate signed CloudFront URL.
I assume my Distribution is properly configured as I'm able to access it using (https://d298o8yem5c56d.cloudfront.net/123.pdf) assuming Restrict Viewer Access: is set to No in Behaviors settings.
After switching it to Yes it can no longer be accessed without signedURL.
I was trying to use the sample code from AWS Developer Guide: Create a URL Signature Using C# and the .NET Framework
The URL was generated, but what I get is following error message:
<Error>
<Code>AccessDenied</Code>
<Message>Access denied</Message>
</Error>
Any ideas what should I check ?
Finally I've solved the issue using the sample code from AWS Developer Guide: Create a URL Signature Using C# and the .NET Framework
The issue seem to be related to the PrivateKey.xml
Remember to replace PrivateKey.xml with your PrivateKey (which can be generated / downloaded from AWS root account settings).
As a next step it has to be converted from PEM to XML (required by .NET)
Nice and easy way to convert from PEM to XML is by using an - online converter
I migrated my project from Dropbox API version 1 to 2 and it returns error code 400 (Bad request) when I try to load xml file from Dropbox.
I have read the documentation but somehow I still don't understand how to correctly structure version 2 URLs.
What would be the correct V2 url to load an XML file?
I'm loading XML like this:
XmlDocument xmlDoc = new XmlDocument();
string uri = new Uri(string.Format(...)).AbsoluteUri;
xmlDoc.Load(uri);
Version 1 (deprecated)
string.Format("https://content.dropboxapi.com/1/files/auto{0}?access_token={1}", svcUri, ACCESS_TOKEN)
Version 2 (current)
// What is wrong here??
string.Format("https://content.dropboxapi.com/2/files/download{0}?access_token={1}", svcUri, ACCESS_TOKEN)
In your version 2 code, you're attempting to put the file path directly on the URL path, and are passing the access token in an access_token path. These worked on API v1, but API v2 is a different interface so those won't work there.
In API v2, you're correct that the replacement is /2/files/download. That's a "content-download endpoint", so the standard way of using that is via a POST with 'Authorization' and 'Dropbox-API-Arg' headers.
To just use a GET with it instead though, as it appears you want to do, i.e., so you can just use a URL by itself, you can use the URL parameters documented here under "Request and response formats".
So, to access a file at "/folder/filename.xml" the API call parameters for /2/files/download would be:
{"path": "/folder/filename.xml"}
URL encoding those for use with the arg URL parameter, along with the access token information in the authorization URL parameter, the result would be:
https://content.dropboxapi.com/2/files/download?authorization=Bearer%20ACCESS_TOKEN&arg=%7B%22path%22%3A%20%22%2Ffolder%2Ffilename.xml%22%7D
Be sure to replace ACCESS_TOKEN with the actual access token.
I need to obtain the BinarySecurityToken to authenticate to Soap WebApi, I know that BinarySecurityToken is certificate content encoded in Base64. When I test api in SoapUI the Binary sec token is generated from jks file from my certificate, everything works. The problem is when I need to connect to api form C# then I am using p12 cert and getting encoded base64 content of cert like in jks file but the values are different and BinarySecurityToken from p12 is not working with Soap api.
Conclusion: BinarySecToken generated from jks is different than generated from p12.
Is there any way to generate BinarySecToken as same as from jks file?
Is any way to work with jks files in c# ?
This is how I get the BinarySecToken:
X509Certificate2 cert = new X509Certificate2(certPath,"pass");
var content = cert.RawData;
var base64content = Convert.ToBase64String(content);
BinarySecurityToken in .jks file is raw content data but with one difference. Token in jks file contains file size at the begining, token data generated from .p12 is the same data as jks but without file size. In my solution I solve it in other way. I think there is no solutions when you need to obtain BinarySecurityToken from file as raw data. There are other api mechanism that will solve it for you. When you want to obtain token as raw data from file, you do it something wrong and for sure that won't solve your issue.
I am using this code to download file from server and parse data from JSON notation:
WebClient wcl = new WebClient();
Uri url = new Uri(tickurl);
string srlz = wcl.DownloadString(url);
var dict = (new JavaScriptSerializer()).Deserialize<Dictionary<string, dynamic>>(srlz);
When I use it with http://deepbit.net/api/ + my token (URI returns JSON data) it works well.
But with https://mtgox.com/code/data/ticker.php it stucks on 3rd line of the function(data downloading).
What am i doing wrong? Both URLs return same JSON formatted data.
[add] it's not issue with https, this code works well enough with other https services. i am wondering if this could be a problem with SSL cert.
SOLVED: turned off SSL certificate validation. thanks
I suspect it's failing due to a security problem. When I fetch with wget, I get:
ERROR: certificate common name www.mtgox.com' doesn't match requested host namemtgox.com'
It's fine when I fetch with wget using the --no-check-certificate flag.
I don't know whether you can persuade WebClient not to check certificates... but a better option would obviously be to get the certificate fixed.
Alternatively, try this URL instead: https://www.mtgox.com/code/data/ticker.php - note the www at the front. That fetches in wget without any issues.
The Url: https://mtgox.com/code/data/ticker.php doesn't even open up in browser. It starts downloading the 'ticker.php' file. Your server is misconfigured. The code is fine. Most probably the server is not properly configured to process .php files as scripts.
it is a certificate error like Jon Skeet said.
Have a look here to find a easy solution
WebClient + HTTPS Issues
you shouldn't use this for all request, only for debugging