2.6.4: ERROR: failed to read OpenVPN tls-crypt-v2 server key file (keys/myserver.tls-crypt-v2.key) ERROR: invalid tls-crypt-v2 server key format

Hi,
I am trying to setup tls-crypt-v2 but the server complain about the key being wrong, somehow. I used easy-rsa3 and easy-tls to generate one but they look same even under od -c, where = and \n chars are in same positions. Also the header lines are exactly same. I haven't found which cipher is used to generate them. Could it be the cipher got removed in recen openssl libs? It should be specified in the description line of the key, IMO.

I tried both approaches:

openvpn --genkey tls-crypt-v2-server myserver.tls-crypt-v2.key
easytls build-tls-crypt-v2-server myserver.domainname 

Jul 16 18:51:46 myserver openvpn[20021]: OpenVPN 2.6.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Jul 16 18:51:46 myserver openvpn[20021]: library versions: OpenSSL 1.1.1q  5 Jul 2022, LZO 2.10
Jul 16 18:51:46 myserver openvpn[20024]: WARNING: you are using user/group/chroot/setcon without persist-tun -- this may cause restarts to fail
Jul 16 18:51:46 myserver openvpn[20024]: WARNING: you are using user/group/chroot/setcon without persist-key -- this may cause restarts to fail
Jul 16 18:51:46 myserver openvpn[20024]: Diffie-Hellman initialized with 4096 bit key
Jul 16 18:51:46 myserver openvpn[20024]: tls-crypt-v2 server key: Cipher 'AES-256-CTR' initialized with 256 bit key
Jul 16 18:51:46 myserver openvpn[20024]: tls-crypt-v2 server key: Using 256 bit message hash 'SHA256' for HMAC authentication
Jul 16 18:51:46 myserver openvpn[20024]: TLS-Auth MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]

...

Jul 16 18:54:40 myserver openvpn[20024]: Control Channel: using tls-crypt-v2 key
Jul 16 18:54:40 myserver openvpn[20024]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jul 16 18:54:40 myserver openvpn[20024]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jul 16 18:54:40 myserver openvpn[20024]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jul 16 18:54:40 myserver openvpn[20024]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jul 16 18:54:40 myserver openvpn[20024]: Connection Attempt Control Channel: using tls-crypt-v2 key
Jul 16 18:54:40 myserver openvpn[20024]: Connection Attempt Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jul 16 18:54:40 myserver openvpn[20024]: Connection Attempt Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jul 16 18:54:40 myserver openvpn[20024]: Connection Attempt Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jul 16 18:54:40 myserver openvpn[20024]: Connection Attempt Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jul 16 18:54:40 myserver openvpn[20024]: Connection Attempt MULTI: multi_create_instance called
Jul 16 18:54:40 myserver openvpn[20024]: xx.xx.xx.xx:58184 Re-using SSL/TLS context
Jul 16 18:54:40 myserver openvpn[20024]: xx.xx.xx.xx:58184 ERROR: failed to read OpenVPN tls-crypt-v2 server key file (keys/myserver.domainname-tls-crypt-v2.key)
Jul 16 18:54:40 myserver openvpn[20024]: xx.xx.xx.xx:58184 ERROR: invalid tls-crypt-v2 server key format
Jul 16 18:54:40 myserver openvpn[20024]: xx.xx.xx.xx:58184 Exiting due to fatal error

Client receives only:

... read UDPv4 [ECONNREFUSED]: Connection refused (fd=4,code=111)

Initially I thought that openvpn does not follow symlinks to the keys but even when full path is specified, the error is same.

At least the error should appear immediately upon startup and not only after a client connects.

No source file or test is named. Reproduce the issue with the two shown key-generation commands and the OpenVPN 2.6.4 logs, then trace tls-crypt-v2 server-key loading during startup and client connection handling. Done means the key-format failure is diagnosed and the reported error timing or compatibility behavior is covered by a regression test.