From 8afc310083e0538e214d44be9ebcd09f71c1fada Mon Sep 17 00:00:00 2001 From: Ivan Shumkov Date: Tue, 25 Aug 2026 09:48:53 +0700 Subject: [PATCH 1/6] Add certificate renewal troubleshooting for evonodes Inbound port 80 is documented as a setup step, but the requirement is permanent: Let's Encrypt IP certificates are short-lived and dashmate reissues them every few days, so a firewall rule that does not survive a reboot takes a node dark within a week. Nothing warns the operator until the certificate expires. There was no troubleshooting page for this, and the one diagnostic operators reach for is misleading: an external port check reports port 80 closed on a perfectly healthy node, because nothing listens there except for the seconds a renewal takes. Operators act on that result and rewrite firewall rules that were already correct. This page explains why the port must stay open, why an external check cannot answer the question, and what to do about each cause dashmate can now name - including the ones where obtaining another certificate makes things worse, such as an exhausted ZeroSSL free tier or a rate-limited address. Co-Authored-By: Claude Opus 5 (1M context) --- docs/user/masternodes/index.rst | 1 + .../troubleshooting-certificates.rst | 187 ++++++++++++++++++ 2 files changed, 188 insertions(+) create mode 100644 docs/user/masternodes/troubleshooting-certificates.rst diff --git a/docs/user/masternodes/index.rst b/docs/user/masternodes/index.rst index f1dade943..fd901f523 100644 --- a/docs/user/masternodes/index.rst +++ b/docs/user/masternodes/index.rst @@ -57,3 +57,4 @@ a self-operated masternode. setup-evonode setup-testnet.rst maintenance.rst + troubleshooting-certificates.rst diff --git a/docs/user/masternodes/troubleshooting-certificates.rst b/docs/user/masternodes/troubleshooting-certificates.rst new file mode 100644 index 000000000..054506b0f --- /dev/null +++ b/docs/user/masternodes/troubleshooting-certificates.rst @@ -0,0 +1,187 @@ +.. meta:: + :description: How to diagnose and fix TLS certificate renewal problems on a Dash evonode, including inbound port 80 requirements for Let's Encrypt and ZeroSSL + :keywords: dash, cryptocurrency, masternode, evonode, certificate, ssl, tls, port 80, lets encrypt, zerossl, acme, renewal, troubleshooting + +.. _evonode-cert-troubleshooting: + +=================================== +Certificate renewal troubleshooting +=================================== + +Your evonode serves Dash Platform over TLS, so it needs a valid certificate at all times. Dashmate +obtains that certificate for you and renews it automatically, but renewal can stop working long +after setup succeeded — and when it does, nothing warns you until the certificate expires and your +node stops accepting clients. + +Serving an expired certificate is one of the most common faults on mainnet evonodes, and almost all +of it comes down to the causes below. + +This page explains why renewal fails, how to find out which cause applies to your node, and what to +do about each one. + +.. _evonode-cert-port-80: + +Inbound port 80 is a permanent requirement +========================================== + +This is the single most common cause, and the most commonly misunderstood. + +Both Let's Encrypt and ZeroSSL prove that you control your IP address by connecting **to** your node +on port 80 and reading a file dashmate serves there for a few seconds. This happens on **every +issuance and every renewal**, not only during setup. + +Let's Encrypt certificates for IP addresses are :ref:`short-lived ` — about 160 +hours — and dashmate renews them a couple of days before they expire. So a firewall rule that was +opened once for setup and closed afterwards, or one that does not survive a reboot, takes your node +dark within a week. + +.. warning:: + + Inbound port 80 must stay open permanently. Nothing warns you when it stops being reachable, and + the certificate you are currently serving keeps working until it expires. + +Why you cannot test port 80 with a port scanner +----------------------------------------------- + +An external port check on port 80 will report it **closed on a perfectly healthy node**, and this +confuses almost everyone who tries it. + +Nothing listens on port 80 on a normal evonode. Dashmate starts a listener only for the few seconds +a renewal takes, and shuts it down again immediately. So a scanner that happens to check at any +other moment finds nothing — which is exactly what a healthy node looks like. + +.. note:: + + A "port 80 closed" result from an online port checker tells you nothing about whether certificate + renewal works. Do not rewrite firewall rules based on it. + +The reliable way to find out is to ask your node what actually happened the last time it tried. + +.. _evonode-cert-diagnose: + +Find out what is actually wrong +=============================== + +Run the doctor:: + + dashmate doctor + +Dashmate records the outcome of every scheduled renewal, so the doctor reports the reason the +certificate authority gave rather than guessing. Work from what it tells you. + +If the doctor reports no problem with your certificate, renewal is working and there is nothing to +do here. + +.. _evonode-cert-causes: + +Causes and what to do about each +================================ + +The certificate authority could not reach this node on port 80 +-------------------------------------------------------------- + +Nothing answered. The connection was dropped or refused before it arrived, which means a firewall +somewhere between the internet and your node. + +Check all three layers — a rule on one does not help if another blocks it: + +#. **The machine's own firewall.** On Ubuntu with ``ufw``:: + + ufw allow 80/tcp + ufw status + +#. **Your hosting provider's firewall.** Many providers (AWS security groups, Hetzner Cloud + firewalls, OVH, Vultr, DigitalOcean) apply a second firewall outside the machine, configured in + their web console. Port 80 must be allowed there too. + +#. **Your router**, if the node is behind NAT. Forward inbound port 80 to the node's internal + address. + +Once the port is open, wait for the next automatic attempt — the doctor tells you when that is. You +do not need to run any command. + +Something answered on port 80, but not this node's certificate check +-------------------------------------------------------------------- + +The certificate authority reached your address and got the wrong response. Something else is +answering: another web server on the machine, a reverse proxy in front of it, or a router forwarding +port 80 somewhere other than your node. + +Check the machine first:: + + sudo ss -lntp 'sport = :80' + +If that lists a process (nginx, Apache, Caddy, another container), stop it or move it to a different +port. Dashmate needs port 80 free to answer the challenge. + +If it lists **nothing**, then something upstream is answering instead of your node — check your +router's port forwarding and your hosting provider's configuration. + +Something on this machine is already using port 80 +--------------------------------------------------- + +Dashmate could not start its own listener because the port is taken. Note this is the opposite +problem to an unreachable port: the port is reachable, it is occupied. Find and stop the occupant +with the ``ss`` command above. + +The free ZeroSSL account has used all three of its certificates +---------------------------------------------------------------- + +A free ZeroSSL account allows three certificates in total, so renewals stop permanently after about +270 days. This is not something you can wait out or repair — ZeroSSL will not issue another one. + +Switch to Let's Encrypt, which is free and does not cap certificates this way:: + + dashmate ssl obtain --config mainnet --provider letsencrypt + +This still needs inbound port 80 open to the internet, permanently. If you cannot open port 80, +there is no other way to obtain a certificate for an IP address automatically — see +:ref:`SSL certificates ` for the manual upload option. + +The certificate authority has temporarily refused this address +--------------------------------------------------------------- + +Let's Encrypt limits how often a single address may fail validation — five failed attempts per hour, +and that budget is shared with dashmate's own automatic renewal. + +.. important:: + + Do not keep running the obtain command. Each attempt spends part of this budget and makes the + situation last longer. Fix the underlying cause first, then let the automatic retry run. + +A certificate was issued but dashmate could not save it +-------------------------------------------------------- + +The certificate authority issued a certificate that never reached disk. That issuance is spent +against your weekly limit whether or not it arrived, so requesting another one immediately spends a +second one to fix a problem that is local to your machine. + +Check free disk space and the permissions on your dashmate directory first, then obtain again. + +.. _evonode-cert-avoid: + +Avoid making it worse +===================== + +- **Do not repeatedly run** ``dashmate ssl obtain``. Failed attempts are rate-limited by the + certificate authority and shared with automatic renewal, so retrying without changing anything + makes recovery slower. +- **Do not switch provider hoping it helps.** If port 80 is unreachable, every provider fails the + same way — they all validate the same route. +- **Do not rely on an external port check.** See :ref:`above `. + +Getting help +============ + +If the doctor cannot determine the cause, or the remedy does not work, collect a report and send it +to the support team:: + + dashmate doctor report + +The report includes the recorded renewal outcome along with service logs and system information. +Review it before sharing: it contains your node's IP address and configuration. + +.. seealso:: + + - :ref:`SSL certificates ` — choosing and configuring a certificate provider + - :ref:`Server configuration ` — firewall setup From a14a0fb0faa414ecb80a48cef7aea82af4a53be5 Mon Sep 17 00:00:00 2001 From: Ivan Shumkov Date: Tue, 25 Aug 2026 14:13:55 +0700 Subject: [PATCH 2/6] Separate a refused connection from a dropped one, and scope the provider claims Review feedback. A timeout and a refusal are different findings and this page is built on that kind of distinction elsewhere. A drop means a firewall swallowed the packets; a refusal means they arrived and nothing was listening, which points at forwarding or at the challenge server rather than at a firewall rule. Sending both to the same three-layer firewall walkthrough wastes the operator's time on half of them. The firewall commands now use sudo, matching the ss command already on the page. Two scoping corrections: the port 80 requirement belongs to the flows where dashmate obtains the certificate, not to a certificate the operator uploads themselves; and the three-certificate limit is ZeroSSL's free plan through the API dashmate uses, worded to match the setup page rather than restating it differently. Co-Authored-By: Claude Opus 5 (1M context) --- .../troubleshooting-certificates.rst | 29 ++++++++++++------- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/docs/user/masternodes/troubleshooting-certificates.rst b/docs/user/masternodes/troubleshooting-certificates.rst index 054506b0f..ccc9a4386 100644 --- a/docs/user/masternodes/troubleshooting-certificates.rst +++ b/docs/user/masternodes/troubleshooting-certificates.rst @@ -26,9 +26,10 @@ Inbound port 80 is a permanent requirement This is the single most common cause, and the most commonly misunderstood. -Both Let's Encrypt and ZeroSSL prove that you control your IP address by connecting **to** your node -on port 80 and reading a file dashmate serves there for a few seconds. This happens on **every -issuance and every renewal**, not only during setup. +When dashmate obtains a certificate for you — the Let's Encrypt and ZeroSSL options — the authority +proves you control your IP address by connecting **to** your node on port 80 and reading a file +dashmate serves there for a few seconds. This happens on **every issuance and every renewal**, not +only during setup. It does not apply if you upload a certificate yourself. Let's Encrypt certificates for IP addresses are :ref:`short-lived ` — about 160 hours — and dashmate renews them a couple of days before they expire. So a firewall rule that was @@ -80,15 +81,21 @@ Causes and what to do about each The certificate authority could not reach this node on port 80 -------------------------------------------------------------- -Nothing answered. The connection was dropped or refused before it arrived, which means a firewall -somewhere between the internet and your node. +Nothing usable answered. Which of two things happened is worth knowing, and ``dashmate doctor`` +shows the authority's own words: -Check all three layers — a rule on one does not help if another blocks it: +- **Timed out.** The connection went nowhere and nothing replied — a firewall dropping it silently. + Work through the three layers below. +- **Refused.** Something reachable actively rejected the connection, so the packets arrive but + nothing is listening when they do. Check that port 80 is forwarded to *this* machine, then look + at what dashmate reported: ``dashmate logs dashmate_helper``. + +For a timeout, check all three layers — a rule on one does not help if another blocks it: #. **The machine's own firewall.** On Ubuntu with ``ufw``:: - ufw allow 80/tcp - ufw status + sudo ufw allow 80/tcp + sudo ufw status #. **Your hosting provider's firewall.** Many providers (AWS security groups, Hetzner Cloud firewalls, OVH, Vultr, DigitalOcean) apply a second firewall outside the machine, configured in @@ -127,8 +134,10 @@ with the ``ss`` command above. The free ZeroSSL account has used all three of its certificates ---------------------------------------------------------------- -A free ZeroSSL account allows three certificates in total, so renewals stop permanently after about -270 days. This is not something you can wait out or repair — ZeroSSL will not issue another one. +Dashmate obtains ZeroSSL certificates through ZeroSSL's own API, and :ref:`a free account allows +3 certificates ` — or 3 renewals of one certificate — in total. Renewals stop +permanently after that. It is not something you can wait out or repair; ZeroSSL will not issue +another one on that plan. Switch to Let's Encrypt, which is free and does not cap certificates this way:: From a24b8393cee3f470103cee925059c728dbadc9bb Mon Sep 17 00:00:00 2001 From: Ivan Shumkov Date: Tue, 25 Aug 2026 14:26:09 +0700 Subject: [PATCH 3/6] Separate Let's Encrypt's two rate limits Review feedback. The page referred to a single budget, which merged two limits that are spent by opposite things: five failed validations per hour, which retrying a broken node consumes, and five certificates per week for the same address, which successful issuance consumes. The distinction is load-bearing on this page rather than trivia. It is why a certificate that was issued and never saved still costs something, and why the advice for a rate-limited address is to stop retrying while the advice for a spent issuance is to fix the machine first. Co-Authored-By: Claude Opus 5 (1M context) --- .../masternodes/troubleshooting-certificates.rst | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/docs/user/masternodes/troubleshooting-certificates.rst b/docs/user/masternodes/troubleshooting-certificates.rst index ccc9a4386..b1f091442 100644 --- a/docs/user/masternodes/troubleshooting-certificates.rst +++ b/docs/user/masternodes/troubleshooting-certificates.rst @@ -150,8 +150,12 @@ there is no other way to obtain a certificate for an IP address automatically The certificate authority has temporarily refused this address --------------------------------------------------------------- -Let's Encrypt limits how often a single address may fail validation — five failed attempts per hour, -and that budget is shared with dashmate's own automatic renewal. +Let's Encrypt applies two separate limits, and they are easy to confuse: + +- **Five failed validations per hour**, counted per ACME account and address. This is the one you + hit by retrying after a failure, and dashmate's own automatic renewal draws on the same budget. +- **Five certificates per week** for the same address. This one is spent by *successful* issuance, + which is why a certificate that was issued but never saved still counts. .. important:: @@ -161,8 +165,8 @@ and that budget is shared with dashmate's own automatic renewal. A certificate was issued but dashmate could not save it -------------------------------------------------------- -The certificate authority issued a certificate that never reached disk. That issuance is spent -against your weekly limit whether or not it arrived, so requesting another one immediately spends a +The certificate authority issued a certificate that never reached disk. It counts against the +five-per-week limit above whether or not it arrived, so requesting another one immediately spends a second one to fix a problem that is local to your machine. Check free disk space and the permissions on your dashmate directory first, then obtain again. From c01e7bf5fc5a1efbf6d8670f9efd46b12593989c Mon Sep 17 00:00:00 2001 From: thephez Date: Tue, 25 Aug 2026 13:41:42 -0400 Subject: [PATCH 4/6] docs: remove ai bolding --- .../troubleshooting-certificates.rst | 28 +++++++++---------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/user/masternodes/troubleshooting-certificates.rst b/docs/user/masternodes/troubleshooting-certificates.rst index b1f091442..efd3454ec 100644 --- a/docs/user/masternodes/troubleshooting-certificates.rst +++ b/docs/user/masternodes/troubleshooting-certificates.rst @@ -27,8 +27,8 @@ Inbound port 80 is a permanent requirement This is the single most common cause, and the most commonly misunderstood. When dashmate obtains a certificate for you — the Let's Encrypt and ZeroSSL options — the authority -proves you control your IP address by connecting **to** your node on port 80 and reading a file -dashmate serves there for a few seconds. This happens on **every issuance and every renewal**, not +proves you control your IP address by connecting to your node on port 80 and reading a file +dashmate serves there for a few seconds. This happens on every issuance and every renewal, not only during setup. It does not apply if you upload a certificate yourself. Let's Encrypt certificates for IP addresses are :ref:`short-lived ` — about 160 @@ -44,7 +44,7 @@ dark within a week. Why you cannot test port 80 with a port scanner ----------------------------------------------- -An external port check on port 80 will report it **closed on a perfectly healthy node**, and this +An external port check on port 80 will report it closed on a perfectly healthy node, and this confuses almost everyone who tries it. Nothing listens on port 80 on a normal evonode. Dashmate starts a listener only for the few seconds @@ -84,24 +84,24 @@ The certificate authority could not reach this node on port 80 Nothing usable answered. Which of two things happened is worth knowing, and ``dashmate doctor`` shows the authority's own words: -- **Timed out.** The connection went nowhere and nothing replied — a firewall dropping it silently. +- Timed out. The connection went nowhere and nothing replied — a firewall dropping it silently. Work through the three layers below. -- **Refused.** Something reachable actively rejected the connection, so the packets arrive but +- Refused. Something reachable actively rejected the connection, so the packets arrive but nothing is listening when they do. Check that port 80 is forwarded to *this* machine, then look at what dashmate reported: ``dashmate logs dashmate_helper``. For a timeout, check all three layers — a rule on one does not help if another blocks it: -#. **The machine's own firewall.** On Ubuntu with ``ufw``:: +#. The machine's own firewall. On Ubuntu with ``ufw``:: sudo ufw allow 80/tcp sudo ufw status -#. **Your hosting provider's firewall.** Many providers (AWS security groups, Hetzner Cloud +#. Your hosting provider's firewall. Many providers (AWS security groups, Hetzner Cloud firewalls, OVH, Vultr, DigitalOcean) apply a second firewall outside the machine, configured in their web console. Port 80 must be allowed there too. -#. **Your router**, if the node is behind NAT. Forward inbound port 80 to the node's internal +#. Your router, if the node is behind NAT. Forward inbound port 80 to the node's internal address. Once the port is open, wait for the next automatic attempt — the doctor tells you when that is. You @@ -121,7 +121,7 @@ Check the machine first:: If that lists a process (nginx, Apache, Caddy, another container), stop it or move it to a different port. Dashmate needs port 80 free to answer the challenge. -If it lists **nothing**, then something upstream is answering instead of your node — check your +If it lists nothing, then something upstream is answering instead of your node — check your router's port forwarding and your hosting provider's configuration. Something on this machine is already using port 80 @@ -152,9 +152,9 @@ The certificate authority has temporarily refused this address Let's Encrypt applies two separate limits, and they are easy to confuse: -- **Five failed validations per hour**, counted per ACME account and address. This is the one you +- Five failed validations per hour, counted per ACME account and address. This is the one you hit by retrying after a failure, and dashmate's own automatic renewal draws on the same budget. -- **Five certificates per week** for the same address. This one is spent by *successful* issuance, +- Five certificates per week for the same address. This one is spent by *successful* issuance, which is why a certificate that was issued but never saved still counts. .. important:: @@ -176,12 +176,12 @@ Check free disk space and the permissions on your dashmate directory first, then Avoid making it worse ===================== -- **Do not repeatedly run** ``dashmate ssl obtain``. Failed attempts are rate-limited by the +- Do not repeatedly run ``dashmate ssl obtain``. Failed attempts are rate-limited by the certificate authority and shared with automatic renewal, so retrying without changing anything makes recovery slower. -- **Do not switch provider hoping it helps.** If port 80 is unreachable, every provider fails the +- Do not switch provider hoping it helps. If port 80 is unreachable, every provider fails the same way — they all validate the same route. -- **Do not rely on an external port check.** See :ref:`above `. +- Do not rely on an external port check. See :ref:`above `. Getting help ============ From 5ec98b93b7231bb01991cbae3f38d6394dd29995 Mon Sep 17 00:00:00 2001 From: thephez Date: Tue, 25 Aug 2026 14:34:19 -0400 Subject: [PATCH 5/6] docs: minor cleanup --- .../troubleshooting-certificates.rst | 82 +++++++++---------- 1 file changed, 37 insertions(+), 45 deletions(-) diff --git a/docs/user/masternodes/troubleshooting-certificates.rst b/docs/user/masternodes/troubleshooting-certificates.rst index efd3454ec..e67e3ec8c 100644 --- a/docs/user/masternodes/troubleshooting-certificates.rst +++ b/docs/user/masternodes/troubleshooting-certificates.rst @@ -10,46 +10,40 @@ Certificate renewal troubleshooting Your evonode serves Dash Platform over TLS, so it needs a valid certificate at all times. Dashmate obtains that certificate for you and renews it automatically, but renewal can stop working long -after setup succeeded — and when it does, nothing warns you until the certificate expires and your -node stops accepting clients. +after setup succeeded. If renewal fails without you noticing it, your node will stop accepting +clients once the certificate expires. -Serving an expired certificate is one of the most common faults on mainnet evonodes, and almost all -of it comes down to the causes below. - -This page explains why renewal fails, how to find out which cause applies to your node, and what to -do about each one. +Serving expired certificates is one of the most common connection issues on mainnet evonodes. Use +the info on this page to find and fix certificate renewal failures on your evonode. .. _evonode-cert-port-80: Inbound port 80 is a permanent requirement ========================================== -This is the single most common cause, and the most commonly misunderstood. - -When dashmate obtains a certificate for you — the Let's Encrypt and ZeroSSL options — the authority -proves you control your IP address by connecting to your node on port 80 and reading a file -dashmate serves there for a few seconds. This happens on every issuance and every renewal, not -only during setup. It does not apply if you upload a certificate yourself. +This cause is common and often misunderstood. When dashmate obtains a certificate for you using +Let's Encrypt or ZeroSSL, the authority proves you control your IP address by connecting to your +node on port 80 and reading a file dashmate temporarily serves there. This happens on every issuance +and every renewal, not only during setup. It does not apply if you upload a certificate yourself. Let's Encrypt certificates for IP addresses are :ref:`short-lived ` — about 160 -hours — and dashmate renews them a couple of days before they expire. So a firewall rule that was -opened once for setup and closed afterwards, or one that does not survive a reboot, takes your node -dark within a week. +hours — and dashmate renews them a couple of days before they expire. So a non-permanent firewall +rule can result in your node having an expired certificate within a week. .. warning:: - Inbound port 80 must stay open permanently. Nothing warns you when it stops being reachable, and - the certificate you are currently serving keeps working until it expires. + Inbound port 80 must stay open permanently. Dashmate does not warn you when it stops being + reachable. The certificate you are serving just becomes invalid when it expires. + +.. _evonode-cert-port-80-scan: Why you cannot test port 80 with a port scanner ----------------------------------------------- -An external port check on port 80 will report it closed on a perfectly healthy node, and this -confuses almost everyone who tries it. - -Nothing listens on port 80 on a normal evonode. Dashmate starts a listener only for the few seconds -a renewal takes, and shuts it down again immediately. So a scanner that happens to check at any -other moment finds nothing — which is exactly what a healthy node looks like. +Since nothing continuously listens to port 80 on a normal evonode, an external port check will +report it closed even on healthy nodes. Dashmate starts a listener only for the few seconds a +renewal takes, and shuts it down again immediately. A scanner that checks at any other time will +find nothing. .. note:: @@ -68,10 +62,8 @@ Run the doctor:: dashmate doctor Dashmate records the outcome of every scheduled renewal, so the doctor reports the reason the -certificate authority gave rather than guessing. Work from what it tells you. - -If the doctor reports no problem with your certificate, renewal is working and there is nothing to -do here. +certificate authority gave rather than guessing. If the doctor reports no problem with your +certificate, renewal is working and there is nothing to do here. .. _evonode-cert-causes: @@ -84,13 +76,13 @@ The certificate authority could not reach this node on port 80 Nothing usable answered. Which of two things happened is worth knowing, and ``dashmate doctor`` shows the authority's own words: -- Timed out. The connection went nowhere and nothing replied — a firewall dropping it silently. - Work through the three layers below. -- Refused. Something reachable actively rejected the connection, so the packets arrive but - nothing is listening when they do. Check that port 80 is forwarded to *this* machine, then look +- **Timed out**. The connection went nowhere and nothing replied because a firewall dropped it + silently. Work through the three layers below. +- **Refused**. Something reachable actively rejected the connection, so the packets arrive but + nothing is listening when they do. Check that port 80 is forwarded to the evonode, then look at what dashmate reported: ``dashmate logs dashmate_helper``. -For a timeout, check all three layers — a rule on one does not help if another blocks it: +For a timeout, check all three layers. Connections could be blocked at any or all layers: #. The machine's own firewall. On Ubuntu with ``ufw``:: @@ -104,7 +96,7 @@ For a timeout, check all three layers — a rule on one does not help if another #. Your router, if the node is behind NAT. Forward inbound port 80 to the node's internal address. -Once the port is open, wait for the next automatic attempt — the doctor tells you when that is. You +Once the port is open, wait for the next automatic attempt at the time indicated by the doctor. You do not need to run any command. Something answered on port 80, but not this node's certificate check @@ -118,11 +110,11 @@ Check the machine first:: sudo ss -lntp 'sport = :80' -If that lists a process (nginx, Apache, Caddy, another container), stop it or move it to a different -port. Dashmate needs port 80 free to answer the challenge. +If that lists a process (e.g., nginx, Apache, Caddy, another container), stop it or move it to a +different port. Dashmate needs port 80 free to answer the challenge. -If it lists nothing, then something upstream is answering instead of your node — check your -router's port forwarding and your hosting provider's configuration. +If it lists nothing, then something upstream is answering instead of your node. Check your router's +port forwarding and your hosting provider's configuration. Something on this machine is already using port 80 --------------------------------------------------- @@ -144,8 +136,8 @@ Switch to Let's Encrypt, which is free and does not cap certificates this way:: dashmate ssl obtain --config mainnet --provider letsencrypt This still needs inbound port 80 open to the internet, permanently. If you cannot open port 80, -there is no other way to obtain a certificate for an IP address automatically — see -:ref:`SSL certificates ` for the manual upload option. +there is no other way to automatically obtain a certificate for an IP address. See :ref:`SSL +certificates ` for the manual upload option. The certificate authority has temporarily refused this address --------------------------------------------------------------- @@ -179,15 +171,15 @@ Avoid making it worse - Do not repeatedly run ``dashmate ssl obtain``. Failed attempts are rate-limited by the certificate authority and shared with automatic renewal, so retrying without changing anything makes recovery slower. -- Do not switch provider hoping it helps. If port 80 is unreachable, every provider fails the - same way — they all validate the same route. -- Do not rely on an external port check. See :ref:`above `. +- Do not switch provider hoping it helps. If port 80 is unreachable, every provider will fail in the + same way since they all validate the same route. +- Do not rely on an external port check. See :ref:`above `. Getting help ============ -If the doctor cannot determine the cause, or the remedy does not work, collect a report and send it -to the support team:: +If the doctor cannot determine the cause, or the fix does not work, collect a report and send it to +the support team:: dashmate doctor report From 8c94d614e1a870bc75da9d40f3f20372bd8a59e2 Mon Sep 17 00:00:00 2001 From: thephez Date: Tue, 25 Aug 2026 15:57:06 -0400 Subject: [PATCH 6/6] docs: more cleanup --- docs/user/masternodes/troubleshooting-certificates.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/user/masternodes/troubleshooting-certificates.rst b/docs/user/masternodes/troubleshooting-certificates.rst index e67e3ec8c..2d52467e6 100644 --- a/docs/user/masternodes/troubleshooting-certificates.rst +++ b/docs/user/masternodes/troubleshooting-certificates.rst @@ -110,8 +110,10 @@ Check the machine first:: sudo ss -lntp 'sport = :80' -If that lists a process (e.g., nginx, Apache, Caddy, another container), stop it or move it to a -different port. Dashmate needs port 80 free to answer the challenge. +If that lists a process (e.g., nginx, Apache, Caddy, another container), certificate renewals will +continue to fail until the port is released. Reconfigure the process to use a different port where +possible. Otherwise, stop it before the next scheduled renewal attempt and leave it stopped until +the renewal completes. If it lists nothing, then something upstream is answering instead of your node. Check your router's port forwarding and your hosting provider's configuration.