We have front and back end cloud service that communicate via WCF services which are secured using certificate credentials. The problem we are having is that the request fails with the following error:
verb="POST"
authenticationType="NOT_AVAILABLE" activityId="{00000000-0000-0000-0400-0080000000F7}"
failureReason="STATUS_CODE"
statusCode="403.16"
triggerStatusCode="403.16"
(From IIS failed request tracing)
I believe the issue is as described here:
https://support.microsoft.com/en-gb/help/252657/iis-5.0-http-403.16-forbidden-client-certificate-untrusted-or-invalid
(That the server does not trust third party CAs by default. )
If I do as described in the link the issue is resolved but the cloud service isn't part of a domain and I don't know how to apply this setting as part of the deployment or programmatically as part of the start-up.
What I also find strange is that this issue doesn't seem common even though I presume securing WCF communications on Azure cloud services using certificates isn't unusual, so I wonder if the issue is a symptom of something else I am doing wrongly.
Related
We have some Hosted Windows Services using net core (3.1 and later) and a self signed Certificates that we ship to customers.
These Services run on local servers and are listening on localhost:someports and have mostly rest Apis so the certificates are no problem on that side because we can validate them via code.
But some of them will get customer facing Status Frontend Uis where the browser will show the big "self signed certificate is bad" message which the user has to accept and don't look that nice overall.
So is it possible to use a "real" certificate for such services to use https without that hassle?
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 was evaluating appharbor and azure framework or a cloud application.
I came across an article in this url: http://blog.appharbor.com/2012/06/10/some-notes-on-the-recent-azure-launch , which says
Azure Web Sites has no way to add your own SSL certificates at all. If your app needs SSL, you’re stuck with running on the Azure subdomain and piggy-backing off their certificate.
I am a little confused here and so the question:
1) Does this mean that I cannot register and use a ssl certificate for my domain (eg: www.mydomain.com) if my application is hosted in azure?
If that cannot be done- isnt this a fairly basic requirement for a secure web application? why is it not implemented in azure?
2) Azure articles talk of shared ssl certificate. So, if I use a shared certificate, what will the user see in certificate details? will they see something like myapplication.cloudapp.net?
This is true as of today. But please do note that Azure Web Sites is a preview feature and things do change. Having a custom SSL certificate for an Azure Web Sites is something that the team in Redmond is definitely after (check here). Also, please do note that this limitation is only valid for Windows Azure Web Sites. Website addresses usually maps to myapp.azurewebsites.net.
This is not the situation with Windows Azure Cloud Services (that maps to myapp.cloudapp.net). You check some articles and sample how to configure custom SSL for Azure Cloud services here and here.
Azure websites now do support SSL certificates, with the ability to buy an SSL certificate or bring your own.
see this article for the configuration:
https://azure.microsoft.com/nl-nl/documentation/articles/web-sites-configure-ssl-certificate/
Also free SNI certificates are available as of now for Basic, Standard and Premium App Services:
https://azure.microsoft.com/en-us/updates/ssl-connection-pricing-changes/
I'm currently working on an automated deployment process for a hosted service for Windows Azure. The creation of the .cspkg and .cscfg files works perfectly using a call to msbuild. Now I'm writing a small .NET console app that should deploy these files to Azure using the Management REST API.
There is no problem concerning the API itself. I can send a request to the API using one of my management certificates. I upload the .cspkg file to Azure BLOB Storage and then try to call Upgrade Deployment. But every time I try, I get a "400 Bad Request" response stating that the certificate with thumbprint xy was not found. This certificate is the SSL certificate (not a management certificate) I'm using for HTTPS for my custom domain (DNS CNAME).
And now, the whole thing gets interesting:
When I deploy the files using the "Publish" command in my Visual Studio, there is no problem. (I compared the .cscfg/.cspkg files from VS and from my msbuild output: apart from a few GUIDs, they're identical). And furthermore, using the Silverlight Management thingy in my browser, I can even upload my generated files that could not be uploaded using the API.
When I retrieve a list of all certificates using the List Certificates call, the certificate which is said to be missing is apparently there. I can also retrieve its data using the Get Certificate call.
So why does Azure keep telling me that the certificate was not found when using the Upgrade Deployment call? Did anyone experience something similar? Has anyone the hint for me? Thanks in advance.
P.S.: This is what Azure says when I use the API:
<Error xmlns="http://schemas.microsoft.com/windowsazure" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<Code>BadRequest</Code>
<Message>The certitficate with thumbprint 7b232c4a2d6e3deadbeef120d5dbc1fe8049fbea was not found.</Message>
</Error>
P.P.S.: Yes, the word in the response is certitficate, not certificate.
OK, after using the List Subscription Operations API call to find out what Visual Studio calls to deploy apps, I found the solution.
Turns out that the URL I used for the API request was wrong, but: with all due respect, I blame Microsoft for lousily documenting its Azure Management API.
In their documentation, they write the URL to use is:
https://management.core.windows.net/<subscription-id>/services/hostedservices/<service-name>/deploymentslots/<deployment-slot>/?comp=upgrade
And the description is the following:
To generate the request URI, replace <subscription-id> with your subscription ID, <service-name> with the name of your service, <deployment-slot> with staging or production, and <deployment-name> with the unique name of your deployment.
What they forgot to mention is, that you have to use the DNS Name of your service, and not the Name! They could at least return an appropriate error message telling you that the service name is invalid, non-existent or doesn't belong to your subscription ID, instead of complaining about some certificate issue.
Thank you Microsoft, that cost me more than two days.
The error indicates that you have not uploaded that certificate into the hosted service's secret store. Visual Studio might be doing that automagically for you, but if you want to replicate it programmatically, then use the Add Certificate API call and upload the PFX into the deployment.
You can see '400 BadRequest - The certificate with thumbprint XYZ was not found.' appear in the CreateDeployment or UpgradeDeployment scenario for the following reason (which I just debugged):
You use the same certificate for subscription management as you do for e.g. SSL or Remote Desktop password encryption in your hosted service. You therefore will use the certificate with thumbprint XYZ to authenticate your service management REST call that creates the deployment.
When specifying your deployment parameters you pass in your CSCFG which references that same cert by its thumbprint, because it needs to configure Remote Desktop/SSL etc.
That cert is not yet added to your hosted service certs.
In this case the 400 Bad Request error really is telling you that you have a bad request, because the certificate in your CSCFG is not yet attached to your hosted service. The confusion arises (for me) because, since its a multi purpose cert, you misinterpret the error message as referring to the authentication of the request, even though you are not getting 401.
I have binded my IIS7 with a third party 'Server certificate' (Not issued by my server).
I have deployed a secured WCF service on this server with Transport security.
When i try to consume this service, it only accepts those client certificates which are issued by my server (made using makecert). The third party client certificates just don't work here.
To my knowledge it should accept them as they are issued by the same CA!!
Any idea on how to make it work?
Seeing your configuration would help, anyway it seems that the WCF service (not IIS itself) is not configured to use your third party certificate, thus requesting your clients to have a client-side certificate issued by your server.
Take a look at this guide, it helped me a lot when I had to deal with this:
Link