Our company PC machines are connecting to an internal server where a webservice hosted on it further connects to an external webservice in Italy. The certificate provided by the company in Italy to us only has client authentication purposes (thus not allowing us to import the certificate in IIS, right?). From a console application connecting directly to Italy's webservice, the certificate works fine. However the same logic fails when Italy's webservice is requested through our webservice.
Could this be because of the missing server authentication purpose in the certificate?
Thanks,
Justin
Related
I am using webservice in my .NET based application.The web services are called from control M job which connects to our server where B2B services are hosted and files are fetched. Recently the link between interface and webs service was broken. When I tried to hit the web service in our browser it gave error as SSL certificate got expired.But the website was working fine without any certificate error, and the only certificate bound in the server was not expired. We renewed the certificate and bound it again in IIS, but then we were not able to hit the web service and getting the error page not found. Can anyone tell the reason for it?
I have a very private problem, I have a Java EE application (WildFly 10), running on the infrastructure of Amazon, well.
This application has an SSL certificate acquired of a specific domain ("www.xxx.com"), which has been properly installed on Amazon's Application Load Balancer (ALB), which retains requests and forwards securely to the application server an EC2, so far everything great.
But when we try to instantiate in the pages a "client" "WebSocket" in JavaScript it even presents "MixedContent" errors when used via unsecured WebSocket (WS), so that's fine because it is a browser security requirement:
ws = new WebSocket("ws://<ip-address>:8080/web-socket");
So i use a secure WebSocket (WSS) to make the connection, then under the IP and then presented the error that the IP was not secure because it had not been certified:
ws = new WebSocket("wss://<ip-address>:8443/web-socket");
So I installed the SSL certificate of the domain on the WildFly 10 server, but even then the error was still presented because the SSL certificate was purchased for the domain, not for the IP I'm trying to connect.
If i try to connect Secure WebSocket (WSS) through the secure domain, the same connects, but the Amazon ALB always drops it for inactivity time, and even if the value is too high, the Time to Live (TTL) over time, it shows performance loss over time, I believe by pooling TCP connections.
ws = new WebSocket("wss://www.xxx.com.br:8443/web-socket");
A possible solution would be to buy an SSL certificate that instead of registering a domain, would be registered under the IP of the server, the same would be installed on the server to allow this secure connection between Secure WebSocket and Secure Application, what opinion or experience you?
I have created a Wcf service with SAML implementation. I am using federation binding for the same. From my client application I'm able to access the services hosted on my WCF web service easily when I'm running both client and host service on same machine. I have used certificates for authentication(SAML implementation).
For your information I have custom module at client side which acts as a identity provider. The host service just has some functions which are exposed using wsfederationbinding.
Now the problem is that when I'm running my WCF service host at a different system and client application(consumer with identity provider) on a different system, I`m getting the following error message
MessageSecurityException: The EncryptedKey clause was not wrapped with the required encryption token 'System.IdentityModel.Tokens.X509SecurityToken'.
Note:I feel there is a something mismatch happening interms of certificates between client and host service.
I have resolved the above problem, actually the root cause for the above error was certificate mismatch.
I read at one of the SAML forum regarding the SAML certificate authentication procedure,which says
The token is encrypted using the Public certificate at client side.
At the server side(Webservice Host in my case) the received token is decrypted using the private key of the certificate.
So,in my case the certificates were different at client side compared to the one's at server side.
Resolution :
Just export the certificates from server side(Webservice host in my case) and import the same at client side.
Note: There exist 2 certificates,client certificate and server certificate at both sides(client side and server side).
so in reality,when a client wants to access the host web service(dynamically), just like downloading apps,we need to create both certificates at service side and deploy those certificates to client upon activation of the client app.this way certificates will be in sync.
I have a website hosted on my web server contacting a secure web service on another server. I have created a self signed certificate and attached it to the https:// binding. I have done 2 things to try and accept the certificate on my web server:
Open IE and browse to my wsdl file in the web service - Installed the certificate to the Trusted Root Cert Authority.
Exported the certificate from the other server, gone into MMC and installed imported it manually into the Local Computer Trusted Root Cert Auth.
Neither of these have worked and I am not sure which route to try next.
System: Windows Server 2008 running IIS7.
Many thanks for your time.
I had to do this the way everyone else seems to do it by overriding the certificate check. Not what I wanted but has sorted it for now.
Scenario:
A client calls WebService A on the LAN. WebService A is running under an App Pool with Identity "Network Service".
WebService A does some work, prepares to call WebService B.
WebService B requires a client cert (*.cer) and SSL.
WebService A is on a dedicated Windows 2003 server.
Everything works in the Dev environment as it should (but the developer with Administrator privileges is always logged on locally (no surprise!).
The certificates are stored on disk at C:\MyCertificates\
The certificate is being applied at runtime successfully in Dev with this snippet: myWebService.ClientCertificates.Add(new X509Certificate.CreateFromCertFile(certPath));
Problem:
WebService A is calling WebService B, and the returned exception is:
The request failed with HTTP status
403: Forbidden
This really means that the certificate was not sent in the request to WebService B.
I am under the assumption that installing this cert into the browser is not a solution. The browser settings typically are per-user, and I need to give the certificate to the user whose credentials the web service is running under. (e.g. Network Service, System, or whatever is in the IIS AppPool settings).
Question: How can I grant access or association to my certificate living at the specified directory location to the Network Service or other non-user account?
This Microsoft knowledgebase article may be of use:
How to call a Web service by using a client certificate for authentication in an ASP.NET Web application (MS KB901183)
Your web service 'A' would effectively be the ASP.NET application calling the web service as described in the article.