U tweetove putem weba ili aplikacija drugih proizvođača možete dodati podatke o lokaciji, kao što su grad ili točna lokacija. Povijest lokacija tweetova uvijek možete izbrisati. Saznajte više
I wonder why does it even touch the supplied CA certificate. Shouldn't it simply get the CA certificate from the trusted store, keyed by the signer Subject/KeyID listed in the child certificate?
I'd suspect it's because the chain verification is distinct from whether the chain is trusted by policy. Therefore you supply the full chain with the bogus cert, which checks out okay. Then the trust is checked, it compares AuthKeyIDs and find a matching trusted root. Job done!
Basically. Trust settings are stored on the PCCERT_CONTEXT associated with the HCERTSTORE it came from (as PROP_IDs plus the source of the store they came from). Standard practice for chain building (not just win) is for supplied certs, to replace with the trust anchor you have
You do sig verification of each node first (using supplied), then you try to swap supplied with any trust anchors you have. Also, Microsoft has really weird-ass behaviour with AKIs/SKIs that let you bypass the name checks and just be sig checks. See https://social.technet.microsoft.com/wiki/contents/articles/4954.windows-xp-certificate-status-and-revocation-checking.aspx …
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.
