When it comes to free SSL/TLS certificates, Let’s Encrypt is a name everyone recognizes. However, understanding it and effectively using its services are two different endeavors.

In the past, my approach was to follow tutorials, implementing the certificate acquisition process as per tool instructions. However, during these recent days off, I delved into comprehending Let’s Encrypt thoroughly.

What’s Let’s Encrypt

Let’s Encrypt is the initiating organization, but it’s not the sole provider of such services (ZeroSSL being another). Applying for certificates from these services revolves around the ACME standard protocol. Since it’s an open protocol, various tools have been developed to implement this system. Certbot (Python) and ACME.sh (Shell) are the most prevalent among them.

Choosing between these tools often boils down to the “environment.” The tool that is most adaptable across platforms, demands the least, and integrates seamlessly with other services tends to gain popularity.

Verification method

Another critical factor is the verification method. Ensuring that the authorized certificates are genuinely intended for use, not forged, is pivotal. Two primary methods are HTTP verification, where your website validates the request, and DNS record updates, verifying your domain ownership or management. Applying for Wildcard certificates, for instance, mandates DNS verification.

Surprisingly, many overlook the verification method’s significance. I believe this stems from two key points: the perception that websites are already public, so the method doesn’t matter, and the potential difficulty in understanding DNS verification, requiring familiarity with DNS technology.

If you are familiar with DNS technology and are aware of security risks, opting for DNS verification is advisable. Particularly with the exposure of websites through public validation, there is an inherent risk, especially for newly launched or minimally protected websites.

In a previous article about exposing a WordPress site to the public using frp/sish services, the tool DNSroboCert caught my attention. It specializes in DNS verification and supports multiple DNS service APIs, rivalling my commonly used ACME.sh tool.


Here is a step-by-step guide on using DNSroboCert:

1. Preparation for Using DNSroboCert

Create a directory for configuration files:

mkdir -p /etc/dnsrobocert
touch /etc/dnsrobocert/config.yml


Create a directory for Let’s Encrypt settings and certificate storage:
mkdir -p /etc/letsencrypt


Install Docker for the operating environment:
{{curl -fsSL https://get.docker.com -o get-docker.sh && sh get-docker.sh}}

2. Download DNSroboCert Container

docker pull adferrand/dnsrobocert:latest

3. Edit DNSroboCert Configuration File

Open the configuration file for editing:

vi /etc/dnsrobocert/config.yml


draft: false
email_account: email@reg.tw # Registration email for Let's Encrypt service
staging: false
- domains:
- ssl.mxp.tw # Domain to validate for obtaining the certificate
- '*.ssl.mxp.tw' # Wildcard domain string enclosed in single quotes
name: mxp.tw # Folder name in Let's Encrypt live directory
profile: cloudflare # Name of the DNS service provider
profiles: # Define data blocks for DNS service providers
- name: cloudflare # Name configured, corresponding to the above usage
provider: cloudflare # Match the provider name in the file
auth_token: # Enter the authorization token obtained
auth_username: emai@cloudflare # Cloudflare account
zone_id: # Enter the domain zone ID

Remember to remove the ‘#’ and associated comments when using the configuration.

This file can define multiple domains and DNS service providers, offering great flexibility.

Verify if your DNS service provider is supported by checking this page: [Providers available].

4. Launch DNSroboCert to Obtain Certificates

docker run -itd --name letsencrypt-dns \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /etc/letsencrypt/:/etc/letsencrypt \
-v /etc/dnsrobocert/config.yml:/etc/dnsrobocert/config.yml \
--restart always \

After executing the command, use docker logs letsencrypt-dns to check the operational logs. Ideally, you should see records of successful verification, and the requested domain certificates should be in /etc/letsencrypt/live/.

This container checks for certificate renewal every two days by default. Keep it running as a permanent service. If you need to add new domains, update the configuration file and restart the container.

5. Postscript

After confirming that DNS verification does not expose public records, a significant concern is resolved. Keeping the Docker container running to handle certificate requests and renewals is a clean and efficient solution. I’m quite satisfied with this approach and might consider replacing my previous methods.

Note: This article is a rewrite for better readability and SEO optimization, ensuring a more engaging and informative user experience.

Categorized in: