Cloud-managed distribution signing writes a non-ASCII certificate name decomposed (NFD) into the designated requirement, so every upload fails ITMS-90035

Question

Created 14h

Replies 2

Boosts 0

Participants 2

Every App Store Connect upload I sign with my Cloud Managed Apple Distribution certificate is rejected with ITMS-90035 ("Code failed to satisfy specified code requirement(s)") for the app binary and its widget extension. It happens from Xcode Cloud and from a manual Organizer upload alike. I think I have found the cause, and it looks like a Unicode normalization bug in cloud-managed signing.

The certificate holder's name contains an umlaut: "Apple Distribution: Jonathan Thorsten Müller (…)". In the certificate the "ü" is precomposed (NFC, UTF-8 c3 bc). In the designated requirement that the export writes into the signature it is decomposed (NFD, "u" + U+0308, UTF-8 75 cc 88):

certificate subject CN          ... 4d c3 bc 6c 6c 65 72 ...     ("Müller", NFC)
designated requirement leaf CN  ... 4d 75 cc 88 6c 6c 65 72 ...  ("Müller", NFD)

The bytes differ, so the signature can never satisfy its own designated requirement.

It reproduces with Xcode 27.0's App template, unmodified, and without uploading anything:

Archive for a generic iOS device.
With no distribution identity in the local keychain, export for App Store Connect to a folder (export options: method app-store-connect, destination export, signingStyle automatic). DistributionSummary.plist shows "Cloud Managed Apple Distribution".
```
xcodebuild -exportArchive -archivePath MyApp.xcarchive -exportPath out -exportOptionsPlist ExportOptions.plist -allowProvisioningUpdates
```
Verify the exported app:
```
codesign --verify --strict -vv Payload/MyApp.app
```
Result: "valid on disk", then "does not satisfy its designated Requirement".

Compare the requirement with the certificate's subject:

codesign -d -r- Payload/MyApp.app
codesign -d --extract-certificates Payload/MyApp.app
openssl x509 -inform DER -in codesign0 -noout -subject -nameopt RFC2253,-esc_msb | xxd

The same archive exported with a regular Apple Distribution certificate (same name, private key in my keychain) writes the NFC form, verifies, and App Store Connect accepts that upload. That works for manual uploads only. Xcode Cloud always signs with the cloud-managed certificate, so I cannot distribute from Xcode Cloud at all.

Setup: Xcode 27.0 (27A266a) locally and in Xcode Cloud, automatic signing, one team, no custom code-signing flags. Product name, bundle IDs and file names are plain ASCII.

Questions:

Is this a known issue with cloud-managed signing and non-ASCII certificate names?
Is there a supported way to have Xcode Cloud sign without hitting it in the meantime?

If you see ITMS-90035 on Xcode Cloud and your name (or your team's) has an accent or umlaut in it, you may be hitting the same thing: run step 3 on an exported IPA and check.

Answer 1

Etresoft OP

9h

Is this a known issue with cloud-managed signing and non-ASCII certificate names?

Yes. I'm pretty sure I've seen a very similar post here in the forums before.

Is there a supported way to have Xcode Cloud sign without hitting it in the meantime?

Supported? That's a real can-o-worms.

And I use that phrase on purpose. Apple is a California company. And California is in the USA. And pretty much the rest of the tech industry is too. Americans don't do diacritics. Americans do English, and that's it.

If you feel the need or desire to use something other than English, the responsibility is on you to properly manage it. All of your code and anything that interacts with the operating system should be strictly ASCII. A-Z, 0-9, and that's it. Spaces are a risk. Even changing case still introduces some risk.

Apple is one of the most "foreigner-friendly" platforms. So they have a wide range of supported APIs for localization into foreign languages. These APIs all do the exact same thing. They take text written in some sequence of acceptable ASCII as described above, and display it with whatever diacritics or font-supported Unicode glyph you hopefully have installed. (And Apple installs a whole lot of 'em.)

You are, of course, welcome to file feedback on this bug. Apple will get to work on it "real soon now".

(Please don't take offence at my use of Americanisms or terms like "foreigner". I'm doing that on purpose. I spent my first, formative years in the USA, so I know how Americans think. It's certainly possible that localization engineers working on Apple developer tools may fix this bug in a few months. But then it's equally possible that some other engineer will break it again 3 weeks later because he hates dealing with those "garbage characters".)

Answer 2

Etresoft OP

6h

Don't use the comments. They hide your replies.

But the certificate name isn't mine to choose: Apple takes it from the account holder's legal name, which I had to verify with my ID. So there's no way around my real name, umlaut included.

That's unfortunate.

If you remember where you saw the similar post, a link would be great.

It's hard to be sure. I found this one after a quick search. There is a link in that one to a similar, earlier question.

These questions were regarding Notarization on macOS. It's possible that old bug got promoted in Xcode 27.

Was this working before Xcode 27? If this works in an older version of Xcode, then you can just use that instead. You'll be on the clock though. Apple will eventually require a newer Xcode for submissions. And Apple's pretty aggressive about that. Xcode 27 will likely be required by April.

It sounds like this is only an issue for Xcode Cloud. Perhaps that explains why no one has experienced it yet. I don't know the details of how Xcode versions and Xcode Cloud are released. Perhaps this bug is entirely on the Cloud side. But even so, it's worth testing with and older Xcode. Maybe Apple has some older servers for compatibility.

Hopefully it will be fixed eventually.