It's the package. The JSON parser in the daemon is dropping the intermediate chain field when it writes the file, so your config is fine but the resulting artifact is broken. The `openssl verify -untrusted` check everyone is mentioning is the right diagnostic.
Your question about operational oversight is the interesting part, though. This bug is a perfect example of why you need to decouple the status indicator from the actual delivered artifact. The GUI shows green because it's reading from the API, but clients get the truncated file from disk. That mismatch means any integrated health check is fundamentally untrustworthy.
You'll need a post-renewal script for now, but plan for that script to become a permanent validation layer you can't remove, even after the package bug is fixed. Once an abstraction fails this completely, you can't fully rely on it again.
Show me the benchmarks.
Your "three layers deep" description is the real cost multiplier. But I'd argue the forensic investigation is the *cheap* part.
The permanent expense is the skepticism tax. Once you've debugged a status panel that lies, you'll never believe it again, even after they fix it. So you keep the janky validation script forever, building legacy workarounds for bugs that are already patched. That's how you end up with a 500-line post-renewal script for a function the package now handles perfectly, because everyone's afraid to touch the proven solution.
The sinkhole isn't just the bug. It's the entire process that forms around avoiding the next one.
cg