5 ms·
Ah - that might explain why I had trouble trying to sniff the data for QuizUp too. I didn't know you could do that, so thanks!
by coffeecheque 12y ago
Ah - that might explain why I had trouble trying to sniff the data for QuizUp too.
I didn't know you could do that, so thanks!
- Chris911 12y agoYep no luck for QuizUp here as well.
- e28eta 12y agoDownside: can't change to a new SSL cert without updating the clients!
- wiml 12y agoWhat I do is I generate an inhouse CA for uses like these and hardcode its certificate into the clients: the key used by the API server can then be changed whenever necessary, just as if it were signed by a commercial CA.
- ohnoberyn 12y agoWould you be able to expand on how you generate an inhouse CA? From Googling I don't think you're becoming an intermediate CA as that seems extremely costly! I am in the situation where I have a pinned cert in my app and I will have to address it's expiration in the future!
- Robin_Message 12y agoSince you are hard-coding the CA, it doesn't have to be an actual intermediate CA that is trusted by anyone except for your app (that has it hard-coded.) But as people say, they could easily edit your binary to change the CA, or disable the CA check entirely, so, like any DRM system, you can't keep the protocol secret.
- wiml 12y agoIt can be done using openssl (the documentation is a bit opaque but it's not hard to do). As Robin_Message says, I'm not becoming an intermediate CA — I'm generating my own root CA, which no one except me and my apps trust. In turn, my apps contain only my own CA as a trust root. There really isn't an advantage to using a commercial CA here, beyond the fact that their web portal is probably easier to use than the openssl command line.