Lines Matching full: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>
51 <p>In a typical SSL usage scenario, a server is configured with a certificate containing a
53 and server, the server proves it has the private key by signing its certificate with <a
56 <p>However, anyone can generate their own certificate and private key, so a simple handshake
58 matches the public key of the certificate. One way to solve this problem is to have the client
59 have a set of one or more certificates it trusts. If the certificate is not in the set, the
64 certificate with a new one. Unfortunately, now the client app has to be updated due to what
72 href="http://en.wikipedia.org/wiki/Certificate_authority">Certificate Authorities (CAs)</a>.
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
78 the server certificate using its private key. The
79 client can then verify that the server has a certificate issued by a CA known to the platform.</p>
83 server you want. To address this, the certificate issued by the CA identifies the server
89 tool's {@code s_client} command looks at Wikipedia's server certificate information. It
104 <p>You can see that the certificate was issued for servers matching <em>*.wikipedia.org</em> by
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></li>
162 <h3 id="UnknownCa">Unknown certificate authority</h3>
166 you have a certificate from a new CA that isn't yet trusted by Android or your app is
186 connection will use your CAs for certificate validation.</p>
197 Certificate ca;
231 that your server certificate come from a trusted issuer.</p>
240 certificate and—without a {@link javax.net.ssl.TrustManager} that actually
241 validates that the certificate comes from a trusted
243 always make your app trust the issuer of the server's certificate, so just do it.</p>
247 <h3 id="SelfSigned">Self-signed server certificate</h3>
250 due to a self-signed certificate, which means the server is behaving as its own CA.
251 This is similar to an unknown certificate authority, so you can use the
255 this time trusting the server certificate directly. This has all of the
256 downsides discussed earlier of tying your app directly to a certificate, but can be done
257 securely. However, you should be careful to make sure your self-signed certificate has a
265 <h3 id="MissingCa">Missing intermediate certificate authority</h3>
269 CAs don't sign server certificates directly. Instead, they use their main CA certificate,
273 certificate—signed by the intermediate CA—and the certificate verifier,
275 this, the server doesn't send the client only it's certificate during the SSL handshake, but
279 <p>To see what this looks like in practice, here's the <em>mail.google.com</em> certificate
286 Certificate chain
295 <p>This shows that the server sends a certificate for <em>mail.google.com</em>
296 issued by the <em>Thawte SGC</em> CA, which is an intermediate CA, and a second certificate
307 Certificate chain
314 does not cause an error like a completely unknown CA or self-signed server certificate would
317 certificate chain the next time.</p>
320 example, they might have their main HTML page served by a server with a full certificate
341 is to verify the certificate is from a trusted source, which was the focus of the previous
343 talking to presents the right certificate. When it doesn't, you'll typically see an error
359 configured with a certificate that does not have a subject or subject alternative name fields
360 that match the server you are trying to reach. It is possible to have one certificate be used
361 with many different servers. For example, looking at the <em>google.com</em> certificate with
366 are connecting to isn't listed by the certificate as acceptable.</p>
372 HTTPS, because the server has to know which certificate to return before it sees the HTTP
376 hostname to the server so the proper certificate can be returned.</p>
382 virtual host on a unique port so that it's unambiguous which server certificate to return.</p>
435 far to deal with certificate verification issues also apply to {@link javax.net.ssl.SSLSocket}.
452 <em>gmail.com</em> port 443 without SNI support, you'll receive a certificate for
454 the certificate is indeed for <em>mail.google.com</em>:</p>
470 // At this point SSLSocket performed certificate verificaiton and
