Replacing Expired OpenVPN Certificates

guardian

I hope one of the VPN gurus here can give me a few hints as to what I may be doing wrong, I had my OpenVPN server working, but I recently upgraded the phone to Oreo 8.1 AND my OpenVPN certificates just expired. I thought it would be easy to just create new certs, but for some reason I am getting validation errors and the VPN won't connect. pfSense has had a couple of updates in the year since I originally created the certificates.

In an attempt to get this thing working, I have recreated everything - Server certificate, User certificate, TLS Key, and I increased the strength of my password (since my initial setup was only intended for testing and the password was way too weak). I used the export tool, to put the info on a USB key and then imported it on my phone. The import seemed to work OK.
(I Didn't destroy/recreate the servers-I just changed the .)

Can someone give me a hint as to what part of the process these messages refer to?
(Only the XXXXXXXXXs and --.-- have been redacted - all other values are the actual contents.)

Jun  6 15:49:13 XXXXXXXX openvpn[48686]: 209.171.--.--:27235 VERIFY SCRIPT OK: depth=2, C=CA, ST=PRIVATE, L=PRIVATE, O=PRIVATE, emailAddress=nobody@nowhere, CN=XXXXXXXX_ROOT, OU=PRIVATE
Jun  6 15:49:13 XXXXXXXX openvpn[48686]: 209.171.--.--:27235 VERIFY OK: depth=2, C=CA, ST=PRIVATE, L=PRIVATE, O=PRIVATE, emailAddress=nobody@nowhere, CN=XXXXXXXX_ROOT, OU=PRIVATE
Jun  6 15:49:13 XXXXXXXX openvpn[48686]: 209.171.--.--:27235 VERIFY SCRIPT OK: depth=1, C=CA, ST=PRIVATE, L=PRIVATE, O=PRIVATE, emailAddress=nobody@nowhere, CN=XXXXXXXX_INTERMEDIATE_MAY2017, OU=PRIVATE
Jun  6 15:49:13 XXXXXXXX openvpn[48686]: 209.171.--.--:27235 VERIFY OK: depth=1, C=CA, ST=PRIVATE, L=PRIVATE, O=PRIVATE, emailAddress=nobody@nowhere, CN=XXXXXXXX_INTERMEDIATE_MAY2017, OU=PRIVATE
Jun  6 15:49:13 XXXXXXXX openvpn[48686]: 209.171.--.--:27235 VERIFY KU OK
Jun  6 15:49:13 XXXXXXXX openvpn[48686]: 209.171.--.--:27235 Validating certificate extended key usage
Jun  6 15:49:13 XXXXXXXX openvpn[48686]: 209.171.--.--:27235 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Server Authentication
Jun  6 15:49:13 XXXXXXXX openvpn[48686]: 209.171.--.--:27235 ++ Certificate has EKU (oid) 1.3.6.1.5.5.7.3.2, expects TLS Web Server Authentication
Jun  6 15:49:13 XXXXXXXX openvpn[48686]: 209.171.--.--:27235 VERIFY EKU ERROR
Jun  6 15:49:13 XXXXXXXX openvpn[48686]: 209.171.--.--:27235 OpenSSL: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed
Jun  6 15:49:13 XXXXXXXX openvpn[48686]: 209.171.--.--:27235 TLS_ERROR: BIO read tls_read_plaintext error
Jun  6 15:49:13 XXXXXXXX openvpn[48686]: 209.171.--.--:27235 TLS Error: TLS object -> incoming plaintext read error
Jun  6 15:49:13 XXXXXXXX openvpn[48686]: 209.171.--.--:27235 TLS Error: TLS handshake failed
Jun  6 15:49:13 XXXXXXXX openvpn[48686]: 209.171.--.--:27235 SIGUSR1[soft,tls-error] received, client-instance restarting

The android log doesn't show too much other than a printout of the certificate autority, and the server certificate - both say - Verify OK, but at the bottom of the Server Certificate it says Authentication, ??? - Then EVENT_CONNECTION_TIMEOUT.

Additional questions:
Is the Auth digest algorithm on the Server tab under cryptographic settings exported properly?
I changed it to SHA512? I just noticed this 'Leave this set to SHA1 unless all clients are set to match. SHA1 is the default for OpenVPN. ' Since the handful of clients that I might set up will all be exported by the export tool, I was assuming that all clients would be set to match - Did I assume wrong?

Am I correct that the password hasn't yet been evaluated?
Am I correct that the password is checked in pfSense (i.e. it isn't certificate encryption?)
Is it OK to have a SPACE in the password?

EDIT

I just noticed that when I click the info bubble for the old user cert I see:
EKU: TLS Web Client Authentication

I just noticed that when I click the info bubble for the new user cert I see:
KU: Digital Signature, Non Repudiation, Key Encipherment
EKU: TLS Web Client Authentication

Is this a change in the way pfSense generates keys or did I do something wrong?
Could this be the problem?

Also is there any way I can conveniently list the contents of a previously generated certificate from the command line for reference?

EDIT
I found this post:
https://forum.netgate.com/topic/114387/key-usage-checks-fail-on-user-client-certificate

and this set of custom options seems to be working:

persist-key
persist-tun
reneg-sec 0
remote-cert-ku e0
remote-cert-eku "TLS Web Client Authentication"

It appears that something changed in the last year as to how pfSense generates keys because I didn't need these options a year ago.