On Tue, Apr 09, 2024 at 08:44:41AM -0700, Doug Hardie wrote:
> When using client certificates, how does SSL_accept validate the
> provided certificate?
By building a certificate chain to a local trust-anchor using the
server's configured trust store, and any untrusted intermediate
certificates presented by the remote client.
Note that verification of client certificates DOES NOT typically include
any "identity" checks, rather only the trustworthiness of the chain is
verified. It is up to the server application to perform access control
on the requested resources based on whatever information the server
independently gleams from the certificate during or after the TLS
handshake.
> If verify_callback is used, is the client certificate validated before
> the callback is called?
No, if all goes well, the callbacks (one per chain certificate) are
made *as part of* validation, with the "ok" parameter set to "1" if
there's no (new?) problem to report at the level in question.
If the callback returns a non-zero value, the handshake continues, if
zero it is aborted. A callback that is purely diagnostic should return
the input "ok" value. If the callback wants to either abort an
otherwise "ok" handshake, or ignore a particular problem, it can return
1 under appropriate conditions even if "ok" was zero.
Note that returning "ok" equal to one does not reset the verification
status for the chain, which can be tested, for e.g. success, via:
SSL_get_verify_result(ssl) == X509_V_OK
this works even on resumption, because the original validation status is
part of the saved/resumed session.
The callback can (with great care to not ignore any important error
conditions) reset the validation result for less critical conditions,
but then it is necessary to either abort the handshake on the import
conditions, or save away state that an earlier problem was not
ignorable, and reset the error to that, rather than to X509_V_OK.
See X509_STORE_CTX_set_error(3), but tread cautiously, there be dragons.
On Tue, Apr 09, 2024 at 08:43:39AM -0700, Doug Hardie wrote:
> The server requires client certificates. If I use
> openssl s_client and give it the proper certificate, I see one
> connection that makes the request and returns the response.
The "s_client" application is liberal in what it accepts:
- Without non-default options, the handshake completes (with some
addtional noise) even if the server certificate fails to verufy.
- It presents the specified client certificate even if the server
does not solicit its issuer CA (or ultimate trust anchor) in its
certificate request message, which lists the acceptable CAs.
- There may of course be subtle differences in various extensions
used, the SNI extension may be important, the others typically
less so.
- Your s_client may be dated, and the issue may only manifest with
bleeding edge client capabilities, though again your s_client is
likely not that old (1.1.1, supports TLS 1.3) and you rarely need
more.
Speculatively, the second item is the most likely source of issues.
> However, if I use one of the various clients to make the same request,
> the results are quite different. There are a number of connections
> made that fail and then finally they make the proper connection and
> everything works. The time it takes to get through all of that is
> quite long - around 5 seconds. The server is recording the following
> errors from SSL_accept:
>
> Connection 1 - session id context uninitialized
> Connection 2 - session id context uninitialized
> Connection 3 - sslv3 alert certificate unknown
> Connection 4 - sslv3 alert certificate unknown
Who's sending/receiving the alerts? The server would typically report
*received* alerts, and it is then perhaps the client that is failing to
validate the server certificate, but without a clear context, it is
difficult to say what happened.
As for session id contexts, your server code needs to set one in order
to support resumption properly, one more difference between s_client
and other clients, is that s_client always starts with no saved
sessions.
The Postfix SMTP server has:
/* * The session_id_context identifies the service that created a session. * This information is used to distinguish between multiple TLS-based * servers running on the same server. We use the name of the mail system. */ static const char server_session_id_context[] = "Postfix/TLS";
...
SSL_CTX_set_session_id_context(server_ctx, (void *) &server_session_id_context, sizeof(server_session_id_context));
> and then Connection 5 sees the proper client certificate, authenticates and produces output.
Perhaps the client is no longer attempting resumption?
> How can I figure out what is causing these multiple connections and
> the resulting errors. I have tcpdump and ssldump output but nothing
> there gives me any ideas.
The ssldump software is abandoned, use "tcpdump" + ""tshark", as explained in:
https://marc.info/?l=postfix-users&m=166005488423800&w=2
> I can provide either of those if needed, but they are large.
With "tcpdump", after capturing a bunch of traffic, you extract just a
particular connection of interest, details in the post linked above.
You can then analyse it with "tshark" (same link).
> Unfortunately I have not figured out how to get ssldump to decode the
> application data. As best as I can tell, the negotiated cipher cannot
> be handled by ssldump.
Delete "ssldump" you're better off without it.
> The clients each have the same 2 client certificates. They ask which
> one to use, but perhaps they are trying both?
A given handshake can only try one client certificate as part of the
normal handshake. THere's also post-handshake authenticaiton (PHA) in
TLS 1.3, but you probably don't have server code for that.
That the clients are putting up a dialogue does strengthen the
plausibility of the server's client certificate request being part of
the problem. You may need to carefully tune your server's list of
solicited client CAs. See the docs for SSL_CTX_set_client_CA_list(3).
Less is more (ideally just one if there's only one CA issuing the
desired certificates).
And finally, but importantly, what exactly is your use case? How does
the server expect to benefit from (make access and authorisation
decisions based on) client certificates?
--
Viktor.
