Why does Apple create a certificate for my push notification key Brief rundown of how Apple Push Notifications (APN) work:


Generate a keypair, generate a CSR for it
Upload the latter to your Apple Developer account and associate it with your mobile app
In the process, your CSR is signed and you get to download the certificate
Connect to the APN server using the key + certificate, send your notifications


Note that this is a separate key/certificate just for push notifications. It is distinct from the code signing key, and not used anywhere else. And, TTBOMK, the mobile phones never see that key, they verify that push notifications are genuine based on the fact that they receive them via a secure channel from the Apple HQ.

Here is my alternative, simpler idea: create a keypair and upload the public half to Apple. You can then send messages by authenticating with the private key.

So, why does Apple sign my key? What do I actually use the certificate for, while connecting? Is that signing dance done because SSL supports client certs but does not support bare private keys?

I'm not a cryptography expert, so please correct any wrong assumptions I've made!
I'm guessing that the need for a certificate has nothing to do with authenticating the upload, but so that people's iPhones can authenticate the app at install time / runtime.

[Ah, I see your edit that this is not right. I'll leave it here for posterity anyway. Are you sure you can't find documentation for this somewhere?]


As a developer, you create code-signing keys for yourself.
You announce to Apple "Yo Apple, I'm the developer of this app, and here's my code-signing key".
Apple makes a certificate out of your public key, telling the world that Apple agrees that you are the rightful developer of this app.
Apple distributes this certificate along with your app to millions (we hope!) of end-users who download your app.
Any update you push must be signed by the same code-signing key as the original, otherwise the end-user iPhones will reject it. (How to you prevent malicious updates and NSA-style sideloading?)




I'll also address this part of your question:


  Is that signing dance done because SSL supports client certs but does not support bare private keys?


No, SSL does not support "bare private keys" and here's why: how do I know who the private key belongs to? Any bloke can walk up and say "Hi, I'm Christian Aichinger, here's my public key, and I'm going to use the corresponding private key to sign some data". Ok, fine, but how do I know that I'm talking to the real Christian Aichinger, and not somebody pretending to be them. 

The commonly accepted way to solve this is to have some third party that we both trust verify that you are who you say you are, and that this public key does in fact belong to you. That trusted third-party is called a Certificate Authority, and that statement that this public key belongs to you is called a Certificate.