Lines Matching refs:certificate
15 <li><a href="#UnknownCa">Unknown certificate authority</a></li>
16 <li><a href="#SelfSigned">Self-signed server certificate</a></li>
17 <li><a href="#MissingCa">Missing intermediate certificate authority</a></li>
50 <p>In a typical SSL usage scenario, a server is configured with a certificate containing a
52 and server, the server proves it has the private key by signing its certificate with <a
55 <p>However, anyone can generate their own certificate and private key, so a simple handshake
57 matches the public key of the certificate. One way to solve this problem is to have the client
58 have a set of one or more certificates it trusts. If the certificate is not in the set, the
63 certificate with a new one. Unfortunately, now the client app has to be updated due to what
74 in each release. Similar to a server, a CA has a certificate and a private key. When issuing
75 a certificate for a server, the CA <a
77 the server certificate using its private key. The
78 client can then verify that the server has a certificate issued by a CA known to the platform.</p>
82 server you want. To address this, the certificate issued by the CA identifies the server
88 tool's {@code s_client} command looks at Wikipedia's server certificate information. It
103 <p>You can see that the certificate was issued for servers matching <em>*.wikipedia.org</em> by
111 certificate issued by a well known CA, you can make a secure request with code as
151 <li><a href="#UnknownCa">The CA that issued the server certificate was unknown</a></li>
152 …<li><a href="#SelfSigned">The server certificate wasn't signed by a CA, but was self signed</a></l…
161 <h3 id="UnknownCa">Unknown certificate authority</h3>
165 you have a certificate from a new CA that isn't yet trusted by Android or your app is
185 connection will use your CAs for certificate validation.</p>
230 that your server certificate come from a trusted issuer.</p>
239 certificate and—without a {@link javax.net.ssl.TrustManager} that actually
240 validates that the certificate comes from a trusted
242 always make your app trust the issuer of the server's certificate, so just do it.</p>
246 <h3 id="SelfSigned">Self-signed server certificate</h3>
249 due to a self-signed certificate, which means the server is behaving as its own CA.
250 This is similar to an unknown certificate authority, so you can use the
254 this time trusting the server certificate directly. This has all of the
255 downsides discussed earlier of tying your app directly to a certificate, but can be done
256 securely. However, you should be careful to make sure your self-signed certificate has a
264 <h3 id="MissingCa">Missing intermediate certificate authority</h3>
268 CAs don't sign server certificates directly. Instead, they use their main CA certificate,
272 certificate—signed by the intermediate CA—and the certificate verifier,
274 this, the server doesn't send the client only it's certificate during the SSL handshake, but
278 <p>To see what this looks like in practice, here's the <em>mail.google.com</em> certificate
294 <p>This shows that the server sends a certificate for <em>mail.google.com</em>
295 issued by the <em>Thawte SGC</em> CA, which is an intermediate CA, and a second certificate
313 does not cause an error like a completely unknown CA or self-signed server certificate would
316 need to have the intermediate CA included in the certificate chain the next time.</p>
319 example, they might have their main HTML page served by a server with a full certificate
340 is to verify the certificate is from a trusted source, which was the focus of the previous
342 talking to presents the right certificate. When it doesn't, you'll typically see an error
358 configured with a certificate that does not have a subject or subject alternative name fields
359 that match the server you are trying to reach. It is possible to have one certificate be used
360 with many different servers. For example, looking at the <em>google.com</em> certificate with
365 are connecting to isn't listed by the certificate as acceptable.</p>
371 HTTPS, because the server has to know which certificate to return before it sees the HTTP
375 hostname to the server so the proper certificate can be returned.</p>
381 virtual host on a unique port so that it's unambiguous which server certificate to return.</p>
434 far to deal with certificate verification issues also apply to {@link javax.net.ssl.SSLSocket}.
451 <em>gmail.com</em> port 443 without SNI support, you'll receive a certificate for
453 the certificate is indeed for <em>mail.google.com</em>:</p>
469 // At this point SSLSocket performed certificate verificaiton and