"certificate rejected: [SelfSigned]"

[o1lo01ol1o]

Hi, I'm running into an issue connecting to a third-party's api using a provided certificate. I've configured the supported ciphers and created a cert store using only the top-level client certificate as per their instructions. (I omit intermediary certificates also per their instructions.)

This results in:

InternalException (HandshakeFailed (Error_Protocol ("certificate rejected: [SelfSigned]",True,CertificateUnknown

Could anyone shed some light onto what it might mean?

[ocheron]

If this exception is thrown by the client, this means it does not trust the root CA given by the server.

You mention a step about a client certificate, but the server root certificate must also be added to sharedCAStore in clientShared.

[o1lo01ol1o]

@ocheron Thanks for the info, that's helpful. Is there any ordering required to correctly populate the store?

Is it as simple as makeCertificateStore [clientCert, rootCert]?

I ask because including both the root and the client yields a 500 ... The digital certificate is invalid. As does including all intermediary certificates in the chain. However, the client certificate works when installed in the browser and pointed to the test endpoint.

[ocheron]

The client certificate does not go to sharedCAStore but sharedCredentials instead.
You need to provide both the client certificate chain and private key.

[o1lo01ol1o]

In the end I needed to provide the onCertificateRequest ClientHook to pull out the credential I provided in sharedCredentials when the server requested it. Is this the intended usage? It seems more than a little confusing to have already provided sharedCredentials to the TLSSettings and then also be required to write the callback that finds the needed credentials when they're asked for. If it is the intended usage of the library, some documentation would have saved me a significant amount of time learning this.

[ocheron]

Yes you're right, it is onCertificateRequest and not sharedCredentials, sorry.
Documentation will be very welcome if you can contribute some.

[o1lo01ol1o]

Where should such documentation live? It would likely only be a minimal code example and text.

[ocheron]

We can start with simplest possible thing, it's always possible to refactor later when more content is available. I'm thinking EXAMPLES.md at top-level. Or something similar to module Crypto.Tutorial, then in core.

Primary goal is to show what ClientParams to use. Possibly with tls only, or from context of package connection. Improving the Haddock comments on parameters is also something we need.

What works best for you and you feel most useful to avoid the issue you ran into.