What makes a certificate invalid?

[Rupert Kittinger-Sereinig]

last but not least:

10) the certificate is on a revocation list

cheers,
Rupert

Daniel Kahn Gillmor schrieb:
> 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
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnutls


-- 
Rupert Kittinger-Sereinig <rks at mur.at>
Krenngasse 32
A-8010 Graz
Austria