iked: "rsa routines:CRYPTO_internal:block type is not 01"

Hello,

I try to connect two OpenBSD 7.0 systems using iked and kindly seek
assistance.

The IKE_AUTH process fails with the following:
router03 iked[15809]: ca_sslerror: dsa_verify_final: error:04FFF06A:rsa
routines:CRYPTO_internal:block type is not 01
router03 iked[15809]: ca_sslerror: dsa_verify_final: error:04FFF072:rsa
routines:CRYPTO_internal:padding check failed
router03 iked[15809]: spi=0x47b7e91158cd1425: ikev2_auth_verify:
ikev2_msg_authverify failed
router03 iked[15809]: spi=0x47b7e91158cd1425: ikev2_send_auth_failed:
authentication failed for FQDN/router04.example.com

router04 iked[14683]: spi=0x47b7e91158cd1425: sa_free: authentication
failed notification from peer

This is the iked.conf for router03:
ikev2 'foo' passive transport esp proto gre \
from 7x.xx.xx.x5 to 5x.xx.xx.x3 \
local 7x.xx.xx.x5 peer 5x.xx.xx.x3 \
ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group brainpool384 \
childsa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group
brainpool384 \
srcid router03.example.com

This is the iked.conf for router04:
ikev2 'bar' active transport esp proto gre \
from 5x.xx.xx.x3 to 7x.xx.xx.x5 \
local 5x.xx.xx.x3 peer 7x.xx.xx.x5 \
ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group brainpool384 \
childsa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group
brainpool384 \
srcid router04.example.com

I attempted the following routes of authentication:
- X.509: Creating a new CA on router04, installing the CA and client
certificates on router03.
- X.509: Installing the existing CA from router03 on router04 with a
respective client certificate for the latter.
- Public Key: Installing the public keys as described in iked(8).

And the following configuration variations:
- Specifying of ikeauth ecdsa384 or ikeauth rsa on both sides.
- Removing the ikesa and childsa declarations on both sides.

The X.509 attempts were performed using CA's and client certificates
manually requested and signed using openssl, as well as using CA's and
client certificates generated using ikectl.
In the X.509 attempts, the srcid was made sure to be present in the
SAN's of the client certificate.
In the public key attempts, the srcid was made sure to be the name of
the public key in the fqdn directory.

I would appreciate any advice.
Please note that I am able to successfully connect both iked instances
to StrongSwan endpoints - only the authentication between the two iked
instances themselves fails.

Kind regards
Georg