* Nikos Mavrogiannopoulos <[email protected]> [10-06-21 13:06]: > On Mon, Jun 21, 2010 at 12:43 PM, Lars Noschinski > <[email protected]> wrote: > > >> I don't see any normal situation where this flag is useful. > >> > >> I'm not sure the behaviour you see is actually intended, I don't see why > >> it should reject the chain here. So it may be a bug... > >> > >> The flag _may_ be useful if you have a X.509 Version 1 certificate as a > >> trust anchor. You may want to trust a X.509v1 CA for verifying server > >> certificates signed by the X.509v1 CA, but you definitely do not want to > >> accept that certificate as the server certificate (because there are no > >> name restriction extensions). On the other hand, you shouldn't use > >> X.509v1 certificates anyway... > > > > Just to clarify: Using GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT without > > GNUTLS_VERIFY_DO_NOT_ALLOW_SAME is a sane choice (if one stills needs to > > deal with X.509v1 certificates). > > The GNUTLS_VERIFY_DO_NOT_ALLOW_SAME is a flag, to make the trusted > certificate list, a list that can only certify other keys. That is it > will not allow a certificate from this list to be used as a server > certificate. So how it works it depends on your usage of this list. If > you add end server certificates there maybe > GNUTLS_VERIFY_DO_NOT_ALLOW_SAME is not a good option for you. But for > other uses it is quite sensible.
Ok. But in this case, the behaviour I observed seems to be indeed a bug in gnutls, as my certificate list did not contain the server's certificate, but only the CA certificates. _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
