3 ms·
Hint: the web is one thing, but if you're deploying a library that talks to your own server, consider embedding your own root certificate. In addition to veri
by kogir 14y ago
Hint: the web is one thing, but if you're deploying a library that talks to your own server, consider embedding your own root certificate. In addition to verifying the traffic isn't being proxied[1], you can also issue 10 or 20 year certs and be done.
[1] Users can add their own root certs and watch your traffic (typically with the intent of breaking your app), or worse, companies can deploy roots to all their devices and sniff their employees' traffic. Why be complicit?
- j_s 14y agoIf you have your own cert, wouldn't it be best to ignore expiration (and decide based on risk whether or not to implement revocation)? Unless you are saying to add the cert to the device/computer's list of trusted certs, which doesn't seem necessary to me. All of Google's pinned certs are certainly evidence that this is a reasonable approach (I haven't looked at their expirations), though now it's kind of weird since it can't be MitM'd even to debug -- no one knows what is being shipped off to Google by Chrome anymore without reverse engineering binaries.
- sk5t 14y agoIssuing inordinately long-lived certificates might not be the best security decision. To put it another way, "infinity" is not the appropriate lifetime for a 4096-bit cert.