https://github.com/keyfactor/azure-appgateway-orchestrator
The Azure Application Gateway Universal Orchestrator Extension for Keyfactor
https://github.com/keyfactor/azure-appgateway-orchestrator
azure-app-gateway azure-application-gateway keyfactor-universal-orchestrator
Last synced: 3 months ago
JSON representation
The Azure Application Gateway Universal Orchestrator Extension for Keyfactor
- Host: GitHub
- URL: https://github.com/keyfactor/azure-appgateway-orchestrator
- Owner: Keyfactor
- License: apache-2.0
- Created: 2023-01-20T18:38:13.000Z (over 3 years ago)
- Default Branch: main
- Last Pushed: 2024-08-14T22:32:29.000Z (almost 2 years ago)
- Last Synced: 2024-08-15T22:04:07.125Z (almost 2 years ago)
- Topics: azure-app-gateway, azure-application-gateway, keyfactor-universal-orchestrator
- Language: C#
- Homepage:
- Size: 1.31 MB
- Stars: 2
- Watchers: 20
- Forks: 0
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE
Awesome Lists containing this project
README
Azure Application Gateway Universal Orchestrator Extension
Support
·
Installation
·
License
·
Related Integrations
## Overview
The Azure Application Gateway Orchestrator extension remotely manages certificates used by Azure Application Gateways. The extension supports two different store types - one that generally manages certificates stored in the Application Gateway, and one that manages the bindings of Application Gateway certificates to HTTPS/TLS Listeners.
> The extension manages only App Gateway Certificates, _not_ Azure Key Vault certificates. Certificates imported from Azure Key Vault to Azure Application Gateways will be downloaded for certificate inventory purposes _only_. The Azure Application Gateway orchestrator extension will _not_ perform certificate management operations on Azure Key Vault secrets. If you need to manage certificates in Azure Key Vault, use the [Azure Key Vault Orchestrator](https://github.com/Keyfactor/azurekeyvault-orchestrator).
>
> If the certificate management capabilities of Azure Key Vault are desired over direct management of certificates in Application Gateways, the Azure Key Vault orchestrator can be used in conjunction with this extension for accurate certificate location reporting via the inventory job type. This management strategy requires manual binding of certificates imported to an Application Gateway from AKV and can result in broken state in the Azure Application Gateway in the case that the secret is deleted in AKV.
The Azure Application Gateway Universal Orchestrator extension implements 2 Certificate Store Types. Depending on your use case, you may elect to use one, or both of these Certificate Store Types. Descriptions of each are provided below.
- [Azure Application Gateway Certificate](#AzureAppGw)
- [Azure Application Gateway Certificate Binding](#AppGwBin)
## Compatibility
This integration is compatible with Keyfactor Universal Orchestrator version 10.4 and later.
## Support
The Azure Application Gateway Universal Orchestrator extension If you have a support issue, please open a support ticket by either contacting your Keyfactor representative or via the Keyfactor Support Portal at https://support.keyfactor.com.
> To report a problem or suggest a new feature, use the **[Issues](../../issues)** tab. If you want to contribute actual bug fixes or proposed enhancements, use the **[Pull requests](../../pulls)** tab.
## Requirements & Prerequisites
Before installing the Azure Application Gateway Universal Orchestrator extension, we recommend that you install [kfutil](https://github.com/Keyfactor/kfutil). Kfutil is a command-line tool that simplifies the process of creating store types, installing extensions, and instantiating certificate stores in Keyfactor Command.
### Azure Service Principal (Azure Resource Manager Authentication)
The Azure Application Gateway Orchestrator extension uses an [Azure Service Principal](https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals?tabs=browser) for authentication. Follow [Microsoft's documentation](https://learn.microsoft.com/en-us/entra/identity-platform/howto-create-service-principal-portal) to create a service principal.
#### Azure Application Gateway permissions
For quick start and non-production environments, a Role Assignment should be created on _each resource group_ that own Application Gateways desiring management that grants the created Application/Service Principal the [Contributor (Privileged administrator) Role](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#contributor). For production environments, a custom role should be created that grants the following permissions:
- `Microsoft.Resources/subscriptions/resourcegroups/read` - Read : Get Resource Group
- `Microsoft.Network/applicationGateways/read` - Read : Get Application Gateway
- `Microsoft.Network/applicationGateways/write` - Write : Create or Update Application Gateway
- `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action` - Other : RBAC action for assigning an existing user assigned identity to a resource
- `Microsoft.Network/virtualNetworks/subnets/join/action` - Other : Joins a virtual network. Not Alertable.
> [!IMPORTANT]
> Even if the Service Principal has permission to perform the 'Microsoft.Network/applicationGateways/write' action over the scope of the required resource group, there may be other permissions that are required by the CreateOrUpdate operation depending on the complexity of the Application Gateway's configuration. As such, the list of permissions above should not be considered as comprehensive.
#### Azure Key Vault permissions
If the managed Application Gateway is integrated with Azure Key Vault per the discussion in the [Certificates Imported to Application Gateways from Azure Key Vault](#certificates-imported-to-application-gateways-from-azure-key-vault) section, perform one of the following actions for each Key Vault with certificates imported to App Gateways:
* **Azure role-based access control** - Create a Role Assignment that grants the Application/Service Principal the [Key Vault Secrets User](https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide?tabs=azure-cli) built-in role.
* **Vault access policy** - [Create an Access Policy](https://learn.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal) that grants the Application/Service Principal the Get secret permission for each Azure Key Vault.
#### Client Certificate or Client Secret
Beginning in version 3.0.0, the Azure Application Gateway Orchestrator extension supports both [client certificate authentication](https://learn.microsoft.com/en-us/graph/auth-register-app-v2#option-1-add-a-certificate) and [client secret](https://learn.microsoft.com/en-us/graph/auth-register-app-v2#option-2-add-a-client-secret) authentication.
* **Client Secret** - Follow [Microsoft's documentation](https://learn.microsoft.com/en-us/graph/auth-register-app-v2#option-2-add-a-client-secret) to create a Client Secret. This secret will be used as the **Server Password** field in the [Certificate Store Configuration](#certificate-store-configuration) section.
* **Client Certificate** - Create a client certificate key pair with the Client Authentication extended key usage. The client certificate will be used in the ClientCertificate field in the [Certificate Store Configuration](#certificate-store-configuration) section. If you have access to Keyfactor Command, the instructions in this section walk you through enrolling a certificate and ensuring that it's in the correct format. Once enrolled, follow [Microsoft's documentation](https://learn.microsoft.com/en-us/graph/auth-register-app-v2#option-1-add-a-certificate) to add the _public key_ certificate (no private key) to the service principal used for authentication.
The certificate can be in either of the following formats:
* Base64-encoded PKCS#12 (PFX) with a matching private key.
* Base64-encoded PEM-encoded certificate _and_ PEM-encoded PKCS8 private key. Make sure that the certificate and private key are separated with a newline. The order doesn't matter - the extension will determine which is which.
If the private key is encrypted, the encryption password will replace the **Server Password** field in the [Certificate Store Configuration](#certificate-store-configuration) section.
#### Creating and Formatting a Client Certificate using Keyfactor Command
To get started quickly, you can follow the instructions below to create and properly format a client certificate to
authenticate to the Microsoft Graph API.
1. In Keyfactor Command, hover over **Enrollment** and select **PFX Enrollment**.
2. Select a **Template** that supports Client Authentication as an extended key usage.
3. Populate the certificate subject as appropriate for the Template. It may be enough to only populate the Common
Name, but consult your IT policy to ensure that this certificate is compliant.
4. At the bottom of the page, uncheck the box for **Include Chain**, and select either **PFX** or **PEM** as the
certificate Format.
5. Make a note of the password on the next page *it won't be shown again*.
6. Prepare the certificate and private key for Azure and the Orchestrator extension:
* If you downloaded the certificate in PEM format, use the commands below:
```shell
# Verify that the certificate downloaded from Command contains the certificate and private key. They should be in the same file
cat Click to expand details
The Azure Application Gateway Certificate store type, `AzureAppGw`, manages `ApplicationGatewaySslCertificate` objects
owned by Azure Application Gateways. This store type collects inventory and manages all ApplicationGatewaySslCertificate
objects associated with an Application Gateway. The store type is implemented primarily for Inventory and Management
Remove operations, since the intended usage of ApplicationGatewaySslCertificates in Application Gateways is for serving
TLS client traffic via TLS Listeners. Management Add and associated logic for certificate renewal is also supported for
this certificate store type for completeness, but the primary intended functionality of this extension is implemented
with the App Gateway Certificate Binding store type.
> [!IMPORTANT]
> If an ApplicationGatewaySslCertificate is bound to a TLS Listener at the time of a Management Remove operation, the
> operation will fail since at least one certificate must be bound at all times.
> [!IMPORTANT]
> If a renewal job is scheduled for an `AzureAppGw` certificate store, the extension will report a success and perform
> no action if the certificate being renewed is bound to a TLS Listener. This is because a certificate located in an
> `AzureAppGw` certificate store that is bound to a TLS Listener is logically the same as the same certificate located in
> an `AzureAppGwBin` store type. For this reason, it's expected that the certificate will be renewed and re-bound to the
> listener by the `AppGwBin` certificate operations.
> [!IMPORTANT]
> If the renewed certificate is not bound to a TLS Listener, the operation will be performed the same as any certificate
> renewal process that honors the Overwrite flag.
#### Certificates Imported to Application Gateways from Azure Key Vault
Natively, Azure Application Gateways support integration with Azure Key Vault for secret/certificate management. This
integration works by creating a TLS Listener certificate with a reference to a secret in Azure Key Vault (specifically,
a URI in the format `https://.vault.azure.net/secrets/`), authenticated using a Managed
Identity. If the Application Gateway orchestrator extension is deployed to manage App Gateways with certificates
imported from Azure Key Vault, the following truth table represents the possible operations and their result,
specifically with respect to AKV.
| Store Type | Operation | Result |
|-----------------|-----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `AzureAppGw` | Inventory | Certificate is downloaded from Azure Key Vault and reported back to Keyfactor Command. In Keyfactor Command, the certificate will show as being located in the AzureAppGw certificate store [in addition to the AKV, if AKV orchestrator extension is also deployed]. |
| `AzureAppGw` | Add | The Add operation will not create secrets in AKV; it creates ApplicationGatewaySslCertificates.
If an `AzureAppGw` Add operation is scheduled with the Replace flag, the _**link to the AKV certificate will be broken**_, and a native ApplicationGatewaySslCertificate will be created in its place - The secret in AKV will still exist. |
| `AzureAppGw` | Remove | The ApplicationGatewaySslCertificate is deleted from the Application Gateway, but the secret that the certificate referenced in AKV still exists. |
| `AzureAppGwBin` | Inventory | Certificate is downloaded from Azure Key Vault and reported back to Keyfactor Command. In Keyfactor Command, the certificate will show as present in both an `AzureAppGw` certificate store _and_ an `AppGwBin` certificate store [in addition to the AKV, if AKV orchestrator extension is also deployed]. |
| `AzureAppGwBin` | Add | The Add operation will not create secrets in AKV; it creates ApplicationGatewaySslCertificates.
If a certificate with the same name as the TLS Listener already exists, it will be _replaced_ by a new ApplicationGatewaySslCertificate.
If the certificate being replaced was imported from AKV, this binding will be broken and the secret will still exist in AKV. |
##### Mechanics of the Azure Key Vault Download Operation for Inventory Jobs that report certificates imported from AKV
If an AzureApplicationSslCertificate references a secret in AKV (was imported to the App Gateway from AKV), the
inventory job will create and use a `SecretClient` from the [
`Azure.Security.KeyVault.Secrets.SecretClient` dotnet package](https://learn.microsoft.com/en-us/dotnet/api/azure.security.keyvault.secrets.secretclient?view=azure-dotnet).
Authentication to AKV via this client is configured using the exact same `TokenCredential` provided by
the [Azure Identity client library for .NET](https://learn.microsoft.com/en-us/dotnet/api/overview/azure/identity-readme?view=azure-dotnet).
This means that the Service Principal described in the [Azure Configuration](#azure-configuration) section must also
have appropriate permissions to read secrets from the AKV that the App Gateway is integrated with. The secret referenced
in the AzureApplicationSslCertificate will be accessed exactly as reported by Azure, regardless of whether it exists in
AKV.
#### Supported Operations
| Operation | Is Supported |
|--------------|------------------------------------------------------------------------------------------------------------------------|
| Add | ✅ Checked |
| Remove | ✅ Checked |
| Discovery | ✅ Checked |
| Reenrollment | 🔲 Unchecked |
| Create | 🔲 Unchecked |
#### Store Type Creation
##### Using kfutil:
`kfutil` is a custom CLI for the Keyfactor Command API and can be used to create certificate store types.
For more information on [kfutil](https://github.com/Keyfactor/kfutil) check out the [docs](https://github.com/Keyfactor/kfutil?tab=readme-ov-file#quickstart)
Click to expand AzureAppGw kfutil details
##### Using online definition from GitHub:
This will reach out to GitHub and pull the latest store-type definition
```shell
# Azure Application Gateway Certificate
kfutil store-types create AzureAppGw
```
##### Offline creation using integration-manifest file:
If required, it is possible to create store types from the [integration-manifest.json](./integration-manifest.json) included in this repo.
You would first download the [integration-manifest.json](./integration-manifest.json) and then run the following command
in your offline environment.
```shell
kfutil store-types create --from-file integration-manifest.json
```
#### Manual Creation
Below are instructions on how to create the AzureAppGw store type manually in
the Keyfactor Command Portal
Click to expand manual AzureAppGw details
Create a store type called `AzureAppGw` with the attributes in the tables below:
##### Basic Tab
| Attribute | Value | Description |
| --------- | ----- | ----- |
| Name | Azure Application Gateway Certificate | Display name for the store type (may be customized) |
| Short Name | AzureAppGw | Short display name for the store type |
| Capability | AzureAppGw | Store type name orchestrator will register with. Check the box to allow entry of value |
| Supports Add | ✅ Checked | Check the box. Indicates that the Store Type supports Management Add |
| Supports Remove | ✅ Checked | Check the box. Indicates that the Store Type supports Management Remove |
| Supports Discovery | ✅ Checked | Check the box. Indicates that the Store Type supports Discovery |
| Supports Reenrollment | 🔲 Unchecked | Indicates that the Store Type supports Reenrollment |
| Supports Create | 🔲 Unchecked | Indicates that the Store Type supports store creation |
| Needs Server | ✅ Checked | Determines if a target server name is required when creating store |
| Blueprint Allowed | 🔲 Unchecked | Determines if store type may be included in an Orchestrator blueprint |
| Uses PowerShell | 🔲 Unchecked | Determines if underlying implementation is PowerShell |
| Requires Store Password | 🔲 Unchecked | Enables users to optionally specify a store password when defining a Certificate Store. |
| Supports Entry Password | 🔲 Unchecked | Determines if an individual entry within a store can have a password. |
The Basic tab should look like this:

##### Advanced Tab
| Attribute | Value | Description |
| --------- | ----- | ----- |
| Supports Custom Alias | Required | Determines if an individual entry within a store can have a custom Alias. |
| Private Key Handling | Required | This determines if Keyfactor can send the private key associated with a certificate to the store. Required because IIS certificates without private keys would be invalid. |
| PFX Password Style | Default | 'Default' - PFX password is randomly generated, 'Custom' - PFX password may be specified when the enrollment job is created (Requires the Allow Custom Password application setting to be enabled.) |
The Advanced tab should look like this:

> For Keyfactor **Command versions 24.4 and later**, a Certificate Format dropdown is available with PFX and PEM options. Ensure that **PFX** is selected, as this determines the format of new and renewed certificates sent to the Orchestrator during a Management job. Currently, all Keyfactor-supported Orchestrator extensions support only PFX.
##### Custom Fields Tab
Custom fields operate at the certificate store level and are used to control how the orchestrator connects to the remote target server containing the certificate store to be managed. The following custom fields should be added to the store type:
| Name | Display Name | Description | Type | Default Value/Options | Required |
| ---- | ------------ | ---- | --------------------- | -------- | ----------- |
| ServerUsername | Server Username | Application ID of the service principal, representing the identity used for managing the Application Gateway. | Secret | | 🔲 Unchecked |
| ServerPassword | Server Password | A Client Secret that the extension will use to authenticate with the Azure Resource Management API for managing Application Gateway certificates, OR the password that encrypts the private key in ClientCertificate | Secret | | 🔲 Unchecked |
| ClientCertificate | Client Certificate | The client certificate used to authenticate with Azure Resource Management API for managing Application Gateway certificates. See the [requirements](#client-certificate-or-client-secret) for more information. | Secret | | 🔲 Unchecked |
| AzureCloud | Azure Global Cloud Authority Host | Specifies the Azure Cloud instance used by the organization. | MultipleChoice | public,china,germany,government | 🔲 Unchecked |
| ServerUseSsl | Use SSL | Specifies whether SSL should be used for communication with the server. Set to 'true' to enable SSL, and 'false' to disable it. | Bool | true | ✅ Checked |
The Custom Fields tab should look like this:

### AppGwBin
Click to expand details
The Azure Application Gateway Certificate Binding store type, `AzureAppGwBin`, represents certificates bound to TLS
Listeners on Azure App Gateways. The only supported operations on this store type are Management Add and Inventory. The
Management Add operation for this store type creates and binds an ApplicationGatewaySslCertificate to a pre-existing TLS
Listener on an Application Gateway. When the Add operation is configured in Keyfactor Command, the certificate Alias
configures which TLS Listener the certificate will be bound to. If the HTTPS listener is already bound to a certificate
with the same name, the Management Add operation will perform a replacement of the certificate,
_**regardless of the existence of the Replace flag configured with renewal jobs**_. The replacement operation performs
several API interactions with Azure since at least one certificate must be bound to a TLS listener at all times, and the
name of ApplicationGatewaySslCertificates must be unique. For the sake of completeness, the following describes the
mechanics of this replacement operation:
1. Determine the name of the certificate currently bound to the HTTPS listener - Alias in 100% of cases if the
certificate was originally added by the App Gateway Orchestrator Extension, or something else if the certificate was
added by some other means (IE, the Azure Portal, or some other API client).
2. Create and bind a temporary certificate to the HTTPS listener with the same name as the Alias.
3. Delete the AppGatewayCertificate previously bound to the HTTPS listener called Alias.
4. Recreate and bind an AppGatewayCertificate with the same name as the HTTPS listener called Alias. If the Alias is
called `listener1`, the new certificate will be called `listener1`, regardless of the name of the certificate that
was previously bound to the listener.
5. Delete the temporary certificate.
In the unlikely event that a failure occurs at any point in the replacement procedure, it's expected that the correct
certificate will be served by the TLS Listener, since most of the mechanics are actually implemented to resolve the
unique naming requirement.
The Inventory job type for `AzureAppGwBin` reports only ApplicationGatewaySslCertificates that are bound to TLS
Listeners. If the certificate was added with Keyfactor Command and this orchestrator extension, the name of the
certificate in the Application Gateway will be the same as the TLS Listener. E.g., if the Alias configured in Command
corresponds to a TLS Listener called `location-service-https-lstn1`, the certificate in the Application Gateway will
also be called `location-service-https-lstn1`. However, if the certificate was added to the Application Gateway by other
means (such as the Azure CLI, import from AKV, etc.), the Inventory job mechanics will still report the name of the TLS
Listener in its report back to Command.
#### Certificates Imported to Application Gateways from Azure Key Vault
Natively, Azure Application Gateways support integration with Azure Key Vault for secret/certificate management. This
integration works by creating a TLS Listener certificate with a reference to a secret in Azure Key Vault (specifically,
a URI in the format `https://.vault.azure.net/secrets/`), authenticated using a Managed
Identity. If the Application Gateway orchestrator extension is deployed to manage App Gateways with certificates
imported from Azure Key Vault, the following truth table represents the possible operations and their result,
specifically with respect to AKV.
| Store Type | Operation | Result |
|-----------------|-----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `AzureAppGw` | Inventory | Certificate is downloaded from Azure Key Vault and reported back to Keyfactor Command. In Keyfactor Command, the certificate will show as being located in the AzureAppGw certificate store [in addition to the AKV, if AKV orchestrator extension is also deployed]. |
| `AzureAppGw` | Add | The Add operation will not create secrets in AKV; it creates ApplicationGatewaySslCertificates.
If an `AzureAppGw` Add operation is scheduled with the Replace flag, the _**link to the AKV certificate will be broken**_, and a native ApplicationGatewaySslCertificate will be created in its place - The secret in AKV will still exist. |
| `AzureAppGw` | Remove | The ApplicationGatewaySslCertificate is deleted from the Application Gateway, but the secret that the certificate referenced in AKV still exists. |
| `AzureAppGwBin` | Inventory | Certificate is downloaded from Azure Key Vault and reported back to Keyfactor Command. In Keyfactor Command, the certificate will show as present in both an `AzureAppGw` certificate store _and_ an `AppGwBin` certificate store [in addition to the AKV, if AKV orchestrator extension is also deployed]. |
| `AzureAppGwBin` | Add | The Add operation will not create secrets in AKV; it creates ApplicationGatewaySslCertificates.
If a certificate with the same name as the TLS Listener already exists, it will be _replaced_ by a new ApplicationGatewaySslCertificate.
If the certificate being replaced was imported from AKV, this binding will be broken and the secret will still exist in AKV. |
##### Mechanics of the Azure Key Vault Download Operation for Inventory Jobs that report certificates imported from AKV
If an AzureApplicationSslCertificate references a secret in AKV (was imported to the App Gateway from AKV), the
inventory job will create and use a `SecretClient` from the [
`Azure.Security.KeyVault.Secrets.SecretClient` dotnet package](https://learn.microsoft.com/en-us/dotnet/api/azure.security.keyvault.secrets.secretclient?view=azure-dotnet).
Authentication to AKV via this client is configured using the exact same `TokenCredential` provided by
the [Azure Identity client library for .NET](https://learn.microsoft.com/en-us/dotnet/api/overview/azure/identity-readme?view=azure-dotnet).
This means that the Service Principal described in the [Azure Configuration](#azure-configuration) section must also
have appropriate permissions to read secrets from the AKV that the App Gateway is integrated with. The secret referenced
in the AzureApplicationSslCertificate will be accessed exactly as reported by Azure, regardless of whether it exists in
AKV.
#### Supported Operations
| Operation | Is Supported |
|--------------|------------------------------------------------------------------------------------------------------------------------|
| Add | ✅ Checked |
| Remove | 🔲 Unchecked |
| Discovery | ✅ Checked |
| Reenrollment | 🔲 Unchecked |
| Create | 🔲 Unchecked |
#### Store Type Creation
##### Using kfutil:
`kfutil` is a custom CLI for the Keyfactor Command API and can be used to create certificate store types.
For more information on [kfutil](https://github.com/Keyfactor/kfutil) check out the [docs](https://github.com/Keyfactor/kfutil?tab=readme-ov-file#quickstart)
Click to expand AppGwBin kfutil details
##### Using online definition from GitHub:
This will reach out to GitHub and pull the latest store-type definition
```shell
# Azure Application Gateway Certificate Binding
kfutil store-types create AppGwBin
```
##### Offline creation using integration-manifest file:
If required, it is possible to create store types from the [integration-manifest.json](./integration-manifest.json) included in this repo.
You would first download the [integration-manifest.json](./integration-manifest.json) and then run the following command
in your offline environment.
```shell
kfutil store-types create --from-file integration-manifest.json
```
#### Manual Creation
Below are instructions on how to create the AppGwBin store type manually in
the Keyfactor Command Portal
Click to expand manual AppGwBin details
Create a store type called `AppGwBin` with the attributes in the tables below:
##### Basic Tab
| Attribute | Value | Description |
| --------- | ----- | ----- |
| Name | Azure Application Gateway Certificate Binding | Display name for the store type (may be customized) |
| Short Name | AppGwBin | Short display name for the store type |
| Capability | AzureAppGwBin | Store type name orchestrator will register with. Check the box to allow entry of value |
| Supports Add | ✅ Checked | Check the box. Indicates that the Store Type supports Management Add |
| Supports Remove | 🔲 Unchecked | Indicates that the Store Type supports Management Remove |
| Supports Discovery | ✅ Checked | Check the box. Indicates that the Store Type supports Discovery |
| Supports Reenrollment | 🔲 Unchecked | Indicates that the Store Type supports Reenrollment |
| Supports Create | 🔲 Unchecked | Indicates that the Store Type supports store creation |
| Needs Server | ✅ Checked | Determines if a target server name is required when creating store |
| Blueprint Allowed | 🔲 Unchecked | Determines if store type may be included in an Orchestrator blueprint |
| Uses PowerShell | 🔲 Unchecked | Determines if underlying implementation is PowerShell |
| Requires Store Password | 🔲 Unchecked | Enables users to optionally specify a store password when defining a Certificate Store. |
| Supports Entry Password | 🔲 Unchecked | Determines if an individual entry within a store can have a password. |
The Basic tab should look like this:

##### Advanced Tab
| Attribute | Value | Description |
| --------- | ----- | ----- |
| Supports Custom Alias | Required | Determines if an individual entry within a store can have a custom Alias. |
| Private Key Handling | Required | This determines if Keyfactor can send the private key associated with a certificate to the store. Required because IIS certificates without private keys would be invalid. |
| PFX Password Style | Default | 'Default' - PFX password is randomly generated, 'Custom' - PFX password may be specified when the enrollment job is created (Requires the Allow Custom Password application setting to be enabled.) |
The Advanced tab should look like this:

> For Keyfactor **Command versions 24.4 and later**, a Certificate Format dropdown is available with PFX and PEM options. Ensure that **PFX** is selected, as this determines the format of new and renewed certificates sent to the Orchestrator during a Management job. Currently, all Keyfactor-supported Orchestrator extensions support only PFX.
##### Custom Fields Tab
Custom fields operate at the certificate store level and are used to control how the orchestrator connects to the remote target server containing the certificate store to be managed. The following custom fields should be added to the store type:
| Name | Display Name | Description | Type | Default Value/Options | Required |
| ---- | ------------ | ---- | --------------------- | -------- | ----------- |
| ServerUsername | Server Username | Application ID of the service principal, representing the identity used for managing the Application Gateway. | Secret | | 🔲 Unchecked |
| ServerPassword | Server Password | A Client Secret that the extension will use to authenticate with the Azure Resource Management API for managing Application Gateway certificates, OR the password that encrypts the private key in ClientCertificate | Secret | | 🔲 Unchecked |
| ClientCertificate | Client Certificate | The client certificate used to authenticate with Azure Resource Management API for managing Application Gateway certificates. See the [requirements](#client-certificate-or-client-secret) for more information. | Secret | | 🔲 Unchecked |
| AzureCloud | Azure Global Cloud Authority Host | Specifies the Azure Cloud instance used by the organization. | MultipleChoice | public,china,germany,government | 🔲 Unchecked |
| ServerUseSsl | Use SSL | Specifies whether SSL should be used for communication with the server. Set to 'true' to enable SSL, and 'false' to disable it. | Bool | true | ✅ Checked |
The Custom Fields tab should look like this:

## Installation
1. **Download the latest Azure Application Gateway Universal Orchestrator extension from GitHub.**
Navigate to the [Azure Application Gateway Universal Orchestrator extension GitHub version page](https://github.com/Keyfactor/azure-appgateway-orchestrator/releases/latest). Refer to the compatibility matrix below to determine whether the `net6.0` or `net8.0` asset should be downloaded. Then, click the corresponding asset to download the zip archive.
| Universal Orchestrator Version | Latest .NET version installed on the Universal Orchestrator server | `rollForward` condition in `Orchestrator.runtimeconfig.json` | `azure-appgateway-orchestrator` .NET version to download |
| --------- | ----------- | ----------- | ----------- |
| Older than `11.0.0` | | | `net6.0` |
| Between `11.0.0` and `11.5.1` (inclusive) | `net6.0` | | `net6.0` |
| Between `11.0.0` and `11.5.1` (inclusive) | `net8.0` | `Disable` | `net6.0` |
| Between `11.0.0` and `11.5.1` (inclusive) | `net8.0` | `LatestMajor` | `net8.0` |
| `11.6` _and_ newer | `net8.0` | | `net8.0` |
Unzip the archive containing extension assemblies to a known location.
> **Note** If you don't see an asset with a corresponding .NET version, you should always assume that it was compiled for `net6.0`.
2. **Locate the Universal Orchestrator extensions directory.**
* **Default on Windows** - `C:\Program Files\Keyfactor\Keyfactor Orchestrator\extensions`
* **Default on Linux** - `/opt/keyfactor/orchestrator/extensions`
3. **Create a new directory for the Azure Application Gateway Universal Orchestrator extension inside the extensions directory.**
Create a new directory called `azure-appgateway-orchestrator`.
> The directory name does not need to match any names used elsewhere; it just has to be unique within the extensions directory.
4. **Copy the contents of the downloaded and unzipped assemblies from __step 2__ to the `azure-appgateway-orchestrator` directory.**
5. **Restart the Universal Orchestrator service.**
Refer to [Starting/Restarting the Universal Orchestrator service](https://software.keyfactor.com/Core-OnPrem/Current/Content/InstallingAgents/NetCoreOrchestrator/StarttheService.htm).
6. **(optional) PAM Integration**
The Azure Application Gateway Universal Orchestrator extension is compatible with all supported Keyfactor PAM extensions to resolve PAM-eligible secrets. PAM extensions running on Universal Orchestrators enable secure retrieval of secrets from a connected PAM provider.
To configure a PAM provider, [reference the Keyfactor Integration Catalog](https://keyfactor.github.io/integrations-catalog/content/pam) to select an extension and follow the associated instructions to install it on the Universal Orchestrator (remote).
> The above installation steps can be supplemented by the [official Command documentation](https://software.keyfactor.com/Core-OnPrem/Current/Content/InstallingAgents/NetCoreOrchestrator/CustomExtensions.htm?Highlight=extensions).
## Defining Certificate Stores
The Azure Application Gateway Universal Orchestrator extension implements 2 Certificate Store Types, each of which implements different functionality. Refer to the individual instructions below for each Certificate Store Type that you deemed necessary for your use case from the installation section.
Azure Application Gateway Certificate (AzureAppGw)
### Store Creation
#### Manually with the Command UI
Click to expand details
1. **Navigate to the _Certificate Stores_ page in Keyfactor Command.**
Log into Keyfactor Command, toggle the _Locations_ dropdown, and click _Certificate Stores_.
2. **Add a Certificate Store.**
Click the Add button to add a new Certificate Store. Use the table below to populate the **Attributes** in the **Add** form.
| Attribute | Description |
| --------- | ----------- |
| Category | Select "Azure Application Gateway Certificate" or the customized certificate store name from the previous step. |
| Container | Optional container to associate certificate store with. |
| Client Machine | The Azure Tenant (directory) ID that owns the Service Principal. |
| Store Path | Azure resource ID of the application gateway, following the format: /subscriptions//resourceGroups//providers/Microsoft.Network/applicationGateways/. |
| Orchestrator | Select an approved orchestrator capable of managing `AzureAppGw` certificates. Specifically, one with the `AzureAppGw` capability. |
| ServerUsername | Application ID of the service principal, representing the identity used for managing the Application Gateway. |
| ServerPassword | A Client Secret that the extension will use to authenticate with the Azure Resource Management API for managing Application Gateway certificates, OR the password that encrypts the private key in ClientCertificate |
| ClientCertificate | The client certificate used to authenticate with Azure Resource Management API for managing Application Gateway certificates. See the [requirements](#client-certificate-or-client-secret) for more information. |
| AzureCloud | Specifies the Azure Cloud instance used by the organization. |
| ServerUseSsl | Specifies whether SSL should be used for communication with the server. Set to 'true' to enable SSL, and 'false' to disable it. |
#### Using kfutil CLI
Click to expand details
1. **Generate a CSV template for the AzureAppGw certificate store**
```shell
kfutil stores import generate-template --store-type-name AzureAppGw --outpath AzureAppGw.csv
```
2. **Populate the generated CSV file**
Open the CSV file, and reference the table below to populate parameters for each **Attribute**.
| Attribute | Description |
| --------- | ----------- |
| Category | Select "Azure Application Gateway Certificate" or the customized certificate store name from the previous step. |
| Container | Optional container to associate certificate store with. |
| Client Machine | The Azure Tenant (directory) ID that owns the Service Principal. |
| Store Path | Azure resource ID of the application gateway, following the format: /subscriptions//resourceGroups//providers/Microsoft.Network/applicationGateways/. |
| Orchestrator | Select an approved orchestrator capable of managing `AzureAppGw` certificates. Specifically, one with the `AzureAppGw` capability. |
| Properties.ServerUsername | Application ID of the service principal, representing the identity used for managing the Application Gateway. |
| Properties.ServerPassword | A Client Secret that the extension will use to authenticate with the Azure Resource Management API for managing Application Gateway certificates, OR the password that encrypts the private key in ClientCertificate |
| Properties.ClientCertificate | The client certificate used to authenticate with Azure Resource Management API for managing Application Gateway certificates. See the [requirements](#client-certificate-or-client-secret) for more information. |
| Properties.AzureCloud | Specifies the Azure Cloud instance used by the organization. |
| Properties.ServerUseSsl | Specifies whether SSL should be used for communication with the server. Set to 'true' to enable SSL, and 'false' to disable it. |
3. **Import the CSV file to create the certificate stores**
```shell
kfutil stores import csv --store-type-name AzureAppGw --file AzureAppGw.csv
```
#### PAM Provider Eligible Fields
Attributes eligible for retrieval by a PAM Provider on the Universal Orchestrator
If a PAM provider was installed _on the Universal Orchestrator_ in the [Installation](#Installation) section, the following parameters can be configured for retrieval _on the Universal Orchestrator_.
| Attribute | Description |
| --------- | ----------- |
| ServerUsername | Application ID of the service principal, representing the identity used for managing the Application Gateway. |
| ServerPassword | A Client Secret that the extension will use to authenticate with the Azure Resource Management API for managing Application Gateway certificates, OR the password that encrypts the private key in ClientCertificate |
| ClientCertificate | The client certificate used to authenticate with Azure Resource Management API for managing Application Gateway certificates. See the [requirements](#client-certificate-or-client-secret) for more information. |
Please refer to the **Universal Orchestrator (remote)** usage section ([PAM providers on the Keyfactor Integration Catalog](https://keyfactor.github.io/integrations-catalog/content/pam)) for your selected PAM provider for instructions on how to load attributes orchestrator-side.
> Any secret can be rendered by a PAM provider _installed on the Keyfactor Command server_. The above parameters are specific to attributes that can be fetched by an installed PAM provider running on the Universal Orchestrator server itself.
> The content in this section can be supplemented by the [official Command documentation](https://software.keyfactor.com/Core-OnPrem/Current/Content/ReferenceGuide/Certificate%20Stores.htm?Highlight=certificate%20store).
Azure Application Gateway Certificate Binding (AppGwBin)
### Store Creation
#### Manually with the Command UI
Click to expand details
1. **Navigate to the _Certificate Stores_ page in Keyfactor Command.**
Log into Keyfactor Command, toggle the _Locations_ dropdown, and click _Certificate Stores_.
2. **Add a Certificate Store.**
Click the Add button to add a new Certificate Store. Use the table below to populate the **Attributes** in the **Add** form.
| Attribute | Description |
| --------- | ----------- |
| Category | Select "Azure Application Gateway Certificate Binding" or the customized certificate store name from the previous step. |
| Container | Optional container to associate certificate store with. |
| Client Machine | The Azure Tenant (directory) ID that owns the Service Principal. |
| Store Path | Azure resource ID of the application gateway, following the format: /subscriptions//resourceGroups//providers/Microsoft.Network/applicationGateways/. |
| Orchestrator | Select an approved orchestrator capable of managing `AppGwBin` certificates. Specifically, one with the `AzureAppGwBin` capability. |
| ServerUsername | Application ID of the service principal, representing the identity used for managing the Application Gateway. |
| ServerPassword | A Client Secret that the extension will use to authenticate with the Azure Resource Management API for managing Application Gateway certificates, OR the password that encrypts the private key in ClientCertificate |
| ClientCertificate | The client certificate used to authenticate with Azure Resource Management API for managing Application Gateway certificates. See the [requirements](#client-certificate-or-client-secret) for more information. |
| AzureCloud | Specifies the Azure Cloud instance used by the organization. |
| ServerUseSsl | Specifies whether SSL should be used for communication with the server. Set to 'true' to enable SSL, and 'false' to disable it. |
#### Using kfutil CLI
Click to expand details
1. **Generate a CSV template for the AppGwBin certificate store**
```shell
kfutil stores import generate-template --store-type-name AppGwBin --outpath AppGwBin.csv
```
2. **Populate the generated CSV file**
Open the CSV file, and reference the table below to populate parameters for each **Attribute**.
| Attribute | Description |
| --------- | ----------- |
| Category | Select "Azure Application Gateway Certificate Binding" or the customized certificate store name from the previous step. |
| Container | Optional container to associate certificate store with. |
| Client Machine | The Azure Tenant (directory) ID that owns the Service Principal. |
| Store Path | Azure resource ID of the application gateway, following the format: /subscriptions//resourceGroups//providers/Microsoft.Network/applicationGateways/. |
| Orchestrator | Select an approved orchestrator capable of managing `AppGwBin` certificates. Specifically, one with the `AzureAppGwBin` capability. |
| Properties.ServerUsername | Application ID of the service principal, representing the identity used for managing the Application Gateway. |
| Properties.ServerPassword | A Client Secret that the extension will use to authenticate with the Azure Resource Management API for managing Application Gateway certificates, OR the password that encrypts the private key in ClientCertificate |
| Properties.ClientCertificate | The client certificate used to authenticate with Azure Resource Management API for managing Application Gateway certificates. See the [requirements](#client-certificate-or-client-secret) for more information. |
| Properties.AzureCloud | Specifies the Azure Cloud instance used by the organization. |
| Properties.ServerUseSsl | Specifies whether SSL should be used for communication with the server. Set to 'true' to enable SSL, and 'false' to disable it. |
3. **Import the CSV file to create the certificate stores**
```shell
kfutil stores import csv --store-type-name AppGwBin --file AppGwBin.csv
```
#### PAM Provider Eligible Fields
Attributes eligible for retrieval by a PAM Provider on the Universal Orchestrator
If a PAM provider was installed _on the Universal Orchestrator_ in the [Installation](#Installation) section, the following parameters can be configured for retrieval _on the Universal Orchestrator_.
| Attribute | Description |
| --------- | ----------- |
| ServerUsername | Application ID of the service principal, representing the identity used for managing the Application Gateway. |
| ServerPassword | A Client Secret that the extension will use to authenticate with the Azure Resource Management API for managing Application Gateway certificates, OR the password that encrypts the private key in ClientCertificate |
| ClientCertificate | The client certificate used to authenticate with Azure Resource Management API for managing Application Gateway certificates. See the [requirements](#client-certificate-or-client-secret) for more information. |
Please refer to the **Universal Orchestrator (remote)** usage section ([PAM providers on the Keyfactor Integration Catalog](https://keyfactor.github.io/integrations-catalog/content/pam)) for your selected PAM provider for instructions on how to load attributes orchestrator-side.
> Any secret can be rendered by a PAM provider _installed on the Keyfactor Command server_. The above parameters are specific to attributes that can be fetched by an installed PAM provider running on the Universal Orchestrator server itself.
> The content in this section can be supplemented by the [official Command documentation](https://software.keyfactor.com/Core-OnPrem/Current/Content/ReferenceGuide/Certificate%20Stores.htm?Highlight=certificate%20store).
## Discovery Job
The Discovery operation discovers all Azure Application Gateways in each resource group that the service principal has access to. The discovered Application Gateways are reported back to Command and can be easily added as certificate stores from the Locations tab.
The Discovery operation uses the "Directories to search" field, and accepts input in one of the following formats:
- `*` - If the asterisk symbol `*` is used, the extension will search for Application Gateways in every resource group that the service principal has access to, but only in the tenant that the discovery job was configured for as specified by the "Client Machine" field in the certificate store configuration.
- `,,...` - If a comma-separated list of tenant IDs is used, the extension will search for Application Gateways in every resource group and tenant specified in the list. The tenant IDs should be the GUIDs associated with each tenant, and it's the user's responsibility to ensure that the service principal has access to the specified tenants.
> The Discovery Job only supports Client Secret authentication.
## License
Apache License 2.0, see [LICENSE](LICENSE).
## Related Integrations
See all [Keyfactor Universal Orchestrator extensions](https://github.com/orgs/Keyfactor/repositories?q=orchestrator).