SSL pinning with *.appspot.com: How can I know when Google is going to change their public key?

Question

I have an iOS app that is about to go live in the App Store that uses Google App Engine as its server backend. Bundled in the app binary is the *.appspot.com. wildcard certificate to allow me require SSL pinning of any HTTPS connection using the bundled certificate's public key. This helps prevent man-in-the-middle attacks on my client/server communication.

When I set this up, I knew that Google cycled their *.appspot.com. certificates every month or two. However, I was expecting appspot.com to use the same public key from month to month so that communication between my app and server wouldn't be broken.

However, in the latest certificate, without any warning, Google has changed their public key. Now my app is DOA as far as communicating with my server goes. Am I wrong to have tried to use SSL pinning with the *.appspot.com. certificate? Does Google notify developers when they are going to change their public key? Should I be using my own certificate with a custom domain instead?

Answer 1

In an interesting coincidence, I've just done a first pass of editing on a future blog post about pinning (among other responsibilities I curate Cloud tech support blog posts) so there is absolutely no doubt on my mind about this:

Am I wrong to have tried to use SSL pinning with the *.appspot.com. certificate?

Yep.

Does Google notify developers when they are going to change their public key?

Nope, whence the above.

Should I be using my own certificate with a custom domain instead?

Yes, exactly. More generally, pinning only to public keys you control is a best-practice.

Other advice from that future blog post: a certain fraction of your app's users just won't update -- so how you can ever do any rotation of your pin-set? If e.g 5% of your users don't update, are you OK with cutting them off? The blog's advice is to have the app bypass its own pinning checks if it knows it's too old -- say, if system time is at least six weeks later than the build-time baked into the app at compile time; at least, this way, the non-updater "bricking" is temporary, not permanent...