Attached is the result for the first connection: Nothing stands out that I can see. -- Doug > On Apr 9, 2024, at 10:59, Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> wrote: > > 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. Thanks for that explanation. That would probably be helpful to others if it was included somewhere in the openssl documentation. > > 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. It should be a fairly new s_client. The client I used for that testing, and for the server is FreeBSD 14.0. > > >> 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. All of the logging is on the server side. I don't really have any ability to do anything with the clients. > > 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)); I'll have to do that then. > >> 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 Thanks. I have tdump available but had not figured out how to use it. > > >> 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. So I see. It's going away after I send this. > >> 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). I only have my root certificate in the chain for authentication. Your last response to me made that point loud and clear. Thanks. > > 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? The case is an organization that was initially using passwords for authentication. That worked properly and was easy to setup. However, in the process of doing that I discovered that all their users had the name of the company as their password. Given that the loss of the information that needs to be protected would be a very significant financial loss to the company, that approach is really not a good idea. I proposed the certificate authentication and management agreed. -- Doug
Attachment:
ccc
Description: Binary data
