fastlane: App Store distribution certificate expiring

This is still an issue, can people who find this interesting please add a thumbs up so this can get more attention?

Just wanted to chime in here (again)! I would also like to have this feature ❤️ fastlane is the best way (only way IMO) to manage certs and profiles. The hard part about developing this feature is getting an expired certificate and being to test against. I don’t think there is a way for us to manually expire cert so it requires waiting for an account’s cert to expire (which I currently do not have any). Once that cert is expired, we can’t really test any if this new implementation we write a lot of times because that cert will be deleted 😕

One possible solution that we could possibly make I guess might be to add an option called something like create_new_cert_num_days_before_expiration: 30 (looking for a better name) that will could look when the cert is going to expire, delete it, create a new one, and create new profiles? 🤔🤔🤔🤔🤔🤔

Doing this approach would make it easier to test because I could set my option to 900 days and then everyone could delete (expire) their cert however many days for their own workflow.

Any thoughts / objections / issues to an approach like this?

Heyyyy 👋 I totes understand this issue. When match tries to create a new profile, it will first try to create a new profile for that app identifier from the existing cert that app was using (almost like its recreating) <-- this is why nuking solves this issue.

However, I do agree that there should almost be some sort of mini-nuke on a single provisioning profile so that the newly created profile will be used from the newest cert. <-- I will look into this issue

I would also like to fix the App Store expiring issue but that one is a bit harder to test since I can’t manually expire a certificate on the iOS Developer Center 😢

Hey @krish722, I got the same error as @agordeev:

“Your certificate ‘XXXXXXXXXX.cer’ is not valid, please check end date and renew it if necessary”

It’s the certificate that expired, not the profile. I know how to delete everything manually from the repos and regenerate them. But it would be so much convenient to have fastlane do it, which I’m guessing that’s why everybody uses it, not to do manual stuff

Thanks!

This issue will be auto-closed because there hasn’t been any activity for a few months. Feel free to open a new one if you still experience this problem 👍

Just stumbled onto this thread… Our prod profile is about to expire. Seems crazy to have to let it expire and then run fastlane match to generate a new one… +1 for an option to renew prior to expiration. What is the correct way to handle this without having to manually decrypt and edit the match repo?

This definitely needs a better solution. I can’t use nuke because I have other apps/certificates using the same repo.

And waiting for the certificate to expire is not very safe. We are missing a lot of days to prepare a new build with the new certificate.

This might not be a big problem with App Store apps, since they still work even if a certificate expires. But with enterprise apps, once the certificate expires, the app stops working.

A similar issue is mentioned here for the need to delete individual certificates from a repo: #10502

@CihanBoz Correct, it throws an error because match doesn’t really know (right now) if it was revoked manually by someone, expired, or if some other error occurred. match prompts for the error because it doesn’t want to do anything unknown/dangerous to the user and their certs

That being said… I think we could create an option to recreate cert (mini nuke) if something like this occurs (so that its at least somewhat opt-in). Thoughts on that?

My workflow after I receive 30 days expiration notification from Apple (tried on dev and appstore certs):

1. Remove certs and profiles from repo
2. Revoke profiles from Dev Portal
3. Run match to regenerate everything

I guess in case of already expired certs it will be:

1. Remove certs and profiles from repo
2. Run match to regenerate everything

It would be really nice to have this automated by match, like it is now with push certs. If expiration date is less, than N days - do the way I described.

The only way I found to do this right now is to manually update the profile/certificate in the git repo:

1. Launch irb in your terminal and run the following:

require 'match'
git_url = '<url to your git repo, you can find this in your Matchfile>'
workspace = Match::GitHelper.clone(git_url, false)

Don’t close IRB yet, copy the workspace directory path

1. Run open <workspace directory> so it opens in finder on your machine`
2. Replace your .cer and .p12 files inside the certs folder, the .p12 should be just the key exported with no password on it (make sure it has identical name as before)
3. Replace your provisioning profile inside the profiles folder (make sure it has identical name as before)
4. Return to IRB and run Match::GitHelper.commit_changes(workspace, "Manual Update", git_url)
5. Run fastlane match <env>

This should be built into fastlane match as an option, nuking stuff from the program portal just to renew profiles is extremely dangerous as for enterprise deployments can disable the app and we have to renew these and push updates before the old profiles expire.

A possible solution to force Fastlane match to stop using the certificate that is about to expire is to remove manually the certificate and the private key from the fastlane repo. This is similar to @oanhof. This should force match to create new iOS Distribution certificate and use it to generate provisionings further. The old non-expired certificate will remain active until expiration. So all Enterprise apps will continue to work. But you will have time to resign these apps with the new provisioning and notify the users that the app needs to be updated.

I will test this tomorrow. From my experience with ‘match’ so far it seems that should work!

@ohayon I can run fastlane match nuke distribution but I’m looking for an alternative. An expiring distribution cert is something most users will encounter once a year. I’m wondering what to do when that happens.

• Do I wait until the cert expires and then run fastlane match appstore --force. Will that automatically create a new cert if the old one is expired?
• Do I have to run fastlane match nuke distribution every year?

@joshdholtz First of all, thank you for looking into it!

I would also like to fix the App Store expiring issue but that one is a bit harder to test since I can’t manually expire a certificate on the iOS Developer Center

When an certificate expires IMHO it just disappears from the Dev Center, it is the same behaviour like when you press “revoke” manually. So if match doesn’t find the certificate anymore in the Dev Center it could/should create a new one. If I remember correctly the current behaviour of match is to throw an error that the certificate is not in the Dev Center and that is it, right?

Just to mention that the approach described by me above is working fine.

Fastlane always saves a lot of time and it’s almost perfect. But I still hope these hiccups can get fixed or improved. I just solved it by manually deleting my debug certs and profiles for my app. I can’t use nuke because I also have many certs and profiles for other apps on it. There’s also the fact I don’t like manually touching something that has been entirely generated by some system, as it is the case with the fastlane match repo.

+1

It’s a shame that fastlane offers match but fails to handle expiring certificates without forcing the user to nuke or manually editing the repo, as previously also documented in #10395 and #10076. Would be really great to see this improved and even better to allow preemptively creating new certificates before they expire.

I have done some work and did a work around my side.

Basically problem with fastlane is not getting expired profile in the list at all.

Spaceship.provisioning_profile.all

Never gives expired profile. It can get invalid profile but not expired.

If this is fixed then the existing code will work.

How its working now.

1. when certificate expires in developer portal. that is automatically removed in dev portal.
2. profile expired in dev portal but not removed.
3. Run match now.
4. creates the new certificate.
5. tying to create profile with AppStore_bundleid. where expired profile preset in dev portal. so getting this error error respone - {“responseId”=>“22222222-33333-4335-a1bc-ce2269bb9153”, “resultCode”=>35, “resultString”=>“There were errors in the data supplied. Please correct and re-submit.”, “userString”=>“Multiple profiles found with the name ‘match AppStore com.example.mobile’. Please remove the duplicate profiles and try again.”, “creationTimestamp”=>“2019-01-08T19:53:38Z”, “protocolVersion”=>“QH6333”, “userLocale”=>“en_US”, “requestUrl”=>“url…”, “httpCode”=>200, “validationMessages”=>[{“validationKey”=>“provisioningProfileName”, “validationUserMessage”=>“Multiple profiles found with the name ‘match AppStore com.example.mobile’. Please remove the duplicate profiles and try again.”}]}
6. Also now match did clears the storage… so p12 is not checked in too.

My work around is generate a new name that can be created.

Fix needed is expired profile should be accessible.

@joshdholtz That sounds like a great suggestion and it would be backwards compatible as well 👍

@BObereder Just had the same problem. Fixed it by manually deleting the expired certificate from our match git repository and running fastlane match appstore again.