I am using WCF services with C#.
I am using the transport security mode by setting the client and service certificates.
In the middle of operation I would like to change the certificates that I am using and use certificates signed by other CA.
Is it possible to change these certificates in the middle of operation without restarting the service host? If so how?
Is it enough if I just call set certificate with other certificate passed:
serviceHost.Credentials.ServiceCertificate.SetCertificate(...)
serviceHost.Credentials.ClientCertificate.SetCertificate(...)
Someone have encountered this problem and resolved it?
I have tested this as a high-availability issue. You can't do it. The service acquires its certificate when the ServiceHost opens and never again.
If your goal is to support HA, you need to put multiple services behind a load-balancer and restart them one-by-one.
You can't change certificates without restarting the web service, unfortunately. I've looked into this extensively. There's no way to do it. Sorry
Related
I am working on a legacy architecture that has a server that has an existing certificate for communication. Multiple existing services in the legacy architecutre use this for communication. I am working on creating a communication channel on a much newer system that is built for scale that will communicate with our old framework. This will be used to perform a phased migration where we rely on the old architecture for a period of time, while still running the old system.
Due to some internal constraints, we can't simply add the existing certificate to the new architecture. Furthermore, changing the certificate to the new one will require changing every single service that communicates with the server to have retry logic & both certificates. Furthermore, this has the potential to instantly break the old system entirely (as all the services rely on the server to perform - one of the limitations of the old architecture).
So the ideal solution is that the service simply accepts two different certificates for a period of time while we perform the migration. The new services communicate with their certificate and the old services communicate with theirs. Then we can deprecate & decommission the old services
The only way I see to set a certificate is either in config or how we currently do it:
host.Credentials.ServiceCertificate.SetCertificate(System.Security.Cryptography.X509Certificates.StoreLocation.LocalMachine,
System.Security.Cryptography.X509Certificates.StoreName.My,
System.Security.Cryptography.X509Certificates.X509FindType.FindByThumbprint,
thumbprint);
Calling this again would overwrite the certificate set on the host. So is there any way that I can add an additional certificate that the server can distinguish between and use the appropriate certificate for communication with the client when it receives a connection?
Thanks for your time
As Ding Peng mentioned in the comments:
This solution is not feasible, if use certificate verification, the server can only bind one certificate, as you said, if you add two certificates, one of the certificates will be overwritten.
This is correct, but I was misunderstanding how certificate encryption worked and it was unnecessary to add an additional certificate.
Simply by adding logic to whitelist the client certificate subject names of the new architecture - it was able to authenticate.
I had assumed that if the server certificate did not share the subject name of the client cert, that there would be an issue with authentication & encryption. However, this is not the case and simply whitelisting the new subject name was enough to perform the auth.
I have an multi layered application that I have developed. I communicate with the windows service using http with ServiceStack (AppHostHttpListenerBase). While this works fine in clean environments, I often find that customers computers are not so clean and one of the first problem areas is the introduction of an unwanted Proxy with causes my application not to run. I get alot of bad press that the application does not work well, when in reality it is a result of a hidden issue on the customer machine.
When I go to query my endpoints the proxy interferes and I lose all communications with the Service.
I am thinking of going back to WCF and using namedpipes but before I do so, wondered if there was a better way in the ServiceStack world (Which I absolutely love)
Ideas? Suggestions?
If a local HTTP proxy is causing issues one thing you could try is to use SSL which will let you tunnel your traffic as an opaque binary through their proxy minimizing potential for interference.
Configuring SSL for HttpListener is configured the same way for all HttpListener's, i.e. it's not specific to ServiceStack - and it needs to be configured on the OS where it's run.
This answer shows how to configure SSL on Windows: https://stackoverflow.com/a/11457719/85785
You'll be able to use https with ServiceStack HttpListener self-host by following the steps above, I used "https://*:8443/" for the url and "CN=localhost" to bypass the SSL browser warning dialog.
It's not specifically clear in the answer but you can get the Thumbprint from the details tab of the certificate where you then need to remove spaces. If it's easier, you can follow the walkthrough in the answer below to use MMC to import the certificate: https://stackoverflow.com/a/33905011/85785
I build a WCF Windows Service and I want connect to it via Internet.
So I was looking for a suitable binding. I decided to use wsDualHttpBinding.
It is working so far if I use securityMode=None in my xml and ProtectionLevel=None in my ServiceContract.
Now I have the problem that I cannot secure the connection between my Service and my Client, because I don´t want anybody to see any details during my Login process.
When I use Message security and ProtectionLevel=EncryptAndSign I cannot access my Service.
Does anybody know where the problem is?
Thanks a lot in advance.
Finally done,
after days of researches I found a suitable solution for my problem.
I decided to use a certificate mechanism. Now I am creating a certificate and I can use message security.
Yes, it was quite an overhead, but it works fine.
I'm currently working on integrating a third party API to our software. One requirement of this is the use of an OAuth style authentication system over SSL/TLS.
This isn't a problem, and it WAS working for about a day and a half. Then all of a sudden, it starts returning this error to me constantly, even when trying to authenticate.
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
The fact that it was working and now it isn't confuses the bag out of me, and I have no idea where to even begin looking to solve this.
The methods involved are called from our WCF service hosted in an HTTPS environment. We have a valid signed certificate from a provider. Nothing changed in the implementation, it simply stopped working.
Do any of you have any suggestions on why we would get an error like this? I have no idea where to even begin looking.
UPDATE
The certificate exists in the trusted store.
We currently have our website as www.mywebsite.co.uk, with a valid certificate for said website. Our services are located at www.mywebsite.co.uk/Services.
We also use a Windows Service, which consumes the appropriate WCF located at www.mywebsite.co.uk/Services. Could it be the Windows Service that is causing issues? The Windows Service application is located on the hosting server, which is Windows Server 2012.
UPDATE 2
In order to workaround this issue, we've decided to use the method to ignore the certificate validation errors. This code excerpt can be found on a tonne of other articles here, but here it is anyway for any reader.
ServicePointManager.ServerCertificateValidationCallback = (obj, certificate, chain, errors) => true;
UPDATE 3
Okay, after a bit more looking I managed to get these errors from the ServerCertificateValidationCallback. It tells me that there is this error
RemoteCertificateNameMismatch
The server we are trying to access for API calls has an odd web address, that doesn't match the issuer/subject of the certificate. Is this what is throwing it off?
The server we are trying to access for API calls has an odd web address, that doesn't match the issuer/subject of the certificate. Is this what is throwing it off?
Yes, it is. Certificates are validated by checking for a match between the host name you are opening a connection to and the host name(s) identified in the certificate. The host name is the first part of the "web address" - e.g., stackoverflow.com or www.google.com.
I'm working on a client-server project implemented using WCF. The clients are deployed on different machines and communicate with services through the internet. I'm relatively new to WCF, and am a bit confused on choosing the appropriate binding for my Web services. The clients need to be authorized to perform operations, however, I'm implementing my own authentication algorithm and trying to avoid Windows authentication for various reasons, but I still need to make sure the message transferred in the channel is encrypted.
Right now I'm using wsHttpBinding with security mode set to Message. Full configuration looks like this:
I've set the authentication type in IIS to Anonymous Authentication to make sure the requests are passed through, and was expecting a service call to fail since MessageClientCredentialType in my binding is explicitly set to Windows. However, when I run the code, the service successfully gets called and returns the expected values. I have a feeling that I'm missing something - why is the call authorized? Can I make sure the message is still encrypted even though authentication type is set to Anonymous? Any help is appreciated.
Edit
To clarify on this, I tested the service with a client deployed to a machine outside the network on a different domain.
This MSDN article kind of sums up a lot of security issues relevant to WCF
http://msdn.microsoft.com/en-us/library/ms733836.aspx
regarding your specific situation,
the negotiateServiceCredential="true" means that you streamline certificate distribution to your clients for message encryption.
This option will only work with windows clients and has some performance problems.
read more here http://msdn.microsoft.com/en-us/library/ff647344.aspx
search the topic "streamline certificate distribution" in this page.
Which account do you use to make the call to the service? Allowing anonymous in IIS lets your request pass through to the service and service should authenticate if your caller has credentials that windows understands (Active directory/NTLM).
In your case, I think you are testing it in your own environment so service responds. Once you deploy it over internet, I doubt your service will allow anybody outside of your domain if you keep clientcredentialtype to windows.
Check these link for securing services on the Internet -
http://msdn.microsoft.com/en-us/library/ms734769.aspx
http://msdn.microsoft.com/en-us/library/ms732391.aspx