“codesign”

Dear Apple Developer Support, I am experiencing a critical issue with Developer ID certificates issued for Turkish (C=TR) developer accounts that prevents code signing on macOS. Issue Summary All Turkish Developer ID certificates issued on October 4, 2025, contain an Apple proprietary extension (OID 1.2.840.113635.100.6.1.13) marked as critical that both OpenSSL and codesign cannot handle. Technical Details Team ID: 4B529G53AG Certificate Country: TR (Turkey) Issue Date: October 4, 2025 macOS Version: 15.6.1 (24G90) Problematic Extension OID: 1.2.840.113635.100.6.1.13 (marked as critical) Evidence I have verified this issue across THREE different Turkish Developer ID certificates: Serial: 21F90A51423BA96F74F23629AD48C4B1 Serial: 461CBAF05C9EDE6E Serial: 184B6C2222DB76A376C248EC1E5A9575 All three certificates contain the same critical extension. Error Messages OpenSSL: error 34 at 0 depth lookup: unhandled critical extension Codesign: unable to build chain to self-signed root for signer errSe

Hello everyone, I am migrating a legacy KEXT to a DriverKit (DEXT) architecture. While the DEXT itself is working correctly, I am completely blocked by a code signing issue when trying to establish the UserClient connection from our SwiftUI management app. Project Goal & Status: Our DEXT (com.accusys.Acxxx.driver) activates successfully (systemextensionsctl list confirms [activated enabled]). The core functionality is working (diskutil list shows the corresponding disk device node). The Core Problem: The userclient-access Signing Error To allow the app to connect to the DEXT, the com.apple.developer.driverkit.userclient-access entitlement is required in the app's .entitlements file. However, as soon as this entitlement is added, the build fails. Both automatic and manual signing fail with the same error: `Provisioning profile ... doesn't match the entitlements file's value for the ... userclient-access entitlement.` This build failure prevents the generation of an .app bundle, making it impossible to insp

Hello, appreciate any help here. Objective: perform a scoped write to a removable block device (using low-level system frameworks in C). Issue: launchd-run privileged helper (as root) denied permission to open block device. Manual 'sudo ./helper' call succeeds, however. Importantly: the entire process works flawlessly if the main app is granted Full Disk Access in Privacy & Security. However, this should be completely unnecessary for this objective, as scoped access should be sufficient, and FDA is in fact not required for other apps which perform this task. Architecture and flow: Main GUI process collects ISO path and target removable device path (queried via IOKit). Main GUI process installs a Privileged Helper via SMJobBless. The Privileged Helper is started on demand by launchd as root (UID 0, EUID 0). Main GUI process communicates selected ISO and device paths to Privileged Helper via XPC. Privileged Helper conducts security and sanity checks, unmounts volumes from target device via DiskArbitration.

In our local test configurations, a developer can sign test apps for device installation using any key associated with the company team. However, if a developer accidentally chooses an identity from some other team, installation fails with no information about the problem. It just mentions that no provisioning profile could be found, leaving everyone in the dark about what is wrong. Instead, we would like to pre-validate the selected signing identity by checking the team name or id. This could be done, for example, by extracting the x509 certificate from the signing identity and checking the OU field (which is set to the team id). However, none of the apple commands will divulge the x509 certificate from a developer id. So far our best options is to create a fake app, sign the app, then use command: codesign --display --extract-certificates This solution seems excessively serpentine. Is there no direct command that will accept the sha of a signing identity and return a nice .pem containing the associ

I'm developing this app that uses python (pythonkit) to access certain python tools. It works fine locally but I was trying to validate it in order to upload it for the final testing and submission but I'm getting this signing error: codesign command failed (/var/folders/w0/9xsxryw94ps9n139w7g9q3gh0000gp/T/XcodeDistPipeline.~~~jO0urX/Root/Applications/RubyEyes.app/Contents/Frameworks/Python.framework/Versions/3.13/lib/python3.13/config-3.13-darwin/python.o: operation inapplicable or not supported for this type of code ) can someone help me?

I'm trying to sign a .app package coming from Py2app. Unfortunately I keep running into the same two issues: The binary is not signed with a valid Developer ID certificate. and The signature does not include a secure timestamp. I tried everything, from recreating the signatures, with different arguments, different keys and certificates, but it keeps complaining with these two errors on a long list of files. For reference I added the python script I use for signing the files. code_singing.py

Hey, Just recently I realized something I have been overlooking in my build pipelines. I thought that by adding the the hardened runtime, I disable 3rd-party library injection (I do not have the disable-library-validation entitlement added). However, I was using some checks on my code and I noticed that the library validation code signature check fails on my applications (e.g. adding the .libraryValidation requirement via the LightweightCodeRequirements framework) - with codesign -dvvvv /path/to/app I can check it doesn't have the CS_REQUIRE_LV flag: [...] CodeDirectory v=20500 size=937 flags=0x10000(runtime) hashes=18+7 location=embedded [...] then I used in Xcode the Other Code Signing Flags setting and added the -o library option, which added the flag: [...] CodeDirectory v=20500 size=937 flags=0x12000(library-validation,runtime) hashes=18+7 location=embedded [...] Is this flag something I should be explicitly setting? Because I was under the impression enabling hardened runtime would be enough. P

I tried building a macOS app with Electron, but I ran into problems during notarization. I used notarytool to upload my DMG and got status: Invalid. xcrun notarytool log output { logFormatVersion: 1, jobId: 680bf475-a5f4-4675-9083-aa755d492b18, status: Invalid, statusSummary: Archive contains critical validation errors, statusCode: 4000, archiveFilename: BODYPARK-v3.6.0-mac.app.zip, uploadDate: 2025-09-25T02:50:41.523Z, sha256: e61074b9bba6d03696f2d8b0b13870daafc283960e61ab5002d688e4e82ef6f6, ticketContents: null, issues: [ { severity: error, code: null, path: BODYPARK-v3.6.0-mac.app.zip/BODYPARK-v3.6.0-mac.app/Contents/Resources/plugin/XMagic/mac/libpag.framework/libpag, message: The signature of the binary is invalid., docUrl: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735, architecture: x86_64 }, { severity: error, code: null, path: BODYPARK-v3.6.0-mac.app.zip/BODYPARK-v3.6.0-mac.app/Contents/Resources/plugin/XMa

Does anyone know how to fix their launch agents list to remove suspicious applications. I found out there is a codesigning tool allowing suspicious applications to snatch Apple's certificates and codesign their own binaries with them. How do I know, I've literally done it test the restrictions / requirements. Once a binary or application has been signed, it can run anywhere and the system will trust it. I found a process called com.apple.seserviced in the file path /usr/libexec/seserviced. I checked the entitlments and this straight up looks like a commercial sized entrance for this binaries to trample on my computer and iPhone. I'm thinking about putting the code in jail or a lock on the file until I can figure out it's purpose. codesign -d --entitlements :- /usr/libexec/seserviced