Beyond the maze: How Canonical Notary aims to unify the TLS Lifecycle
The foundation of any secure software infrastructure or platform is Transport Layer Security, yet its lifecycle management remains fragmented, complicated and burdensome, leading to frustration at inopportune times. A service goes down at 3:00 AM because an obscure certificate, buried three layers deep in a microservices mesh, reached its expiration date unnoticed …
Canonical’s Notary was born out of a desire to solve this problem by simplifying and centralizing the orchestration, management, and distribution of TLS Certificates across every imaginable infrastructure use case, from local dev to air gapped data centers.
The problem: navigating the “certificate maze”
To understand why the idea of Notary is a potential game changer, we must look at the maze that infrastructure teams currently navigate. Usually, an organization’s security needs are split across several different tools, each with its own logic, interface, and lifecycle requirements. This creates a patchwork of specialized operators that, while functional individually, create massive technical debt when combined.
1. The local prototyping:
For rapid prototyping or isolated labs,using self-signed certificates is usually the path forward. It allows developers to get encryption up and running without waiting for a CA, but these certs aren’t trusted externally. When an application moves from a developer’s machine to a staging environment, the operator must be swapped out, requiring a change in the model’s relationship logic.
2. The public trust challenge:
For external-facing services, tools like an ACME client are used to pull certificates from Let’s Encrypt or other authorities. While the ACME client automates the DNS-01 and HTTP-01 challenges, managing these challenges across dozens of different applications becomes repetitive and prone to configuration drift.
3. The air gapped barrier:
In high-security or legacy environments, automation isn’t always an option. Security policy may dictate that a human must review every Certificate Signing Request (CSR). This requires the manual TLS certificates, where an operator must manually run actions to extract CSRs, sign them elsewhere, and upload the results.
4.Paid certificates import
When an organization purchases a commercial certificate (e.g., from DigiCert, Sectigo), the certificate files (key, certificate, and chain) must be securely imported and distributed to the various services and pods that need them. This often requires:
-
Secure Storage: Storing the private key securely, often requiring integration with secrets managers or injecting directly into application configuration.
-
Format Conversion: Certificates often come in different formats (e.g., .pfx, .pem, .crt). Manual conversion and formatting are frequently necessary before injection into a Kubernetes Secret or a microservice configuration.
-
Distribution Management: Once stored, propagating the certificate to dozens or hundreds of services requires writing custom automation or relying on environment specific tools. The lack of a unified distribution mechanism means engineers must often manually track which service received which paid certificate.
5. The Operational Burden of Ephemeral Certificates
Ephemeral certificates, which have a very short lifespan (minutes/hours) for enhanced security, create a significant operational and architectural burden. This is primarily because services must fetch a new certificate from the Certificate Authority (CA) or Key Management Service (KMS) every time they restart. While ephemeral certificates solve a security problem by limiting key compromise damage, they introduce a distinct operational and reliability problem centered on the critical, timing-dependent fetching process.
6. The enterprise standard:
For enterprise secrets, tools like Vault act as the central CA. Integrating Vault directly with every application requires complex authentication and creates a wide “blast radius” if many applications have high level access to the Vault PKI engine.
This fragmentation leads to “Certificate Fatigue.” When every tool requires a different configuration, the risk of human error, and that dreaded expired certificate outage, increases exponentially.
The vision: Notary as the unified orchestrator
Canonical Notary is a Go based management service designed to act as a central hub or a “proxy” for all your certificate needs. Its aim is to abstracts the complexity of the backend providers while offering a consistent interface to the applications that need security.
By deploying Notary, the goal is to setup once and forget about it. You can just use Notary to monitor and manage certificates without needing to dig through CLI’s and services. No matter if you are operating on premise, in the cloud, or in an air gapped environment, Notary aims to serve as the single source of truth for your TLS state. Available as a Snap or Charm (machine or kubernetes).
The core philosophy behind Notary is to provide provider agnostic security. In the current ecosystem, switching from a self-signed certificate to a Let’s Encrypt or Vault backed certificate often requires changing the entire operator or rewriting the deployment logic.
Notary changes this by following three guiding principles:
Abstraction of the “How”: The application needing the certificate (the “requirer”) should never need to know if the certificate came from a hardware module, a public CA, or a manual approval process. It simply requests a certificate, and Notary fulfills it.
API first lifecycle or easy to use UI: by exposing a clean, RESTful API built in Go, Notary turns certificate management into a programmable service rather than a series of manual CLI commands or fragmented operator logs, alternatively users can manage the flow via the UI built on top of it for ease of access.
Reliability through observability: Notary is designed with native Prometheus integration, so it is able to provide tracking of everything from request counts to granular expiration windows, ensuring that “certificate fatigue” is replaced by actionable data that can easily fit different automation flows.
Notary is built to scale alongside your infrastructure, moving from a lightweight deployment to a robust enterprise hub.
State management: for small scale/initial deployments, Notary utilizes a local SQLite database. This allows for zero configuration persistence, making it perfect for edge cases and local labs. However, the architecture is “SQL agnostic,” designed to eventually plug into external SQL servers (e.g. Postgres) for high availability enterprise environments.
Integration Layer: Notary communicates with the Juju ecosystem via the tls-certificates interface so it can trigger events, whenever a new certificate is signed or updated, the workload notifies the operator immediately, ensuring the application receives its credentials in near real-time.
Capabilities and usage
Notary isn’t just a wrapper for existing tools, it introduces enterprise grade capabilities that were previously difficult to implement at scale.
Hardware security module (HSM) support
Security conscious organizations require more than just software based key storage. Notary provides robust HSM support via the PKCS#11 standard. This allows private keys to be generated and stored within specialized hardware. Even if the host environment is compromised, your root of trust remains physically protected. In environments where compliance (like FIPS) is non-negotiable, Notary’s ability to interface with HSMs makes it the only viable choice for a unified TLS strategy.
Simplifying TLS today
Currently, Notary can act as the intermediary that simplifies the handshake and identity verification process between microservices. It handles the generation of short lived credentials and manages the mutual trust between services, ensuring that every internal communication is encrypted and authenticated without the overhead of manual credential rotation.
Example usage scenarios
To see how Notary simplifies operations, let’s look at how it handles the workflows previously scattered across multiple operators.
Scenario A: The transition from Dev to Prod
In the future, your application charm will remain related to Notary via the standard tls-certificates interface from day one. To move from dev to production, you won’t tear down relations. Instead, you’ll simply update Notary’s configuration to point to a production CA (like Vault). The application charm will receive a new, valid certificate without ever knowing the “plumbing” changed in the background.
Scenario B: automated “Manual” workflows
In air gapped systems, the manual-tls-certificates-operator requires a sequence of manual steps for example:
juju run manual-tls-certificates/leader get-outstanding-certificate-requests
Manually sign the CSR and then
juju run manual-tls-certificates/leader provide-certificate
Notary incorporates this logic. It can hold certificate requests in a “pending” state, providing a centralized dashboard (via its UI or API) where an administrator can approve and provide the signed response. This centralizes the manual work for the entire infrastructure into a single point of control.
The roadmap: one tool to rule them all
The goal of the Canonical Notary project is to reduce the cognitive load on Engineers by achieving full future parity with the existing suite of operators.
Currently: Notary successfully acts as a proxy and handles TLS and HSM backed security.
The Plan: Future development is aimed at providing native ACME support and self-signing capabilities within Notary itself.
The Outcome: Eventually, Notary once setup it will detect your requirements and route them to the appropriate backend, whether that’s an internal self-signed engine, a public ACME server, an enterprise Vault instance, or a physical HSM.
With this Notary aims to simplify Day 2 operations for TLS certificate management by automating essential tasks and centralizing control. It prevents service outages by proactively monitoring certificate expiration and automating renewals and distribution via the Juju relation system. Notary will offer engineers centralized observability into the status of all certificates. Finally, it will act as a central policy enforcement point, ensuring consistent security and compliance across the platform by automatically mandating requirements like minimum key sizes for every certificate request.
Future proofing your transport level security
The ecosystem of TLS and identity management will continue to evolve. New protocols will emerge, and security standards will tighten. By adopting Notary, organizations can begin to future proof their infrastructure.
Instead of being tied to the specific implementation details of tools and apps like certbot, Lego/ACME client, Vault, k8s cert-manager or manual .pkx certificates, you adopt a flexible architecture that can adapt to change. Notary will take the fragmented world of all of those tools and combine them into a single, cohesive security strategy.
In the complex world of platform apps lifecycle management, simplicity is the ultimate sophistication. Notary aim is to provide that simplicity, ensuring that your certificates are always valid, your data is always encrypted, and your engineers are no longer lost in the maze.
Ready to simplify your TLS management? Explore the Canonical Notary Documentation and start planning your unifying your certificate lifecycle today.
Notary is an open source project that warmly welcomes community contributions, suggestions, fixes, and constructive feedback.
Interested in joining the team? Canonical is hiring! Apply for career opportunities.