Hi JR, the formatting problem is in your <ca> block, and there are actually two separate issues in it.
1) It contains the human-readable dump, not just the certificate. Between BEGIN CERTIFICATE and END CERTIFICATE there must be nothing except the base64 body. Your block has "openssl x509 -text" output pasted inside the markers (Certificate:, Data:, Issuer:, Modulus:, X509v3 extensions ...), so the parser hits non-base64 characters and rejects the profile.
2) That certificate is not your CA. The dump itself tells you: Subject: CN=client1, Basic Constraints: CA:FALSE, Extended Key Usage: TLS Web Client Authentication. That is your client certificate. Your CA would show Subject: CN=Easy-RSA CA and CA:TRUE.
Both point to the same root cause. Easy-RSA v3 writes pki/issued/<name>.crt with a text dump above the PEM block, so it is very easy to copy the wrong region of the wrong file.
Use these, and paste only from the BEGIN line to the END line with nothing above it:
<ca> = pki/ca.crt
<cert> = pki/issued/client1.crt
<key> = pki/private/client1.key
To strip the dump automatically: openssl x509 -in pki/issued/client1.crt -out client1.pem
Two smaller notes. key-direction 1 together with <tls-auth> is correct for a client, so leave that as is. And "cipher AES-256-GCM" is deprecated in favour of "data-ciphers AES-256-GCM" on 2.5+/3.x; it will not block the import, but it avoids a warning.
If it still fails after fixing <ca>, post the exact error text and whether it appears at import or at connect, as Joseph asked. A profile that fails to parse and a profile that parses but fails TLS negotiation look similar to the user but have very different causes.
