Skip to main content

Introduction

There are many ACMI clients that exist, but az-acme is different in that it has been designed from the outset with a focus on Microsoft Azure and aligned to the following goals.

  • Replicate certificate management capabilities for ACMI based certificate issuers that exist natively between Azure Key Vault and Digicert / GlobalSign to make ACMI feel like a first-class capability.
  • Store certificates in Azure Key Vault to enable existing Azure native integrations between services and Azure Key Vault to operate as expected. This also provides architectural advantages when establishing multi-cluster configurations for AKS as certificates are managed externally, and synchronished to the cluster.
  • Separate TLS certificate management processes from Azure compute resources (this means only ACME DNS challenges are supported). No need to deploy additional infrastructure required by other solutions.

The following shows how az-acme fits within the certificate management context. To certificate consumers, there is no difference between using a certificate managed by an Azure Key Vault native issuer (Digicert / GlobalSign) and those obtained from an ACMI based issuer via az-acme(s).

The az-acme CLI can be added to existing CI/CD or automation tools and scheduled to run every 12/24 hours to perform the renewal checks as requried. Using existing operational tools means alerting and notifications have already been established, making it simpler to introduce and run across teams.