Revoke cert incorrect

[vsc55]

Hi,

I've detected the following malfunction.

I believe it's a web UI issue, and it occurs in both version v25.12 and v26.03.

If you go to the ACME > Certificates section, access any certificate, and click Revoke, everything seems to have gone correctly. However, when you return to the certificate list, instead of the one you selected being revoked, the certificate with a higher ID appears as revoked.

For example, if you revoke certificate ID 70, the one that appears revoked is 71.

If you try to revoke 70 again, the system generates an internal error with the following message in the console:
Note that the SerialNumber that appears in the error is the SerialNumber of the certificate we want to revoke, so it seems the revocation is being applied to the correct certificate.

gui-1             | 2026/03/14 08:47:54 POST /certificates/70
boulder-1         | 2026-03-14T08:47:54.744068+00:00Z boulder-ra[377]: 6 boulder-ra 8BZMow [AUDIT] Revocation request: JSON={"ID":"AAAAAAAA","SerialNumber":"XXXXXXXXX","reason":4,"Method":"admin","CRLShard":0,"AdminName":"root","Error":"no certificate with serial XXXXXXXXX and status other than revoked"}
bmysql-1          | 2026-03-14  8:47:54 220 [Warning] Aborted connection 220 to db: 'boulder_sa_integration' user: 'revoker' host: '10.77.77.77' (Got an error reading communication packets)
gui-1             | 2026/03/14 08:47:54 ERROR: Message from server: '2026-03-14T08:47:54.711727+00:00Z admin[469]: 6 admin uuBEZA No debug listen address specified
gui-1             | 2026-03-14T08:47:54.711771+00:00Z admin[469]: 6 admin 4ysLIw Versions: admin=(v0.20251216.0 +f3e973a9 Sat Dec 27 16:13:24 UTC 2025) Golang=(go1.25.5) BuildHost=(labca-v25.12)
gui-1             | 2026-03-14T08:47:54.717284+00:00Z admin[469]: 6 admin 7oNmiA [AUDIT] admin tool executing with the following arguments: "bin/admin -config labca/config/admin.json revoke-cert -serial XXXXXXXXX -reason superseded -dry-run=false"
gui-1             | 2026-03-14T08:47:54.717308+00:00Z admin[469]: 6 admin 6GJd3Q Found 1 certificates to revoke
gui-1             | 2026-03-14T08:47:54.744816+00:00Z admin[469]: 3 admin xcREug [AUDIT] not revoking "XXXXXXXXX": already revoked
gui-1             | 2026-03-14T08:47:54.744859+00:00Z admin[469]: 3 admin glXXEA [AUDIT] executing subcommand: revoking serials: encountered 1 errors while revoking certs; see logs above for details
gui-1             | ERROR! On line 166 in commander script
gui-1             | '
gui-1             | 2026/03/14 08:47:54 errorHandler: err=2026-03-14T08:47:54.711727+00:00Z admin[469]: 6 admin uuBEZA No debug listen address specified
gui-1             | 2026-03-14T08:47:54.711771+00:00Z admin[469]: 6 admin 4ysLIw Versions: admin=(v0.20251216.0 +f3e973a9 Sat Dec 27 16:13:24 UTC 2025) Golang=(go1.25.5) BuildHost=(labca-v25.12)
gui-1             | 2026-03-14T08:47:54.717284+00:00Z admin[469]: 6 admin 7oNmiA [AUDIT] admin tool executing with the following arguments: "bin/admin -config labca/config/admin.json revoke-cert -serial XXXXXXXXX -reason superseded -dry-run=false"
gui-1             | 2026-03-14T08:47:54.717308+00:00Z admin[469]: 6 admin 6GJd3Q Found 1 certificates to revoke
gui-1             | 2026-03-14T08:47:54.744816+00:00Z admin[469]: 3 admin xcREug [AUDIT] not revoking "XXXXXXXXX": already revoked
gui-1             | 2026-03-14T08:47:54.744859+00:00Z admin[469]: 3 admin glXXEA [AUDIT] executing subcommand: revoking serials: encountered 1 errors while revoking certs; see logs above for details
gui-1             | ERROR! On line 166 in commander script
gui-1             |
gui-1             | main._hostCommand({0x16b7348, 0xc0000fca50}, 0xc000f212c0, {0x112647e, 0xb}, {0xc0006e78c0, 0x2, 0xc000d1cc60?})
gui-1             |     /go/src/labca/main.go:2122 +0x5e8
gui-1             | main.certRevokeHandler({0x16b7348, 0xc0000fca50}, 0xc000f212c0)
nginx-1           | ::ffff:192.168.0.1 - - [14/Mar/2026:08:47:54 +0000] "POST /admin/certificates/70 HTTP/1.1" 500 8774 "https://labca.domain.lan/admin/certificates/70" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0" "-"
gui-1             |     /go/src/labca/main.go:2890 +0x171
gui-1             | net/http.HandlerFunc.ServeHTTP(0xfbe600?, {0x16b7348?, 0xc0000fca50?}, 0xc0000fca50?)
gui-1             |     /usr/local/go/src/net/http/server.go:2322 +0x29
gui-1             | main.authorized.func1({0x16b7348, 0xc0000fca50}, 0xc000f212c0)
gui-1             |     /go/src/labca/main.go:3141 +0x32e
gui-1             | net/http.HandlerFunc.ServeHTTP(0xc000f21180?, {0x16b7348?, 0xc0000fca50?}, 0x28dbeabf8532?)
gui-1             |     /usr/local/go/src/net/http/server.go:2322 +0x29
gui-1             | github.com/gorilla/mux.(*Router).ServeHTTP(0xc0000de540, {0x16b7348, 0xc0000fca50}, 0xc000f20f00)
gui-1             |     /root/go/pkg/mod/github.com/gorilla/mux@v1.8.1/mux.go:212 +0x1e2
gui-1             | net/http.serverHandler.ServeHTTP({0x16b2bc0?}, {0x16b7348?, 0xc0000fca50?}, 0x6?)
gui-1             |     /usr/local/go/src/net/http/server.go:3340 +0x8e
gui-1             | net/http.(*conn).serve(0xc000fb4900, {0x16b9800, 0xc000d90f30})
gui-1             |     /usr/local/go/src/net/http/server.go:2109 +0x665
gui-1             | created by net/http.(*Server).Serve in goroutine 1
gui-1             |     /usr/local/go/src/net/http/server.go:3493 +0x485

Best Regards.

[hakwerk]

I have not been able to reproduce this issue, and looking at the queries I also cannot understand how this could ever happen

[vsc55]

Hi @hakwerk,

I believe it's being applied correctly to the correct certificate.
Is this "status" column retrieved from the same table or from a different one?
It seems like a bug in how the table is displayed in the web UI.

[vsc55]

Hi @hakwerk.

I have tried again with another registry and the same thing happens, as you can see the correct certificate is revoked, id (69) and serial is the correct one, but then in the list of certificates the one that appears revoked is the certificate with id 70.

gui-1             | 2026/03/20 16:37:16 POST /certificates/69
boulder-1         | 2026-03-20T16:37:16.612925+00:00Z boulder-ra[337]: 6 boulder-ra WXqoMw [AUDIT] Revocation request JSON={"ID":"IjiQ4r5aXxnbUSZiG-6M63Z3MYwEiIcWxAOB73qDL-A","SerialNumber":"6efffc8f3999a9be0846123c2c3d65a620b8","reason":4,"Method":"admin","CRLShard":0,"AdminName":"root"}
gui-1             | 2026/03/20 16:37:16 Message from server: '2026-03-20T16:37:16.546143+00:00Z admin[414]: 6 admin uuBEZA No debug listen address specified
nginx-1           | ::ffff:192.168.0.1 - - [20/Mar/2026:16:37:16 +0000] "POST /admin/certificates/69 HTTP/1.1" 200 0 "https://labca.domain.local/admin/certificates/69" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0" "-"
gui-1             | 2026-03-20T16:37:16.546180+00:00Z admin[414]: 6 admin Tp4kpA [AUDIT] Process starting JSON={"Command":"admin","BuildID":"v0.20260309.0 +5c3a8315","BuildTime":"Fri Mar 20 11:39:26 UTC 2026","GoVersion":"go1.25.8","BuildHost":"labca-v26.03.1"}
gui-1             | 2026-03-20T16:37:16.549537+00:00Z admin[414]: 6 admin D4PWLA [AUDIT] admin tool beginning execution JSON={"cmd":"bin/admin -config labca/config/admin.json revoke-cert -serial 6efffc8f3999a9be0846123c2c3d65a620b8 -reason superseded -dry-run=false"}
gui-1             | 2026-03-20T16:37:16.549559+00:00Z admin[414]: 6 admin 6GJd3Q Found 1 certificates to revoke
gui-1             | 2026-03-20T16:37:16.614061+00:00Z admin[414]: 6 admin 5Zl4jA [AUDIT] admin tool completed successfully JSON={"cmd":"bin/admin -config labca/config/admin.json revoke-cert -serial 6efffc8f3999a9be0846123c2c3d65a620b8 -reason superseded -dry-run=false"}
gui-1             | 2026-03-20T16:37:16.614087+00:00Z admin[414]: 6 admin dMeJyA [AUDIT] Process exiting normally JSON={"Command":"admin","BuildID":"v0.20260309.0 +5c3a8315","BuildTime":"Fri Mar 20 11:39:26 UTC 2026","GoVersion":"go1.25.8","BuildHost":"labca-v26.03.1"}'
gui-1             | 2026/03/20 16:37:16 GET /certificates/69
nginx-1           | ::ffff:192.168.0.1 - - [20/Mar/2026:16:37:16 +0000] "GET /admin/certificates/69 HTTP/1.1" 200 13187 "https://labca.domain.local/admin/certificates" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0" "-"

I've been reviewing the tables and it seems there's a discrepancy between the certificates and certificateStatus tables; as you can see, the ID is not the same. It is also seen that there is a record of difference between the two.

select * from revokedCertificates;
+----+-------------------+--------------------------------------+---------------------+----------+---------------------+---------------+
| id | issuerID          | serial                               | notAfterHour        | shardIdx | revokedDate         | revokedReason |
+----+-------------------+--------------------------------------+---------------------+----------+---------------------+---------------+
|  7 | 60359405690188196 | 6e6806b8e82a604a3e1506f9088f12e507f9 | 2026-05-21 17:00:00 |        1 | 2026-03-13 20:22:00 |             4 |
|  8 | 60359405690188196 | 6efffc8f3999a9be0846123c2c3d65a620b8 | 2026-05-21 16:00:00 |        1 | 2026-03-20 16:37:16 |             4 |
+----+-------------------+--------------------------------------+---------------------+----------+---------------------+---------------+

select id, serial, subscriberApproved, status, revokedReason, revokedDate from certificateStatus;
+----+--------------------------------------+--------------------+---------+---------------+---------------------+
| id | serial                               | subscriberApproved | status  | revokedReason | revokedDate         |
+----+--------------------------------------+--------------------+---------+---------------+---------------------
| 70 | 6efffc8f3999a9be0846123c2c3d65a620b8 |                  0 | revoked |             4 | 2026-03-20 16:37:16 |
| 71 | 6e6806b8e82a604a3e1506f9088f12e507f9 |                  0 | revoked |             4 | 2026-03-13 20:22:00 |
+----+--------------------------------------+--------------------+---------+---------------+---------------------+
73 rows in set (0.000 sec)

select id, registrationID, serial, issued, expires from certificates;
+----+----------------+--------------------------------------+---------------------+---------------------+
| id | registrationID | serial                               | issued              | expires             |
+----+----------------+--------------------------------------+---------------------+---------------------+
| 69 |              4 | 6efffc8f3999a9be0846123c2c3d65a620b8 | 2026-02-20 16:45:33 | 2026-05-21 15:47:00 |
| 70 |              4 | 6e6806b8e82a604a3e1506f9088f12e507f9 | 2026-02-20 17:55:18 | 2026-05-21 16:56:47 |
+----+----------------+--------------------------------------+---------------------+---------------------+
72 rows in set (0.001 sec)

[vsc55]

I've noticed that starting with ID 22 in the certificateStatus table, there's a record that doesn't exist in the certificates table, which is why there's a discrepancy.
From what I've seen, the serial number at position 22, which is missing from the certificates table, exists in other tables like keyHastToSerial, precertificates, and serials.

[vsc55]

Root Cause Analysis

The issue is caused by an incorrect join between the certificates and certificateStatus tables in the LabCA UI.

Current implementation (in gui/acme.go) uses:

JOIN certificateStatus cs ON cs.id = c.id

This assumes both tables share the same id values, which is not guaranteed.

In Boulder, both tables (certificates and certificateStatus) have independent auto-increment primary keys. The correct relationship between them is the serial field, not the id.

---

Observed Behavior

• Revoking certificate ID 70 correctly revokes the intended certificate (confirmed via Boulder logs using serial)
• The UI incorrectly shows ID 71 as revoked
• This indicates a mismatch between the displayed row and the actual certificate status

---

Database Evidence

I verified this directly in the database with:

SELECT c.id AS cert_id, cs.id AS status_id, c.serial
FROM certificates c
JOIN certificateStatus cs ON cs.serial = c.serial
WHERE c.id <> cs.id
LIMIT 20;

This query returns rows, proving that:

• certificates.id ≠ certificateStatus.id
• Even when both rows refer to the same certificate (same serial)

Therefore, joining by id produces incorrect associations.

---

Why This Happens

The UI assumes:

certificates.id == certificateStatus.id

But in reality:

• Both tables have independent auto-increment sequences
• Insert order can differ
• IDs will eventually diverge

This leads to:

• Wrong status being attached to a certificate
• Off-by-one (or worse) mismatches in the UI

---

Why Revocation Still Works

Revocation uses the certificate serial, not the id.

So:

• Backend behavior is correct
• Only the UI representation is wrong

---

Proposed Fix

All joins between certificates and certificateStatus must use serial instead of id.

Replace:

JOIN certificateStatus cs ON cs.id = c.id

With:

JOIN certificateStatus cs ON cs.serial = c.serial

---

Affected Code

Located in gui/acme.go:

• GetCertificates()
• GetCertificate()

Both functions currently use the incorrect join.

---

Expected Result After Fix

• UI will display the correct certificate status
• Revoked certificates will match Boulder logs
• No more ID mismatch issues

---

Additional Note

The current implementation relies on synchronized auto-increment IDs across two independent tables, which is inherently unsafe and will break as soon as insert operations diverge.

This is now confirmed with real database evidence, not just observed behavior.

[vsc55]

Proposed patch attached.
#227