To add a little more information on this one:
1) If you see "The signing certificate is not from the expected issuer", it means that the certificate you're using for code-signing has got an "Issuer" that isn't one of the Apple intermediate certificates that we expect. Originally (in AIR 32 and before, and in early 33.x SDKs) there was only one intermediate certificate, with OU=Apple Worldwide Developer Relations
as per the original post here. In 33.1.1.345 we added the new intermediate certificate that Apple started using as the issuer, which has OU=G3
. So: you should no longer see this message in build 33.1.1.345 or later. If you do see this message then please let us know: we've just added some additional debug output into the ADT tool so that we can see what's actually being used which should help us understand why there may be a problem.
2) Once we had that part done, we then found that Apple had updated their requirements for the code signature format version. The AIR SDK had been adding the code signing manually - literally, creating the code signature blocks and injecting these into the MachO binary file - and this was done with code signature 2.2.0 (20200) format. So we then updated this to 2.4.0 (20400) although there's already 2.5.0 (20500) being used if you run codesign on a recent macOS machine. So.. we may need to do the updates again...
But rather than us maintain this code-signing functionality - particularly because it relies upon internal Java classes that aren't actually part of the Java spec and may be disappearing - I think it makes more sense for the code signatures to be added via native tools. On macOS you already have scripts that can be used to do the manual code-signing, and we're looking at using that sort of mechanism internally - i.e. instead of our Java code manually adding a code signature, it will just call the codesign
tool with the appropriate arguments.
Windows is then a problem. There are mentions on this thread of various tools that can be used for code-signing on Windows. It make be that we pick a tool and use it (ideally this would be a tool that we could then just distribute within the SDK so that it becomes seamless for developers to use) and I have a slight preference for it being open source so that anyone could then maintain it.. although, suggestions welcome if you have a tool that you currently use and think would be suitable!
thanks