Migrating from Nginx to Angie: Using the Built‑in ACME Module

What is Angie’s ACME Module?

The ACME module is a native component of the Angie web server that implements the ACME protocol (RFC 8555) for automated issuance and renewal of TLS certificates from providers such as Let’s Encrypt.

• Integrated: Runs inside the Angie process, no external binaries.
• Configuration‑driven: Clients, challenges, and certificates are declared in Angie’s configuration files.
• Variable exposure: Issued certificates are available to the server via built‑in variables (e.g., $acme_cert, $acme_key).
• Automatic renewal: Angie periodically contacts the ACME server and renews certificates without cron jobs.

Why Replace Certbot with Angie’s ACME Module?

Certbot is an external tool that modifies web‑server configuration and stores certificates on disk. Angie’s built‑in module eliminates the need for this extra layer.

• Reduced operational complexity – only one service to manage.
• Faster startup – certificates are loaded directly from memory.
• Lower disk I/O – no file‑system polling for changes.
• Improved reliability – renewal failures are logged within Angie’s own error log.
• Consistent configuration – all TLS settings remain in a single file hierarchy.

How to Install Angie

Installation follows the standard package manager workflow for the target OS.

• RHEL/CentOS/AlmaLinux: sudo dnf install angie
• Debian/Ubuntu: sudo apt install angie
• Enable and start the service:
  sudo systemctl enable --now angie

How to Migrate Nginx Configuration to Angie

The migration consists of three main steps: copy relevant directives, replace Certbot‑related blocks, and test.

• Copy server blocks – Transfer listen, server_name, location, and proxy settings to Angie’s http context.
• Remove Certbot hooks – Delete ssl_certificate and ssl_certificate_key file paths; replace them with ACME variables:
  ssl_certificate $acme_cert;
ssl_certificate_key $acme_key;
• Define an ACME client in the global http block, e.g.:
  acme_client @acme {\n directory email admin@example.com;\n resolver 1.1.1.1 8.8.8.8;\n}
• Reference the client inside each server that needs a certificate:
  acme_certificate @acme {\n domains tangaacademie.com api.tangaacademie.com;\n}
• Test and reload – Run angie -t to validate syntax, then sudo systemctl reload angie.

How to Configure Multiple Domains

Each distinct domain or sub‑domain can share a single ACME client or use separate clients for different validation methods.

• Single client example – list all domains in one acme_certificate block.
• Separate client example – create a second client with its own resolver or DNS‑01 challenge configuration for wildcard certificates.
• Ensure that port 80 is reachable for HTTP‑01 challenges unless DNS‑01 is used.

Common Pitfalls and Solutions

Typical issues arise from DNS resolution, missing resolver directives, or blocked challenge ports.

• Resolver errors – “acme‑v02.api.letsencrypt.org could not be resolved”.
  Solution: Add a public DNS resolver list in the http block.
• Port 80 blocked – HTTP‑01 challenge fails.
  Solution: Open port 80 in firewalls or switch to DNS‑01 validation.
• Incorrect variable usage – Using file paths instead of $acme_* variables.
  Solution: Replace all ssl_certificate directives with the ACME variables.

Monitoring, Maintenance, and Security Best Practices

After migration, ongoing checks keep the system healthy.

• Watch Angie’s error log for ACME activity: tail -f /var/log/angie/error.log
• Periodically verify certificate dates with openssl x509 -in $acme_cert -noout -dates
• Use strong TLS ciphers and enable HTTP/2 or HTTP/3 as needed.
• Keep Angie up‑to‑date – regular package updates include security patches and new ACME features.