Module issue 

Certificate issuance as queued work.

finalize checks the CSR, claims the order (ready → processing) and queues one of these rows in the same transaction; the job runner asks the backend to sign. RFC 8555 §7.4 already has the state this needs — an order is processing while “the certificate is being issued”, and the client polls — and the relay backend has always answered that way.

The point is where the key lives, not latency. Signing needs ca.key, a PKCS#11 login or a relay’s upstream account, and only the worker role builds a backend, so the process parsing untrusted JWS and CSRs never holds one. This is the one place a backend is asked to issue.

One handler over every profile, the SignerRevokeJob shape: a row names its order, the order names its profile, and the profile names the backend.

How each answer settles the row:

Backend answer	Order	Job
a chain	valid, certificate_issued, notified	Done
a chain this server cannot read	invalid via abandon	Failed
a chain it could not store	unchanged	Retry
Processing (relay)	unchanged — the relay job owns it	Done
BadCsr	invalid with badCSR — a verdict	Done
(not asked) account or an authorization deactivated since the claim	invalid with unauthorized	Done
Internal	unchanged	Retry, then invalid via abandon

BadCsr makes the order invalid rather than ready again, although §7.4 says a rejected CSR SHOULD leave it finalizable: the client was already told processing, and certbot, acme.sh and lego all poll for valid or invalid — an order back at ready would have them poll until they time out, with no error to show. finalize still runs the CSR/order match and the filter itself, so almost every bad CSR is still refused synchronously, with the order left ready.

Structs

SignerIssueJob

Issues the certificate a finalize request queued, at the backend of the order’s profile.

Constants

SIGNER_ISSUE_KIND

The jobs.kind one issuance is queued under.

Functions

signer_issue_spec

The row asking a worker to issue the certificate order was just claimed for.