pki: Make --dn optional for certificate renewals via --scep command

When using OpenXPKI, the subject DN in the renewal request has to match
the previous DN exactly.  However, because OpenXPKI may add a bunch of
DC/O RDNs to subjects of issued certificates, running --scep with the
same --dn that was used for the original request won't work (results in
a "Client error / malformed request badRequest" error even after enabling
`renewal_via_pkcs_req`).  This simplifies renewals as --dn can just be
omitted and extracted from the original certificate to avoid this issue.

References strongswan/strongswan#1689

Merge branch 'debug-level-build'

This fixes the build with DEBUG_LEVEL < 4, which was broken when building
from the repository since --enable-warnings was made the default.

Although, most issues only occurred with the level reduced to 0/-1.  And
while removing debug statements at compile time completely is probably
not useful in production, there might be use cases in certain benchmarking
scenarios.  Also, with the recent changes to the controller there should
only rarely be a listener registered at a higher log level so the overhead
for those higher-level DBG statements is minimal.

Anyway, reducing the log level at compile time is a documented feature and
at least DEBUG_LEVEL=3 could be useful to prevent leaking sensitive
information via logs from the outset.  So we should make sure compilation
doesn't fail.

github: Add build with DBG completely disabled

sec-updater: Fix build with DEBUG_LEVEL < 1

sw-collector: Fix build with DEBUG_LEVEL < 1

conftest: Fix build with DEBUG_LEVEL < 1

pki: Fix build with DEBUG_LEVEL < 1

selinux: Fix build with DEBUG_LEVEL < 1

radattr: Fix build with DEBUG_LEVEL < 1

systime-fix: Fix build with DEBUG_LEVEL < 1

kernel-netlink: Fix build with DEBUG_LEVEL < 2

ha: Fix build with DEBUG_LEVEL < 1

dhcp: Fix build with DEBUG_LEVEL < 1

tnc-ifmap: Fix build with DEBUG_LEVEL < 2

eap-peap: Fix build with DEBUG_LEVEL < 1

eap-ttls: Fix build with DEBUG_LEVEL < 1

eap-radius: Fix build with DEBUG_LEVEL < 1

eap-dynamic: Fix build with DEBUG_LEVEL < 2

eap-mschapv2: Fix build with DEBUG_LEVEL < 1

vici: Fix build with DEBUG_LEVEL < 2

forecast: Fix build with DEBUG_LEVEL < 2

save-keys: Fix build with DEBUG_LEVEL < 0

mode-config: Fix build with DEBUG_LEVEL < 1

keymat_v1: Fix build with DEBUG_LEVEL < 3

ike-init: Fix build with DEBUG_LEVEL < 1

ike-config: Fix build with DEBUG_LEVEL < 1

child-create: Fix build with DEBUG_LEVEL < 1

pubkey-authenticator: Fix build with DEBUG_LEVEL < 1

eap-authenticator: Fix build with DEBUG_LEVEL < 1

ike-sa: Fix build with DEBUG_LEVEL < 1

message: Fix build with DEBUG__LEVEL < 1

generator: Fix build with DEBUG_LEVEL < 2

backend-manager: Fix build with DEBUG_LEVEL < 3

libimcv: Fix build with DEBUG_LEVEL < 3

libtpmtss: Fix build with DEBUG_LEVEL < 2

tnccs-20: Fix build with DEBUG_LEVEL < 2

tnccs-11: Fix build with DEBUG_LEVEL < 2

radius-client: Fix build with DEBUG_LEVEL < 3

libtls: Fix build with DEBUG_LEVEL < 3

simaka-manager: Fix counter in log message when getting quintuplets

Also fixes the build with DEBUG_LEVEL < 1.

esp-packet: Fix build with DEBUG_LEVEL < 3

drbg: Fix build with DEBUG_LEVEL < 4

bliss: Fix build with DEBUG_LEVEL < 2

sqlite: Fix build with DEBUG_LEVEL < 2

pkcs7: Fix build with DEBUG_LEVEL < 2

constraints: Fix build with DEBUG_LEVEL < 1

revocation: Fix build with DEBUG_LEVEL < 1

x509: Fix build with DEBUG_LEVEL < 2 for structures that ignore unknown critical extensions

plugin-loader: Fix build with DEBUG_LEVEL < 3

auth-cfg: Fix build with DEBUG_LEVEL < 1

certificate: Fix build with DEBUG_LEVEL < 1

credential-factory: Fix build with DEBUG_LEVEL < 1

crypto-tester: Fix build with DEBUG_LEVEL < 1

asn1: Fix build with DEBUG_LEVEL < 2

debug: Add macro to mark variables that are only used in DBG statements

Some variables that are only assigned to be used in DBG statements
will otherwise trigger a "set but not used" warning/error if DEBUG_LEVEL
is too low.

doxygen: Enable JS search engine

doxygen: Fix syntax for some output parameters

ikev1: Migrate CHILD_SAs when IKE_SA is reset during reauthentication

When we reset the initiator SPI, we have to migrate the adopted children
again so the correct IKE_SA can later be checked out.

Closes strongswan/strongswan#1663

vici: Improve log messages for terminate/rekey() in case of combined filters

As long as any `child*` selector is received, only CHILD_SAs will be
terminated or rekeyed.  Any passed `ike*` selectors will only be used to
filter the IKE_SAs when looking for matching CHILD_SAs.  However, the
previous log messages seemed to indicate that IKE_SAs will also be
terminated/rekeyed.

References strongswan/strongswan#1655

vici: Create default TCP socket on Windows in Python bindings

This uses the same value as VICI_DEFAULT_URI.

References strongswan/strongswan#1655

charon-systemd: Add a log message when the daemon is starting

While there is a status message sent to systemd (can be seen e.g. in
systemctl status), the version etc. is currently not logged to the
journal, syslog or any log files.

leak-detective: Add `on_exit(3)` to whitelist

Seems to allocate some TLS value in newer glibc versions.

controller: Add parameter for maximum log level to initiate/terminate_*()

Previously, the logger installed by the controller always announced
LEVEL_PRIVATE(4), which produced completely useless logging calls with
the common clients (vici/stroke) whose default log level is LEVEL_CTRL(1).
This can produce quite some overhead if there are e.g. a lot of concurrent
initiate() calls.

controller: Ignore log messages unrelated to IKE_SA affected by a command

Until we know which IKE_SA is affected by an initiate() or terminate_*()
command, unrelated log messages that don't have any IKE context (i.e.
the passed `ike_sa` is NULL) would previously get logged.

watcher: Prevent busy wait if callback is active and other FDs have events

Exiting the loop previously could cause watcher to busy wait (i.e.
rebuild the array and call poll() repeatedly) until the active callback
was done.

Assume watcher observes two FDs 15 and 22, which are in the list in that
order.  FD 15 is signaled and its callback gets triggered.  The array of
FDs is rebuilt and does not include 15 anymore.  Now FD 22 is ready for
reading.  However, when enumerating all registered FDs, the loop previously
was exited when reaching FD 15 and seeing that it's active.  FD 22 was
never checked and the array was immediately rebuilt and poll() called.
If the callback for 15 took longer, this was repeated over and over.

This basically reverts d16d5a245f0b ("watcher: Avoid queueing multiple
watcher callbacks at the same time"), whose goal is quite unclear to me.
If it really wanted to allow only a single callback for all FDs, it didn't
achieve that as any FD before an active one would get notified and if
multiple FDs are ready concurrently, they'd all get triggered too.
Skipping entries with active callback makes sense as it avoids a lookup
in the FD array and subsequent revents checks.  But why would we need to
rebuild the array if we see such an entry?  Once the callback is done,
the watcher is notified and the array rebuilt anyway (also if any other
FD was ready and jobs get queued).

watcher: Move debug log messages out of mutex

The list of FDs is recreated quite often (e.g. due to the kernel-netlink
event sockets) and if a logger depends on watcher_t in some way this
might cause conflicts if the mutex is held.

watcher: Make sure to re-activate the correct entry after a callback

Since the same FD may be added multiple times (e.g. with separate
callbacks for WATCHER_READ and WATCHER_WRITE), the previous check
might not have found the correct entry.  As the entry can't be removed
while in a callback, the pointer comparison is fine.

watcher: Log when watched FDs are added, removed or updated

watcher: Only log number of managed FDs

Adding the internal notify FD might be confusing.

watcher: Avoid logging on level 1 while holding the mutex

This could be problematic in case loggers in some way rely on watcher_t
themselves.  This particular log message should rarely occur if at all,
but still avoid holding the mutex.

vici: Don't lock connection in write mode when enabling on_write() callback

This should prevent a deadlock that could previously be caused when a
control-log event was raised.  The deadlock looked something like this:

 * Thread A holds the read lock on bus_t and raises the control-log event.
   This requires acquiring the connection entry in write mode to queue the
   outgoing message.  If it is already held by another thread, this blocks
   on a condvar.

 * Thread B is registering the on_write() callback on the same connection's
   stream due to a previous log message.  Before this change, the code
   acquired the entry in write mode as well, thus, blocking thread A.  To
   remove/add the stream, the mutex in watcher_t needs to be acquired.

 * Thread C is in watcher_t's watch() and holds the mutex while logging on
   level 2 or 3.  The latter requires the read lock on bus_t, which should
   usually be acquirable even if thread A holds it.  Unless writers are
   concurrently waiting on the lock and the implementation is blocking
   new readers to prevent writer starvation.

 * Thread D is removing a logger from the bus (e.g. after an initiate()
   call) and is waiting to acquire the write lock on bus_t and is thereby
   blocking thread C.

With this change, thread B should not block thread A anymore.  So thread D
and thread C should eventually be able to proceed as well.

Thread A could be held up a bit if there is a thread already sending
messages for the same connection, but that should only cause a delay, no
deadlock, as on_write() and do_write() don't log (or lock) anything while
keeping the entry locked in write mode.

Closes strongswan/strongswan#566

sonarcloud: Ignore "User-defined types should not be passed as variadic arguments"

This triggers an error for functions that take chunk_t as variadic
arguments (cat, debug, builders, ASN.1 wrap).

Since we are not using C++, this should be fine as we are only passing
POD types anyway.

Version bump to 5.9.11dr3

cert_cache: Replace cached stale OCSP responses in-place

Version bump to 5.9.11dr2

pki: Filter whitespace in base64 encoded EST responses

As clarified in RFC 8951, section 3.1 [1].

[1] https://www.rfc-editor.org/rfc/rfc8951#name-white-space-processing

Co-authored-by: Tobias Brunner <tobias@strongswan.org>
Closes strongswan/strongswan#1616

pki: Add support for EST server label

As specified in EST RFC 7030, Section 3.1 [1].

[1] https://www.rfc-editor.org/rfc/rfc7030.html#section-3.1

Merge branch 'pkcs7-signatures'

Adds support for CMS-style signatures in PKCS#7 containers, which allows
verifying RSA-PSS and ECDSA signatures.

Ed25519 signatures should be supported when verifying, however, they
currently can't be created.  Ed448 signatures are currently not supported.
That's because RFC 8419 has very strict requirements in regards to the
hash algorithms used for signed attributes.  With Ed25519 only SHA-512 is
allowed (pki currently has an issue with Ed25519 in combination with
SHA-512 due to its associated HASH_IDENTITY) and with Ed448 only SHAKE256
with 512-bit output, which has to be encoded in the algorithmIdentifier
parameters (something we currently don't support at all).

Closes strongswan/strongswan#1615

pki: Allow specifying signature scheme for PKCS#7 signatures

Also changed the error handling a bit so it is more like in the other
pki commands.

pki: Unify parsing of RSA padding scheme and fix disabling PSS

If PSS padding is enabled by default, not all commands allowed disabling
it explicitly.

openssl: Add support for CMS-style signatures in PKCS#7 (RSA-PSS, ECDSA)

pkcs7: Add support for CMS-style signatures (RSA-PSS, ECDSA)

For the legacy schemes with rsaEncryption nothing changes, but if an
actual signature scheme is encoded we use that to find the key and
verify the signature.

The descriptions for the PKCS#7 structure are adapted for CMS.

asn1: Allow suppressing log messages when parsing algorithm identifiers

botan: Pass n and e separately for RSA public keys

Some encoders, like those provided by the dnskey and sshkey plugins,
require these separately when encoding keys.

Also fixes the type for the ASN.1 encoding (which is a subjectPublicKeyInfo
structure) depending on the key type.  This worked fine for PEM encoding
as the pem plugin doesn't care what the actual type of the key is (which
is encoded in the SPKI structure), but other plugins do (e.g. the sshkey
plugin).

ipseckey: Add support for ECDSA and EdDSA public keys

Use wolfSSL 5.6.0 for tests

The `--enable-heapmath` configure option has been deprecated.  As
already described in eae30af029b1 ("Use wolfSSL 5.4.0 for tests"), the
alternative is to configure `--with-max-rsa-bits=8192` instead in order
to test the modp6144 and modp8192 DH groups.

Version bump to 5.9.11dr1

revocation: Suppress some log messages for cached OCSP responses

We don't have any information on the issuer of cached OCSP responses, in
particular if the OCSP response is issued by a dedicated OCSP signer,
whose certificate might not be contained in the response or even signed
by the same CA but could just be locally installed.  So the only way to
determine if a response applies to the current certificate and its CA
is searching for the response's issuer certificate and verifying that.

However, when using multiple CAs that provide revocation checking via
OCSP, in particular with multi-level CAs (e.g. like the
ikev2-multi-ca/ocsp-signers test scenario), we might have unrelated OCSP
responses in the cache when verifying a particular certificate.  In this
case we don't need any confusing

  ocsp response verification failed, no signer certificate '...' found

error messages because the response was for a different CA.

Similarly, if lots of clients of the same CA connect there could be lots
of OCSP responses in the cache that, while being applicable to the current
CA, don't have any information on the certificate we are currently
checking.  In this case all the

  ocsp response correctly signed by "..."
  ocsp response contains no status on our certificate

messages don't provide any value.

In the mentioned test scenario, we suppress the

  ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Research OCSP Signing Authority, CN=ocsp.research.strongswan.org' found

message from the cached OCSP response for carol's end-entity certificate
when verifying the "Research" intermediate CA certificate that issued
carol's certificate.

Then the

  ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Research OCSP Signing Authority, CN=ocsp.research.strongswan.org' found
  ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=OCSP Signing Authority, CN=ocsp.strongswan.org' found

messages from the cached OCSP responses for carol's end-entity and
intermediate CA certificates when verifying dave's end-entity certificate.

And finally the

  ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Research OCSP Signing Authority, CN=ocsp.research.strongswan.org' found
    ocsp response correctly signed by "C=CH, O=strongSwan Project, OU=OCSP Signing Authority, CN=ocsp.strongswan.org"
    ocsp response contains no status on our certificate
  ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Sales OCSP Signing Authority, CN=ocsp.sales.strongswan.org' found

messages from the cached OCSP responses for carol's end-entity
certificate, the applicable but unrelated response for carol's "Research"
intermediate CA certificate and the response for dave's end-entity
certificate when verifying dave's "Sales" intermediate CA.

testing: Fix installation of swid-generator with newer versions of setuptools

With version 60.0.0 setuptools changed to a local installation of
distutils.  This seems to break the installation of swid-generator (causing
an `importlib.metadata.PackageNotFoundError: swid-generator` error).

Note that while Debian ships setuptools 52.0.0, `python-daemon` recently
added a dependency on `setuptools>=62.4.0`, which installs that version
that's then later used to install swid-generator.

The main difference seems to be that the local version installs the
package in `/usr/lib/python3.9/site-packages`, while the stdlib version
does so in `/usr/local/lib/python3.9/dist-packages` (similarly for the
`swid_generator` script and the `distro` dependency).

Not sure if there is a better/proper way to fix this.  Might just be an
issue with Debian bullseye and mixing system packages with those installed
via pip3.

Merge branch 'crl-sign'

Enforces that the certificate that signed a CRL either encodes the
cRLSign keyUsage (even if it is a CA certificate) or is a CA certificate
without a keyUsage extension (which should rarely be the case nowadays).

This is in compliance with RFC 5280, section 6.3.3. (f):

  If a key usage extension is present in the CRL issuer's certificate,
  verify that the cRLSign bit is set.

strongSwan encodes a keyUsage extension with cRLSign bit set in all CA
certificates it generates since 1ec8f22de222 ("set Certificate Sign and
CRL Sign flags in keyUsage extension if CA is true"), which was 13 years
ago.  Before that the extension was not encoded so those CA certificates
would also still be accepted as CRL issuer (if they are still valid, but
considering the SHA-1 deprecation that happened since then, they were
most likely replaced anyway).

References strongswan/strongswan#1548

openssl: Only allow certificates with cRLSign keyUsage to sign CRLs

x509: Only allow certificates with cRLSign keyUsage to sign CRLs

openssl: Set X509_CRL_SIGN for CA certificates without keyUsage extension

x509: Set X509_CRL_SIGN for CA certificates without keyUsage extension

appveyor: Build eap-radius plugin on Windows

libradius: Link to winsock32 on Windows

eap-radius: Don't include socket.h explicitly

We rely on the includes via utils.h so this compiles on Windows.

windows: Fix compat define for sendto(2)

kernel-wfp: Install bypass policies also on FWPM_SUBLAYER_IPSEC_TUNNEL sublayer

This is apparently necessary to bypass tunnel mode SAs/policies.

References strongswan/strongswan#1552

windows: Fix invalid pointer dereference when terminating service thread

When running as a service, the libraries are initialized/deinitialized
not by the main thread but by a separate thread that runs the registered
main service procedure.  When the service is stopped, the libraries are
deinitialized by that thread and the thread lock and hashtable are
destroyed.  But afterwards the DllMain callback is also triggered for
that thread so we have to prevent it from accessing these objects again.

References strongswan/strongswan#1567