Commit graph

19 commits

Author SHA1 Message Date
Dr. Stephen Henson
2e1d669cba Tolerate some "variations" used in some
certificates.

One is a valid CA which has no basicConstraints
but does have certSign keyUsage.

Other is S/MIME signer with nonRepudiation but
no digitalSignature.
2001-02-01 02:03:58 +00:00
Dr. Stephen Henson
2f043896d1 *BIG* verify code reorganisation.
The old code was painfully primitive and couldn't handle
distinct certificates using the same subject name.

The new code performs several tests on a candidate issuer
certificate based on certificate extensions.

It also adds several callbacks to X509_VERIFY_CTX so its
behaviour can be customised.

Unfortunately some hackery was needed to persuade X509_STORE
to tolerate this. This should go away when X509_STORE is
replaced, sometime...

This must have broken something though :-(
2000-09-05 17:53:58 +00:00
Richard Levitte
26a3a48d65 There have been a number of complaints from a number of sources that names
like Malloc, Realloc and especially Free conflict with already existing names
on some operating systems or other packages.  That is reason enough to change
the names of the OpenSSL memory allocation macros to something that has a
better chance of being unique, like prepending them with OPENSSL_.

This change includes all the name changes needed throughout all C files.
2000-06-01 22:19:21 +00:00
Geoff Thorpe
ccd86b68ef The previous commit to crypto/stack/*.[ch] pulled the type-safety strings
yet tighter, and also put some heat on the rest of the library by
insisting (correctly) that compare callbacks used in stacks are prototyped
with "const" parameters. This has led to a depth-first explosion of
compiler warnings in the code where 1 constification has led to 3 or 4
more. Fortunately these have all been resolved to completion and the code
seems cleaner as a result - in particular many of the _cmp() functions
should have been prototyped with "const"s, and now are. There was one
little problem however;

X509_cmp() should by rights compare "const X509 *" pointers, and it is now
declared as such. However, it's internal workings can involve
recalculating hash values and extensions if they have not already been
setup. Someone with a more intricate understanding of the flow control of
X509 might be able to tighten this up, but for now - this seemed the
obvious place to stop the "depth-first" constification of the code by
using an evil cast (they have migrated all the way here from safestack.h).

Fortunately, this is the only place in the code where this was required
to complete these type-safety changes, and it's reasonably clear and
commented, and seemed the least unacceptable of the options. Trying to
take the constification further ends up exploding out considerably, and
indeed leads directly into generalised ASN functions which are not likely
to cooperate well with this.
2000-06-01 02:36:58 +00:00
Dr. Stephen Henson
0cb957a684 Fix for SSL server purpose checking 2000-05-04 23:03:49 +00:00
Dr. Stephen Henson
068fdce877 New compatability trust and purpose settings. 2000-03-07 14:04:29 +00:00
Bodo Möller
6d0d5431d4 More get0 et al. changes. Also provide fgrep targets in CHANGES
where the new functions are mentioned.
2000-02-26 08:36:46 +00:00
Dr. Stephen Henson
c7cb16a8ff Rename functions for new convention. 2000-02-26 01:55:33 +00:00
Dr. Stephen Henson
ff8a4c47ce Rename the X509V3_*_d2i functions to X509_get_ext_d2i() etc.
This better reflects their behaviour.
2000-02-07 01:17:22 +00:00
Ulf Möller
731d9c5fb5 Some more ifdefs for no-xxx options. 2000-01-21 00:03:51 +00:00
Dr. Stephen Henson
6ea5314007 Fix a bug in the modified purpose code: it wasn't updated to use the
new purpose getting function.

Update the ca-cert.pem and pca-cert.pem "CA" certificates so they
really are CA certificate: that is they have the appropriate extensions.
1999-12-03 00:53:48 +00:00
Dr. Stephen Henson
dd4134101f Change the trust and purpose code so it doesn't need init
either and has a static and dynamic mix.
1999-12-02 02:33:56 +00:00
Dr. Stephen Henson
13938aceca Add part of chain verify SSL support code: not complete or doing anything
yet.

Add a function X509_STORE_CTX_purpose_inherit() which implements the logic
of "inheriting" purpose and trust from a parent structure and using a default:
this will be used in the SSL code and possibly future S/MIME.

Partial documentation of the 'verify' utility. Still need to document how all
the extension checking works and the various error messages.
1999-11-29 01:09:25 +00:00
Dr. Stephen Henson
51630a3706 Add trust setting support to the verify code. It now checks the
trust settings of the root CA.

After a few fixes it seems to work OK.

Still need to add support to SSL and S/MIME code though.
1999-11-27 19:43:10 +00:00
Dr. Stephen Henson
d4cec6a13d New options to the -verify program which can be used for chain verification.
Extend the X509_PURPOSE structure to include shortnames for purposed and default
trust ids.

Still need some extendable trust checking code and integration with the SSL and
S/MIME code.
1999-11-26 00:27:07 +00:00
Dr. Stephen Henson
e947f39689 New function X509_cmp(). 1999-11-16 00:56:03 +00:00
Dr. Stephen Henson
ce1b4fe146 Allow additional information to be attached to a
certificate: currently this includes trust settings
and a "friendly name".
1999-11-04 00:45:35 +00:00
Bodo Möller
798757762a Improve support for running everything as a monolithic application.
Submitted by: Lennart Bång, Bodo Möller
1999-10-25 19:36:01 +00:00
Dr. Stephen Henson
673b102c5b Initial support for certificate purpose checking: this will
ultimately lead to certificate chain verification. It is
VERY EXPERIMENTAL at present though.
1999-10-13 01:11:56 +00:00