[david-crespo]

Closes #11272

Deleting a silo's only certificate leaves Nexus unable to serve TLS for the silo's domain, so nobody in the silo can reach the API to upload a replacement. #11470 mitigates this by making it so fleet admins can fix this from a different silo, but it can still be a problem if it happens to the fleet admins' own silo.

This PR makes certificate_delete error out unless another certificate exists for the same silo. The check is an EXISTS subquery in the same UPDATE that sets time_deleted, avoiding a TOCTOU race that would let two concurrent deletes on the last two certs both succeed. (#11109 does the same thing for unassigning a service's last IP pool.)

The error is a 400. 409 could make sense, but 400 is the convention for refusing to delete; it's what we do for non-empty projects and silos, VPCs with subnets, IP pools with ranges, attached floating IPs and disks, etc.

[smklein]

as an FYI, you may also be interested in #11238, which overlaps here

[david-crespo]

Saw it — am I right that they're complementary and don't conflict?

[smklein]

Saw it — am I right that they're complementary and don't conflict?

I believe that's the case! If anything I might be able to make the guarantees in the diagnosis engine a little stronger with this PR

[david-crespo]

@claude review

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[sudomateo]

I tested this locally using the API, CLI, and Terraform and it works as expected. I expect most Terraform users will create the silo using oxide_system_silo, which creates the first certificate. Then, they would use oxide_system_certificate to rotate the certificate which would put them at 2 total certificates. Then, future rotatations would delete/create the 2nd certificate, leaving the 1st always there as a fallback. This is all to say that I don't see the Terraform users hitting this "delete last certificate" error and I confirmed this all works as expected, so approved!