This will allow us to add a --no-roots option to
hxtool copy-certificate
which is convenient when copying certificate chains from stores that may
include root CA certificates.
Add two ways to exclude private keys when dealing with an hx509
certificate store. One as a load option (load no private keys, never
add private keys), one as a store option (store no private keys).
This is useful for CA code so it can have a single store with the
issuer's credentials _and_ the chain for it, and copy those to a store
with the issued certificate and _not_ accidentally include the issuer's
private key.
It would be much safer still to flip the default for this flag, but that
could break out-of-tree libhx509 dependents.
Most consumers of PEM files don't care about the order in which private
keys and certificates are stored. However, Postfix does care when
multiple EE certs (and chains) are stored in a file, in which case it
requires that private keys come before their certificates.
Now we'll use mkostemp() and rename() into place to make
hx509_certs_store() atomic for FILE/DER-FILE/PEM-FILE stores.
This is not ideal, as it can leave temp files in place if a process
crashes in between the mkostemp() and the rename into place.
On Linux we'll eventually make use of O_TMPFILE and linkat(). The idea
will be to first create an anonymous, zero-link file in the directory
that will contain the file at the end, write the file, then linkat() the
file into place as a .new file, then rename() the .new into place. That
will limit the amount of junk that may be left behind to just one file.
(If the linkat() fails, then unlink() the .new and try again. If the
rename() fails that just means the caller raced with another and the
operation is complete.)
We should really make a lib/roken interface that does this.
This commit adds:
- hx509_cert_init_private_key() for creating an hx509_cert object that
has just a private key
- hx509_cert_have_private_key_only() for checking whether an hx509_cert
object has just a private key
This also generalizes the get_key() internal function in hxtool, which
is tasked with reding or generating a private key for use in signing
CSRs. Now hxtool request-create can read/write private keys to/from PEM
files, not just DER files.
This is needed to support key types other than just RSA for CSRs and
certificates.
On 32-bit Windows Intel builds the __cdecl and __stdcall calling
conventions are different so labeling the functions that are
exported or assigned to function pointers matters.
Change-Id: I03b6f34baeb9ffb2e683fd979f12f27a5078a4da
libhx509 is not built according to the same export and calling conventions
on Windows as the other libraries. This change declares and applies
HX509_LIB_FUNCTION, HX509_LIB_NORETURN_FUNCTION, HX509_LIB_CALL and
HX509_LIB_VARIABLE to lib/hx509.
As a result of this change the calling convention for exported functions
will be __stdcall instead of __cdecl.
Change-Id: Ibc3f05e8088030ef7d13798f1d9c9b190bc57797
This adds a new backend for libhcrypto: the OpenSSL backend.
Now libhcrypto has these backends:
- hcrypto itself (i.e., the algorithms coded in lib/hcrypto)
- Common Crypto (OS X)
- PKCS#11 (specifically for Solaris, but not Solaris-specific)
- Windows CNG (Windows)
- OpenSSL (generic)
The ./configure --with-openssl=... option no longer disables the use of
hcrypto. Instead it enables the use of OpenSSL as a (and the default)
backend in libhcrypto. The libhcrypto framework is now always used.
OpenSSL should no longer be used directly within Heimdal, except in the
OpenSSL hcrypto backend itself, and files where elliptic curve (EC)
crypto is needed.
Because libhcrypto's EC support is incomplete, we can only use OpenSSL
for EC. Currently that means separating all EC-using code so that it
does not use hcrypto, thus the libhx509/hxtool and PKINIT EC code has
been moved out of the files it used to be in.
