Let's Encrypt
TLS Certificate Automation for Public and Private Web Interfaces
Public TLS certificates are moving toward much shorter lifetimes, and that changes how secure web interfaces must be operated. The CA/Browser Forum has adopted a phased reduction in maximum certificate lifetime for publicly trusted TLS certificates: 100 days on March 15, 2027, and 47 days on March 15, 2029. In parallel, Let's Encrypt has announced plans to reduce its default certificate lifetime from 90 days to 64 days and then 45 days.
The direction is clear, even if implementations vary by CA: manual certificate renewal does not scale. What used to be an occasional maintenance task is becoming a continuous operational process. For long-lived products, services, and device fleets, automatic certificate renewal is no longer just convenient. It is becoming the only viable long-term approach.
This page explains why certificate automation is required, how ACME works in simple terms, and how Mako Server supports both public Internet deployments and browser-trusted device web interfaces running on private networks.
Why Manual Certificate Renewal Becomes Impractical
Manual renewal has always been error-prone. Someone must track expiration dates, prove domain control, request a new certificate, install it correctly, reload the server, and verify that browsers trust the result. That process is manageable once or twice a year for a single system. It breaks down quickly when you have many servers, many customer sites, or embedded devices deployed for years in the field.
Shorter certificate lifetimes make the problem worse in two ways:
- Renewal frequency increases: a workflow that was already tedious at 90 days becomes operationally expensive as lifetimes move toward 47 days.
- Validation reuse windows shrink: by 2029, the maximum reuse period for domain validation data is scheduled to drop to 10 days, which further reduces how long prior checks can carry you.
In practice, manual renewal means more outages, more last-minute work, more forgotten certificates, and more support events triggered by browser warnings. For browser-facing systems, especially device web interfaces, that is not a sustainable operating model.
Why Automated Renewal Is the Only Viable Path
Automatic certificate lifecycle management turns renewal into a background service instead of a recurring project. A well-designed automated flow can request a certificate, prove control of the hostname, install the new certificate, and renew it before expiry without requiring a person to remember anything on a specific day.
This matters because certificate renewal is not a one-time setup task. It is an ongoing operational responsibility for as long as the system exists. As lifetimes continue to shrink, organizations that still rely on calendars, email reminders, and manual DNS changes will spend more time maintaining certificates and still accept more risk than teams that automate.
Manual handling may still exist as a fallback or emergency path. It should no longer be the default plan.
ACME and Browser-Trusted Certificates
ACME, short for Automatic Certificate Management Environment (RFC 8555), is the protocol used by services such as Let's Encrypt to automate certificate issuance and renewal. In simple terms, ACME lets a server ask a certificate authority for a certificate and then prove that it controls the requested domain name.
The certificate authority does not trust the request blindly. It sends a challenge. If the server or DNS configuration answers that challenge correctly, the certificate authority can issue the certificate. This is the foundation that makes safe automation possible.
Figure 1: ACME automates issuance, but the certificate authority still requires proof of domain control.
Browser-trusted certificates matter because they remove friction. A certificate signed by a publicly trusted CA is accepted by standard browsers and operating systems without installing a private root certificate on every client machine. For public services, that is expected. For device web interfaces, it is often the difference between a usable product and a support problem.
Public vs. Private (Device) Web Server
The Mako Server can power conventional public-facing websites and web applications, where the server is directly available on the Internet, and certificates can be validated with the standard http-01 Let's Encrypt challenge.
At the same time, Mako Server is often used very differently: as the web server inside embedded products, industrial devices, appliances, and other systems that are deployed on a local network and are not directly reachable from the public Internet. In these deployments, the web interface is still expected to be secure and browser-trusted, but certificate issuance and renewal must work under private-network constraints.
That dual-use case is why certificate automation matters so much here. The same server platform must support both publicly accessible websites and private device web interfaces, including systems behind firewalls, NAT, or temporary maintenance connections.
Why Browser Trust Matters for Device Web Interfaces
Many embedded products expose a local web interface for setup, maintenance, diagnostics, or emergency access. These interfaces are often accessed from laptops, tablets, contractor machines, or customer-managed PCs that lack a private corporate root certificate installed. A self-signed certificate or private CA, therefore, creates friction at exactly the moment when the user needs the interface to work.
Are you designing devices with an embedded web Server? Learn why you won't pass the new EU CRA requirements without trusted certs.
Browser-trusted certificates and automated renewal matter for device web interfaces because they:
- remove browser warning dialogs that train users to click through security errors,
- avoid the operational burden of installing a private CA on every client device,
- make field service and support easier across unmanaged client machines, and
- keep the interface usable years after deployment without requiring certificate maintenance visits.
For devices on private networks, the key insight is that public browser trust is still possible without exposing the device itself to the public Internet. That is where DNS-based validation becomes important.
Challenge Options for Automated Certificate Issuance
Let's Encrypt and other ACME certificate authorities verify domain control by using challenge methods. The two methods most relevant here are http-01 and dns-01. Mako Server supports both.
See the Let's Encrypt challenge types documentation if you want the protocol details.
The http-01 Challenge for Servers Publicly Available on Port 80
The http-01 option is the simplest path when the server is publicly reachable on the Internet, either directly or through port forwarding. The certificate authority asks the server to place a challenge file under a well-known URL on port 80. If the CA can fetch that file, it can issue the certificate.
This is typically the right option for Internet-facing web servers, VPS deployments, and systems where inbound port 80 is intentionally available.
acme={
acceptterms=true,
rsa=true, -- Remove this line if you want to use a TPM-protected ECC key
production=true,
email="john.doe@company.com",
domains={"realtimelogic.com"}
}
Figure 2: Example http-01 configuration for a public server.
When Mako Server starts with this configuration, it can obtain and later renew the certificate automatically as long as the domain points to the server and the CA can reach the HTTP challenge endpoint on port 80.
With the http-01 option, you can include multiple domain names in the Lua domains list when the same public server must answer for more than one host name.
Automatic DNS Validation with SharkTrustX for Private and Intranet Servers
When a server is not publicly reachable on port 80, dns-01 is the practical automation path. Instead of proving control through an HTTP file, the CA asks for a specific DNS TXT record under _acme-challenge.your-domain. If that TXT record appears in DNS, the CA can issue the certificate.
For private-network servers and embedded devices, the best operational model is to automate the DNS update as well. That is where SharkTrustX fits in. SharkTrustX can maintain the required DNS state and support automatic renewal without requiring an operator to edit DNS TXT records by hand each time a certificate is renewed.
This matters because the DNS challenge is the right technical method for non-public servers, but it only becomes a good long-term operational solution when the DNS changes are automated.
Figure 3: Automatic DNS validation lets a private server renew a browser-trusted certificate without exposing the server on the public Internet.
The simplest Mako Server example uses the integrated test zone local.makoserver.net:
acme={
acceptterms=true,
email="john.doe@company.com",
domains={"mydevice"}, -- FQDN becomes mydevice.local.makoserver.net
challenge={type="dns-01"}
}
Figure 4: Example automatic dns-01 configuration using the integrated test zone.
With the dns-01 option, Mako Server uses one domain entry only. For the automatic SharkTrustX-backed mode, that entry is the subdomain only, not the full host name. In the above example, domains={"mydevice"} becomes the FQDN mydevice.local.makoserver.net.
For production deployments, you would typically create your own zone and add the zone key supplied by SharkTrustX. The domain list should still contain only the device subdomain, while the service manages the full host name and the required DNS challenge records.
This approach is especially useful for:
- device web interfaces on LANs,
- servers behind firewalls or NAT, and
- products that need browser trust without exposing the device directly to the public Internet.
The hosted testing service local.makoserver.net is useful for development and evaluation. For production, manufacturers should plan on using their own SharkTrustX deployment or equivalent controlled DNS automation.
If you also enable the SharkTrustX service's reverse connection option, the private server can be reached from the Internet without opening inbound ports. That setup is covered in the tutorial Secure Remote Access for Servers Behind a Firewall.
Manual DNS TXT Record Validation
Manual dns-01 validation exists for a specific class of deployments: devices and private-network systems that are not permanently connected to the Internet, but can be temporarily given Internet access when a certificate must be issued or renewed. In practice, that can mean tethering through a phone, temporarily routing through a laptop, or enabling outbound access through a maintenance connection.
With manual dns-01, Mako Server also uses one domain entry only, but here the value must be the full domain name (FQDN), for example device1.example.com. This is not the preferred long-term model, but it is an important fallback when full DNS automation is not available and browser trust is still required. For the complete setup and operating procedure, see the full manual DNS walkthrough at the end of this article.
How Mako Server Supports Automated Certificate Management
Mako Server includes built-in support for ACME-based certificate automation and can be configured through mako.conf or controlled programmatically from Lua modules. In practical terms, that means Mako Server can be used as the automation engine for certificate issuance, installation, and renewal rather than forcing you to bolt together external scripts.
Mako Server supports:
- Automatic issuance and renewal for browser-trusted certificates.
http-01validation for servers reachable on port 80.dns-01validation for private-network and firewall-protected systems.- Automatic DNS validation via SharkTrustX for hands-off renewal on non-public servers.
- Manual DNS mode for testing or exceptional cases where full automation is not yet available.
The examples above use RSA certificates for clarity, but Mako Server also supports ECC certificates and defaults to ECC when not configured otherwise. The current Mako Server includes an integrated software-based TPM that can protect ECC private keys, which is valuable for products that need stronger key handling. Note that when using ECC keys, they are not transferable to another machine because they are protected by the softTPM.
If you are new to the Mako Server, see the Getting Started Guide. If you want the lower-level API details, see the Mako Server ACME documentation. For a broader overview of automated certificate management for embedded and intranet deployments, see SharkTrust.
Future-Proofing: Design for Continuous Renewal
The certificate industry is moving in one direction: shorter validity periods, more frequent renewal, and less tolerance for manual handling. Even if today's deployment could survive with reminders and ad hoc maintenance, that approach will become steadily less reliable as public-trust TLS moves toward 47-day lifetimes.
The safest long-term strategy is straightforward:
- use browser-trusted certificates instead of training users to accept warnings,
- choose an ACME-based renewal flow,
- automate domain validation whenever possible, and
- treat manual renewal as a fallback, not as the design.
That is the larger lesson behind Let's Encrypt and ACME. The point is not only that certificates can be free. The point is that certificate lifecycle management must be automated if secure web interfaces are expected to stay reliable over time.
Related Reading
Manual DNS Walkthrough for Temporarily Connected Devices
This section covers the manual dns-01 flow in more detail. It is intended for devices and private-network systems that do not have a permanent Internet connection, but can be brought online temporarily to complete certificate issuance or renewal. A common example is a service technician connecting a laptop to a device on a local network while the laptop is tethered to a phone or other temporary uplink.
The basic idea is simple: Mako Server starts the ACME process, pauses when the CA asks for DNS proof of ownership, and tells you exactly which DNS TXT record to create. After the record has propagated, you resume the ACME flow and Mako Server completes the certificate request.
Figure 5: Manual DNS validation lets a temporarily connected device complete the ACME dns-01 challenge.
1. Configure Mako Server for Manual DNS Mode
Create a working directory with a mako.conf file and a small www application:
Use the following mako.conf as a starting point:
acme={
acceptterms=true,
production=false, -- Use the Let's Encrypt staging environment while testing
email="john.doe@company.com",
domains={"device1.realtimelogic.com"},
challenge={
type="dns-01",
servername="manual"
}
}
Figure 6: Mako Server configuration for manual dns-01 validation.
Change the email address to a valid address and replace the sample domain name with your own registered domain.
Note that manual dns-01 expects the domains entry to be the full domain name, not just the subdomain.
Create www/index.lsp with the following content:
<?lsp
local ad=require("acme/dns")
if ad.recordset then
print(ad.recordset())
else
print"Oops, manual mode not activated!"
end
?>
This page resumes the paused ACME flow after the TXT record has been created and had time to propagate.
2. Start the Server and Capture the TXT Record
Start Mako Server in console mode and load the www application:
x:\>mako -l::www
Mako Server. Version 3.0
BAS lib 4402. Build date: Jul 2 2019
Copyright (c) Real Time Logic.
Loading x:\\mako.conf.
Trace file: mako.log
Mounting mako.zip
Server listening on IPv6 port 80
Server listening on IPv4 port 80
Loading certificate MakoServer
SharkSSL server listening on IPv6 port 443
SharkSSL server listening on IPv4 port 443
Info: www/.preload not found
Loading www as "root application" : ok
Set ACME DNS TXT Record:
Record name: _acme-challenge.device1.realtimelogic.com
Record data: UctRs7Sq51Y7_hSECQFBcBr_jCe5tjQXMqQPwWBP7Ro
Figure 7: Mako Server starts the ACME flow and pauses with the DNS TXT record you must create.
If the device itself has no permanent Internet access, this is the point where you temporarily enable outbound connectivity, for example through phone tethering or a maintenance laptop that shares its connection.
3. Create the DNS TXT Record
Use your DNS provider or registrar to create the TXT record exactly as shown by Mako Server.
Figure 8: Create the TXT record in your DNS provider's management interface.
After saving the record, wait for DNS propagation. Two minutes is a reasonable minimum, but slower DNS providers may require more time.
If you have dig installed, you can verify the record before continuing:
dig +short _acme-challenge.device1.realtimelogic.com TXT "xYTPUjSj4ArzEVNT0pG1dXrdRuFqmYOxQK4qXs15gBo"
4. Resume the ACME Flow
After the TXT record has propagated, open a browser and navigate to the server over HTTP. The sample index.lsp page calls acmedns.recordset(), which resumes the paused ACME state machine.
Figure 9: Visiting the helper page resumes the paused ACME flow.
After a short delay, Mako Server should complete renewal and load the certificate:
ACME: device1.realtimelogic.com renewed Loading certificate "cert/device1.realtimelogic.com.cert.pem"
Figure 10: Mako Server reports successful renewal and loads the new certificate.
You can then switch from HTTP to HTTPS and confirm that the browser now trusts the certificate.
Figure 11: The browser now trusts the publicly signed certificate.
5. Staging First, Then Production
The example above uses the Let's Encrypt staging environment. That is the right place to test the flow because the staging certificate is not browser-trusted and failures do not affect production issuance limits. After you have validated the process, switch to production mode.
When switching from staging to production, the ACME account information stored in cert/account.json will no longer match. Mako Server may print an error, then recover by creating a new production account.
6. Operational Notes for Real Deployments
Manual mode is usually not run from a visible console in the field. If the console is not available, enable the log module so the responsible operator receives the TXT-record details when renewal is needed.
This mode is particularly relevant when:
- the device sits on a private network with no permanent outbound Internet access,
- a technician occasionally connects the device to the Internet through tethering,
- the network is behind a proxy and only temporary outbound access is possible, or
- the system must remain mostly offline but still present a browser-trusted certificate during maintenance windows.
If the environment is behind a proxy, see the proxy options in the Mako Server documentation.
If the device has no built-in path to the Internet, a maintenance laptop can bridge the connection temporarily. In that setup, the device uses the laptop as its outbound path long enough to complete the ACME transaction while the operator performs the DNS step.
7. Troubleshooting
If renewal fails with an error such as the following, the issue is often with the DNS provider rather than with ACME itself:
ACME: renewing device1.realtimelogic.com failed: DNS problem: SERVFAIL looking up CAA for device1.realtimelogic.com - the domain's nameservers may be malfunctioning.
That type of error can happen with overloaded or unreliable DNS providers. If so, wait and try again later, or move the domain to a more reliable DNS service.
Manual DNS mode remains useful, but it is still operationally manual. If certificate renewal must happen repeatedly and predictably, the automatic DNS option is the better long-term design.