Issuance Runs
Every certificate issuance mipo has attempted, newest first — successful, failed, and refused before any request left the manager. Each run records the ordered steps it went through, where it stopped, and what happened to the certificate it produced. Selecting a run shows those steps and, on request, the raw HTTP exchanges with the certificate authority and the DNS provider.
Fields & columns
| Name | Description |
|---|---|
Started | When the run began. Runs are kept until the newest 200 push an older one out |
Profile | The certificate profile the run was for. A deleted profile falls back to the hostname the run asked for |
Trigger | manual (an operator pressed Issue), promotion (the profile moved to the production account), or renewal (mipo renewed it on schedule) |
Directory | Staging (proof) or Production (trusted) — which Let's Encrypt service the run used |
Status | running, succeeded, failed, or refused. Refused means a guard stopped the run before any network request, so no rate limit was spent |
Failed step | The step the run stopped at: dns_propagation and challenge are the common ones |
Duration | How long the run took. A normal issuance is under two minutes; several minutes usually means waiting on DNS |
Outcome | What happened to the certificate: staged and not served, activated, rolled back, or superseded by a later run |
How to
Find out why an issuance failed
- Find the run and select its row. The panel lists every step in order with its status.
- Read the failed step first, then the error message above the steps — together they say what stopped it.
- dns_propagation means the challenge record was written but the zone's own nameservers had not served it before the deadline. Re-run it; the second attempt usually succeeds.
- challenge means the certificate authority itself could not see the record. Check that the credential set is for the right zone.
- A refused run never reached the network, so its steps stop early and nothing was spent.
Read the raw traffic of a run
- Select the run, then click "View HTTP exchanges" at the bottom of the panel.
- Each line is one request, response or error, in order. Click one to see it in full.
- Secrets are removed when the exchange is written, so provider API keys and account keys are never in what you read.
- Only the most recent runs keep their journal; older ones say it has been pruned.
Gotchas
- Opening the exchange journal is recorded in the audit log, with your username and the run you opened. The rest of this page is an ordinary read and is not. The journal carries the raw traffic with the certificate authority and the DNS provider, so who reads it is worth knowing.
- A refused run is a success of a different kind: a guard stopped it before it could spend a rate limit. Let's Encrypt production allows five duplicate certificates per week and a failed attempt still counts, which is what the guards protect.
- Runs are pruned to the newest 200, and exchange journals to far fewer than that. A run whose journal is gone still shows all of its steps — those live in the database.
- A run that succeeded did not necessarily change what anyone sees. Issuing only stages a certificate; the Outcome column says whether it was ever activated.
- Duration is wall-clock, including the wait for DNS propagation. A long run is usually a slow zone, not a slow mipo.
API calls (3)
| Method | Path | Description |
|---|---|---|
| GET | /api/admin/ssl/issuance-runs | List the retained runs, newest first, each with its steps |
| GET | /api/admin/ssl/issuance-runs/:id | Read one run in full |
| GET | /api/admin/ssl/issuance-runs/:id/journal | Read the run's HTTP exchange index, or one exchange with ?seq=. Audited |
Related
- Certificate Profiles — Profiles are what start these runs, and show the latest one while it is running
- Certificates — A successful run leaves a certificate here, staged and waiting for an explicit activation
- SSL Status — The guided path that runs an issuance in the first place