dashmate ssl obtain --force is broken on the ZeroSSL provider

[shumkov]

Expected Behavior

dashmate ssl obtain --force should obtain a new ZeroSSL certificate, bypassing the "certificate already exists and is not expiring soon" early exit.

Current Behavior

On the ZeroSSL provider (the default), --force cannot complete. It should fail during "Create a certificate" with an undefined API key; if it got past that, "Save certificate private key file" would call fs.writeFileSync(undefined, …).

The first task in the pipeline, "Check if certificate already exists and not expiring soon", is declared skip: (ctx) => ctx.force — and it is the only place that merges the validator's data into the Listr context:

• packages/dashmate/src/listr/tasks/ssl/zerossl/obtainZeroSSLCertificateTaskFactory.js — the skip predicate on the first task, and the single lodash.merge(ctx, data) inside it.
• packages/dashmate/src/ssl/zerossl/validateZeroSslCertificateFactory.js — where that data originates: sslConfigDir, apiKey, externalIp, certificate, csrFilePath, privateKeyFilePath, bundleFilePath, and the isXxxFilePresent flags.
• packages/dashmate/src/commands/ssl/obtain.js — seeds the context with only { noRetry, force, expirationDays }.

So under --force, every one of those values is undefined for the remainder of the pipeline.

The intent of --force appears to be "get a new certificate regardless of the existing one" — which still needs the API key and the resolved file paths. Skipping the whole task discards the context setup along with the early exit.

Possible Solution

Separate context population from the early-exit decision. Either:

• drop the skip and make only the "certificate is still valid, stop here" branch conditional on ctx.force, so the merge always runs; or
• move the lodash.merge(ctx, data) into a preceding task that never skips.

Steps to Reproduce

1. Configure a node with the ZeroSSL provider and a valid API key.
2. Run dashmate ssl obtain --force.
3. Observe the failure. Expected failure point is certificate creation with an undefined API key.

Context

Found by code inspection while fixing unrelated TLS private-key permission issues in the same files (see the private-key permission changes on feat/dashmate/update). Not reproduced end to end — doing so needs a real ZeroSSL API key and an externally reachable IP, which was not available. The exact failure point (API rejection vs. writeFileSync(undefined, …)) is therefore inferred from the code path rather than observed; the context-seeding, the skip predicate and the single merge site are all directly verifiable in the source.

The self-signed and Let's Encrypt providers do not share this path.

Your Environment

• Version used: dashmate 4.1.0 (v4.1-dev, code path unchanged on feat/dashmate/update)
• Link to your project: Dash Platform

[DashBot-0001]

Reproduced end to end on dashmate 4.1.0 GA (4.1.0.bfc80249b9-1, testnet node with a real ZeroSSL API key and an externally reachable IP). Confirms the bug, but the actual failure point is earlier than the issue predicts.

Observed:

[STARTED] Obtain ZeroSSL certificate
[STARTED] Check if certificate already exists and not expiring soon
[SKIPPED] Check if certificate already exists and not expiring soon
[STARTED] Generate a keypair
[SUCCESS] Generate a keypair [0.0s]
[STARTED] Generate certificate request
[FAILED] Attribute value not specified.
exit 1

It never reaches "Create a certificate", so the undefined API key is not what surfaces first. It dies in "Generate certificate request":

// obtainZeroSSLCertificateTaskFactory.js
enabled: (ctx) => !ctx.isCsrFilePresent,
task: async (ctx) => {
  ctx.csr = await generateCsr(ctx.keyPair, ctx.externalIp);
}
// generateCsr.js
{ name: 'commonName', value: externalIp }   // undefined -> "Attribute value not specified."

One consequence worth adding to the analysis: the isXxxFilePresent flags from that merge don't just carry data — they drive the enabled/skip predicates of the later tasks. With the merge skipped they are all undefined, so every subsequent branch is evaluated against a false premise. Here csr.pem was present on disk; with a populated context enabled: !ctx.isCsrFilePresent would have skipped this task entirely. Instead it ran and hit the undefined externalIp. So --force doesn't just lose values, it takes a different path through the pipeline than it would with the same on-disk state and no --force.

Safe to reproduce, for anyone else verifying. Checked after the run: certificate and private key files untouched (same mtime and sha256), zerossl.id unchanged, key/cert moduli still match, gateway and helper containers not restarted. Since it dies before "Create a certificate", it should also cost no issuance quota — though I checked the local state, not the ZeroSSL account.

Both suggested fixes look right. Moving the lodash.merge(ctx, data) into a preceding task that never skips also fixes the predicate problem above, which making only the early-exit branch conditional would fix as well.

Posted with assistance from Claude (Anthropic).