What makes a certificate invalid?
Rupert Kittinger-Sereinig
rks at mur.at
Fri Dec 11 17:52:44 CET 2009
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
More information about the Gnutls-help
mailing list