Six core apps cannot publish a release: NEXTCLOUD_SIGNING_CERT is not a PEM certificate
Release fails on development for six core apps with an identical error from
the pre-flight credential check in the reusable release.yml:
##[error]The secret is set but does not contain a '-----BEGIN ... CERTIFICATE-----'
line, so phpseclib will not load it and signing will return false.
Only the certificate is rejected. The NEXTCLOUD_SIGNING_KEY check passes in
all six, so the key is at least a well-formed PEM.
Measured
Signing secrets were pasted into eight repos in one batch on 2026-08-20. Six
of those eight now fail; the other two, and all nine repos whose secrets predate
the batch, pass. portaliq and hermiq ran the same commit as the failures
and passed, so the check itself is sound.
| repo |
cert secret set |
latest Release (push, development) |
last published release |
| shillinq |
2026-08-20 |
failure |
2026-08-24 |
| launchpad |
2026-08-20 |
failure |
2026-08-24 |
| learniq |
2026-08-20 |
failure |
2026-08-24 |
| decidiq |
2026-08-20 |
failure |
2026-08-24 |
| buildiq |
2026-08-20 |
failure |
2026-08-24 |
| keepiq |
2026-08-20 |
failure |
2026-08-24 |
| portaliq |
2026-08-20 |
success |
2026-08-25 |
| hermiq |
2026-08-20 |
success |
2026-08-25 |
| openregister |
2026-08-10 |
success |
2026-08-25 |
| opencatalogi / thematiq / dossiq / pipelinq / filinq / integriq / stackiq / larpinq |
2024–2026, older |
success |
— |
The six have published nothing since 2026-08-24; every healthy repo has.
Two different problems wearing one error
(a) shillinq, launchpad — a bad paste. A valid certificate exists for
each, with a CN matching the app id, in the public
nextcloud/app-certificate-requests repo:
shillinq.crt — CN shillinq, valid to 2036-09-09launchpad.crt — CN launchpad, valid to 2036-09-29
The cert is public — only the key is secret. Re-pasting the certificate
whole (BEGIN/END lines included) is very likely the whole fix, provided the
stored private key is the one this certificate was issued against. That last
part cannot be checked from outside; it falls out of the next run.
(b) learniq, decidiq, buildiq, keepiq — no certificate exists for the
app id they now ship. All four already carry the NEW id in
appinfo/info.xml on development:
| repo |
<id> on development |
id landed |
only certificate available |
| learniq |
learniq |
2026-08-19 |
scholiq.crt (CN scholiq) |
| decidiq |
decidiq |
2026-08-24 |
decidesk.crt (CN decidesk) |
| buildiq |
buildiq |
2026-08-24 |
openbuild.crt (CN openbuild) |
| keepiq |
keepiq |
2026-08-24 |
doriath.crt (CN doriath) |
The id-change dates line up exactly with the last release that got out.
occ integrity:sign-app binds the certificate to the app id, so an old-name
certificate is expected to be rejected for a renamed app even once the PEM is
well-formed — predicted, not yet observed: the current failure is the PEM
pre-flight, which is upstream of signing, so nothing has reached that check yet.
If it holds, these four need a fresh keypair and a new CSR approved by Nextcloud
via nextcloud/app-certificate-requests — an external, multi-day process — and
that is a renaming-procedure gap, not a paste error. It belongs in
docs.conduction.nl/hydra/operations/renaming-an-app as a required step, and in
the app-id channel inventory.
Why this was invisible
Before the pre-flight check landed, an empty/malformed certificate surfaced four
steps later inside Nextcloud as base64_encode(): Argument #1 ($string) must be of type string, bool given — which names nothing actionable. The check is doing
its job; it turned a silent misfire into a precise error. Worth noting that these
apps did publish on 2026-08-24 with the same broken secret, so it is worth
confirming what those packages actually shipped with.
Not fixable from CI
Both halves need a human: (a) needs the certificate re-pasted into repository
secrets, (b) needs certificates that do not exist yet.
Six core apps cannot publish a release:
NEXTCLOUD_SIGNING_CERTis not a PEM certificateReleasefails ondevelopmentfor six core apps with an identical error fromthe pre-flight credential check in the reusable
release.yml:Only the certificate is rejected. The
NEXTCLOUD_SIGNING_KEYcheck passes inall six, so the key is at least a well-formed PEM.
Measured
Signing secrets were pasted into eight repos in one batch on 2026-08-20. Six
of those eight now fail; the other two, and all nine repos whose secrets predate
the batch, pass.
portaliqandhermiqran the same commit as the failuresand passed, so the check itself is sound.
The six have published nothing since 2026-08-24; every healthy repo has.
Two different problems wearing one error
(a)
shillinq,launchpad— a bad paste. A valid certificate exists foreach, with a CN matching the app id, in the public
nextcloud/app-certificate-requestsrepo:shillinq.crt— CNshillinq, valid to 2036-09-09launchpad.crt— CNlaunchpad, valid to 2036-09-29The cert is public — only the key is secret. Re-pasting the certificate
whole (BEGIN/END lines included) is very likely the whole fix, provided the
stored private key is the one this certificate was issued against. That last
part cannot be checked from outside; it falls out of the next run.
(b)
learniq,decidiq,buildiq,keepiq— no certificate exists for theapp id they now ship. All four already carry the NEW id in
appinfo/info.xmlondevelopment:<id>on developmentlearniqscholiq.crt(CNscholiq)decidiqdecidesk.crt(CNdecidesk)buildiqopenbuild.crt(CNopenbuild)keepiqdoriath.crt(CNdoriath)The id-change dates line up exactly with the last release that got out.
occ integrity:sign-appbinds the certificate to the app id, so an old-namecertificate is expected to be rejected for a renamed app even once the PEM is
well-formed — predicted, not yet observed: the current failure is the PEM
pre-flight, which is upstream of signing, so nothing has reached that check yet.
If it holds, these four need a fresh keypair and a new CSR approved by Nextcloud
via
nextcloud/app-certificate-requests— an external, multi-day process — andthat is a renaming-procedure gap, not a paste error. It belongs in
docs.conduction.nl/hydra/operations/renaming-an-app as a required step, and in
the app-id channel inventory.
Why this was invisible
Before the pre-flight check landed, an empty/malformed certificate surfaced four
steps later inside Nextcloud as
base64_encode(): Argument #1 ($string) must be of type string, bool given— which names nothing actionable. The check is doingits job; it turned a silent misfire into a precise error. Worth noting that these
apps did publish on 2026-08-24 with the same broken secret, so it is worth
confirming what those packages actually shipped with.
Not fixable from CI
Both halves need a human: (a) needs the certificate re-pasted into repository
secrets, (b) needs certificates that do not exist yet.