Sửa lỗi ITMS-90034 “Missing or invalid signature”

ITMS-90034 xuất hiện khi bạn gửi build lên App Store Connect. Lỗi này cho biết app của bạn, hoặc một thành phần của nó, không được ký bằng chứng chỉ nộp app (submission certificate) của Apple, tức là một chứng chỉ phân phối hợp lệ. Cách sửa: tìm ra bundle nào bị ký sai và vì sao, rồi build lại một bản được ký cho App Store.

Bài này chỉ tập trung vào lỗi đó. Nếu bạn còn mơ hồ về chứng chỉ và profile, hãy đọc trước bài chứng chỉ nhà phát triển iOS và provisioning profile. Ở đây bạn sẽ có: cách đọc thông báo lỗi, một cây quyết định, các lệnh để kiểm tra file IPA và cách sửa với thông tin xác thực do EAS quản lý. Với phần EAS, mình đã đọc mã nguồn của EAS CLI 24.10.0, chỗ nó chọn chứng chỉ.

Lỗi ITMS-90034 nghĩa là gì?

Đây là dạng thường gặp của nó, với tên ví dụ:

ITMS-90034: Missing or invalid signature. The bundle 'com.example.myapp' at bundle path 'Payload/MyApp.app' is not signed using an Apple submission certificate.

Năm 2026, trên diễn đàn của Apple, lỗi này còn xuất hiện dưới dạng "Validation failed (409) Missing or invalid signature", theo sau là cùng đoạn văn bản và "(ID: 90034)".

"Chứng chỉ nộp app" chính là chứng chỉ phân phối (distribution certificate). Trang trợ giúp của Apple về chứng chỉ ghi rõ: chứng chỉ phát triển dùng để chạy app trên thiết bị của bạn, chứng chỉ phân phối dùng để phân phối app hoặc gửi lên App Store Connect.

Hãy đọc đường dẫn được nêu: nó chỉ ra bundle bị lỗi. Payload/MyApp.app là chính app. Đường dẫn kết thúc bằng .appex là một extension, ví dụ widget. Đường dẫn kết thúc bằng .framework là một thư viện được nhúng.

Đây không phải là từ chối của reviewer. Bước kiểm tra này diễn ra lúc gửi hoặc khi build đang được xử lý, trước TestFlight: build này sẽ không bao giờ đến tay tester của bạn.

Cây quyết định: từ thông báo lỗi đến cách sửa

Mỗi dòng tương ứng với một dấu hiệu bạn đọc được trong thông báo lỗi, trong các lệnh ở phần sau hoặc trong log của EAS. Xét lần lượt từ trên xuống: dòng đầu tiên khớp chính là hướng xử lý của bạn.

Điều bạn thấy	Nguyên nhân có thể	Cách sửa
Đường dẫn .appex	Extension ký sai	Khai báo extension
Signature=adhoc	Build không được ký	Build với profile store
Apple Development	Build phát triển	Build với profile store
Đọc được ProvisionedDevices	Build nội bộ (ad hoc)	Build với profile store
sealed resource	IPA bị sửa sau khi ký	Build lại
EAS: "no longer valid"	Chứng chỉ bị thu hồi	Tạo chứng chỉ mới
Mọi thứ đều hợp lệ	Sự cố phía Apple	Gửi lại, rồi báo lỗi

Kiểm tra IPA bằng bốn lệnh

Tải IPA từ trang build trên expo.dev, rồi mở terminal trên máy Mac.

1. Ai đã ký app?

unzip -q MyApp.ipa -d ipa
codesign -dv --verbose=4 ipa/Payload/*.app 2>&1 | grep -E "^(Identifier|Authority|Signature|TeamIdentifier)="

codesign ghi ra luồng lỗi, nên mới có 2>&1. Theo ghi chú kỹ thuật TN3161 của Apple, mỗi dòng Authority là một mắt xích của chuỗi tin cậy. Dòng đầu tiên phải bắt đầu bằng Apple Distribution: hoặc iPhone Distribution:, theo sau là tên team của bạn. Nhãn thứ hai là của loại iOS Distribution cũ: theo mã nguồn, EAS CLI 24.10.0 vẫn tạo chứng chỉ loại này. Nếu bạn thấy Apple Development:, đó là build phát triển. Nếu bạn thấy Signature=adhoc mà không có dòng Authority nào, binary không được ký bởi chứng chỉ nào cả.

2. App có bị sửa sau khi ký không?

codesign --verify --deep --strict -vv ipa/Payload/*.app

Kết quả bạn muốn thấy là valid on disk, rồi satisfies its Designated Requirement. TN3161 nói rõ phép kiểm tra này đảm bảo gì: mọi file cần có đều có mặt, không file nào bị thêm vào, không file nào bị sửa. Với một bundle thử nghiệm mình đã ký rồi chỉnh sửa, lệnh trả về a sealed resource is missing or invalid, rồi file modified: kèm file bị thay đổi. Tùy chọn --deep ở đây chỉ dùng để kiểm tra, không bao giờ dùng để ký: trên diễn đàn của Apple, một kỹ sư của đội hỗ trợ khuyên không nên dùng nó khi ký.

3. Profile nào được nhúng vào?

security cms -D -i ipa/Payload/*.app/embedded.mobileprovision -o profile.plist
plutil -extract ProvisionedDevices xml1 -o - profile.plist
plutil -extract ExpirationDate raw profile.plist

Đây là các lệnh trong ghi chú TN3125 về profile. Profile App Store không chứa danh sách thiết bị nào: dòng thứ hai phải trả về Could not extract value. Nếu nó hiện ra các mã định danh thiết bị, đó là profile ad hoc, của một build nội bộ. Dòng thứ ba cho biết ngày hết hạn của profile.

4. Extension và framework có được ký giống nhau không?

find ipa/Payload/*.app \( -name "*.appex" -o -name "*.framework" \) \
  -exec sh -c 'echo "$1"; codesign -dvv "$1" 2>&1 | grep -m1 "^Authority="' _ {} \;

Mỗi thành phần phải hiện cùng dòng Authority với app. Nếu có thành phần nào khác đi, đó chính là cái mà thông báo lỗi nhắc đến.

Nếu muốn kiểm tra trước khi gửi, TN3161 khuyên dùng altool, cùng phép kiểm tra với nút Validate App của Xcode. Nó cần một API key của App Store Connect, với file AuthKey_<KEY_ID>.p8 đặt trong ~/.appstoreconnect/private_keys:

xcrun altool --validate-app -f MyApp.ipa -t ios --api-key <KEY_ID> --api-issuer <ISSUER_ID>

Sửa với EAS, theo từng nguyên nhân

Gửi nhầm build nội bộ hoặc build phát triển lên Apple

Theo tài liệu của Expo về eas.json, build với "distribution": "internal" không được ký cho store: chúng dùng profile ad hoc. Chỉ profile có distribution là store, giá trị mặc định, mới tạo ra build gửi được. Cách an toàn nhất là gửi đúng build bạn vừa tạo, không chọn tay:

eas build --platform ios --profile production --auto-submit

Nếu bạn dùng eas submit --path, hãy kiểm tra file đó đúng là build store mới nhất của bạn. Trên diễn đàn của Apple, một team phát hiện công cụ gửi của họ lần nào cũng gửi lại một file IPA cũ được lưu trong git.

Quên khai báo extension

Mỗi extension là một bundle riêng, có mã định danh và profile riêng. Trong một dự án Expo dùng native generation, trang của Expo về extension iOS yêu cầu khai báo chúng trong extra.eas.build.experimental.ios.appExtensions. Khi đó EAS CLI biết đến chúng trước khi build, và tạo hoặc kiểm tra thông tin xác thực cho chúng. Phần lớn thư viện có thêm extension sẽ tự viết khai báo này cho bạn qua plugin của chúng.

Solys, app báo thức kèm mini game của mình, có bốn extension: một widget và ba extension Screen Time. Cả bốn đều được khai báo trong cấu hình, và EAS có một profile cho từng cái. Một extension thêm tay trong Xcode mà không có khai báo này là ứng viên hàng đầu cho một đường dẫn .appex trong thông báo lỗi.

Chứng chỉ bị thu hồi hoặc hết hạn

Trang của Apple về chứng chỉ nói rõ: bạn không thể gửi build được ký bằng chứng chỉ đã hết hạn hoặc bị thu hồi. Một build đã gửi nhưng chưa nộp duyệt thậm chí có thể chuyển sang Invalid Binary nếu chứng chỉ của nó bị thu hồi.

Mã nguồn EAS CLI 24.10.0 cho thấy khi nào trường hợp này bị bỏ qua:

• Build tương tác, có đăng nhập Apple: EAS so sánh chứng chỉ của nó với các chứng chỉ còn hợp lệ phía Apple. Nếu không còn, nó hiện "Current distribution certificate is no longer valid in Apple Dev Portal" và đề nghị bạn chọn hoặc tạo một cái khác.
• Build tương tác, không đăng nhập: EAS chỉ kiểm tra ngày tháng và cảnh báo rằng nó bỏ qua bước xác thực phía Apple.
• Build không tương tác, trong CI: EAS hiện "Distribution Certificate is not validated for non-interactive builds" và vẫn ký.

Trong CI, EAS không kiểm tra lại bản thân chứng chỉ: việc thu hồi có thể chỉ lộ ra lúc gửi. Cách sửa: chạy một build tương tác có đăng nhập tài khoản Apple, hoặc dùng eas credentials --platform ios, menu Build Credentials, rồi "Distribution Certificate: Add a new one to your account". Các profile chứa chứng chỉ cũ sẽ trở nên không hợp lệ: EAS kiểm tra chúng ở lần build sau và tạo lại. Giới hạn của Apple về số lượng chứng chỉ được trình bày chi tiết trong bài về chứng chỉ nhà phát triển iOS.

Binary bị sửa sau khi ký

Chữ ký niêm phong mã, tài nguyên và metadata bằng các mã băm, như ghi chú TN3126 của Apple giải thích. Giải nén IPA để sửa một file rồi nén lại sẽ phá vỡ lớp niêm phong này. Hãy sửa trong cấu hình, rồi build lại. Đừng bao giờ chỉnh sửa file IPA do EAS tạo ra.

Cùng logic đó với mã đặt sai chỗ, ví dụ trong một file .zip: App Store không thể ký lại nó. Apple mô tả các vị trí được phép trong trang về nội dung của một bundle.

Thông tin xác thực cục bộ

Nếu profile EAS của bạn dùng "credentialsSource": "local", file credentials.json sẽ trỏ đến một chứng chỉ .p12 và một profile .mobileprovision. Kiểm tra profile bằng các lệnh ở bước 3: nó phải là loại App Store và chứa chứng chỉ phân phối hiện tại của bạn. Và giữ các file này ngoài repo, giống như API key của một app Expo.

Khi mọi thứ đều hợp lệ

Còn một trường hợp gây bực bội. Trên diễn đàn của Apple, có developer thấy lỗi biến mất khi gửi lại đúng build đó mà không đổi gì. Vào tháng 8 và tháng 9 năm 2026, hai chủ đề mô tả điều ngược lại: chứng chỉ và profile mới, chữ ký đã kiểm tra, vẫn thất bại. Ở một trong hai, một kỹ sư Apple khuyên gửi báo cáo lỗi kèm IPA, kết quả phân tích chữ ký và log của Transporter, rồi liên hệ App Store Connect.

Vậy hãy gửi lại một lần với số build mới. Nếu lỗi vẫn quay lại trong khi bốn lệnh của bạn đều sạch, hãy báo cho Apple với các thông tin đó. Đừng thu hồi chứng chỉ theo phản xạ: việc đó không giải quyết thêm gì mà còn làm profile của bạn mất hiệu lực.

Gửi build mà không gặp bất ngờ

Kiểm tra chữ ký chỉ mất hai phút trước khi gửi. Các bước kiểm tra tự động khác cũng cần sự cẩn thận tương tự, như ITMS-90725 về phiên bản Xcode hay ITMS-90683 về câu giải thích quyền truy cập. Toàn bộ quy trình từ build đến gửi, không cần Mac, có trong bài phát hành app iOS không cần Mac.

Bị reviewer từ chối thì cần nhìn rộng hơn: cách xử lý nằm ở trang app bị Apple từ chối, và các lý do phổ biến nhất nằm trong bài vì sao Apple từ chối app.

Để kiểm tra hồ sơ trước khi gửi, Review Kit gồm checklist của mình và các skill Claude Code đọc lại dự án của bạn. Nếu bạn bị kẹt khi gửi và muốn có người xem giúp, đặt một giờ với mình: mình sẽ cùng xem dự án qua video call, ngay trên màn hình của bạn. Còn nếu bạn đang chuẩn bị ra mắt app đầu tiên, làm bài chẩn đoán miễn phí: nó sắp xếp lại các bước theo đúng thứ tự và gửi cho bạn checklist chống bị Apple từ chối của mình.

Câu hỏi thường gặp

ITMS-90034 có phải là bị App Review từ chối không?

Không. Đây là bước kiểm tra tự động khi gửi build, trước TestFlight và trước mọi đợt duyệt. Chưa ai mở app của bạn: Apple chỉ thấy rằng chữ ký của nó không đến từ một chứng chỉ phân phối hợp lệ.

Có cần thu hồi chứng chỉ phân phối để sửa ITMS-90034 không?

Chỉ khi nó bị lộ hoặc đã không còn hợp lệ. Thu hồi một chứng chỉ đang hoạt động sẽ làm profile của bạn mất hiệu lực mà không sửa được nguyên nhân. Hãy bắt đầu bằng việc đọc chữ ký IPA bằng codesign, rồi sửa đúng chỗ mà cây quyết định chỉ ra.

Có thể sửa ITMS-90034 bằng cập nhật từ xa không?

Không. Chữ ký là một phần của binary, và build bị từ chối sẽ không bao giờ dùng được. Bạn phải tạo một binary mới được ký đúng và gửi lại.

Vì sao lỗi nhắc đến widget chứ không phải app của tôi?

Vì widget là một bundle riêng, được ký bằng profile riêng. Nếu nó không được khai báo với EAS hoặc được ký theo cách khác, nó làm hỏng toàn bộ lần gửi. Hãy khai báo extension trong cấu hình rồi build lại.

Phải làm gì nếu codesign báo mọi thứ đều hợp lệ?

Kiểm tra thêm profile được nhúng và từng extension. Nếu tất cả đều sạch, hãy gửi lại một lần với số build mới. Nếu lỗi vẫn còn, gửi báo cáo cho Apple kèm IPA, kết quả của codesign và log gửi build.