I have a project consisting of a website (ASP.NET WebForms) and a desktop application (WinForms + WPF). Right now I'm designing a WCF Service to be hosted in IIS, that will be consumed by these applications. Service is authenticated by an Active Directory. Unfortunatelly in WCF all security related stuff needs a certificate to work.
On the development machine I know I can use a temporary certificate, but the problem is with production. The client server is accessible only from the intranet, so there is no SSL configured and no certificate (and it's not an option to buy one).
My question is: can I use a IIS Self-Signed Certificate on production? What are the disadventages of this? Until now I have used WCF only for simple AJAX calls, and haven't played with the security stuff and certificates.
Related
I have a working WCF Service, that does what it should do, hosted by an IIS.
Now in another environment, this service shall be used as ever, but IIS should additionally require a client certificate for allowing to access.
So I generated some certificates, used iisClientCertificateMappingAuthentication to configure them and map them to users. So I can control which users can access the website and I see to what user the certificates are mapped in the FailedReqLogFiles.
Then I added a sub directory, put the WCF application in there, converted to an application with an apppool and ther the pain began.
The WCF Service is determined to demand that 'Anonymous authentication' must be activated. When I activate anonymous authenticaiton, the service can be invoked, but from then on, it doesn't matter which certificate is used for authentication.
I googled tons of articles and tried lots of configurations, but didn't success so far. I must admit, I'm not very familiar with WCF, this always drove me crazy. I do simply not understand why an application deals with the way the Webserver handles security (it's smiliar to adding SSL, when WCF is not configured properly, IIS shows 404, that's also one thing i do not understand, why the WCF is interfering with the way IIS exposes content to the world...).
Hope there's someone who could give advice, thank you very much in advance.
Regards, Chris
You could try below setting in iis to resolve the issue:
1)Open iis manager, select your site.
2)select the SSL setting from the middle pane.
3)in SSL setting check require SSL, client certificate select accept radio button.
4)click on apply and restart iis.
You could refer the below link for how to set iisclientcertificate authentication with WCF:
WCF Service Using Client Certificates Requires Anonymous Access in IIS and Therefore Doesn't Actually Work?
How do I implement Client Certificate authentication the right way?
https://learn.microsoft.com/en-us/iis/configuration/system.webServer/security/authentication/iisClientCertificateMappingAuthentication/
We are using Asp.Net core 2.1, Kestrel web server and service fabric. We have server certificate for our services which get bound to the service during service startup. The certificates are stored and renewed in Azure Key Vault.
The question is how can we bind the service to the renewed certificate without restarting or re-deploying the service at runtime?
In Server1 - (IIS hosted, Self Signed Certificate)
I hosted the IdentityServer3 named myDevIds3.com , the Url is exposed to internet, with SSL.
I hosted the ASP.Net MVC Client, which uses ids3 for login, works fine.
I hosted the Web API, which is called by the MVC Client, uses ids3 (in the same server), works fine.
In Development Server / Box.
I hosted MVC client (X), which uses client side js famework (https://github.com/IdentityModel/oidc-client-js) to connect to Server1 hosted ids3 (myDevIds3.com), works fine.
I hosted an Web API, which is called by MVC Client (X), while API uses myDevIds3.com for authorisation. [HERE is the problem]
When I try to access this Web API, I am getting an error in the Startup.cs - The remote certificate is invalid according to the validation procedure.
BUT I tried in other way.
I hosted another IdentityServer3, the MVC Client, the API also in development box, mapped to local identityserver3 with MVC client & apit, looks everything seems to be working with out any issue. If I put everything together in one box, everything seems to be working.
What is wrong in accessing the remote machine IdentityServer3 in Web API which is hosted in local development Box ? Why I am able to access from the browser, but not from development box IIS ?
Appreciate your time and inputs.
Because your ssl cert is probably home made and not trusted. Guessing Chrome also gives you warning about this (?).
CAUTION: This solution is not recommended for production, but this can be used for non production environments, where your data is not critical.
Add below code in Startup.cs (Web API)
ServicePointManager
.ServerCertificateValidationCallback +=
(sender, cert, chain, sslPolicyErrors) => true;
This can be refered in below link aswell.
C# Ignore certificate errors?
I found this solution helpful, since I want to have identityserver3 DEV hosted centralised and multiple developers need to access it. Hope it might help someone.
I have a WCF service which is exposed using a single endpoint with netTcpBinding which sits on Server A, hosted on IIS7.5/WAS on our internal LAN on our domain.
This service is then consumed by an ASP.NET web client application sitting on Server B, also hosted on IIS7.5 with an external hosting provider outside of our domain, and linked to our LAN via a VPN secured to allow only traffic between Server A and Server B.
During development while I was testing the concept I ran the web client application on another IIS server internally on our domain using binding security mode="Transport" and transport clientCredentialType="Windows" which worked fine.
I then moved the web client application to the external Server B for further proof-of-concept testing setting the binding security mode="None", as obviously with this server being outside of our domain I cannot use Windows authentication, and it still works fine.
What I need to do now, to enable the switch back to using transport security is to set the clientCredentialType="Certificate", as you cannot have transport security with clientCredentialType="None".
This is where I have started to come unstuck. I seem to be going around in circles as to where in the web.config of the service and the client web.config to define the certificate and where to store which bits of the certificate.
Essentially what I'm trying to do is authenticate that Server B is indeed Server B calling the service on Server A, thus preventing any spoofing or DNS subversion issues, which could result in the service at Server A being illegally accessed.
My thinking is that I need to create a certificate for Server B to which Server A holds the public key to validate it? If this is the case Server B already has a wildcard SSL certificate installed on it as it serves various applications of ours as subdomains. Could this certificate be used for the WCF authentication?
None of the SO questions I've found seem to cover this, and all the various websites and book examples I've found aren't that clear. It's starting look like WCF configuration is somewhat of a black art.
This is all built using .NET 4 and Visual Basic. Any help would be greatly appreciated.
This MSDN example has examples of how to configure netTcpBinding with certificates in both code and config. Just pick the scenario that suits you. The certificate should be issued by a public (commercial) certificate authority like VeriSign or Thwate so it will be trusted by your external host provider and your internal server.
I have created and tested a WCF REST service that is protected with SSL and Windows Authentication through IIS 7. I have also created and tested a pure html/javascript web client that is hosted in IIS 7 that is protected with SSL and Windows Authentication -- same server, different "site" within IIS. The REST service is not public, but the web client is.
Without security, everything works beautifully, but now we are ready for field testing and security must be implemented.
My end goal is to have the user visit mywebclient.com and authenticate using their Active Directory accounts. Initially I thought it would be safe to leave the service calls from the client to the REST service unprotected (since the traffic from the web client to the web service would be internal), but this does not protect us from an internal attacker. Also, in the future, the REST services will be available to handhelds through native applications.
I've tried to gain as much information on this subject as possible, but every piece of Microsoft documentation contains client examples written in .NET.
How can I share the security context between these sites without converting the web client to a .NET-based application? Could this be accomplished by combining the web client and service into one IIS "site"?
Edit: If the client and service exist in the same app pool, does that mean they could share authentication information between client and server processes?