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.
Related
Here's my setup
an IdentityServer 4 as a stateless reliable ASP.NET Core service.
a WebAPI as a reliable ASP.NET Core service.
using them with a JS client, it is now working with HTTP. The problem is with HTTPS. The WebAPI needs to request the openID config via htttps [is4URL].well-known/openid-configuration. I'm getting this error
System.InvalidOperationException: IDX10803: Unable to obtain
configuration from:
'https://localhost:9999/.well-known/openid-configuration'. --->
System.IO.IOException: IDX10804: Unable to retrieve document from:
'https://localhost:9999/.well-known/openid-configuration'. --->
System.Net.Http.HttpRequestException: An error occurred while sending
the request. ---> System.Net.WebException: The underlying connection
was closed: Could not establish trust relationship for the SSL/TLS
secure channel. --->
System.Security.Authentication.AuthenticationException: The remote
certificate is invalid according to the validation procedure.
can anybody help me to make this work in localhost with the SF Local Cluster Manager?
Thanks
Here's my two cents worth but it will need to be verified...
I am assuming that you have created a self-signed certificate using following article or similar but the certificate has same properties.
https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-configure-ssl-certificate
This means that the certificate can not be verified via actual CA. Ofcourse with self-signed certificate this is not possible.
Now when you upload the certificate to Azure App Service it installs in CurrentUser - MyStore. With self-signed certificate, it also needs to be installed in LocalMachine Root store.
This is becouse then the machine's Certificate Authority can verify that certificate to be valid. (May be a security expert can correct me if I am wrong but thats my theory). I have got same setup on my locally hosted windows server where the self-signed certificate is installed in Root Certificate Store as well as Personal store and the app works. This is the reason I belive this happens.
So this part which needs to be verified. Following is the article which shows you how you can do this in Azure App service.
https://learn.microsoft.com/en-us/azure/cloud-services/cloud-services-configure-ssl-certificate-portal
AGAIN THIS IS JUST A THEORY THIS NEEDS TO BE VERIFIED. :)
EDIT:
I have just tested this and it is the case. In cloud services you can do as shown in second link above and create Web Job which install certificate in appropriate store.
For Azure App Service unfortunaltly you dont have access to root store. It has to be install in CurrentUser's personal store. Which means the self signed certificate will not work, and you have to purchase a real certificate. :( I think this is a real thumb down to Microsoft. Why should I need to pay for real certificate for my dev/test environment? (Rant Over)
For Service Fabric you will need to find out how to install certificate in Root Store as well as personal store (if thats possible at all). Here's Links that might be useful
http://ronaldwildenberg.com/running-an-azure-service-fabric-cluster-locally-on-ssl/
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security-update-certs-azure
Hope this helps.
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.
We receive a SHA-2 certificate from a vendor to use on our site when making requests to them. This is unlike anything i have done before. Typically in IIS we would create the request, receive the certs and install.
In this scenario we were just handed one for requests to them. Anyone know how or what is supposed to be done with them?
Did use MMC and installed the cert that way, but not sure how or if that is to link to website.
It's only for server side certificates that you use the IIS management console. It sounds like this is a client certificate used to identify your app to someone else.
It is up to the language you are using to call the webservice to determine where the certificate should be placed. If you are using C# then there are lots of questions that talk about using client certificates. I would imagine that most languages would let you reference the certificate file directly.
I want to migrate an existing On Premise WCF service to Windows azure without asking clients to change anything in thier application like endpoint URL, certificate etc.
PLease let me know if this can be done?
In principal - yes.
The Endpoint Url is dependant on you controlling the domain and forwarding the URL over to Azure (for us, we use a CNAME redirect to the Azure URL). More details here.
For the certificate, as long as you've got an exportable version of the certificate with a Private Key, it should be a matter of uploading the certificate to the server that matches the endpoint URL. More details here.
So, all in all (with these changes in place) it's just a matter of uploading the certificate, redirecting to over to Azure and then letting DNS do its thing. If in doubt, certificates are buttons to purchase, so use that for testing purposes to prove the concept.
I have a WCF service running on IIS6 which is configured with a WSHTTPBinding using the "Transport with Message Credentials" security setting (with the transport client credentials set to 'None' and the Message set to 'Certificate'. This is being consumed by a .NET client that was created through the auto generated code by consuming a service in VS 2010.
In my development environment, I created a certificate to act as both the service cert and the IIS SSL certificate, and since I was lazy, I exported the certificate for use with my client application. Everything works great in that configuration, but that is not the target environment. The idea is to have users utilize their smart cards to access this service. The server will not be on the same domain and LDAP is not allowed, for now.
The problem is that now I got this in a test lab and set up an environment where the SSL certificate was issued by the same CA as the user's certs, and I have created a custom x509 Cert validator and service credentials, but after the initial call to my validator, something is happening in between the hand off and kicks out an error on the service trace log saying, "Error verifying message security" with an inner exception of "Cannot verify the signature". Since is is coming through my custom validator and I got the message logging up, everything looks fine on the SOAP side and I am getting the certificate through on the other side. I have made sure that every cert that I am trying to use is in the "Trusted Users" store and even tried exporting the certs and putting them in the local computer "Personal" store, with no luck.
I have a feeling that I do not fully understand the use of the service certificate and the client certificate in the web.config file. Can someone please help me out here?
Ok so I have managed to answer my own question with some help from my coworker. After we sat down together and started to run a bunch of questions by me and doing some random google searches, we decided to change something in the configuration that surprised me.
So to finish my question up top, I had the message credentials set to "Certificate" with the encryption algorithm suite set to "TripleDesSha256Rsa15". Turns out that the certificates on the smart card, or the card itself, would only support Sha1 (which was not an option with everything else). When we changed the setting to "Basic256", everything started working. I eventually was able to set it to "TripleDesRsa15" and it continued to work.
Basically, WCF sends the certificate up without a private key, because it cannot access it with that encryption algorithm. WCF DOES NOT throw an exception with this when trying to access the certificate, it will only throw it on the server side with the exception "Could not Verify Signature". Kind of wish it would say "There was no signature" because that would have been a bit easier to track down. I don't know if anyone will ever find this useful, but if you do and can find a reference to the "Proper" way of using Smart Cards with WCF, please post it with a ref.
Overall, check your encryption algorithm that you are trying to use, and make sure it works with the smart cards/certificates that you plan on using.