What makes a certificate invalid?

[Daniel Kahn Gillmor]

Hi Kunal--

On 12/10/2009 06:55 PM, Shanishchara, Kunal wrote:
> What makes a certificate invalid? 

There are many things that could make one side of a TLS connection
consider the other side's certificate invalid.  For example, the
certificate offered by the remote party could:

 0) be expired

 1) be not-yet-valid

 2) be issued by an unknown or untrusted certificate authority

 3) be issued by a known, trusted certificate authority, but during a
time that CA's own certificate was either expired or not-yet-valid.

 4) have no common name or SubjectAltName matching the expected name of
the remote party (e.g. an otherwise-valid certificate for foo.example
would not be valid if you were trying to connect to bar.example)

 5) have the wrong certificate properties for the type of connection
(e.g. a certificate that indicates it is good for use only as a TLS
client would be considered invalid when received from a TLS server)

 6) use a bad digest algorithm in the signature (e.g. if the certificate
was signed over an MD2 digest, most reasonable X.509 implementations
would consider it invalid because it is forgeable)

 7) have a bad signature (e.g. if the signature in the certificate was
originally calculated over the wrong data, or if someone tampered with
the certificate in transit)

 8) have the wrong properties for the parameters of the TLS connection
(e.g. a TLS connection made using RSA for key agreement won't work if
the server's certificate does not have the "Key Encipherment" (i think!)
X509v3 Usage flag set)

 9) simply be malformed

I'm sure someone else can come up with possible ways i've missed that a
certificate could be invalid ;)

> During a TLS handshake, if the Common name parameter does not match
> between the client and server, is the handshake suppose to fail?

If the certificate presented by the other side of the communication
doesn't match who you think you should be talking to, why would you go
on talking to them?  The reason the handshake should fail at that point
is because *no secure communications link has been established*.

You have an encrypted channel to talk to *something*, but you don't know
who is actually on the other end.  For example, it could be an attacker
who turns around and relays your communications to your expected end
party (a so-called "man in the middle" attack).  Then the attacker can
effectively see all the traffic in the clear (snooping!), and can even
make changes to it before relaying to the remote party (tampering!).
This is does not meet the security guarantees that TLS would like to make.

does this answer your question?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20091210/59d90231/attachment.pgp>