If what you're saying is correct, self-signed cert is not a "hard" requirement, but rather a questionable practice and in this regard, I'm curious if I'll have any problems with publishing apps on Android market when use non self-signed certs, but the ones signed by an approved CA?
On a separate note, yet another reason why I don't like self-signed cert is that it undermines the value of all fields that X.509 certificate usually has (e.g. DN) and reduces it to a primitive binary blob. If you don't know anything about a signer and don't have anyone to ask about him, which is the case with self-signed certs, then you should not really trust to the content provided in its fields. On Jan 18, 12:54 am, David Herges <[email protected]> wrote: > What you actually do talk about is code signing verification. iOS and > BlackBerry have these security measures. Upon execution, the signing > certificate is validated by checking against trusted root certificates and, > if that verification succeeds, the application is executed. Otherwise, it > is not. > > Android does not have this security measure by default. The signing > certificate is just "a" X509 certificate, no matter whether self-signed, > issued by CA/PKI strategy, whatever. > > > > > > > > On Tuesday, 17 January 2012 18:57:24 UTC+1, Oleg Gryb wrote: > > > Is self-signed cert a "hard" requirement? It's kind of unusual. In my > > mindset, self-signed certs should be used in pre-prod environments > > only. The whole idea of CA is that everybody knows and trusts them and > > relies on them when something needs to be verified about a less known > > 3-rd party. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
