I have a problem while porting my site from http to https, expecially while I invoke any WS.
That are the steps I've follow:
Import certificate in IIS
Change security mode from "Message" to "TransportWithMessageCredential"
I got this error:
SecurityNegotiationException: The server certificate with name XXXXX failed identity verification
because its thumbprint ('XXXXXXX') does not match the one specified in the endpoint identity ('YYYYYY').
As a result, the current HTTPS request has failed.
Please update the endpoint identity used on the client or the certificate used by the server.
What's the problem ?
Could it be a problem of connections cache ?
How can I prevent it ?
Related
I have an ASP.NET API running locally. On the MacBook Pro, I can access the endpoints with Swagger, Postman and in the frontend (running on LiveServer) using Axios/JavaScript.
I have successfully loaded the frontend webpage on an iPhone (192.168.0.10:5500/index.html), however the Axios call to the endpoint is failing with the following error message logged to the console Failed to load resource: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “192.168.0.10”, which could put your confidential information at risk.
Running the command dotnet dev-certs https --trust generates the message Successfully trusted the existing HTTPS certificate. but does not resolve the issue.
Am I missing something?
#Lex Li's comment worked.
Steps
Remove or comment out app.UseHttpsRedirection(); in program.cs file.
In the launchSettings.json file, "applicationUrl": "https://localhost:7139;http://localhost:5171", generates a http and https url for the API endpoints. Edit the http route to the IP of the computer/local server, e.g., "applicationUrl": "https://localhost:7139;http://192.168.0.10:5171"
use the http endpoint
We have a problem we're facing while trying to authenticate with ADFS,
We have two environments (dev and prod), both configured the same way, windows server 2012
In dev everything works fine, but in prod we are getting the following error:
Exception: The remote server returned an error: (401) Unauthorized.
Message: The HTTP request is unauthorized with client authentication
scheme 'Negotiate'. The authentication header received from the server
was 'Negotiate
oXAwbqADCgEBomcEZWBjBgkqhkiG9xIBAgIDAH5UMFKgAwIBBaEDAgEepBEYDzIwMTYwMjAyMTUyOTI2WqUFAgMM8+6mAwIBKakLGwlIUlQuTE9DQUyqGjAYoAMCAQGhETAPGw1TVkMtQURGUy1QUkQy'.
Inner Exception: The target principal name is incorrect
We don't know what to do, we've checked every ADFS configuration and everything looks fine.
An SAML trace using SAML tracer (FireFox extension : https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/) could be useful in your case to decode the SAML Request and Response in order gather more information about your issue.
I have an IIS-hosted, WCF web service deployed on a UAT web server. In IIS, I have site bindings on this same web service--one for internal access (Ex: uat-nodotsinternalonly) and one for external access (Ex: mysvc.uat.mydomain.com).
When I use SoapUI to test against the internal host name (http://uat-nodotsinternalonly/MyService.svc), it calls the service and returns the response envelope as expected.
When I use SoapUI to test against the external host name (https://mysvc.uat.mydomain.com/MyService.svc), it calls the service and returns the WSDL HTML as would be seen in the web browser instead of the response envelope as expected.
We need to expose past our firewall for testing with a vendor. Our external client can browse to our web service using the external host name and receive the WSDL back in their web browser, but when they call it, it fails with a 302 error.
I’m far from an expert on security, but I believe our firewall is handling the security then forwarding over http to the UAT server. The redirect and variations seem as though there’s something to change in how DNS is managed or settings in IIS. Does anyone have suggestions as to how to narrow it down so that the call to the external service will work?
We too had a WCF service that in SoapUI was returning the WSDL HTML instead of the expected response when invoking a method. This was an SSL-enabled service, and the solution in our case was to edit the endpoint URL after creating the request so that it used https instead of http. This is because we found that for some reason it defaults to http even when you initially specify https when creating the request. Here's how to edit the endpoint URL in SoapUI:
In the request window, click the drop-down arrow on the URL.
Select [edit current..]
Change http to https, and then try your request again.
The problem with the client getting a 302 error was because the client was not sending a SOAP request envelope to our web service. The client was just sending XML.
I have a tomcat webapp that has SSL enabled. I want it to return a 403 response if the client's certificate is invalid. Is there a way to do this? Currently, my browser will give me messages such as "Secure Connection Failed," but is there anyway to override this behavior?
You will have to do the work yourself. Set clientCert=want in your SSL configuration and then write your own code to do the certificate-chain verification. You can do it like this.
We publish an asp.net API on:
http://API.domain.com/v3/service.svc
https://API.domain.com/v3/service.svc
Had a problem last week with a corrupt SSL certificate which meant connecting to the HTTPS ref fails with an internet explorer connection problem. HTTP ref was fine, was confirmed the SSL corruption was the issue.
A customer that should have been using HTTPS never noticed, logs confirmed they are actually using HTTP for authentication and data.
When testing with WCF STORM (test app I used to test method calls) I could recreate the issue i.e HTTP ok & HTTPS fails. Installing a backup certificate resolved the problem instantly, everything back to normal operation.
So I started looking at HTTP to HTTPS redirects. Got it up and running using http://www.iis-aid.com/articles/how_to_guides/redirect_http_to_https_iis_7 (i.e the change to web.config).
When browsing to my API HTTP and HTTPS url, everything worked as expected.
When using WCF STORM to I get the message:
System.InvalidOperationException: The document at the url http://API.domain.com/v3/service.svc was not recognized as a known document type.
The error message from each known type may help you fix the problem:
- Report from 'DISCO Document' is 'Discovery document at the URL http://API.domain.com/v3/service.svc?disco&disco could not be found.'.
- The document format is not recognized.
- Report from 'http://API.domain.com/v3/service.svc' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.
- Report from 'WSDL Document' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.
- Report from 'XML Schema' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.
at System.Web.Services.Discovery.DiscoveryClientProtocol.DiscoverAny(String url)
at WcfStorm.DynamicProxy.ServiceClientProxyFactory.(Option`1 )
at WcfStorm.DynamicProxy.ServiceClientProxyFactory.DiscoverEndpoint(Option`1 cfgOption)
at WcfStorm.Model.WcfServiceModel.(ServiceClientProxyFactory )
at WcfStorm.Lib.Common.BgWorker`2.OnDoWork(DoWorkEventArgs e)
Client proxy code is empty!
I remember one of the developers telling me that the AUTHENTICATION uses SSL but the SOAP messages are transmitted over HTTP. Therefore I suspect the HTTP to HTTPS redirection has caused this issue as its forcing the SOAP messages to use HTTPS and the API has not been configured to do this .... I'm guessing? Developer explained that its recommended that APIs using HTTP for transmitting the SOAP data after authentication using SSL to confirm credentials.
Questions:
How do we force the SOAP data to be transmitted over HTTPS if this is deemed the solution?
If this is not possible how do i deployed HTTP to HTTPS redirect within the environment above ?
Any other way to force HTTPS onto end users / disabled HTTP and / or redirect to HTTPS ?
Thank you for any help.