AWS-LC lacks support for a number of elliptic curve algorithms so this
adds some conditional macros to avoid registering the related plugin
features. Support for curves ed448 and x448 is completely absent and are
not planned for implementation as they are no longer recommended for use.
While ed25519 is supported by the library, a single missing API for
ASN.1 DER encoding of its private keys is missing which prevents its
use in strongSwan. Future work may remove this limitation, but for now
we will disable the functionality.
Closesstrongswan/strongswan#2109
AWS-LC is a BoringSSL-based libcrypto implementation. SHA_CTX is declared with
the hash data specified as an array rather than as a field in upstream OpenSSL.
Since AWS-LC builds against C99, we are unable to handle this with anonymous
unions like BoringSSL. The workaround I propose is to add these conditional
macros around the accessors within openssl_sha1_prf. After this change,
everything builds successfully with AWS-LC headers.
Closesstrongswan/strongswan#2103
Newer curl versions (as used on macOS via Homebrew) add attributes like
__attribute__ ((format(printf, a, b)))
to their `curl_*printf*` functions, which fails if we redefine `printf`
as e.g. `builtin_printf` (pulled in via library.h). We could disable
these checks via CURL_NO_FMT_CHECKS, but reordering the headers should
do the trick as well.
Some servers might not support a length of 32 and return a malformed
request error. Lowering the value to the previous default of 16 could
help in that case.
The two OPTs that were used previously allowed to omit it completely (hence
the fallback to ID_ANY), but that's invalid, so it's better to fail
parsing.
The has_issuer() and issued_by() methods relied on it to be defined, so
if the OCSP response wasn't successful (i.e. OCSP status indicates an
error and no OCSP response is parsed), a null-pointer dereference was
caused if the caller checked if the OCSP response was issued by a
specific certificate.
That's a side-effect of the referenced commit. Previously, error codes
caused the OCSP response to not get parsed successfully, which technically
wasn't correct as it's well formed and successfully parsed, it's just
indicating an error state.
Fixes: 00ab8d62c0 ("x509: Support generation of OCSP responses")
Instead of the CA certificate's subjectKeyIdentifier erroneously
the CA's authorityKeyIdentifier was used as the authorityKeyIdentfier
of the certificate to be issued. This might work with a root CA
where the authorityKeyIdentifier equals its subjectKeyIdentfier
but introduces a severe regression when an intermediate CA is used.
The openxpki plugin directly access the certificates table in
the OpenXPKI's MariaDB in order to retrieve the status of an
issued X.509 certificate based on its serial number.
Instead of just generating an authorityKeyIdentifier based on the
issuer's public key, this allows CA certificates to be issued by a
different tool that doesn't use a SHA-1 hash of the subjectPublicKey
for the subjectKeyIdentifier.
Closesstrongswan/strongswan#1992
References strongswan/strongswan#1975
These are not allowed in X.509 certificates according to RFC 5480 and
some newer validations apparently explicitly check for this.
Note that WolfSSL rejects such keys, by default. Only when compiled with
WOLFSSL_NO_ASN_STRICT are they accepted.
Tobias Brunner