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

Hey Georg,

The configs look ok to me. The error message and your description
sound like you might have forgotten to copy the certificate private
keys to /etc/iked/private/local.key

On Wed, Dec 01, 2021 at 08:50:58PM +0100, Georg Pfuetzenreuter wrote:
> 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
>