Accessing Certificates from the Azure Key Vault

This article describes how to use the 1E PowerShell Toolkit to directly retrieve certificates from the Azure Key Vault and then use them to authenticate with the 1E Platform.

As of version 1.2.9 of the 1E PowerShell Toolkit, access to the Azure Key Vault is now possible using direct oAuth requests and without using Microsoft-supplied DLLs. Refer to Accessing the Azure Key Vault using REST and oAuth.

Therefore, the information on this page only applies to versions of the Toolkit prior to version 1.2.9. Note that this change does not affect the functionality of the cmdlets themselves, which are discussed on this page.

This functionality relies on a set of Microsoft-provided DLLs and uses the assigned Managed Identity that has been given to the VM on which the task is running. However, it is possible to directly access the Azure Key Vault using standard REST APIs and bearer tokens, not relying on Microsoft-specific .NET DLLs, which would not be useful in environments such as Python, Java, Javascript, and so on.

About the Azure Key Vault

The Azure Key Vault, or Azure Credential Vault, is a resource accessible from any guest machine in the resource group to which the vault belongs, unlike certificate stores which are local to each guest. Refer to Managing certificates with the Azure Key Vault.

Using the 1E PowerShell Toolkit with the Azure Key Vault

You can use the 1E PowerShell Toolkit to retrieve certificates from the key vault. The set-1Eserver cmdlet accepts three parameters that allow you to authenticate directly using certificates from the key vault.

The get-1Ecertificatefromkeyvault cmdlet allows you to directly retrieve an X509 certificate object and then pass it to other cmdlets that accept certificates, such as get-1Ebearertoken.

For more information on these cmdlets, refer to Platform server management cmdlets.

Prerequisites for using the Azure Key Vault

  • For versions prior to Toolkit 1.2.9, you must run the 1E PowerShell Toolkit using PowerShell Core and not legacy PowerShell. You can use either Linux or Windows guests. Versions 1.2.9+ will work in either legacy PowerShell or PowerShell Core because the DLL dependencies have been removed.

  • For versions prior to Toolkit 1.2.9, you require five support DLLs that must be in the folder that the 1E PowerShell Toolkit resides in. Refer to .Support DLLs

  • For versions prior to Toolkit 1.2.9, the guest VM must have been assigned a managed identity that has permission to access the certificate(s) you wish to retrieve. Version 1.2.9+ of the Toolkit also allows you to use a shared secret to access the vault, which is useful for scenarios where the script is being run outside the SaaS environment.

Support DLLs

The 1E PowerShell Toolkit (prior to 1.2.9) dynamically loads five support DLLs (assemblies) which must be located in the folder containing the Toolkit files. An error is thrown if any of these cannot be loaded.

The support DLLs are the following:

  • Azure.Identity.dll

  • Azure.Security.KeyVault.Certificates.dll

  • Azure.Security.KeyVault.Secrets.dll

  • Azure.Core.dll

  • Microsoft.Identity.Client.dll

You can obtain these for the target .NET platform you are running PowerShell Core from by using the install-package cmdlet for each of these and then copying the appropriate DLL from the installed nugetpackage path for the appropriate library. To find the path use the get-package cmdlet which shows all installed packages and their install paths.

Currently, PowerShell Core doesn’t have direct support for consuming Nuget packages. This is a requested feature that may be implemented in a later release.