The console will always sign local STFS (CON) regardless, where it's failing is when the volume is validated. When STFS is signed there's a certificate (which is signed as well) copied from the KV.bin to the header as well; this certificate holds information about the specific console is was signed on such as the manufacturing date, product line, console type (ie: retail/devkit), but more importantly the console ID.
In the NAND (flash) there's a file called crl.bin, which is an abbreviation for Console Revocation List, this file contains a (very large) list of revoked console IDs. When validating, the dash looks at the stored certificate for validity, if that passes then it checks through the console information stored within that certificate but again, more importantly the console ID. The dash will do a look up in the crl.bin for the console ID stored in the certificate, if it's contained within that list then validation fails thus resulting as files signed on that revoked console showing as corrupt on any console that has a crl.bin that holds that specific console ID - Also, there may be a flag in the secdata.bin for console/key revoksion (not a real word but works in this context) but I couldn't say
Work around:
1) FTP to JTAG
2) Go to /Flash/ folder
3) Find crl.bin and delete or replace with a 0 byte file (which ever feels safer for you)