This is necessary in order to have more control over, e.g., template
certificates for kx509. But also it's good to have this more generally.
Some batteries not included. Specifically: no attempt is made to validate that
given KeyUsage values are compatible with the subjectPublicKey's alrogithm and
parameters.
```
hxtool request-create --subject=... \
--generate-key=... \
--key-bits=... \
--key=STORE \
store
```
wants to generate a key, store it in the location specified by the --key
argument, then read it back, then generate the CSR, and store it in
`store`.
But it didn't work because for generating a key this really wants the
`--key` argument to be a file path into which a raw DER-encoded RSA key
will be written (only RSA is supported, ay!), but for reading the key
back it uses `hx509_certs_init()`, which wants `TYPE:name` keystore
specification. A deadly embrace.
Now that we have improved libhx509 functionality for reading/writing
private keys from/to PEM files we use this functionality and require a
store type in the `--key=STORE` argument.
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.
Modern OpenSSL no longer has the 2038 year restriction. Update the
certs to last 500 years rather than 10 years.
Modern crypto requirements suggest a stronger key strength than 1024.
Update to use a minimum of 4096.
Fix executable bit on gen-req.sh
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
Using non-reentrant getpwuid() (or getpwnam(), or getspnam()) can be
dangerous. We had a report of a login application / PAM that calls
those, and Heimdal, by calling them too, clobbered the cached struct
passwd used by the login app / PAM.
OpenSSL 1.1 has the pkInitKDC OID built in, which breaks as it was redefined by
openssl.cnf in Heimdal. Try to determine if OpenSSL >= 1.1 and if so, use a
configuration file that omits this OID definition. The implementation is not
robust but as this is simply an example (not run by the test suites), it should
be adequete.
When comparing the first component of a multi-component
string that uses a field separator (e.g., '/' or ':'), be sure
to include the separator in the comparison to ensure that the
comparison does not succeed due to a prefix match.
Change-Id: Ieec3e73cb015a83bb652ec11cd7d83e57755c3d2
For consistency make "-I" part of the macro value set by autoconf.
For now, don't attempt to handle OpenSSL rpath in cf/crypto.m4.
That's much easier by just setting LDFLAGS when running configure.
Otherwise too many Makefiles to edit and libtool and automake do
their best to undo the rpath.
We added some new OID symbols in libasn1, make them public.
When an older Heimdal is already installed and its libraries don't
have some newly created symbols we run into build or test problems,
if libtool decides to use installed rather than just-built libraries.
This was happening with a few of test programs in libhx509. Fixed.
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.
