Order a certificate (Settings › Security › Certificates, new button above the list) is a guide in five steps:
Names: enter the names you want, one per line, wildcards allowed. The guide finds the domain they belong to and suggests the closest one. If none covers them, it offers to add the domain only for certificates (DKIM manual, DNS manual, nothing published). A wildcard is refused when the domain's DNS isn't connected, with a link to connect it. If the domain already orders other names, it says those stop being renewed and offers "Keep those names too". If the names are exactly what it already orders, it points to Order again instead.
Check names / Account / Review: the same checks and Let's Encrypt account handling as "Certificates, automatically".
Watch: like the existing guide. Once the certificate is issued it offers Make it the default certificate. The side note explains that connections asking for its names get it anyway: the default is only sent when no certificate covers the name.
The server orders certificates per domain, so the guide sets the names as the domain's certificate hostnames (subjectAlternativeNames, full names as written).
Ordered automatically is a new panel above the list. For each automatic domain it shows the names, the domain, how long the current certificate is valid, and the renewal state: renews on a date, ordering now, retrying (with the reason), the last order failed (with the reason), or nothing queued. Order again appears after a failure, during a retry, or when nothing is queued. It sets the queued renewal task to Pending with due now, and only creates a task when none exists (#290). After a click it rereads every 5 s for a minute. Without the task permission, the renewal line and the button are hidden rather than guessed.
A fix found while previewing: both guides sent a description when adding a Let's Encrypt account. The server treats that as server-set and refuses it ("Cannot modify server set property"), so "Certificates, automatically" could only work on a server that already had a matching account. It's now left out.
The existing guide's loading, polling, provider creation and name lookups move to shared.ts (plus StateIcon.tsx) so both guides use them. The behaviour is unchanged apart from the description fix.
Server side: inbuxa/inbuxa-server#308 makes a renewal created over the API replace the queued one. This PR doesn't depend on it.
Checked locally
typecheck, lint, i18n:check, 1018 tests (new orders.test.ts), notice check, both shell tests, and the build.
A preview on localhost against an empty rc.11 server, with Pebble standing in for Let's Encrypt and outbound HTTPS blocked:
entered names with no domain covering them, then added certs.test from the guide;
the wildcard block;
the name checks with "Order anyway";
the account step;
the order itself, after which the domain was saved with the chosen names;
the panel showing the order;
a Failed renewal with its reason, then Order again, which left the one task back at Pending now;
"Keep those names too".
The preview server doesn't run tasks in recovery mode, so I marked the task Failed through the API to see the failure state. The server test in #308 covers a run-now task actually running.
Closes #167.
**Order a certificate** (Settings › Security › Certificates, new button above the list) is a guide in five steps:
- **Names:** enter the names you want, one per line, wildcards allowed. The guide finds the domain they belong to and suggests the closest one. If none covers them, it offers to add the domain only for certificates (DKIM manual, DNS manual, nothing published). A wildcard is refused when the domain's DNS isn't connected, with a link to connect it. If the domain already orders other names, it says those stop being renewed and offers "Keep those names too". If the names are exactly what it already orders, it points to Order again instead.
- **Check names / Account / Review:** the same checks and Let's Encrypt account handling as "Certificates, automatically".
- **Watch:** like the existing guide. Once the certificate is issued it offers **Make it the default certificate**. The side note explains that connections asking for its names get it anyway: the default is only sent when no certificate covers the name.
The server orders certificates per domain, so the guide sets the names as the domain's certificate hostnames (`subjectAlternativeNames`, full names as written).
**Ordered automatically** is a new panel above the list. For each automatic domain it shows the names, the domain, how long the current certificate is valid, and the renewal state: renews on a date, ordering now, retrying (with the reason), the last order failed (with the reason), or nothing queued. **Order again** appears after a failure, during a retry, or when nothing is queued. It sets the queued renewal task to `Pending` with `due` now, and only creates a task when none exists (#290). After a click it rereads every 5 s for a minute. Without the task permission, the renewal line and the button are hidden rather than guessed.
**A fix found while previewing:** both guides sent a `description` when adding a Let's Encrypt account. The server treats that as server-set and refuses it ("Cannot modify server set property"), so "Certificates, automatically" could only work on a server that already had a matching account. It's now left out.
The existing guide's loading, polling, provider creation and name lookups move to `shared.ts` (plus `StateIcon.tsx`) so both guides use them. The behaviour is unchanged apart from the description fix.
Server side: inbuxa/inbuxa-server#308 makes a renewal created over the API replace the queued one. This PR doesn't depend on it.
**Checked locally**
- typecheck, lint, i18n:check, 1018 tests (new `orders.test.ts`), notice check, both shell tests, and the build.
- A preview on localhost against an empty rc.11 server, with Pebble standing in for Let's Encrypt and outbound HTTPS blocked:
- entered names with no domain covering them, then added `certs.test` from the guide;
- the wildcard block;
- the name checks with "Order anyway";
- the account step;
- the order itself, after which the domain was saved with the chosen names;
- the panel showing the order;
- a Failed renewal with its reason, then Order again, which left the one task back at Pending now;
- "Keep those names too".
The preview server doesn't run tasks in recovery mode, so I marked the task Failed through the API to see the failure state. The server test in #308 covers a run-now task actually running.
"Order a certificate" on the Certificates page takes the names you want,
finds the domain they belong to (or adds one just for certificates, with
no DKIM keys and nothing published), checks the names the way the
existing guide does, and sets them as that domain's certificate
hostnames. The server orders per domain, so that's how a certificate
with chosen names is ordered. Once it's issued the guide offers to make
it the default certificate; connections asking for its names get it
without that.
Above the list, every automatic certificate shows the domain that renews
it, the next renewal, and why the last order failed. Order again tells
the queued renewal to run now; it only creates one when none is queued,
since a second would keep renewing for good (inbuxa-server#290).
The existing guide's loading, polling and name lookups move to shared.ts
so both guides use them. (#167)
The server writes an ACME provider's description itself and refuses one
from a client ("Cannot modify server set property"), so the guides could
never add a Let's Encrypt account: "Certificates, automatically" only
worked on servers that already had one. Both guides now leave it out.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #167.
Order a certificate (Settings › Security › Certificates, new button above the list) is a guide in five steps:
The server orders certificates per domain, so the guide sets the names as the domain's certificate hostnames (
subjectAlternativeNames, full names as written).Ordered automatically is a new panel above the list. For each automatic domain it shows the names, the domain, how long the current certificate is valid, and the renewal state: renews on a date, ordering now, retrying (with the reason), the last order failed (with the reason), or nothing queued. Order again appears after a failure, during a retry, or when nothing is queued. It sets the queued renewal task to
Pendingwithduenow, and only creates a task when none exists (#290). After a click it rereads every 5 s for a minute. Without the task permission, the renewal line and the button are hidden rather than guessed.A fix found while previewing: both guides sent a
descriptionwhen adding a Let's Encrypt account. The server treats that as server-set and refuses it ("Cannot modify server set property"), so "Certificates, automatically" could only work on a server that already had a matching account. It's now left out.The existing guide's loading, polling, provider creation and name lookups move to
shared.ts(plusStateIcon.tsx) so both guides use them. The behaviour is unchanged apart from the description fix.Server side: inbuxa/inbuxa-server#308 makes a renewal created over the API replace the queued one. This PR doesn't depend on it.
Checked locally
orders.test.ts), notice check, both shell tests, and the build.certs.testfrom the guide;The preview server doesn't run tasks in recovery mode, so I marked the task Failed through the API to see the failure state. The server test in #308 covers a run-now task actually running.
The server writes an ACME provider's description itself and refuses one from a client ("Cannot modify server set property"), so the guides could never add a Let's Encrypt account: "Certificates, automatically" only worked on servers that already had one. Both guides now leave it out.