I regularly see folks run into problems with their Developer ID signing identities. Historically I pointed them to my posts on this thread, but I’ve decided to collect these ideas together in one place. If you have questions or comments, start a new thread here on DevForums and tag it with Developer ID so that I see it. IMPORTANT Nothing I write here on DevForums is considered official documentation. It’s just my personal ramblings based on hard-won experience. There is a bunch of official documentation that covers the topics I touch on here, including: Xcode documentation Xcode Help Developer Account Help Developer > Support > Certificates For a lot more information about code signing, see the Code Signing Resources pinned post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" The Care and Feeding of Developer ID Most Apple signing assets are replaceable. For example, if you accidentally lose access to your Apple Development signing identity, it’s a minor inconvenience. Just use the Developer website to revoke your previous certificate and create a replacement. Or have Xcode do that for you. IMPORTANT If you don’t understand the difference between a certificate and a digital identity, and hence signing identity, read Certificate Signing Requests Explained before reading this post. Some signing assets are precious. Losing access to such assets has significant consequences. Foremost amongst those are Developer ID signing identities. These allow you to sign Mac products that ship independently. Anyone with access to your Developer ID signing identity can sign code as you. This has a number of consequences, both for you and for your relationship with Apple. Identify a Developer ID Signing Identity A Developer ID signing identity consists of two parts: the certificate and the private key. There are two different flavours, identifiable by the subject name in the certificate: Developer ID Application — This is named Developer ID Application: TTT, where TTT identifies your team. Use this to sign code and disk images. Developer ID Installer — This is named Developer ID Installer: TTT, where TTT identifies your team. Use this to sign installer packages. Note If you do KEXT development, there’s a third flavour, namely a KEXT-enabled Developer ID Application signing identity. For more details, see KEXT Code Signing Problems. This post focuses on traditional signing identities, where you manage the private key. Xcode Cloud introduced cloud signing, where signing identities are “stored securely in the cloud”. These identities have the Managed suffix in Certificates, Identifiers, and Profiles. For example, Developer ID Application Managed is the cloud signing equivalent of Developer ID Application. To learn more about cloud signing, watch WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing. To identify these certificates ‘in the wild’, see Identifying a Cloud Managed Signing Certificate. Limit Access to Developer ID Anyone with your Developer ID signing identity can sign code as you. Given that, be careful to limit access to these signing identities. This is true both for large organisations and small developers. In a large organisation, ensure that only folks authorised to ship code on behalf of your organisation have access to your Developer ID signing identities. Most organisations have some sort of release process that they use to build, test, and authorise a release. This often involves a continuous integration (CI) system. Restrict CI access to only those folks involved in the release process. Even if you’re a small developer with no formal release process, you can still take steps to restrict access to Developer ID signing identities. See Don’t Leak Your Private Key, below. In all cases, don’t use your Developer ID signing identities for day-to-day development. That’s what Apple Development signing identities are for. Create Developer ID Signing Identities as the Account Holder Because Developer ID signing identities are precious, the Developer website will only let the Account Holder create them. For instructions on how to do this, see Developer Account Help > Create certificates > Create Developer ID certificates. For more information about programme roles, see Developer > Support > Program Roles. IMPORTANT In an Organization team it’s common for the Account Holder to be non-technical. They may need help getting this done. For hints and tips on how to avoid problems while doing this, see Don’t Lose Your Private Key and Don’t Leak Your Private Key, both below. Limit the Number of Developer ID Signing Identities You Create Don’t create Developer ID signing identities unnecessarily. Most folks only need to create one. Well, one Developer ID Application and maybe one Developer ID Installer. A large organisation might need more, perhaps one for each sub-unit, but that’s it. There are two reasons why this is important: The more you have, the more likely it is for one to get into the wrong hands. Remember that anyone with your Developer ID signing identity can sign code as you. The Developer website limits you to 5 Developer ID certificates. Note I can never remember where this limit is actually documented, so here’s the exact quote from this page: You can create up to five Developer ID Application certificates and up to five Developer ID Installer certificates using either your developer account or Xcode. Don’t Lose Your Private Key There are two standard processes for creating a Developer ID signing identity: Developer website — See Developer Account Help > Create certificates > Create Developer ID certificates. Xcode — See Xcode Help > Maintaining signing assets > Manage signing certificates. Both processes implicitly create a private key in your login keychain. This makes it easy to lose your private key. For example: If you do this on one Mac and then get a new Mac, you might forget to move the private key to the new Mac. If you’re helping your Organization team’s Account Holder to create a Developer ID signing identity, you might forget to export the private key from their login keychain. It also makes it easy to accidentally leave a copy of the private key on a machine that doesn’t need it; see Don’t Leak Your Private Key, below, for specific advice on that front. Every time you create a Developer ID signing identity, it’s a good idea to make an independent backup of it. For advice on how to do that, see Back Up Your Signing Identities, below. That technique is also useful if you need to copy the signing identity to a continuous integration system. If you think you’ve lost the private key for a Developer ID signing identity, do a proper search for it. Finding it will save you a bunch of grief. You might be able to find it on your old Mac, in a backup, in a backup for your old Mac, and so on. For instructions on how to extract your private key from a general backup, see Recover a Signing Identity from a Mac Backup. If you’re absolutely sure that you previous private key is lost, use the Developer website to create a replacement signing identity. If the Developer website won’t let you create any more because you’ve hit the limit discussed above, talk to Developer Programs Support. Go to Apple > Developer > Contact Us and follow the path Development and Technical > Certificates, Identifiers, and Provisioning Profiles. Don’t Leak Your Private Key Anyone with your Developer ID signing identity can sign code as you. Thus, it’s important to take steps to prevent its private key from leaking. A critical first step is to limit access to your Developer ID signing identities. For advice on that front, see Limit Access to Developer ID, above. In an Organization team, only the Account Holder can create Developer ID signing identities. When they do this, a copy of the identity’s private key will most likely end up in their login keychain. Once you’ve exported the signing identity, and confirmed that everything is working, make sure to delete that copy of the private key. Some organisations have specific rules for managing Developer ID signing identities. For example, an organisation might require that the private key be stored in a hardware token, which prevents it from being exported. Setting that up is a bit tricky, but it offers important security benefits. Even without a hardware token, there are steps you can take to protect your Developer ID signing identity. For example, you might put it in a separate keychain, one with a different password and locking policy than your login keychain. That way signing code for distribution will prompt you to unlock the keychain, which reminds you that this is a significant event and ensures that you don’t do it accidentally. If you believe that your private key has been compromised, follow the instructions in the Compromised Certificates section of Developer > Support > Certificates. Back Up Your Signing Identities Given that Developer ID signing identities are precious, consider making an independent backup of them. To back up a signing identity to a PKCS#12 (.p12) file: Launch Keychain Access. At the top, select My Certificates. On the left, select the keychain you use for signing identities. For most folks this is the login keychain. Select the identity. Choose File > Export Items. In the file dialog, select Personal Information Exchange (.p12) in the File Format popup. Enter a name, navigate to your preferred location, and click Save. You might be prompted to enter the keychain password. If so, do that and click OK. You will be prompted to enter a password to protect the identity. Use a strong password and save this securely in a password manager, corporate password store, on a piece of paper in a safe, or whatever. You might be prompted to enter the keychain password again. If so, do that and click Allow. The end result is a .p12 file holding your signing identity. Save that file in a secure location, and make sure that you have a way to connect it to the password you saved in step 9. Remember to backup all your Developer ID signing identities, including the Developer ID Installer one if you created it. To restore a signing identity from a backup: Launch Keychain Access. Choose File > Import Items. In the open sheet, click Show Options. Use the Destination Keychain popup to select the target keychain. Navigate to and select the .p12 file, and then click Open. Enter the .p12 file’s password and click OK. If prompted, enter the destination keychain password and click OK. Alternatively, Xcode has a feature to export and import your developer account, including your Developer ID signing identities. Do this using the action menu in Xcode > Settings > Accounts. For the details, see Xcode Help > Maintaining signing assets > Export signing certificates and provisioning profiles. Recover a Signing Identity from a Mac Backup If you didn’t independently backup your Developer ID signing identity, you may still be able to recover it from a general backup of your Mac. To start, work out roughly when you created your Developer ID signing identity: Download your Developer ID certificate from the Developer website. In the Finder, Quick Look it. The Not Valid Before field is the date you’re looking for. Now it’s time to look in your backups. The exact details depend on the backup software you’re using, but the basic process runs something like this: Look for a backup taken shortly after the date you determined above. In that backup, look for the file ~/Library/Keychains/login.keychain. Recover that to a convenient location, like your desktop. Don’t put it in ~/Library/Keychains because that’ll just confuse things. Rename it to something unique, like login-YYYY-MM-DD.keychain, where YYYY-MM-DD is the date of the backup. In Keychain Access, choose File > Add Keychain and, in the resulting standard file panel, choose that .keychain file. On the left, select login-YYYY-MM-DD. Chose File > Unlock Keychain “login-YYYY-MM-DD“. In the resulting password dialog, enter your login password at the date of the backup. At the top, select My Certificates. Look through the list of digital identities to find the Developer ID identity you want. If you don’t see the one you’re looking for, see Further Recovery Tips below. Export it using the process described at the start of Back Up Your Signing Identities. Once you’re done, remove the keychain from Keychain Access: On the left, select the login-YYYY-MM-DD keychain. Choose File > Delete Keychain “login-YYYY-MM-DD”. In the confirmation alert, click Remove Reference. The login-YYYY-MM-DD.keychain is now just a file. You can trash it, keep it, whatever, at your discretion. This process creates a .p12 file. To work with that, import it into your keychain using the process described at the end of Back Up Your Signing Identities. IMPORTANT Keep that .p12 file as your own independent backup of your signing identity. Further Recovery Tips If, in the previous section, you can’t find the Developer ID identity you want, there are a few things you might do: Look in a different backup. If your account has more than one keychain, look in your other keychains. If you have more than one login account, look at the keychains for your other accounts. If you have more than one Mac, look at the backups for your other Macs. The login-YYYY-MM-DD keychain might have the private key but not the certificate. Add your Developer ID certificate to that keychain to see if it pairs with a private key. Revision History 2023-10-05 Added the Recover a Signing Identity from a Mac Backup and Further Recovery Tips sections. 2023-06-23 Added a link to Identifying a Cloud Managed Signing Certificate. 2023-06-21 First posted.

Hello, I have tried both automatic signing and manual signing, and still when I submit I get an error message that says "Provisioning profile failed qualification" and "Profile doesn't include the selected signing certificate.". Everything had been working fine, but I think it may have broken with an Xcode update - not sure. Please let me know what to look for. I appreciate any help you can give me.

Urgent Assistance Needed: Issue Logging into Apple Developer Enterprise Account via Visual Studio 2022 - "Authentication service is unavailable." Dear Apple Support Team, I am encountering an issue while attempting to log into my Apple Developer Enterprise account through Visual Studio 2022. The process consistently fails with the error message: "Authentication service is unavailable." Here are the steps I followed: Open Visual Studio 2022. Navigate to Tools -> Options -> Apple Developer Account -> Add Account -> Select Enterprise Account. Attempt to log in using my Apple Developer ID and password. Despite multiple attempts, I continue to face the error: "Authentication service is unavailable." This issue occurs on both Windows and Mac environments, with the same results. However, I am able to log into my Apple Developer account via the browser, and the Apple service status portal shows no outages. As this issue is impacting our ability to deliver to our customers, I kindly request your prompt assistance in resolving this matter. Thank you in advance for your help. I look forward to your quick response. Best regards, KanTime Dev Team Windows Machine Mac Machine

There is a volunteer run group on GitHub who maintain a well known public domain cross-platform Python script. They build binaries for Linux, Windows and macOS. The macOS binaries are only ad-hoc signed. Thus, in macOS 15, they are rejected by Gatekeeper – requiring user intervention to be used. There are a lot of components each of which must be approved in "Settings" with admin credentials. It would be best if these binaries were code signed. However, the core group of devs changes over time and so, using one person's name might not be ideal. Can such a volunteer group apply for a developer certificate so that they can sign the macOS binaries ? I ask because Apple's requirements for enrolling in the Development Program include that an organisation be a legal entity and this group is not a legal entity. Thnaks.

I am part of Apple Developer Enterprise Program, with role of Developer. I know I can't see it, but even the Account Holder do not see the option. It happened yesterday after the Certificate expired. Is there any change or update on this area? Or we need to raise some special permission? Please help us on this.

macOS application Mulligan's Eagle (403115926) macOS deployment - macOS 10.14 (Mojave) through Sonoma 14.5 macOS targets - Mac App Store, ad hoc direct drag-to-install image Xcode version 15.4, various development Macs (Intel, M1, M2) Eagle delivered since pre-Mac App Store days - derived from System 7 MacApp development. App most recently delivered with min system Mac OS 10.12 through current Sonoma 14.5, dual target for Mac App Store automatically signed with Apple Development credentials and for outside release automatically signed with Developer ID credentials. Recent revisions to the software to bump min system to 10.14 (Mojave) with typical continuing development for tech, reqm'ts, etc. Updates (a couple since previous release) to Xcode - now using version 15.4, which recommended some config changes that made sense, except min system. Popular application with lots of older (uh... elder) users running Macs servicing golfers. The application is ready to distribute with automatic signing, but wasn't able to do so with Developer ID credentials, but Xcode note (and reading of tips in this forum and my poor understanding) managed to submit for notarization - failed. Tried to manually sign... and reviewed signing info in Xcode... So I reviewed Certificate(s) etc. that should have been used when previously signing Dev ID for notarization and release. I have (I think) six Developer ID Application certs and six Developer ID Installer certs and I can't find any combination of those certificates - some with duplicate dates or expirations - that allows me to use one to automatically sign code to notarization or delivery. What do I do? I've lived a peaceful solo developer life for 25 years delivering and signing code for the Mac and as long as iOS has existed. I'm terrified about this issue however... My early Mac OS using customers (since Lion - pre sandbox) still have serial numbers for this software and have bought a Mac every 6 - 10 years so they could get my latest release. We've never required that they re-purchase from the App Store... they have a perpetual license. Sandboxing was a shock they never felt - we kept delivering updates to them and if they decided sandboxing mattered, they purchased from Apple and we included the container-migration entitlement in the App Store version to move their data to the new sandbox. Pretty slick. Until we built an install disk to test it on an unsandboxed version of Eagle in our office. It "lost" its data - vanished by remaining in the old Application Support directory while the new hardened runtime version looked for it in the sandbox - finding nothing. Just imagine encountering that if you're 80 years old running a golf league. How can I "reset" the futzed-up certificate Developer ID mess? I have multiple machines, all with varying subsets of what seem to be good certificates. And Xcode builds new provisioning profiles just for the heck of it, it seems. I'm afraid to revoke or throw out any certificates because I can't tell which ones are good, bad or duplicates - they're all valid. And I can't create any more Developer ID certs because there's a max to control certificate-miscreants like me (yes, I've read Quinn's protection of your Dev ID note - I screwed it up with only 1 employee). I depend on automatic signing because I'm still, after 58 years of coding, just a novice. Is it true that I should still specify in my build settings that I'm using Developer ID credentials for my ad hoc development and distribution schemes? And that the proper settings for those should NOT enable hardened runtime or app sandboxing? Sorry for my intensity here.... It's been 2 weeks since App Review bonked an initial submission with just an "it's broken" reject message, and DTS decided this is not such an emergency that the Developer Forum shouldn't be able to handle it. I'm truly hoping it's so.

I'm a contractor. Not an app store/Mac expert. A few years ago I connected my Apple account to a team I was working with. They set me up as the Account Holder for their team. I forgot all about that, and today I want to set up a new team for another contract, so I reactivated my Developer account. I find I'm still the Account Holder for that old project, and I don't see how to create a new Team and switch to it. (I did send a request for someone to take over the old team, but who knows when they'll get to that, if ever.) All I need is to create a couple of signing certs, but not for the old team.

I got into trouble setting up my X-Code team ID. My user ID suddenly changed. Please take a look at the first screenshot. This is the certificate I was originally using, and I got a new certificate because it's about to expire. The new certificate is the second screenshot. But you can check that the ID is different. The problem is that the Apple login function is not working properly because the ID is different (I'm using Unity to develop a game) Can you tell me why the user ID has changed and I can't change it to the original one?

Hello, I am working on a macOS VPN app using Network Extension's packet tunnel capability. When the container app (referred to as "App" below) and the network extension plugin (referred to as "NE" below) are signed with my development certificate, everything works perfectly. However, when they are signed with a Developer ID certificate, the network extension refuses to activate. Here are the details: The App has sandbox set to off, but the NE has sandbox set to on. I managed to archive and notarize both Developer ID signed App and NE. The Debug version and Release version don't use the same App ID or App Group ID to make sure there is no interference. I am aware that the NE entitlement value changes if signed by Developer ID. I followed the instructions and used packet-tunnel-provider-systemextension instead of packet-tunnel-provider. I tested adding System Extension capability into the App, but it made no difference. The activate tunnel function returns NEVPNError.Code.configurationInvalid, but I don't think the configuration is invalid. The same configuration works with a development profile. In the system console, I observed the following log messages: Looking for an extension with identifier {NE_BUNDLE_ID} and extension point com.apple.networkextension.packet-tunnel Found 1 extension(s) with identifier {NE_BUNDLE_ID} and extension point com.apple.networkextension.packet-tunnel Beginning extension request with extension {NE_BUNDLE_ID} Assertion 395-24105-185921 (target:[xpcservice<{NE_BUNDLE_ID}([osservice<com.apple.neagent(512863558)>:24105:24105])(512863558)>:42188]) will be created as active [0x12be187f0] activating connection: mach=false listener=false peer=false name={NE_BUNDLE_ID}.apple-extension-service Entitlement com.apple.application-identifier={APP_GROUP_ID} is ignored because of invalid application signature or incorrect provisioning profile Entitlement com.apple.security.application-groups=( {APP_GROUP_ID} ) is ignored because of invalid application signature or incorrect provisioning profile {APP NAME}[42130]/1#5 LF=0 copy_matching Error Domain=NSOSStatusErrorDomain Code=-34018 "Client has neither com.apple.application-identifier nor com.apple.security.application-groups nor keychain-access-groups entitlements" UserInfo={numberOfErrorsDeep=0, NSDescription=Client has neither com.apple.application-identifier nor com.apple.security.application-groups nor keychain-access-groups entitlements} Any guidance or suggestions would be greatly appreciated. Thank you!

Our product includes a sudo plugin so we can apply user-defined policies to manage privileged access to command line programs. We’ve been getting reports where the plugin sometimes doesn't get invoked and the sudo command falls back to its default behavior. This seems to only be happening intermittently, but when the issue does occur, this message appears in the Console: Library Validation failed: Rejecting '/usr/local/libexec/sudo/<our_plugin>.so' (Team ID: <OURTEAMID>, platform: no) for process 'sudo(<pid>)’ (Team ID: N/A, platform: yes), reason: mapping process is a platform binary, but mapped file is not I recall a previous discussion of this message (that I can’t locate now), which explained that although the host process has library validation disabled, the code flow raises an error anyway, so that the host process can detect it and bypass the validation to load the plugin. It looks like that's what sudo is doing: it has the private entitlement com.apple.private.security.clear-library-validation and makes the appropriate system call when the plugin initially fails to load [1] — but apparently this isn't working reliably for our sudo plugin. We’ve observed that restarting the Mac generally resolves the issue, at least for a while. This resembles the “classic symptom of a code signing oddity” where the signature is cached and the Mach-O image is rewritten rather than replaced (as documented in Updating Mac Software). But our software uses an Installer package for updates as well as initial installation, and the Installer is documented as not having this issue, so I believe the problem lies somewhere else. I’m running out of ideas; are there any other avenues I should investigate? Thanks for any help. [1] This is described in an article called "About com.apple.private.security.clear-library-validation"; I can't link to it directly from the developer forums, but it can easily be found by searching for the title.

I'm trying to build my Expo app. I already built it for Android, but now I'm struggling to create a release on iOS to upload on TestFlight. I have the apple developer account of my university, and they added our bundle ID there(I'm not an admin). When I try to build with EAS, it requires a p12 file. So, I tried to generate it in this way: From Keychain Access I created a CSR(by adding my mail and name) and then on Apple Developers I uploaded it(Certificates > +), so I downloaded a .cer file I opened the .cer on Keychain Access and I dragged it under "login" section From there I exported the p12 file But that p12 gives me always this error when I run npx eas build --platform ios : Provided Distribution Certificate is no longer valid on Apple's server after submitting the p12 file on eas console. Can someone help us? Thanks in advance for your availability :)

Hi, I have been using a Developer ID Installer Certificate to sign my installer packages since a long time now. Recently, the sign command started giving me error, Error - Certificate is expired or not yet valid. Please check certificate validity. The certificate itself is valid till 2025, so I am confused on the issue. To get a clearer understanding, I created a new certificate by following instructions in the link, https://developer.apple.com/help/account/create-certificates/create-developer-id-certificates However, when I try to use this to sign my installer package, I get the following error, Unable to build a valid certificate chain. Please make sure that all certificates are included in the certificate file. I am using ZXPSignCmd to sign the installers. Hoping for guidance to a quick resolution.

Hi, I'm trying to Developer ID-sign and export a macOS app through my CI/CD pipeline on GitHub Actions, but I've run into an issue signing my app once it has one or more entitlements, in this case, an app group entitlement. I'm using xcodebuild to archive the app and export that archive, signing it along the way. This works fine as long as my app does not have an entitlement, but once it has an entitlement, exporting the archive fails. To elaborate a bit on this, I first make sure the development certificate and the Developer ID certificate are installed on the machine. These are installed using the security CLI, and I'm confident that they are installed correctly. Then I proceed to archive the app using xcodebuild as shown below. xcodebuild archive\ -scheme MyApp\ -configuration Release\ -sdk macosx\ -archivePath MyApp.xcarchive\ -destination "platform=OS X,arch=x86_64"\ -allowProvisioningUpdates\ -authenticationKeyIssuerID XYZ1234\ -authenticationKeyID XYZ\ -authenticationKeyPath AuthKey.p8 Then I export the archive using xcodebuild as shown below. xcodebuild -exportArchive\ -archivePath MyApp.xcarchive\ -exportPath export\ -exportOptionsPlist ExportOptions.plist\ -allowProvisioningUpdates\ -authenticationKeyIssuerID XYZ1234\ -authenticationKeyID XYZ\ -authenticationKeyPath AuthKey.p8 When my app has one or more entitlements, this fails with the following error message: Error: error: exportArchive: Cloud signing permission error Error: error: exportArchive: No profiles for 'com.example.MyApp' were found Note that I am not signed into an Apple ID in Xcode when signing and exporting my app through my CI/CD pipeline, as there does not seem to be a way to sign into an Apple ID in Xcode through the CLI. Instead, I'm authenticating with an App Store Connect API key. Developer ID-signing and exporting my app does work when I do it through Xcode, even if the app has an entitlement, so the signing of the app is configured correctly. Upon inspecting the contents of ~/Library/MobileDevice/Provisioning Profiles after signing and exporting the app through Xcode, I notice that Xcode automatically creates two provisioning profiles with the titles: Mac Team Provisioning Profile: com.example.MyApp Mac Team Direct Provisioning Profile: com.example.MyApp These two provisioning profiles are not created when signing and exporting the app through the xcodebuild command-line tool, and I suspect that is part of the problem. I'd be OK with manually creating these provisioning profiles through Apple's developer portal and installing them as part of my CI/CD pipeline, but I can't seem to find a way to create this type of provisioning profile through the portal. Neither the macOS App Development, Mac App Store Connect, nor Developer ID provisioning profile types yield this kind of provisioning profile. All of this, leaves me with the question: How do I Developer ID-sign and export a macOS app with an entitlement through the command-line without being signed in with my Apple ID in Xcode?

The notarytool service seems to be down, but "Developer ID Notarization Service" is green in the system-status. If I try to submit a DMG for notorization or even just try to get the history it gives this response: Error: internalError(statusCode: Optional(500), strData: nil, jsonData: Optional(["errors": <__NSSingleObjectArrayI 0x60000331d020>( { code = "UNEXPECTED_ERROR"; detail = "<null>"; id = 7S3TTC4N54UMTGOEMVREFQPSNE; links = "<null>"; status = 500; title = "Uncaught server exception"; } ) , "statusCode": 500])) Please try again at a later time. Everything worked a couple weeks ago

Hi I have had severe malware issues recently and need to factory reset my Mac. I may have to reinstall the OS as well in case it has a root-kit. This means I cannot use any standard backups ( Time Machine etc.) and will manually recreate my user setup on the Mac. Will reinstalling Xcode and downloaded signing certificates from my developer account work ? Are there other things to consider ? I will recreate my user ( assuming the uid will be the same as well ) Has anyone tried this before? What is your experience with it?

Hi, I created a developer id certification from my apple developer account a couple of year ago and downloaded it as .cer file into my Laptop. Now I want to use this certificate to sign my application, but unfortunately Xcode shows an error message like 'Missing Private Key" and I can also see that there is no private key under my developer id certificate(there is no grey arrow to expand to see private cer) in keychain access. Moreover my developer account is expired and I do not want to extend it yet so unfortunately no solutions with apple developer account will work like creating a new certification etc. Do you have any other solutions like using Keychain Access or Xcode to link my private key again into my developer id certificate? Note: 1-.cer file was created on my laptop by me, which I am using now. So I would expected that the related private key should already exist in my Keychain Access(if I did not delete it mistakenly.) but I do not know which private key is the relevant one, I have several of them. 2-I have also a CertificateSigningRequest.certSigningRequest file which was copied near my .cer file. Maybe it could be useful for a solution? 3-No! unfortunately I do not have any .p12 file. 4-I had already installed current AppleWWDRCAG3 file before I import my .cer file into my Keychain Access Tool. 5-Get Info shows that my cer file is still valid till sep 2025. 6- I have already restarted my Xcode and laptop. 7-I tried all solutions here: https://stackoverflow.com/questions/12867878/missing-private-key-in-the-distribution-certificate-on-keychain 8-https://developer.apple.com/account/resources/ shows me no certificate with the reason that my membership expired 9-I removed and re-added my apple account into Xcode. the same error occurred. XCODE:Version 15.3 (15E204a) OSX:macOS Sonoma 14.2.1 Thanks a lot in advance.

Hi All, We use a small group of Mac mini units running VMs for our Apple CI system. Since you can't login to an Apple ID on an Apple Silicon VM we wanted to use an App Store Connect API token to handle all the authentication for us. In the past this has not worked but I wanted to see if it could now. The answer is no, you can not use an API token with Developer ID Cloud certificates. The reason is that, even on an Admin role token, the DevID certificates are not enabled by default. When you are using an Apple ID this is no big deal as you can check the box to allow access, but with tokens they are minted with only the default settings for the role. This means that the option for Access to Cloud Managed Developer ID Certificates is always disabled and you can't enable it. If we could continue logging in with an Apple ID we could stumble along with that still, but even this ability is gone on AS VMs. Right now this pretty much means that we either give up on using stateless VMs to build or we go back to manually managing all of our code signing materials. The longer term solution would be to move to Xcode Cloud, but that will take us quite some time. I filed FB13687073 to see if there is any way to create a token that can use this checkbox.

Could someone let me know if it is possible to create a self-signed Developer ID Installer certificate? Create an installer package using this certificate. And share it with others. This is just to do a simple proof of concept.

Hi, I am trying to export my game app to Steam, and trying to understand the external distribution using Developer ID Application. Even when using the Account Holder account (because I cannot get a private key for Developer ID Application otherwise), I am unable to use a Provisioning Profile. It allows me to archive and distribute anyways. But once the app is sent for notarization, I never hear back from Apple. Can anyone help explain this process? I've scoured the web looking for clear instructions but it's eluding me. I had read that notarization is quick, but I don't get anything back, not even an error or rejection. Thanks

There is an app, that is distributed on the web using Company A Developer ID certificate. Now this has to be transferred to Company B apple developer account. There is a way to transfer apps that are distributed on the AppStore, but how to do it in case of Developer ID?

I've developed a Java application for ad hoc distribution, not intended for the Apple Store. Using the jpackage utility and the parameters... --mac-sign --mac-signing-keychain --mac-signing-key-user-name ...I'm able to point the software to a signing certificate. My problem is that jpackage requires a certificate with a "Developer ID Application" type/prefix, and I'm not authorized to create a certificate of this type, as "This operation can only be performed by the account holder." I thought it might be sufficient to create a "Distribution" certificate, since this allows a developer to "Sign your iOS, iPadOS, macOS, tvOS, watchOS, and visionOS apps for release testing using Ad Hoc distribution or for submission to the App Store." However, there doesn't appear to be any way to get jpackage to accept anything other than a "Developer ID Application" -prefixed certificate. I gather from this, and the fact that the Developer ID Application certificate is described as "This certificate is used to code sign your app for distribution outside of the Mac App Store," that this is the only type of "legitimate" security certificate Apple will accept when launching out-of-store apps. I'm not certain of this, however, and I'd like to be certain before pestering my client about it. My questions are: Is a "Developer ID Application" certificate specifically required, or can I sign the app using, e.g., a "Distribution" certificate without issues? If a "Developer ID Application" certificate is required, is it possible for my client (the "Account Holder") to grant me access to download it and use it? If a "Developer ID Application" certificate is required, what exactly is a "Distribution" certificate good for? Why isn't it sufficient to distribute software? If I can sign the app using a Distribution certificate, is there a way to force jpackage to do this, or do I have to it manually using, e.g., codesign ex post facto? Note that this issue has cropped up before on this thread, but the developer there ultimately found his developer ID certificate and the discussion was abandoned before any answers were forthcoming.