Within the “openssl s_server” command can I please verify how “-verifyCAfile” and “-CAfile” directives should work for mutual TLS authentication for TLSv1.3, after drafting this question and a little more testing, I realised they are the reverse of “openssl s_client” and this is probably an error/bug?

It is my assumption that the "openssl s_server" directive “-verifyCAfile file” is a PEM formatted file that should contain only the Issuing CA certificates used to authenticate the client certificates, authorisation would be a separate step.

It is also my assumption the “openssl s_server” directive “-CAfile file” is used by "openss s_server" to build a certificate path to a self-signed Root CA for the client's certificate by the server. Assuming the client doesn’t offer the Issuing CA with their certificate and proof of procession of the private key, then the -CAfile PEM formatted file may also include the Issuing CA.

Using the “openssl s_server” and “openssl s_client” commands below I observe a couple of issues….

# Emulate a Web Server openssl s_server
-port "${Internet_server_port}"
-verifyCAfile "${Internet_IssuingCA}"
-cert "${Internet_server_public_key_cert}"
-chainCAfile "${Internet_server_cert_chain}"
-keyform PEM
-key "${Internet_server_private_key_encrypted}"
-pass "file:${Deliverables}/readme.txt"
-Verify 5
-CAfile "${Internet_RootCA}"
-check_ss_sig
-auth_level 3
-debug
-tls1_3
-state
-security_debug
-security_debug_verbose
-WWW

“-verify_return_error \”. Note, directive is required, but not used to ignore the server client certificate chain verification error.

# Emulate a Web Client ( printf 'GET %s HTTP/1.1\r\n' "${resource}" printf '%s\r\n' "${Internet_server_name}" printf 'Connection: Close\r\n' printf '\r\n' ) | openssl 2>&1 s_client
-connect "${Internet_server_name}:${Internet_server_port}"
-showcerts
-enable_pha
-key "${Internet_client_key}"
-cert "${Internet_client_certificate}"
-pass "file:${Deliverables}/readme.txt"
-tls1_3
-CAfile "${Internet_RootCA}"
-servername "${Internet_server_name}"
-ign_eof

1 ) The first issue I observed is the “openssl s_client “ command is seeing the contents of the PEM file from the “openssl s_server” “-CAfile” directive, not the contents of the -verifyCAfile”, see the “openssl s_client” log snippit below. Note, the “-CAfile” contained the test Root CA, and the “-verifyCAfile” directive contained the subordinate Issuing CA. Acceptable client certificate CA names C=GB, ST=Suffolk, L=Ipswich, O=Example Organisation, CN=Root CA - G1

2. The “openssl s_server” command received the client certificate at depth 0, correctly validating this. At depth 1 the received Issuing CA is also correctly validated, however the “openssl s_server” command was unable to walk the path to the “-CAfile file” directive and validate the issuing CA against a self-signed Root CA at depth 3. Putting aside the first issue, this second issue is more surprising. As I indicate at the top is my understanding of these directives correct? depth=1 C=GB, ST=Suffolk, L=Ipswich, O=Example Organisation, OU=Untrusted, CN=ICA 1 Issuing CA - G1 verify error:num=2:unable to get issuer certificate issuer= C=GB, ST=Suffolk, L=Ipswich, O=Example Organisation, CN=Root CA - G1 verify return:1 depth=0 C=GB, ST=Suffolk, L=Ipswich, O=Example Organisation, OU=Untrusted, CN=nigel.tedeschi issuer= C=GB, ST=Suffolk, L=Ipswich, O=Example Organisation, OU=Untrusted, CN=ICA 1 Issuing CA - G1 verify return:1

3. When I realise the two errors didn’t correlate I made the “-CAfile” directive point to the issuing CA file, and the -verifyCAfile point to a file containing both the Issuing CA and Root CA, and the client chain was built on the server and validated. Hence, I believe these two directives have been reversed - tbd.

Regards Nigel