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.
Related
My local development (5 node) cluster have two stateless services installed. One .Net Core Web Gui service and one .Net Core WebAPI service.
Both are configured to use a https endpoint.
The certificates are self signed certificates and are added to both trusted root and personal (in both current user and localmachine).
I can access both endpoints using a local browser without getting any certificate errors. It says the connection is secure and the certificates are trusted.
So far so good.
But when my Web API services calls my Web Gui service, is says it cannot create a trusted connection.
Why can my local browser create a trusted connection but not the Service running in the local cluster?
Does a Node in a local cluster have it's own Certificate Store?
So it turns out that I missed adding the certificates to the machine root and that's what caused the problem.
For local SSL to work, I needed to to add the self signed certificates to:
localmachine/my
localmachine/root
This lets services call services from within the local cluster.
currentuser/my
currentyser/root
This lets my browsers call my services without ssl errors.
Hope this helps someone else :)
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.
I have two client certificates that I have installed for my API project in the Azure portal. I have set the config option to enable them and can verify that they can both be found in the CurrentUser 'My' store. My problem is now that one of them is failing validation. On my local machine I have this cert installed in the Trusted People store of LocalMachine. Is there anything I can with Azure to make this work?
Is the location of the cert the issue or is it possibly something with the certificate itself?
**Note that this is an app service, not a cloud service
There are few things you can check, In Azure check in the app settings whether you have added your certificate. Its in the SSL section of you Azure app.
Another workaround would be where you are configuring your Token Authentication, you could set this settings.
For e.g. In my case, I was getting X509 Certificate error.
I added this code in my project.
System.IdentityModel.Configuration.IdentityConfiguration config = new System.IdentityModel.Configuration.IdentityConfiguration();
config.CertificateValidator = X509CertificateValidator.None;
config.CertificateValidationMode = X509CertificateValidationMode.None;
Basically turn off your validation. Most of the times, what happens is your local machine as all the certificates installed by an IT Operation person, but Those certificates are not on Azure.
You can check here for some reference as well. Microsoft Certificate Reference
I have my WCF service running in HTTP. I want to make my service run in HTTPS. I did this in my local with self seigned certificate and its working fine. But I'm getting
"Could not establish trust relationship for the SSL/TLS secure channel with authority"
error when I deployed my code in QA environment and created Self signed certificate for the same. I found some solution to validate the certificate at client side (Link). But I'm looking for some solution to fix this from server side. I don't want to disturb the client.
I suspect the error reflect that the client does not recognize your self-signed certificate or the underlying certificate authority. As such, until the client adds the client certificate to their certificate store or otherwise trusts the certificate, the only way they will be able to access the service is via a validation workaround like the one reflected in the link you included.
In order to determine the underlying cause of the issue, you may want to enable WCF Tracing and review the exceptions (especially inner exceptions).
My team supports many WCF connections protected by mutual certificate authentication. We have noticed that the error top level error may not provide as much information as the inner exception. Just yesterday, I had a site with that exact error. When we looked in the trace file, we saw an inner exception revealing that the certificate had not been deployed to the certificate store in the proper location. A few days previously, the “could not establish trust relationship” error had an underlying inner exception that revealed the certificate had been revoked by the certificate authority.
Hope this helps.
Regards,
We have a wcf client, which calls an external webservice. The service is accessed over SSL. The certificate is not a self signed cert. It is issued by Verisign.
The client is hosted in IIS 6 and the application pool's identity is a domain service user.
Every time we want our client to access the remote service we get the following well known exception: "Could not establish trust relationship for the SSL/TLS secure channel with authority-.."
It turned out, that once you access the URL with IE on the same server, our WCF client is working as expected and the certificate is accepted!
My conclusion is, that the URL accessed with IE modified the server in a way, that our WCF client is able to do the validation afterwards. What is our WCF client missing?
(I'm aware that one can circumvent certificate validation by returning true in the ServerCertificateValidationCallback, but this is not an option for production.)
Considering the situation as described, I suspect that your IIS hosted client is not able to load the Verisign root certificate. And it is always a bit unclear to me under which account such IIS based client is trying to access the certificate store. It might be your domain service account user, it might be the ASP.NET user, it might be some other system defined account. This often causing the error.
When you browse the service with IE, there is no doubt about the user (your own credentials) being able to load the Verisign root certificate and resolve the trust relationship correctly.
Please:
Make sure the Verisign root certificate in in the Trusted Root Authorities store under the Local Computer Account
Have your app.config of your client refer to the correct root certificate to be loaded from the correct store.
You might want to run ProcessMonitor to find out which user is trying to load the certificate from the store.