docs: add Let's Encrypt as recommended SSL provider for evonodes#567
docs: add Let's Encrypt as recommended SSL provider for evonodes#567ktechmidas wants to merge 1 commit into23.0.0from
Conversation
Let's Encrypt is now the first and recommended SSL certificate option for evonode setup since it's free, requires no account registration, and dashmate handles renewal automatically. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
📝 WalkthroughWalkthroughDocumentation updates to the Evonode setup guide that expand SSL certificate configuration options from two to three paths, add Let's Encrypt as the recommended primary option, enhance ZeroSSL and manual certificate upload guidance, and clarify port 80/tcp prerequisites for certificate validation. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~4 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/user/masternodes/setup-evonode.rst`:
- Around line 602-604: The prerequisite line currently says "Let's Encrypt
certificate registration" which conflicts with the later claim "no account
registration required"; change the prerequisite text to clarify purpose and
remove the word "registration" — e.g. state "an email address for Let's Encrypt
certificate expiry notifications, or a ZeroSSL API access key, or an SSL
certificate for the public IPv4 address" so it matches the later "no account
registration required" wording and removes ambiguity between registration and
notification; update the phrase containing "Let's Encrypt certificate
registration" to this clearer wording wherever it appears.
- Around line 648-652: The current concat command overwrites bundle.crt before
reading it; replace the line that reads "cat certificate.crt bundle.crt >
bundle.crt" by writing the combined output to a new file (e.g., "chain.crt") or
to a temporary file and then renaming it, and update the subsequent upload
instruction to reference the new certificate chain filename (reference symbols:
certificate.crt, bundle.crt, chain.crt and the upload step that currently points
to bundle.crt).
- Around line 614-627: Update the Let's Encrypt section describing IP-address
certificates to explicitly state that ACME-issued IP certificates use the
shortlived profile and are valid for roughly 160 hours (~6 days), so automated
continuous renewal is operationally required; while editing the text that
references "dashmate setup" and the ACME HTTP-01 challenge, add a note
indicating the short-lived validity and renewal necessity and then verify
whether Dashmate's bundled ACME client requests the `shortlived` profile—if it
does, state that Dashmate handles short-lived renewal automatically, otherwise
document the current limitation and recommend users ensure an ACME client or
external process requests the `shortlived` profile and performs renewals at
least every 5 days.
| - An email address for Let's Encrypt certificate registration, or a `ZeroSSL API access key | ||
| <https://app.zerossl.com/developer>`_, or an SSL certificate for the public IPv4 address (not DNS | ||
| name) |
There was a problem hiding this comment.
"certificate registration" conflicts with the "no account registration" claim in the body.
The prerequisite uses "Let's Encrypt certificate registration," but lines 615–616 explicitly state "no account registration required" and clarify the email is for "certificate expiry notifications." The two phrases are contradictory from a reader's perspective.
✏️ Proposed fix
-- An email address for Let's Encrypt certificate registration, or a `ZeroSSL API access key
+- An email address for Let's Encrypt certificate expiry notifications, or a `ZeroSSL API access key🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/user/masternodes/setup-evonode.rst` around lines 602 - 604, The
prerequisite line currently says "Let's Encrypt certificate registration" which
conflicts with the later claim "no account registration required"; change the
prerequisite text to clarify purpose and remove the word "registration" — e.g.
state "an email address for Let's Encrypt certificate expiry notifications, or a
ZeroSSL API access key, or an SSL certificate for the public IPv4 address" so it
matches the later "no account registration required" wording and removes
ambiguity between registration and notification; update the phrase containing
"Let's Encrypt certificate registration" to this clearer wording wherever it
appears.
There was a problem hiding this comment.
Valid catch. The wording "certificate registration" in the prerequisite conflicts with "no account registration required" in the body. The suggested fix is correct — changing to "certificate expiry notifications" makes the prerequisite consistent with the description below.
@ktechmidas this is a quick one-liner fix if you want to update it.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
| 1. **Let's Encrypt (recommended)**. Let's Encrypt is a free, automated certificate authority that | ||
| provides SSL certificates at no cost and with no account registration required. Dashmate has | ||
| built-in support for obtaining and automatically renewing Let's Encrypt certificates. All you need | ||
| is an email address for certificate expiry notifications. | ||
|
|
||
| During ``dashmate setup``, select **Let's Encrypt** as the SSL provider and enter your email | ||
| address when prompted. Dashmate will handle the rest, including automatic renewal before | ||
| certificates expire. | ||
|
|
||
| .. note:: | ||
|
|
||
| Let's Encrypt requires port 80/tcp to be open for the ACME HTTP-01 challenge used to validate | ||
| your server's IP address during certificate issuance and renewal. | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for ACME profile, shortlived, or letsEncrypt-related terms in dashmate source
rg -i --type=js -n -C3 "shortlived\|acme.*profile\|letsEncrypt\|lets.encrypt" \
-g '!node_modules' -g '!dist'Repository: dashpay/docs
Length of output: 38
🏁 Script executed:
# Also check for certificate-related configurations
rg -i --type=js -n "certificate\|cert\|acme" -g '!node_modules' -g '!dist' | head -100Repository: dashpay/docs
Length of output: 38
🏁 Script executed:
# Look for dashmate configuration and package info
fd -type f -name "package.json" -o -name "*acme*" -o -name "*certificate*" | head -20Repository: dashpay/docs
Length of output: 226
🏁 Script executed:
# Search for any dashmate documentation or configuration in this docs repo
rg -i "dashmate" -n -A 5 -B 5 | head -150Repository: dashpay/docs
Length of output: 11283
🏁 Script executed:
# Look for any setup or configuration files mentioning ACME
rg -i "acme\|shortlived" -nRepository: dashpay/docs
Length of output: 38
🌐 Web query:
Let's Encrypt IP address certificate validity period shortlived profile ACME
💡 Result:
- Validity period (Let’s Encrypt “shortlived” profile): 160 hours (just over 6 days). [1]
- IP address certificates: Must be issued under the
shortlivedACME profile (i.e., they’re also 160-hour certs). [2] - How to request (ACME): Your ACME client must support ACME Profiles and you must explicitly select/request the
shortlivedprofile; otherwise you’ll get the default (classic) profile behavior. [1][3] - Challenges allowed for IP identifiers: HTTP-01 or TLS-ALPN-01 only (not DNS-01). [2]
- Availability: Let’s Encrypt states short-lived and IP address certificates are generally available as of January 15, 2026. [1]
Sources:
[1] Let’s Encrypt — “6-day and IP Address Certificates are Generally Available” (Jan 15, 2026)
[2] Let’s Encrypt — “We’ve Issued Our First IP Address Certificate” (Jul 1, 2025)
[3] Let’s Encrypt docs — “Profiles”
Clarify the certificate validity period and renewal requirements for Let's Encrypt IP-address certificates.
The documentation at lines 614-627 describes automatic certificate renewal without disclosing that Let's Encrypt IP-address certificates are valid for only ~160 hours (approximately 6 days), compared to the standard 90-day validity for domain-name certificates. These short-lived certificates require the ACME client to explicitly request the shortlived ACME profile during issuance and renewal.
Since the snippet confirms these are IP-address certificates (mentioning "your server's IP address" validation), users need to understand that continuous automated renewal is not optional—it's operationally critical. This is a significant operational difference from standard Let's Encrypt usage that should be clearly disclosed to node operators.
Please confirm whether dashmate's bundled ACME client supports and requests the shortlived ACME profile. If it does, add a note explaining the 6-day validity window and the need for continuous renewal. If not yet implemented, document the current limitations.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/user/masternodes/setup-evonode.rst` around lines 614 - 627, Update the
Let's Encrypt section describing IP-address certificates to explicitly state
that ACME-issued IP certificates use the shortlived profile and are valid for
roughly 160 hours (~6 days), so automated continuous renewal is operationally
required; while editing the text that references "dashmate setup" and the ACME
HTTP-01 challenge, add a note indicating the short-lived validity and renewal
necessity and then verify whether Dashmate's bundled ACME client requests the
`shortlived` profile—if it does, state that Dashmate handles short-lived renewal
automatically, otherwise document the current limitation and recommend users
ensure an ACME client or external process requests the `shortlived` profile and
performs renewals at least every 5 days.
There was a problem hiding this comment.
Good research on the short-lived certificate validity. I checked dashmate's implementation and can confirm:
Dashmate already handles this correctly. In obtainLetsEncryptCertificateTaskFactory.js, the lego ACME client is invoked with --profile shortlived specifically for IP address certificates. Dashmate also has automatic renewal scheduling via scheduleRenewLetsEncryptCertificateFactory.js with a 2-day expiration threshold (EXPIRATION_LIMIT_DAYS = 2).
That said, adding a brief note about the ~6-day validity for IP-address certificates would be helpful for node operators who want to understand why renewal happens so frequently. Something like:
Note: Let's Encrypt IP-address certificates use the short-lived profile and are valid for approximately 6 days. Dashmate handles renewal automatically — no manual intervention is required.
This is informational rather than a blocker — the current text ("Dashmate will handle the rest, including automatic renewal") is technically accurate.
| Please make sure that the certificate chain file contains your server certificate at the top and | ||
| intermediate/root certificates if present. If a bundle file is present, you need to concatenate it | ||
| with the certificate file:: | ||
|
|
||
| cat certificate.crt bundle.crt > bundle.crt |
There was a problem hiding this comment.
Pre-existing data-corruption bug in the cat concatenation command.
cat certificate.crt bundle.crt > bundle.crt
The shell opens bundle.crt for writing (truncating it to zero bytes) before cat reads it. The result is that bundle.crt ends up containing only the contents of certificate.crt — the original bundle data is silently discarded. Users following this step will upload an incomplete certificate chain without realising it.
Although this line was not introduced by this PR, it falls within the restructured option-3 section that was touched here, making this a good moment to fix it.
🐛 Proposed fix
- cat certificate.crt bundle.crt > bundle.crt
+ cat certificate.crt bundle.crt > chain.crtThen reference chain.crt as the certificate chain file in the upload step. Alternatively, use a temporary file and rename:
- cat certificate.crt bundle.crt > bundle.crt
+ cat certificate.crt bundle.crt > bundle.crt.tmp && mv bundle.crt.tmp bundle.crt🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/user/masternodes/setup-evonode.rst` around lines 648 - 652, The current
concat command overwrites bundle.crt before reading it; replace the line that
reads "cat certificate.crt bundle.crt > bundle.crt" by writing the combined
output to a new file (e.g., "chain.crt") or to a temporary file and then
renaming it, and update the subsequent upload instruction to reference the new
certificate chain filename (reference symbols: certificate.crt, bundle.crt,
chain.crt and the upload step that currently points to bundle.crt).
There was a problem hiding this comment.
Valid bug — cat certificate.crt bundle.crt > bundle.crt will indeed truncate bundle.crt before cat reads it, silently discarding the bundle data.
However, this is a pre-existing issue not introduced by this PR (the line existed before in the original option 2 section). While it's worth fixing, it should ideally be addressed in a separate commit or PR to keep the scope clean.
The suggested fix of writing to a temp file and renaming is the safest approach:
cat certificate.crt bundle.crt > bundle.crt.tmp && mv bundle.crt.tmp bundle.crt
There was a problem hiding this comment.
@thepastaclaw Agreed — keeping the scope of this PR focused on the Let's Encrypt additions makes sense, and addressing pre-existing issues separately is good practice.
Would you like me to open a GitHub issue to track this bug as a follow-up? I can document the problem and the recommended fix (bundle.crt.tmp + mv) so it doesn't get lost.
2 participants
Summary
Test plan
🤖 Generated with Claude Code
Preview build: https://dash-docs--567.org.readthedocs.build/en/567/
Summary by CodeRabbit
Release Notes