Failed to specify certificate chain for AuthenticateAsServer?

Question

I am struggling with the apparent lack of flexibility in SslStream AuthenticateAsServer. I have a self-signed rootCA, an intermediate CA, and a target (host) certificate. I only perform server authentication. The client has a rootCA certificate, and I'm trying to somehow send the entire chain from the server to the client so that the client can check the server, and I can further compare the anchor rootCA trust prints with the ones included in the client.

Ideally, I would like to avoid using a certificate store and explicitly send certificates. If someone knows how to do this, this is the best solution to my problem.

But it seems that SslStream AuthenticateAsServer will not be in any documented way, allowing you to explicitly specify the chain to send. You just have to send the bottom certificate and let it dig the rest of it from the certificate store. This is less than ideal, but it seems that this is the only option, so I try so hard. Currently, the problem is that (with a self-signed CA in trusted root certification authorities and an intermediate in intermediate root certification authorities on the server), only the client certificate and the intermediate certificate are "automatically" sent to the client. I only get two certificates on the client, not a rootCA certificate. Why?

Is there an AsServer authentication method with a certificate chain?

If not, is it that it cuts the root certificate from the top of the chain before sending?

If there are no answers to the above, is there at least a way to bypass (auto) magic that digs the rest of the chain from the store, where can I look at the result, and not go through AuthenticateAsServer to the CertValidationCallback client? At least in this way I would debug one black box, and not a row of several black boxes.

Answer 1

I asked this question 4 years ago. I could not find a way to do anything described above. SslStream really has such a tough interface. Sometimes I get the root certificate back in the chain (if the authentication side is xamarin?), In most other cases, I would not do this, and there is no way to force it anyway. So I decided to do two things to get around this:

1. Since the client has a root certificate embedded as a resource, I extract it during the certificate verification callback and explicitly add it to chain.ChainPolicy.ExtraStore and then verify that the chain is chain.ChainPolicy.ExtraStore .
2. Assuming the chain is built, I then check the condition (chain.ChainElements[chain.ChainElements.Count - 1].Certificate.Thumbprint == rootCert.Thumbprint) This checks that after adding the true root certificate, the certificate that was actually used as the root a certificate for building a chain is indeed a true root certificate. This does not allow anyone to use any other root certificate, and it is verified only because the chain is being built.

Thus, we guarantee that # 1 with an added root certificate can be built, and # 2 that is built includes our root certificate.