I created a PKCS12 certificate that is installed in my windows trust store. When I create a soap signature by using this certificate in .Net I get the signature algorithm as SHA1. Is it possible to change this algorithm for message signature as it is throwing error when processing the response.
i have been researching a couple of days (5+), i havent been able to find a solution, i am using wse 3.0 and for that is pretty much imposible.
so if you are using wse 2.0 or 3.0, the answer is no, you cant change the inner cyrpto provider, or even subclass the securitytoken class and override the signatureformatter getter.
Related
I use OpenIdict in an Asp.Net Core 2.2 application with DefaultIdentity and the Implicit flow.
I am using the AddEphemeralSigningKey() but you can not really use it for local testing since the token is immediately deleted.
So if I understand the documentation right I need to use the AddSigningCertificate() function (see https://github.com/openiddict/openiddict-samples/blob/dev/samples/ImplicitFlow/AuthorizationServer/Startup.cs).
Is there a way to use the certificate that is created by the Asp.Net Core 2.2 SDK by default (see https://learn.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-2.1?view=aspnetcore-2.2#on-by-default)?
I don't recommend using the X.509 certificate used by ASP.NET Core for TLS. If you need a stable certificate for local development purposes, consider using options.AddDevelopmentSigningCertificate(), that will generate a X.509 certificate, store it in your X.509 store and re-use it when you re-start the application.
(note: certificate generation is only supported on .NET Core 2.x).
faced with next problem:
I have .net web application running under .NET Framework 4.5.2. Applicating communicates to SalesForce using:
SOAP API
REST API (https://github.com/developerforce/Force.com-Toolkit-for-NET/).
SalesForce announced disabling the TLS 1.0 encryption protocol on March 4, 2017. Do I need to do some adjustments in order to migrate to TLS 1.2?
The default System.Net.ServicePointManager.SecurityProtocol in .NET 4.5 is SecurityProtocolType.Tls|SecurityProtocolType.Ssl3, and .NET 4.5 supports up to TLS 1.2
Do I need to update System.Net.ServicePointManager.SecurityProtocol? If so, can it have an impact on communication with other api's?
I will be grateful for any help.
We had some issues in the log alerting us that we were logging on salesforce api using an old protocol not so long ago, after searching a bit i initialise the security protocol with
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
This will force all connection to use tls 1.2 within your program tho.
Sometime it seemed some call were trying to use tls1.0 with the default config... However to be sure you don't need to change just download your API log history and check if you have any connection attempt below tls1.2 and if its the case force the upgrade to tls1.2
You can also add the following registry keys to force TLS 1.2 in .NET 4.5+. They will only be overwritten if the System.Net.ServicePointManager.SecurityProtocol is specifically defined within the application.
Set/create the "SchUseStrongCrypto" DWORD value in the following two registry keys to 1: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319 and
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v4.0.30319
We are using WCF to call a java web service. When we called the service on a test server it worked fine but when we moved to production we encountered the following exception:
Failed to send request message over HTTP:
The token's crypto collection does not support algorithm 'http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p'
One thing we noticed was that the development server certificate’s Signature Algorithm is ‘md5RSA’ while the production certificate has the Signature Algorithm as ‘sha1DSA’.
Is it this ‘RSA’ ‘DSA’ mismatch that would cause the exception? If so, is it possible to configure WCF to handle DSA?
Thanks
Is it possible to have a WCF Service application (.NET 4.0) with Windows Authentication and cross-platform?
As recommended in the below MSDN link
MSDN WCF Security
make use of certificates.
I am currently using X509 Certificate
No, I wouldn't recommend that. Kerberos, which is what windows authentication can use, should be interoperable in theory, but that's only theory. I have never seen a real implementation using this, it's almost impossible. You should use certificates, SAML or username and password.
Regards
Pablo.
I'm trying to connect to a web service that requires me to sign with a certificate before I connect.
In WSE 3.0, all I had to do is create a certificate policy and choose the "sign only" radio button. That worked fine in WSE 3.0, but I want to use this on Visual Studio 2008+ (wse 3.0 only supports 2005). In order to get around the 2005 only WSE limitation, I'm trying to convert my app to WCF.
I read the MSDN article on converting WSE to WCF (such as the Aug2004 limitation), but it fails to mention anything about protection levels.
From the looks of it, the default bindings that support utf-8 don't support sign only protection levels. The default bindings that don't support utf-8 (like the tcp stuff) do, but that doesn't really help me seeing how I'm trying to connect to an asmx page. The customBinding seems to be the key (as stated in the MSDN article) but I can't find any valid protection levels that don't also require encryption.
Any suggestions? Is there anything obvious I'm missing?
You can specify a transport security (authentication) independently from the message security (signing and encryption). I'm not clear from your question whether you need transport security with certificate authentication or message security with a client certificate, but both scenarios are supported.
Please see the documentation for the <security> section of the <basicHttpBinding> for details.
For a more broad understanding of WCF security options, this article provides a good overview.