Our product is distributed as a Mac installer package, and it is only distributed by us, not via the Mac App store. Thus, we have Developer ID certificates to sign both the actual software components within the installer package (Developer ID Application With KEXT - since we have a KEXT), and the installer package itself (Developer ID Installer). Our Developer ID certificates are set to expire next month, so we just created new ones which we are switching to. However, we also maintain an archive of older product installer packages on our website for users that need to run earlier releases for some reason (running on older OS, etc). It sounds like we may need to re-sign those older installers with the new Developer ID Installer cert, as the info here makes it sound like those installers will no longer run after the cert expires: https://developer.apple.com/support/certificates/ https://developer.apple.com/support/developer-id/
We’re trying to get a definitive answer on what we need to do, before it’s too late to do it, but some of the behavior of this certificate stuff is a little confusing (also, I did file a DTS request to get clarification on this, and ultimately they referred me to posting here on the dev forums).
Let’s assume all those older installers were signed with our old Developer ID Installer cert, and let’s say that cert expires on 6/1/22. My questions are:
1 ) I assume those installers will now cease to run after 6/1/22, correct? But any installs that ALREADY happened with those installers will continue to work after 6/1/22? This is what the links above suggest, but we specifically want to make sure this is the case for the KEXT, which in those older installers is signed with the older Developer ID Application With KEXT cert which also expires on 6/1/22.
[Related question, is there any reliable way to test this? I assume it would be more complicated than just setting the system date on a test machine past 6/1/22…]
2 ) Assuming it is the case that those old installers will no longer run after 6/1/22, do we just need to re-sign those installer packages with our new Developer ID Installer cert? OR, do we additionally need to re-NOTARIZE the installer packages (assuming they need to run on Catalina or later)?
[Logically it seems like we need to re-notarize after re-signing, and one test seemed to confirm that, while another similar test done by another developer had different results. I think what happened there was that the developer re-signed the installer with the new cert and saved that off (testA.pkg), then uploaded that installer to the notarization service and saved the result w/stapled ticket as a differently named file (testB.pkg). We figured that when running the “only re-signed" installer (testA.pkg), we would get the gatekeeper error, but we didn’t (also spctl reported it as passing notarization). I assume this is because the same binary installer had already been uploaded for notarization, and something in the OS was able to talk to the notary service and detect that this installer (testA.pkg) was the same as the one that had been uploaded for notarization, hence reporting it passed. I guess that is why the note here about testing notarization mentions testing with network connectivity disabled: https://developer.apple.com/forums/thread/130560]
3 ) Assuming we do need to re-notarize the old installers, do we need to do that before the cert that was used to sign the software components within them expires on 6/1/22? I.e. will the process of notarizing a .pkg look inside the package for executable code bundles, and then fail if a bundle was signed with a now-expired cert? For various reasons it would be difficult to break apart these old installers, re-sign their individual software components with the new Developer ID Application cert, and re-package them.
Thanks for any insight!
