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.
Post Contents
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
mkdir -p /etc/letsencrypt
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
Content:
draft: false acme: email_account: email@reg.tw # Registration email for Let's Encrypt service staging: false certificates: - 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 provider_options: 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 \ adferrand/dnsrobocert:latest
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.