In regards to deploying certs to role instances of cses, what's the significance of specifying references to certificates in osprofile.secrets (in ARM template while describing cses) and also in .csdef/.cscfg? Do I need to list in both places?
Based on the documentation, the cert list in template.json's osprofile.secrets.vault.certificates 'Specifies set of certificates that should be installed onto the role instances.' Does that mean when a new role is created, cses will install these certificates to the role instance (vm). If yes, how does it know which store to install the certificates to in the VM?
Again, the same set of certificates are also listed in service definition file's (.csdef) certificate element. The documentation for that says, 'declaration of all certificates that need to be deployed'. How is this different from what osprofile.secrets.vault.certificates is doing?
Is it something like one of them (osprofile) specifies certificates that needs to be downloaded (not install) in the role instance? And the other listing, in csdef, means install the certs to the specified store location and store name?
Related
I have an Azure Batch account setup with system assigned identity (the account was created through TF and User assigned identities are not yet supported).
A certificate is available to the batch account and on the pool as well.
When inspecting the node on the pool (scaled to one for now), it shows a certificate reference:
I've manually created a job and a simple task (/bin/bash -c 'ls -la $AZ_BATCH_CERTIFICATES_DIR/') to list contents and everything comes empty.
This seems to be the case for all self-signed certificates I've used to try this.
Can somebody please point out what I'm doing wrong?
(I've tried all combinations for Task-NonAdmin, TaskAdmin, Pool-NonAdmin, Pool-Admin together with LocalMachine, currentUser).
Thanks all!
Well, this thing happened:
Issue with Windows LocalMachine certificates:
If you are adding certificate references on your pool which install into the Windows LocalMachine certificate store, and are running tasks without admin access which need access to the certificate's private key, your tasks will work on the old agent but not work in the new agent.
Only pfx files where your non-admin task needs access to the private key should be moved to "My" in CurrentUser
https://github.com/Azure/Batch/issues/1
If I upload the certs to CurrentUser\My, the tasks do get the certs.
Please let me know how to backup Azure WAF Resource Configuration/settings. I am not able find anything related to waf backup setting/configuration.
Go to Application Gateway -> Export Template
The template contains all configuration/settings for your WAF
I appreciate this question is a little old now - the answer already given and accepted is technically valid but note that any export of an Application Gateway you do that uses "SSL Certificates" will not include the certificates in the export.
So if you were to try and re-create the Application Gateway from the exported JSON, it will probably not work and may need additional configuration to re-import the SSL certificates referenced by listeners.
For information, you can also use the Export-AzResourceGroup cmdlet to export your App Gateway but this too does not include the SSL certificates.
A fairly recent (end of 2020) addition which alleviates this to some extent is the ability to pass a reference to a Key Vault certificate but this requires a User Assigned Managed Identity to be associated with the Application Gateway which has permissions to access the certificates and secrets (if they had passwords when added to the Key Vault).
Create a user-assigned managed identity - look for Managed Identities in the Azure Portal.
Configure your key vault - this basically means add permissions to the Key Vault for the Managed Identity to be able to manage certificates and read secrets.
Configure the application gateway. Use the Set-AzApplicationGatewayIdentity cmdlet to assign the UA-MI account's ID to the Application Gateway.
The instructions above are abbreviated from this article (which I'll get grief for adding, but I'm not regurgitating documentation here for the sake of it): https://learn.microsoft.com/en-us/azure/application-gateway/key-vault-certs
Remember that I said the key vault integration alleviates the issue to some extent. Using references still doesn't resolve the issue completely as I believe there are still some pieces of secret information omitted from exports which would be needed to fully re-create the Application Gateway in a working state.
How to use Desired State Configuration in combinition with ARM.
Scope:
- We have an Azure virtual machine that is deployed via an ARM template.
- The VM has an extension resource in the ARM template, for the Desired State Configuration
- We need to pass sensitive parameters (in a secure way!) into the Desired State Configuration (we want to create an additional local windows account with the DSC)
- Configuration file is used to know what public key to use for encryption, and to let the VM know which certificate it has to use for decryption (by thumbprint)
- When using ARM, you need to define the configuration data file in a separate property
- I noticed that the DSC service, automically adds an certificate for document encryption to the VM.
Question:
If I want to get this working out of the box, I will need to create the configurationDataFile upfront, and store it somewhere (like blob or something).
However, the 'out-of-the-box' certificate on the VM is only known after the ARM template has been deployed.
I was wondering if there is a way to get the encryption/decryption in DSC working, using the out of the box DSC Certificate on the VM, without using different incremental DSC templates.
So how can I know the out of the box certificate thumbprint at deployment time? (In the arm template?)
Do I actually need to transform the ConfigurationData file for every deployment (and finding the correct thumbprint of the VM), or is there an out of the box way to tell DSC via ARM to use the out of the box created certificate for this?
Because the target VM is also the authoring machine, the passwords can be passed as plain text, as they never leave the Virtual Machine.
This has been verified by Microsoft support.
I'm using a Azure Resource Manager(ARM) template to create and update a resource group in a release definition in Visual Studio Team Services(VSTS). I'm using the same template to upload the .pfx certificate to the web app.
For the first deployment the certificate got uploaded perfectly, but from the next deployment the deployment fails with the error "Another certificate exists with same thumbprint ******** at location West US in the Resource Group MyResourceGroup".
I tried recreating the webapp, but to my surprise the deployment fails for the first time itself. Looks like the certificate got uploaded to the resource group.
Is there a way to overwrite the existing .pfx certificate for every deployment.
You do not have to upload certificate for all deployments. The first certificate will become available to all deployments
Certificates are exposed at the resource group level, so deploying the same certificate again will definitely error out.
However, I don't see a reason as to why you need to upload a certificate.
Does your application need to read this certificate? if yes, then there is a different way to do this. See this article:
https://azure.microsoft.com/en-us/blog/using-certificates-in-azure-websites-applications/
Until today I had never encountered this error. I have been able to redeploy my applications, certificates and all, with no issues. I believe in my case that someone had previously manually added the certificate using a different name, possibly through the portal, and then when my pipeline executed it attempted to add the certificate using a different name.
Certificates are child resources of Microsoft.Web under the resource group. There are likely a number of options for resolving but I am going to focus on removing the certificate using Resource Explorer. (I bet that there is a Azure CLI or Azure PowerShell command to do this too.)
In resource explorer, locate the certificates node associated with your resource group using the left hand navigation pane. This will likely be in something like subscriptions -> {subscription name} -> resourceGroups -> {resource group name} -> providers -> Microsoft.Web -> certificates -> {certificate name}
Once located, select your certificate and then can use the Actions (POST, DELETE) tab in the right hand pane to delete the certificate. You should then be able to redeploy.
I am attempting to get Wasabi (the Enterprise library autoscaling block) to work within an Azure worker role. The Wasabi worker role (Extra Small, full trust) is scaling a different worker role within the same service. It works perfectly from a local console app, with an identical configuration - given the errors, the certificate isn't making it to the VM. I am using the latest versions of the Azure SDKs, the enterprise library autoscaling block, and the Azure portal.
Here are the steps I took, based on these docs: http://msdn.microsoft.com/en-us/library/hh680937(v=pandp.50).aspx
I created a management certificate as per the directions here: http://msdn.microsoft.com/en-us/library/gg432987.aspx.
I exported the .pfx with the private key and gave it a password.
I uploaded the .cer to the Settings->Management Certificates section on the portal.
I uploaded the .pfx with the correct password to the Cloud Services->(My Service)->Certificates, noting the thumbprint listed.
I created some trivial rules that scale up my app a few instances, and correctly configured the service information to use my new cert. The XML files are in blob storage. This exactly configuration works fine on my local machine in a console app.
I added an entry in the Wasabi role's configuration, using the correct cert name and thumbprint. I set it to use the CurrentUser\My store. I confirmed that the .csdef and .cscfg files were correctly updated.
I deploy the service to staging on Azure, using the publish tool. The certificate configuration setting correctly shows up in the Configuration setting for the role.
It doesn't scale the app. I check the trace entries, and it has an exception when trying to pull access the management API. It is trying to access the right subscription, and it's trying to find the correct certificate thumbprint in the right store, so my configuration is being loaded correctly. It claims that it cannot find the certificate with that thumbprint in that store.
I tried the LocalMachine\My store (configured in the role certificate settings, and in the service information store XML), and I got a different exceptionthe error listed in Azure WASABi SecurityNegotiationException. That fix was ultimately to go to CurrentUser, so that doesn't help me here.
I tried a lot of other combinations of CurrentUser\LocalMachine and different stores, and all CurrentUser locations result in certificate-not-found, and all LocalMachine stores result in the other exception.
I triple-checked the thumbprints in the role settings, the portal (certificate page) and the service information file, and they all match.
I then enabled remote-desktop and logged in to the Wasabi role instance, and used MMC to look at the certificate configuration for both the local machine and the current user. When I selected the LocalMachine store in the role certificate settings, the certificate did show up in the LocalMachine store, which tells me that the certificate is correctly installed in the service and the thumbprints match. When the CurrentUser store is selected, the certificate is not visible anywhere. This could be because the user that is used by RDP is not the same user as the service, but it does match the error.
So, in summary:
The certificate was correctly configured and installed in the portal (management certificates for the subscription, and service certificates).
Apparently, you must use the CurrentUser location, not the LocalMachine location, for the Wasabi role (as per the linked SO question).
When I'm trying to install to the CurrentUser, the certificate is not getting placed in the VM, at least not anywhere that the role can find it.
Any ideas?
Thanks!
See my answer to this SO POST. The certificate must be in LocalMachine and because of config changes in SDK 1.8 and Server2012 role initialization you have to run the worker role with elevated permissions to give NETWORK SERVICE access to the cert's private keys. Edit ServiceDefinition.csdef
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="blah" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2012-10.1.8">
<WorkerRole name="blah" vmsize="Small">
<Runtime executionContext="elevated" />
...
</WorkerRole>
</ServiceDefinition>