https://blog.nginx.org/blog/native-support-for-acme-protocol NGINX Community Blog NGINX Community Blog * All Posts * GitHub + github.com/nginxinc + github.com/nginx * Forum NGINX Introduces Native Support for ACME Protocol Aug 12, 2025 -- by Prabhat Dixit in Uncategorized [NGINX-logo-black] We are very excited to announce the preview release of ACME support in NGINX. The implementation introduces a new module ngx_http_acme_module that provides built-in directives for requesting, installing, and renewing certificates directly from NGINX configuration. The ACME support leverages our NGINX-Rust SDK and is available as a Rust-based dynamic module for both NGINX Open Source users as well as enterprise NGINX One customers using NGINX Plus. NGINX's native support for ACME brings a variety of benefits that simplify and enhance the overall SSL/TLS certificate management process. Being able to configure ACME directly using NGINX directives drastically reduces manual errors and eliminates much of the ongoing overhead traditionally associated with managing SSL/TLS certificates. It also reduces reliance on external tools like Certbot, creating a more secure and streamlined workflow with fewer vulnerabilities and a smaller attack surface. Additionally, unlike existing external tools which can be prone to platform-specific limitations, a native implementation ensures greater portability and platform independence, making it a versatile and reliable solution for modern, evolving web infrastructures. What is ACME? The ACME protocol (Automated Certificate Management Environment) is a communications protocol primarily designed to automate the process of issuing, validating, renewing, and revoking digital security certificates (e.g., SSL/TLS certificates). It allows clients to interact with a Certificate Authority (CA) without requiring manual intervention, simplifying the deployment of secure websites and other services that rely on HTTPS. The ACME protocol was initially developed by the Internet Security Research Group (ISRG) as part of the Let's Encrypt initiative in late 2015, offering free, automated SSL/TLS certificates. Before ACME, obtaining TLS certificates was often a manual, costly, and error-prone process. ACME revolutionized this by providing open-source, automated workflows for certificate management. ACMEv2 is an updated version of the original ACME protocol. It added support for new challenges, expanded authentication methods, wildcard certificates, and other enhancements to improve flexibility and security. NGINX ACME Workflow The ACME workflow with NGINX can be broken into 4 steps: 1. Setting up the ACME Server 2. Allocating Shared Memory 3. Configuring Challenges 4. Certificate Issue and Renewal Setting up the ACME Server To enable ACME functionality, the first (and the only mandatory step) is to specify the directory URL of the ACME server. Additional information regarding how to contact the client in case of certificate-related issues or where to store module data can also be provided, as shown. acme_issuer letsencrypt { uri https://acme-v02.api.letsencrypt.org/directory; # contact admin@example.test; state_path /var/cache/nginx/acme-letsencrypt; accept_terms_of_service; } Allocating Shared Memory The implementation also provides an optional directive acme_shared_zone to store certificates, private keys, and challenge data for all the configured certificate issuers. The zone has a default size of 256K, which can be increased as required. acme_shared_zone zone=acme_shared:1M; Configuring Challenges The current preview implementation supports HTTP-01 challenges to verify the client's domain ownership. It requires defining a listener on port 80 in the nginx configuration to process ACME HTTP-01 challenges: server { # listener on port 80 is required to process ACME HTTP-01 challenges listen 80; location / { #Serve a basic 404 response while listening for challenges return 404; } } Support for other challenges (TLS-ALPN, DNS -01) is planned in future . Certificate Issuance and Renewal Use the acme_certificate directive in the respective server block in your NGINX configuration to automate the issuance/renewal of TLS certificates. The directive requires the list of identifiers(domains) for which the certificates need to be dynamically issued. The list of identifiers can be defined using the server_name directive. The snippet below shows how to configure the server block for issuing /renewing SSL certificate for ".example.domain" domain using the previously defined letsencrypt ACME certificate issuer. server { listen 443 ssl; server_name .example.com; acme_certificate letsencrypt; ssl_certificate $acme_certificate; ssl_certificate_key $acme_certificate_key; ssl_certificate_cache max=2; } Note that not all values accepted by server_name directive are valid identifiers. Wildcards are not supported in this initial implementation. Regular expressions are not supported. Use the $acme_certificate and $acme_certificate_key variables in the module to pass the SSL certificate and key information for the associated domain. Why It All Matters? The rapid rise of HTTPS adoption globally has been driven largely by ACME protocol, making secure web connections a standard expectation. ACME modernizes the way TLS/SSL certificates are issued, renewed, and managed by automating the entire process, eliminating manual effort and reducing costs associated with certificate lifecycle management. Beyond the web, the growth of IoT devices and edge computing positions ACME to play a critical role in automating security for APIs, devices, and edge compute infrastructures. NGINX's native support for ACME underscores the protocol's importance for the future of web security, automation, and scalability. ACME is expected to remain the backbone of certificate automation across the internet and beyond for foreseeable future. With security becoming a baseline for web standards, we'll continue seeing requirements for evolving deployment models and security needs, pushing improvements in ACME. Looking ahead, we are committed to evolving our implementation to align with the needs of our users and customers, meeting them where they are today and building capabilities for where they are headed in the future. How to Get Started Get started with the native ACME implementation in NGINX today. If you are an open source user, pre-built packages are available here. If you are an enterprise NGINX One customer using NGINX Plus, pre-built packages are available as a F5 supported dynamic module. For more information on the module, refer to the NGINX Docs. Community Feedback As always, your feedback is invaluable in shaping the future development of NGINX. If you have suggestions, encounter issues, or want to request additional features, please share them through GitHub Issues. We can't wait for you to try it out. NGINX Community Forum --------------------------------------------------------------------- -Previous: Migrating from ingress-nginx to NGINX Ingress Controller, Part 1 [NGINX-Part-of-F5-horiz-black-type-300x119] Search [ ] GitHub nginxinc nginx Other Sites Community Forum NGINX.org F5.com Social * + YouTube * + Bluesky * + X (c) 2025 F5, Inc. | All Rights Reserved Manage Consent To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions. Functional [ ] Functional Always active The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network. Preferences [ ] Preferences The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user. Statistics [ ] Statistics The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you. Marketing [ ] Marketing The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes. Manage options Manage services Manage {vendor_count} vendors Read more about these purposes Accept Deny View preferences Save preferences View preferences {title} {title} {title} Manage consent