OpenSSL s_server – chainCAfile2 directive??
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 30.8k
- Forks
- 11.5k
- Avg merge
- 10m
- Merged PRs (30d)
- 1
Description
I was in two minds regards “is this a bug” or “is this a documentation” issue? I chose bug because it will be an easier decision to kick it to documentation, if appropriate.
An interesting issue with OpenSSL 3.5.1 on CentOS 9.
I’m just testing some TLSv1.3 mutual authentication issues using OpenSSL s_client and s_server. Within my s_server config I include the “-servername” directive. Surprisingly, to me, the inclusion of the “-servername” directive triggers the need to configure and use the “-key2” and “-cert2” directives. The “s_server” “-servername” documentation doesn’t suggest this, although “-cert2” documentation sort of does. Should the “-servername” text within the “-cert2” directive documentation include a dash and be bolded?
It should be noted, when the “-servername” directive is removed, I’m building the server’s certificate chain, including the Root CA through the use of the “-cert” directive which references a file containing a PEM certificate, and the “-chainCAfile” directive that references a PEM file that contains both the server certificate Issuing CA and the Root CA.
This raises two questions:
Question 1 – why does the inclusion of the “-servername” directive require the use of “-key2” and “-cert2” directives. It is my understanding that the “servername” directive is considered default today for TLSv1.3?
Question 2 – I note there isn’t a “-chainCAfile2” directive, where the “-key2” and “-cert2” don’t build their certificate chain from the contents of “-chainCAfile” directive. Is this an oversight, or am I missing something?
See below the “s_client” client, and “s_server” server configurations from a couple of bash scripts. Note, I use the “-showcerts” directive client side to show the certificates received by the client from the server. FYI - I look for either 1 or 3 certificates, where I expect 3.
# Create Extranet Web client
(
printf 'GET %s HTTP/1.1\r\n' "${resource}"
printf '%s\r\n' "${Extranet_server_name}"
printf 'Connection: Close\r\n'
printf '\r\n'
) | openssl 2>&1 s_client
-connect "${Extranet_server_name}:${Extranet_server_port}"
-showcerts
-tls1_3
-enable_pha
-key "${Extranet_client_key}"
-pass "file:${Extranet_Deliverables}/readme.txt"
-cert "${Extranet_client_certificate}"
-certform PEM
-cert_chain "${Extranet_RootCA_and_IssuingCA}"
-build_chain
-CAfile "${Extranet_RootCA}"
-servername "${Extranet_server_name}"
-ign_eof
# Create Extranet Web Server
openssl s_server
-port "${Extranet_server_port}"
-cert "${Extranet_server_public_key_cert}"
-cert2 "${Extranet_server_public_key_cert}"
-chainCAfile "${Extranet_server_cert_chain}"
-keyform PEM
-key "${Extranet_server_private_key_encrypted}"
-key2 "${Extranet_server_private_key_encrypted}"
-pass "file:${Extranet_Deliverables}/readme.txt"
-debug
-tls1_3
-state
-security_debug
-security_debug_verbose
-verify_return_error
-servername www.example.com
-WWW \
Regards
Nigel
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the s_server -servername, -cert2, -key2, and -chainCAfile directives described in the issue, then reproduce the OpenSSL 3.5.1 command-line behavior from the supplied bash example. Determine whether the behavior is expected and whether the documentation needs clarification or a chainCAfile2 option; done means the two questions have a documented, technically verified answer.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- bash
- Domain
- documentation, security
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100