[cli] Fix development codesigning certificate validity checks

[wschurman]

Why

We need to validate that all certificates in the chain are valid instead of just the leaf (development) certificate. What we're seeing is that we forgot to rotate the Expo Go intermediate certificate at the required cadence of 1 year, so the intermediate cert being served is not valid. https://github.com/expo/universe/pull/14632 and expo/code-signing-certificates#1 rotate the cert, but since the CLI caches the cert it'll continue to try to use the cached development (only if offline) and intermediate cert for up to 30 days (if the user had just generated one).

This will need to be cherry-picked and released. In the meantime, the recommendation is just to go online once and then go back offline if the user so desires.

How

Check that all certificates in the cached chain are valid, otherwise report cache as null and re-fetch current from server.

Test Plan

1. create expo project
2. npx expo start
3. open in store version of Expo Go
4. see "Certificate not valid" error
5. Open codesigning cache file for project (~/.expo/codesigning/<project_id>/development-code-signing-settings-2.json)
6. start in offline mode
7. reload the app in Expo Go
8. see "Offline and no cached development certificate found, unable to sign manifest" since cached stuff is invalidated

Checklist

• Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md).
• Conforms with the Documentation Writing Style Guide
• This diff will work correctly for npx expo prebuild & EAS Build (eg: updated a module plugin).

[ide]

Not just forgetting to rotate, but if the signing certificate (the leaf) expires after the intermediate certificate, too, right?

Say the leaf expires on March 15 and the intermediate certificate expires on February 28. We rotate the intermediate certificate on February 27, but the client CLI uses the old intermediate certificate while it's in offline mode. You could make the argument that the leaf should not have such an expiration (feature for another PR?) but in this case, validating the intermediate certificate would be necessary.

[wschurman]

Theoretically if we rotate every year this will never be the case, but yeah, I agree. I thought about that (setting the leaf expiration to MIN(+30 days, intemediate expiration)) but in the end the result would be the same (invalid chain).

[ide]

I think it's still a good idea to have the child's expiration not exceed its parent's - it's too easy (like in this scenario) to look at just the child and see it's unexpired and to think it's valid, but not a necessary constraint to implement.

[wschurman]

I'll create a separate PR on expo/code-signing-certificates repo to add the min logic above. Going to wait for the leap day bug to be over though so I don't confuse myself: expo/code-signing-certificates#14 (comment)

[wschurman]

Probably not going to chery-pick this since the incident was resolved by just not running offline once (if the user is still experiencing symptoms). Still going to land this for correctness for the next version though.