I'm using new Azure Scheduler service and I have this issue.
I have one console application that works fine with this few code lines
var credentials = new CertificateCloudCredentials(subscriptionId, certificate);
var schedulerClient= new SchedulerManagementClient(credentials);
var jobCollAvailable = schedulerClient.JobCollections.CheckNameAvailability(cloudServiceName, jobCollectionName_NE);
I use the same code lines in a API service with service stack.
When CheckNameAvailability method is called system throws this exception :
Forbidden Error: The server failed to authenticate the request. Verify that the certificate is valid and is associated with this subscription.
Since Friday everything worked also into the service. I had only changed the certificate with another one.
If I remove certificate from Azure the console app throws the same error( but in this case is correct). I have tried with more than one certificate for to be sure and console app has worked fine.
The Certificate loaded and used from Service has the same thumbprint that the console app one.
Thanks for your suggests
Related
My setup is similar to this SO post
My ASP.NET Web App connects to a third party service which requires client certificates. Begin a multitenant application, I've a client certificate for each customer, stored inside a database. Skipping the code to retrieve the certificate from database, I do something like this:
HttpClientHandler httpClientHandler = new HttpClientHandler();
X509Certificate2 customerCertificate = new X509Certificate2(certificateFromDatabase, "", X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.MachineKeySet);
httpClientHandler.ClientCertificates.Add(customerCertificate);
httpClientHandler.ServerCertificateCustomValidationCallback += ServerCertificateValidationCallback;
httpClient = new HttpClient(httpClientHandler);
This code works flawlessly on my Windows 10 development PC.
When published to an Azure Web App it fails 20% of time with the following error:
System.Net.Http.HttpRequestException: An error occurred while sending the request. System.Net.Http.WinHttpException: The client certificate credentials were not recognized.
I've written a test method which calls the third party service as fast as it can, switching certificate every time. This one works on my PC, and fails 80% of times on Azure (same error as above).
The solution proposed on the SO post above does not apply to me: I should have to load hundreads of certificates.
To troubleshoot the issue it could be usefull to execute a packet capture.
But, AFAIK, this is not possibile with Azure Web Apps (can be done with Virtual Machines and Network Watcher).
I've developed an UWP app for a client, which uses WebServices that are hosted in its domain.
Until now, the URL WebServices were related to a test server that don't use SSL
But now, the WebServices URL are related to the prod server that use SSL
As I'm a subcontractor, I don't have an AD account, and I need to use the VPN to access to the client's WebServices.
I didn't get any problem to access to the test server, but it's no longer the case with the prod server.
When I try to access to access to the URL through a navigator, I get a security warning message (DLG_FLAGS_INVALID_CA), but I can "force" the navigation to the URL.
But when I call the WebService from the app with HttpCLient, I also get an error (HttpRequestException) and I don't see how I could fix it.
Here are the details of the exception:
HResult = -2147012851
InnerException =
{System.Runtime.InteropServices.COMException (0x80072F0D): Can't find text related to the error code. The certificate authority is invalid or is incorrect at
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task
task) ...
Message = "An error occurred while sending the request."
Source = "System.Net.Http"
I've already tried to install handly the certificates on my computer, but this doesn't fix the issue...
Is there another approach?
Edit: add "user" certificate
The client sent me the "user" certificate and I installed it on my computer in "User\Trusted Root Certification Authorities Certificate Store": there is no longer problem from the navigator. However, in the app, the problem is still present.
Is it normal? Do I need to "attach" the certificate to the app? This is not really usefull, as the client's users don't need this problem: it's only me as I'm a subcontractor using the VPN...
Edit: add "computer" certificate
Finally the client sent me the "computer" certificate and I installed it on my computer in "Computer\Trusted Root Certification Authorities Certificate Store": this time I could use the app without problem.
It's good to know that the UWP app and the navigators don't use the same certificate.
The problem has been fixed by installing the "user" and "computer" certificates that has been sent by the client.
I'm building a RESTful API using dotnet core 1.1.2.
A big part of this api requires making requests to an external WCF service. These requests are authenticated using windows-based authentication with username, password and domain.
I'm currently in the process of making the api production ready and I wanted to try dockerizing it.
The problem I'm having is that authentication fails towards this third party WCF service as soon as it's called from within the docker container. Running the API using the dotnet runtime works from both windows and mac and the service gets authenticated as it should.
I consume the WCF service using the Connect wcf service feature of Visual studio 2017 and then modifying the endpoint binding with the correct authentication
mode.
public ServiceSoapClient(EndpointConfiguration endpointConfiguration, string username, string password, string domain) :
base(ServiceSoapClient.GetBindingForEndpoint(endpointConfiguration), ServiceSoapClient.GetEndpointAddress(endpointConfiguration))
{
this.ChannelFactory.Credentials.Windows.ClientCredential.UserName = username;
this.ChannelFactory.Credentials.Windows.ClientCredential.Password = password;
this.ChannelFactory.Credentials.Windows.ClientCredential.Domain = domain;
this.Endpoint.Name = endpointConfiguration.ToString();
ConfigureEndpoint(this.Endpoint, this.ClientCredentials);
}
private static System.ServiceModel.Channels.Binding GetBindingForEndpoint(EndpointConfiguration endpointConfiguration)
{
if ((endpointConfiguration == EndpointConfiguration.ServiceSoap))
{
System.ServiceModel.BasicHttpBinding result = new System.ServiceModel.BasicHttpBinding();
result.MaxBufferSize = int.MaxValue;
result.ReaderQuotas = System.Xml.XmlDictionaryReaderQuotas.Max;
result.MaxReceivedMessageSize = int.MaxValue;
result.AllowCookies = true;
result.Security.Mode = System.ServiceModel.BasicHttpSecurityMode.Transport;
result.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;
return result;
}
throw new System.InvalidOperationException(string.Format("Could not find endpoint with name \'{0}\'.", endpointConfiguration));
}
I've tried both Ntml and Windows as ClientCredentialType.
I've verified that the authentication credentials don't get messed up when transferring the api to the docker container by hard coding the credentials inside the app, then running it using the normal dotnet runtime to verify that it works. Finally building the docker image with exactly the same published app and running it again. When exactly the same app is running inside docker it fails to authenticate.
The output from the application is:
The HTTP request is unauthorized with client authentication scheme ‘Negotiate’. The authentication header received from the server was ‘Negotiate, NTLM’.
Which is the same output as if when I'm using incorrect credentials.
I'm wondering if this could be somehow related to how networking works with docker and if the api can't negotiate with the WCF service since it's bridging through the docker host.
If anyone more knowledgeable with docker or WCF consumtion inside dotnet core might have some insight it would be very helpful.
Best regards, Linus.
For anyone experiencing the same issue this is due to the way kerberos is configured on non-windows platforms. This has nothing to do with docker per say but rather running as a linux-based container.
The solution is to either switch your platform to windows or correctly configure kerberos authentication on your platform. This is discussed in more detail in the following github issues:
https://github.com/dotnet/wcf/issues/2641
and
https://github.com/dotnet/corefx/issues/9533
My application was working fine two days ago. I was able to sent the push notification completely fine on live app but suddenly i starts getting this error
{System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. ---> System.ComponentModel.Win32Exception: The certificate is revoked
Here is my code, where i am getting the exception
try
{
stream.AuthenticateAsClient(this.appleSettings.Host,
this.certificates, System.Security.Authentication.SslProtocols.Tls,
false);
}
catch (System.Security.Authentication.AuthenticationException ex)
{
throw new ConnectionFailureException("SSL Stream Failed
to Authenticate as Client", ex);
}
The tried to change the X509Certificate to X509Certificat2 and X509CertificateCollection to X509Certificate2Collection but it didn't help me. I also did not revoked any certificate from my developer account.
We had the same problem, We fixed it by generating the new .p12 certificate file for Apple push notification. Validity of certificate is of one year and it is independent of your app. So you don't need to up the app gain on store to fix the issue. Just find the app id of your app. Use this app id to create a new .p12 certificate file for push notification and upload it on your server.
I'm having problems creating a test X509Certificate in my store that I can use in WCF. All of the certificates I create have the same result when I try to use it in the WCF channel factory - "The private key is not present in the X.509 certificate".
channelFactory.Credentials.ClientCertificate.SetCertificate(StoreLocation.CurrentUser, StoreName.TrustedPeople, X509FindType.FindBySubjectName, "MyClientCert");
I've tried putting the certificate in LocalMachine, having it self-signed vs. a test CA. Nothing helps, the certificate always has the property HasPrivateKey equal to false.
UPDATES:
I've gotten past the above problem, by following the instructions at http://msdn.microsoft.com/en-us/library/ff650751.aspx. However, I'm onto a new problem with the certificate now generating a new error when I try to send the message to the queue. The error is:
An error occurred while sending to the queue: A cryptographic function failed. (-1072824272, 0xc00e0030).Ensure that MSMQ is installed and running. If you are sending to a local queue, ensure the queue exists with the required access mode and authorization.
Again, the process works if I use a real cert instead of a test one, so it seems like it has to be something related to the certificate.