I have been using web deploy for a long time, but somehow, now it will not deploy. What's going on with my certificate? and how can i fix it.
Severity Code Description Project File Line Suppression State
Error Web deployment task failed. (Connected to the remote computer ("xxxx.xxxx.com") using the specified process ("Web Management Service"), but could not verify the server’s certificate. If you trust the server, connect again and allow untrusted certificates. Learn more at: https://go.microsoft.com/fwlink/?LinkId=221672#ERROR_CERTIFICATE_VALIDATION_FAILED.)
Connected to the remote computer ("xxxx.xxxx.com") using the specified process ("Web Management Service"), but could not verify the server’s certificate. If you trust the server, connect again and allow untrusted certificates. Learn more at: https://go.microsoft.com/fwlink/?LinkId=221672#ERROR_CERTIFICATE_VALIDATION_FAILED.
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
The remote certificate is invalid according to the validation procedure.
The solution is already provided in the error message, you can refer to this link: ERROR_CERTIFICATE_VALIDATION_FAILED.
Diagnosis: The certificate presented by the Web Deploy endpoint is untrusted or invalid. This typically happens if the remote server has a self-signed certificate for the Remote Agent Service or the Web Management Service.
Resolution: Either install a trusted certificate on the endpoint, or try bypassing certificate validation.
From the msdeploy.exe command line, you can do this by passing the
-allowUntrusted flag.
From the Visual Studio 2010 publish UI, you can check "Allow
untrusted".
From a Visual Studio 2010 deployment package (e.g. MyApp.deploy.cmd),
you can pass the -allowUntrusted flag.
Related
I am performing a task to authenticate a Active-directory B2C instance in Azure from a local ToDo WebApp using a local WebAPI service.
I have created 2 Apps App1 and App2, apart from adding a B2C instance in a trial-version subscription of Azure. In local windows 10 OS, in Visual-Studio, I collected code for the ToDo Webapp and WebAPI Service as per a Microsoft-blog here
However, when I start the WebAPI service, and run the ToDoWebapp, the login after creating a user works fine, but after that, for any call to the service, I get the error-page with the message:
AuthenticationException: The remote certificate is invalid because of errors in the certificate chain: UntrustedRoot
HttpRequestException: The SSL connection could not be established, see inner exception.
How can one resolve this error?
Please check below points:
Installing the .NET Core SDK installs the ASP.NET Core HTTPS
development certificate to the local user certificate store as part
of the first-run experience, but it is not trusted. To trust the
certificate, perform the one-time step to run the dotnet dev-certs
tool.
Check the certificates in the certificate store.Find
localhost certificate with the ASP.NET Core HTTPS development
certificate both under Current User > Personal > Certificates and
Current User > Trusted root certification authorities > Certificates
Try to remove all found certificates by checking carefully from both Personal and Trusted root certification authorities.
Note: Do not remove the IIS Express localhost certificate.
Try to run the following commands in .NET CLI and try again
dotnet dev-certs https --clean
dotnet dev-certs https --trust
Note: Untrusted certificates should only be used during app development. Production apps should always use valid certificates.
References:
Trust the ASP.NET Core HTTPS development certificate on Windows and
macOS
Enforce HTTPS in ASP.NET Core | Microsoft Docs
Our APIs are exposed through Azure Cloud Services (Web Role). We use certificate uploaded to Cloud Service for encryption of data stored in backend. During certificate rotation, We uploaded new certificate by updating *.CSCFG file
Our CSCFG
<Certificate name="encryptcertificatethumbprint" thumbprint="NewThumbprint" thumbprintAlgorithm="sha1" />
When we login into Portal > Cloud Service > Certificates Tab. We could see both Old Certificate and New certificate.
Unfortunately some of the records in backend system are not re-encrypted with new rotated certificate. When our App reads data from backend system, it fails to decrypt with message "The secret could not be decrypted. Check that certificate with serial number 'XXXXX-XXX' is installed. The inner cryptographic exception: 'Keyset does not exist" since old certificate is not present in webrole instance.
Instead of doing another deployment with both certificates, we remote into web role instance and installed old certificate under Personal > Certificate
After installing old certificate, Application still unable to find certificate by thumbprint in Local Machine certificate store. We tried restarting webrole, still application unable to pick certificate.
Few Questions, can anyone help (without any deployment to address this issue)
What will be certificate location on webrole instance, where we can upload certificate. Our logic of certificate search based on Serial number in LocalMachine and then also Current User. Though we uploaded certificate in LocalMachine, Still webrole unable to pickup certificate
What will be Current User certificate store i.e. what will be account on which webrole runs
If the certificate gets expired, will certificate be returned ?
I haven't tried to accomplish your specific goal, but this information may help get you closer.
The Azure guest agent installs certificates as the system account in the CurrentUser store, so any interactions you want to do with those certs will need to be as the system account. To do this you can download Sysinternals Suite and run psexec to launch a cmd prompt under System context. Then in that new cmd prompt you can run certutil, mmc.exe, etc:
psexec -i -d -s cmd
certutil -store -user My
You should be aware that whatever you do (ie. installing a new certificate) will be temporary.
See https://learn.microsoft.com/en-us/archive/blogs/kwill/windows-azure-disk-partition-preservation for information about when the Windows partition (D drive) will be rebuilt, meaning you will lose your manually installed certificates.
Unexpected role recycles (ie. WaHostBootstrapper exits or WaIISHost/WaWorkerHost crashes) will cause the guest agent to uninstall and then reinstall all certificates.
Issue got resolved. After giving permission to "Network Service".
Right Click on Certificate > All Task > Manage Private Key > Add Network Service Account to get access to certificate.
We have a worker process running in IIS (Windows Server 2019) that makes an https request to a kafka resource in AWS in the background. In order for this process to work, we have to import certificates from Amazon into the local computer cert store so that the ssl connection can be established and it will trust the certificate presented from the resource in AWS. We have imported the cert chain and gotten this to work with the following caveats:
The service account specified for the AppPool identity has to be a local admin
OR
We have to run some process, ANY process (other than w3wp.exe that's already running), as the service account.
I've dealt quite a bit with certs, permissions, etc, but what is really odd about this one is that if I open notepad, for example, as the service account, then as long as notepad is running the process works - meaning it reads the cert and is able to establish the ssl connection. If I close notepad, the process then fails, and I get the following error:
ssl://b-2.kafkamsk.abc123.c2.kafka.us-west-2.amazonaws.com:9094/bootstrap: SSL handshake failed: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed: broker certificate could not be verified, verify that ssl.ca.location is correctly configured or root CA certificates are installed (add broker's CA certificate to the Windows Root certificate store) (after 72ms in state CONNECT)
(text in the URL replaced with abc123 for obfuscation)
Note that we don't need to access the private key of the cert, we simply need to read the cert from the cert store. The CA cert has been imported into "Trusted Root Certification Authorities." The intermediate cert has been imported into "Intermediate Certification Authorities" and the leaf cert has been imported into the personal store - all of these in the Local Computer cert store. And again, it all works if we simply login and run some process as the service account, even without it being a local admin.
I've run sysinternals procmon while executing the process that fails, and see several access denied attempts on HKEY_USERS.DEFAULT\Software\Microsoft\SystemCertificates, and those do not appear if I have notepad running as the service account when attempting the process. I've given explicit permissions to the service account on those registry keys, but it has not helped.
For obvious security reasons, we don't want our service account to be a local admin on the box, and for operations/administration reasons we don't want to rely on having some other process running as this account just to make this work.
It probably works when notepad is run as its triggering the user profile to be loaded, terminating notepad causes the profile to be unloaded. If you were to set LoadUserProfile to true on the app pool it would probably work - BUT this is not a good idea.
I think the proper solution is related to the permissions for IIS AppPool\AppPoolName on the certificate itself (which boils down to a file on disk with an ACL somewhere). Grant the app pool rights via the Certificates MMC or powershell and it should work.
if you download the latest .pem file from https://curl.se/docs/caextract.html, you can specify that file in the code with:
"ssl.ca.location",caCertLocation
Event Hubs Demo from Azure here:
https://github.com/Azure/azure-event-hubs-for-kafka/blob/master/quickstart/dotnet/EventHubsForKafkaSample/Program.cs
I am developing a windows service application that will run on customer PC/servers and access a Web API endpoint hosted in an Azure Website. It needs to authenticate the user, and I would prefer not storing credentials on the customer's machine. So, I've landed on client certificates to authenticate the users. I have this working against a local, non-Azure Website IIS instance with self-signed certificates. However, I'm unable to get it working in an Azure Website.
As far as I can tell, there are two issues that I'm not finding much documentation on:
How do I install my own CA certificate in the Trusted Root of the Website instance(s)? Or will this only work with CA certificates that are already trusted?
How do I enable "Accept Client Certificates" for this application? In IIS you do this under "SSL Settings". Documentation indicates that modifying the system.webServer/security/access node of app.config will accomplish this, but obviously you can't do that in Websites. Documentation for websites suggests this node is unlocked for use in web.config, however adding that node results in an error "The page cannot be displayed because an internal server error has occurred.", even if custom errors is off.
For Azure web sites vs web roles client authentication options are rather limited. Websites don't let you run programs with elevated permissions, which is required for making IIS changes and storing certificates into the trusted root.
There's a way to configure you website to always (you don't get the benefit of making it optional as with IIS 'Accept' configuration) request client certificate. This feature is currently only available through Azure management REST API, you can't access it through the portal UI. You can find more information here.
Essentially you turn on clientCertEnabled website setting to true. The mechanics of this option are different from traditional client authentication where server needs to have a CA certificate with which the client cert is signed in its trusted root. The server doesn't run any validation on the client certificate, the application needs to run the cert check itself, which comes in a request header "X-ARR-ClientCert". GetClientCertificate() extension method on HttpRequestMessage will parse it automatically.
Alternatively, you can host your Web API as a web role. That gives access to running startup tasks with elevated permissions that allows access to trusted root and making IIS configurations, more details/examples here. You can either copy the CA certificate to the app folder or upload to the user store via Azure portal so that it is available for copying over to the trusted root in a startup task. IIS changes can be made via “Microsoft.Web.Administration” library available as NuGet package through ServerManager class.
For question 2, here's a blog post on how to install client certificates on Azure Websites: http://azure.microsoft.com/blog/2014/10/27/using-certificates-in-azure-websites-applications/
For question 1, you can't install your own CA certs as trusted root certificates, but if you have certs from a CA that's already trusted then you can use them without any issues.
I am building a site that needs to call a 3rd party web service over https. The service requires an X509 certificate for authentication.
I can successfully call the service and get a response back using a console application, or a web application running in visual studio web server, this suggests to me that the code, and certificate provided by the 3rd party are all ok.
As soon as I deploy the site in IIS, it cannot connect to the service, I am getting "The request was aborted: Could not create SSL/TLS secure channel" error. I spent a couple of hours trying to figure this out, assuming it was permissions related as IIS app pool running under network service etc.
The certificate is installed in the local machine store, not current user, and I have granted network service (also added everyone is desperation!) using the winhttpcertcfg tool and manually in MMC > Manage Private Keys, so I am confident that the network service account has access to the certificate.
I also used the FindPrivateKey tool and checked the physical windows file and permissions look ok! I tried using identity impersonate in the config, using my windows account and that doesn't make a difference.
I am pulling my hair out with this one, can anyone give me any suggestions on what to try next?
Cheers