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: 00ab8d62c089 ("x509: Support generation of OCSP responses")
Seems this was forgotten in the referenced commit and actually could lead
to a buffer overflow. Since charon-tkm is untrusted this isn't that
much of an issue but could at least be easily exploited for a DoS attack
as DH public values are set when handling IKE_SA_INIT requests.
Fixes: 0356089d0f94 ("diffie-hellman: Verify public DH values in backends")
Fixes: CVE-2023-41913
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.
Adds support for multiple OCSP responders in `pki --ocsp` and one that
is based on OpenSSL-style index.txt files. The parser for these files
also accepts simplified files that only specify the status, serial number
and optional revocation date/reason. The OCSP test scenarios are also
updated to use this OCSP responder including one that shows the multi-CA
capabilities of the --ocsp command and the --index option.
The only exception is the ikev2/ocsp-no-signer-cert scenario as the
pki command won't sign an OCSP response with a certificate that isn't
the CA certificate or marked as an OCSP signer.
Registered OCSP responders should return VALIDATION_SKIPPED for issuer
certificates they are not responsible for. However, VALIDATION_FAILED is
currently treated the same way, so that's fine as well.
Implements a new --ocsp command for the pki tool that can produce OCSP
responses based on information provided by a plugin. A first plugin
that accesses the OpenXPKI database is also added.
Closesstrongswan/strongswan#1958
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.
The kernel includes the XFRMA_REPLAY_ESN_VAL attribute when dumping
SAs since it was added with 2.6.39. So we basically added this attribute
twice to the message sent to the kernel, potentially exceeding the
message buffer if the window size is large.
The XFRMA_REPLAY_VAL attribute is only dumped since 3.19, so that might
still be relevant (Google seems to maintain a 3.18 kernel) and since we
have to query the current lifetime stats anyway, we can just avoid adding
this attribute twice.
Closesstrongswan/strongswan#1967
Adds support to encode SANs of type uniformResourceIdentifier in
certificates. They currently don't have any use in strongSwan, but
might be required for other applications.
Closesstrongswan/strongswan#1983
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
This adds support for password-less PKCS#12 containers and PKCS#8 files.
A new option for charon-cmd also allows loading private keys of any
type (previously only RSA keys were supported).
References strongswan/strongswan#1955
