Lines Matching refs:CA
75 in each release. Similar to a server, a CA has a certificate and a private key. When issuing
76 a certificate for a server, the CA <a
79 client can then verify that the server has a certificate issued by a CA known to the platform.</p>
81 <p>However, while solving some problems, using CAs introduces another. Because the CA issues
83 server you want. To address this, the certificate issued by the CA identifies the server
96 and the issuer, which identifies the CA.</p>
101 <b>issuer=</b> /C=US/O=GeoTrust, Inc./CN=<b>RapidSSL CA</b>
105 the RapidSSL CA.</p>
112 certificate issued by a well known CA, you can make a secure request with code as
152 <li><a href="#UnknownCa">The CA that issued the server certificate was unknown</a></li>
153 …<li><a href="#SelfSigned">The server certificate wasn't signed by a CA, but was self signed</a></l…
154 <li><a href="#MissingCa">The server configuration is missing an intermediate CA</a></li>
165 because you have a CA that isn't trusted by the system. It could be because
166 you have a certificate from a new CA that isn't yet trusted by Android or your app is
167 running on an older version without the CA. More often a CA is unknown because it isn't a
168 public CA, but a private one issued by an organization such as a government, corporation,
173 can be a little convoluted, so below is an example that takes a specific CA from
189 full using an organizational CA from the University of Washington:</p>
250 due to a self-signed certificate, which means the server is behaving as its own CA.
268 occurs due to a missing intermediate CA. Most public
269 CAs don't sign server certificates directly. Instead, they use their main CA certificate,
270 referred to as the root CA, to sign intermediate CAs. They do this so the root CA can be stored
273 certificate—signed by the intermediate CA—and the certificate verifier,
274 which knows the root CA. To solve
276 a chain of certificates from the server CA through any intermediates necessary to reach a
277 trusted root CA.</p>
288 i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
289 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
296 issued by the <em>Thawte SGC</em> CA, which is an intermediate CA, and a second certificate
297 for the <em>Thawte SGC</em> CA issued by a <em>Verisign</em> CA, which is the primary CA that's
301 intermediate CA. For example, here is a server that can cause an error in Android browsers and
309 …Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3
314 does not cause an error like a completely unknown CA or self-signed server certificate would
316 a browser has visited and learned about an intermediate CA from one site, it won't
317 need to have the intermediate CA included in the certificate chain the next time.</p>
322 CA, presumably to save bandwidth. Unfortunately, sometimes these servers might be providing
328 include the intermediate CA in the server chain. Most CAs provide documentation on how to do
332 intermediate CA like any other unknown CA, and create a {@link javax.net.ssl.TrustManager}
496 technique known as pinning. This is basically using the example provided in the unknown CA case