fastlane: Could not find a matching code signing identity for type 'AdHoc'. You can use cert to generate one

New Issue Checklist

Issue Description

Complete output when running fastlane, including the stack trace and command used

No existing profiles found, that match the certificates you have installed locally! Creating a new provisioning profile for you WARN [2017-12-07 18:10:40.07]: No certificates for filter: Certificate ID: ‘NGMBD6E3T8’ ERROR [2017-12-07 18:11:40.09]: Unable to send the crash report. ERROR [2017-12-07 18:11:40.09]: Please open an issue on GitHub if you need help!

Environment

fastlane --version 2.68.0 match 2.68.0 sigh 2.68.0

this is a enterprise account

match(type: “#{type}”, verbose: true, force: true, app_identifier: “#{app_identifier}”, git_branch: ENV[‘MATCH_INHOUSE_BRANCH’], clone_branch_directly: true, force_for_new_devices: true, provisioning_name: “#{provisioning_name}”, username: “dlxdell@hotmail.com”, team_id: “SHDWRXPG6N”)

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 1
  • Comments: 19 (10 by maintainers)

Most upvoted comments

Hey all 👋 I made what I think is a fix for how match will handle enterprise adhoc-ness ^ If you want to check it out that would be ❤️

I was able to figure it out! Turns out the bug is in Sigh and how it uses Spaceship.

First, to get certs, there’s a call to https://developer.apple.com/services-account/PLATFORM_ID/account/ios/certificate/listCertRequests.action that happens. The parameters for that request are teamId, pageSize, pageNumber, sort, and types. For enterprise accounts (note: accounts, not certificates or profiles, the entire account/team is an In-House team), when you query this endpoint after authenticating with a value of R58UK2EWSO for types, which is the certificate identifier that Spaceship has defined for Production in this mapping:

 IOS_CERTIFICATE_TYPE_IDS = {
        "5QPB9NHCEI" => Development,
        "R58UK2EWSO" => Production,
        "9RQEK7MSXA" => InHouse,
        "LA30L5BJEU" => Certificate,
        "BKLRAVXMGM" => DevelopmentPush,
        "UPV3DW712I" => ProductionPush,
        "Y3B2F3TYSI" => Passbook,
        "3T2ZP62QW8" => WebsitePush,
        "E5D663CMZW" => VoipPush,
        "4APLUP237T" => ApplePay
      }

the list returns empty so it was failing despite the certificate existing in the developer portal. I went through and tried a couple different ones and it turns out if you’re trying to fetch an adhoc certificate from an enterprise account, you can get it but only if the value of types is 9RQEK7MSXA or InHouse. The fix is really easy actually, I just added this:

elsif profile_type == Spaceship.provisioning_profile.AdHoc && Spaceship.client.in_house?
     certificates = Spaceship.certificate.in_house.all
else

in this method (runner.rb: 172, the last elsif clause under ios, tvos):

def certificates_for_profile_and_platform
      case Sigh.config[:platform].to_s
      when 'ios', 'tvos'
        if profile_type == Spaceship.provisioning_profile.Development
          certificates = Spaceship.certificate.development.all
        elsif profile_type == Spaceship.provisioning_profile.InHouse
          certificates = Spaceship.certificate.in_house.all
        elsif profile_type == Spaceship.provisioning_profile.AdHoc && Spaceship.client.in_house?
          certificates = Spaceship.certificate.in_house.all
        else
          certificates = Spaceship.certificate.production.all # Ad hoc or App Store
        end

      when 'macos'
        if profile_type == Spaceship.provisioning_profile.Development
          certificates = Spaceship.certificate.mac_development.all
        elsif profile_type == Spaceship.provisioning_profile.AppStore
          certificates = Spaceship.certificate.mac_app_distribution.all
        elsif profile_type == Spaceship.provisioning_profile.Direct
          certificates = Spaceship.certificate.developer_id_application.all
        else
          certificates = Spaceship.certificate.mac_app_distribution.all
        end
      end

When that happens, both the adhoc and enterprise certificate we use returned from the API call and match was able to set up adhoc certificates successfully. I can put up a PR that fixes this if that sounds good @KrauseFx @joshdholtz

This has not been fixed and there is a code proposed as fix. It looks to me that a maintainer has to decide if it makes sense to add that code.

@polmum Thanks for linking that! Will look into 👀

Feedback please?

Is this fixed and released? I’m having the same issue with an enterprise account generating AdHoc profile.