On 02/20/2018 06:34 PM, J Decker <d3c...@gmail.com> wrote: > Yes that is true.... however here's the scenario. > Client does a verification and passes or fails, and via the SSL layer I can > query if the client validated the certificate. > If it failed, provide a option for the client to get a renewed certificate > for verification. If success, no action. > If an actor lies in this scenario he answers > lies *yes* and didn't, don't give him a means to actually verify. *noop* > lies *no* but did, then give him the root cert he already has.... *noop* > > so I don't have to trust the reply.... I'm willing to give him the right > root.
That's nice from the server's POV, but the client REALLY REALLY SHOULD NOT install and/or put trust into any CA certs it received in-band in a connection that failed verification. The best (for you) it can do is to store it and offer it to its user for additional verification and *then* installation - and I'ld venture a guess that you'ld have to write such a client yourself. (And offering the *root* certificate isn't that far from the common practice of a server sending *most* of its CA chain in addition to its own certificate, anyway, so it's debatable whether you even *need* the result of the client's verification as an input to send the root as well.) Kind regards, -- Jochen Bern Systemingenieur Binect GmbH
smime.p7s
Description: S/MIME Cryptographic Signature
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
