fastlane: Sigh does not choose correct certificate when creating/updating provisioning

Original issue by @robwithhair - Imported from fastlane/sigh#122

I am using fastlane with Cert and Sigh and I am getting the following error in deliver in a previously working build script.

⌦  Code Sign error: No codesigning identities found: No codesigning identities (i.e. certificate and private key pairs) that match the provisioning profile specified in your build settings (“com.iKebabs.waterdal AppStore”) were found.


    no rule to process file '/Users/Shared/Jenkins/Home/jobs/iOS Build - Release Automation/workspace/iOS/Framework/Plugins/ChildBrowser/README.md' of type net.daringfireball.markdown for architecture armv7
    no rule to process file '/Users/Shared/Jenkins/Home/jobs/iOS Build - Release Automation/workspace/iOS/Framework/Plugins/ChildBrowser/README.md' of type net.daringfireball.markdown for architecture arm64

⌦  CodeSign error: code signing is required for product type 'Application' in SDK 'iOS 8.3'


** ARCHIVE FAILED **


The following build commands failed:
    Check dependencies
(1 failure)

/Library/Ruby/Gems/2.0.0/gems/fastlane-1.4.0/lib/fastlane/actions/ipa.rb:94:in `rescue in run': A build error occured, this is usually related to code signing. Take a look at the error above (RuntimeError)
    from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.4.0/lib/fastlane/actions/ipa.rb:66:in `run'
    from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.4.0/lib/fastlane/fast_file.rb:112:in `block (2 levels) in method_missing'
    from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.4.0/lib/fastlane/actions/actions_helper.rb:51:in `execute_action'
    from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.4.0/lib/fastlane/fast_file.rb:94:in `block in method_missing'
    from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.4.0/lib/fastlane/fast_file.rb:93:in `chdir'
    from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.4.0/lib/fastlane/fast_file.rb:93:in `method_missing'
    from (eval):58:in `block (2 levels) in parse'
    from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.4.0/lib/fastlane/runner.rb:39:in `call'
    from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.4.0/lib/fastlane/runner.rb:39:in `block in execute'
    from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.4.0/lib/fastlane/runner.rb:29:in `chdir'
    from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.4.0/lib/fastlane/runner.rb:29:in `execute'
    from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.4.0/lib/fastlane/lane_manager.rb:33:in `cruise_lane'
    from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.4.0/bin/fastlane:39:in `block (2 levels) in run'
    from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/command.rb:178:in `call'
    from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/command.rb:178:in `call'
    from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/command.rb:153:in `run'
    from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/runner.rb:428:in `run_active_command'
    from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/runner.rb:68:in `run!'
    from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/delegates.rb:15:in `run!'
    from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.4.0/bin/fastlane:128:in `run'
    from /Library/Ruby/Gems/2.0.0/gems/fastlane-1.4.0/bin/fastlane:134:in `<top (required)>'
    from /usr/bin/fastlane:23:in `load'
    from /usr/bin/fastlane:23:in `<main>'
[17:11:32]: A build error occured. This can have many reasons, usually
[17:11:32]: it has something to do with code signing. The `ipa` action
[17:11:32]: uses `shenzhen` under the hood: https://github.com/nomad/shenzhen
[17:11:32]: The command that was used by fastlane:
[17:11:32]: krausefx-ipa build -s "Framework" -m "/Users/Shared/Jenkins/Home/jobs/iOS Build - Release Automation/workspace/iOS/AppStore_com.iKebabs.waterdal.mobileprovision" --verbose | xcpretty
[17:11:32]: -------------------------------------------------------

This seems to possibly be to do with sigh using/creating a provisioning profile which has been signed with a distribution key which is not on the build server. It isn’t checking/using the one from cert.

Running

  increment_build_number( build_number: "672" )
  produce({
        produce_app_identifier_suffix: "",
        produce_app_name: "Waterdales Kebab House",
        produce_language: "UK English",
        produce_version: "1.0",
        produce_sku: "waterdal",
        produce_team_name: "Savas Saglam"
  })
  cert
  sh "pem"
  sigh( force: true )
  snapshot
  update_project_code_signing( path: "Framework.xcodeproj")
  ipa({
    scheme: "Framework"
  })
  deliver(
    skip_deploy: true,
    force: true
  )

This is my output from Cert and Sigh

[17:09:06]: ------------------
[17:09:06]: --- Step: cert ---
[17:09:06]: ------------------
[17:09:06]: Login into iOS Developer Center
[17:09:10]: Downloading URL: 'https://developer.apple.com/account/ios/certificate/certificateContentDownload.action?displayId=7AEM4BJL26&type=R58UK2EWSO'
[17:09:12]: Downloading URL: 'https://developer.apple.com/account/ios/certificate/certificateContentDownload.action?displayId=59CLB3YM29&type=R58UK2EWSO'
[17:09:14]: Found the certificate 59CLB3YM29-R58UK2EWSO which is installed on the local machine. Using this one.
[17:09:15]: Use signing certificate '59CLB3YM29' from now on!
[17:09:15]: ------------------
[17:09:15]: --- Step: sigh ---
[17:09:15]: ------------------
[17:09:15]: Starting login
Logging spaceship web requests to '/tmp/spaceship.log'
[17:09:17]: Successfully logged in
[17:09:17]: Found 1 matching profile(s)
[17:09:17]: Updating the provisioning profile
[17:09:21]: Downloading provisioning profile...
[17:09:22]: Successfully downloaded provisioning profile...
[17:09:22]: Provisioning profile of app 'Waterdales Kebab House' with the name 'com.iKebabs.waterdal AppStore' successfully analysed.
[17:09:22]: Installing provisioning profile...
[17:09:22]: Profile successfully installed
./AppStore_com.iKebabs.waterdal.mobileprovision

If I am understanding the output correctly it seems like it is using the certificate which exists on the machine in cert and uses that for code signing but the provisioning profile was created by sigh with a deployment certificate which was not the one which cert created. It’s using an old one. So code signing is failing as provisioning doesn’t match certificate from cert. What do you think. Does this sound plausible? I have checked the provisioning profile and it does indeed seem to be the old certificate which it is being used.