spctl throws "internal error in Code Signing subsystem" after replacing app package

I have a new code signing problem with my app under El Capitan that I can't see any mention of on the internet.


We have two versions of our app, one using legacy Java 6 and a new one using Java 8. The two app packages are signed and cleared by gatekeeper in isolation but when you drag the new one in to the Applications folder and choose to replace the old one you can no longer run the app due to Getekeeper.


codesign verifies that the signature is fine but spctl produces the following output for all commands:


Geneious.app/: internal error in Code Signing subsystem


If you simply rename the app package, gatekeeper lets you run it. If you rename it back, the problem comes back.


If you restart the machine, gatekeeper no longer has a problem.


My guess is that Gatekeeper is caching some information about the app then crashing when it sees an app of the same name but a completely different internal structure? Has anyone else hit this? It doesn't happen on Yosemite.


If you would like to reproduce this yourself, you can do so by downloading both the legacy and non-legacy versions of our app, Geneious, and replacing one with the after running it once: http://www.geneious.com/download-beta

I'm also experiencing the same error from spctl ("internal error in Code Signing subsystem") with the only results being the original source code with the error text and this post, though my environment differs.


I'm running Yosemite 10.10.5 and though codesign runs just fine and reports good results with --display and --verify, inspecting it with spctl is a no go. Trying to run the app will result in the typical "This app is damaged and can't be opened. You should move it to the Trash." error message. Restarting has no effect.


Edit: Apologies, didn't see that this was specific to a 10.11 category.

spctl throws "internal error in Code Signing subsystem" after replacing app package
 
 
Q