You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I might be missing something, but it looks to me like warp-tls can't authenticate clients properly, by which I mean, against a CA cert that it doesn't have the private key for.
Where would the CA cert go? If I use runTLS or runTLSServer it'll want a TLSSettings which has the fields tlsCredentials and certSettings. It can't be the former cos that's all cert+key pairs but CAs don't disclose their private keys to all the people they vouch for. If the latter, it could only be the "chain" member but as I reported on stack overflow here ...
... the client was accepted both when that was empty and when it was populated with a CA cert for which the client offered no creds.
It seems to me that a TLS peer loads certificates for two reasons:
authenticating itself to others, in which case said peer needs its own private key, and
authenticating others to itself by referring to a trusted CA, in which case it doesn't need that CA's private key.
This distinction is well modelled in Network.TLS but gets lost in Network.Connection which then presents warp-tls with sand upon which to build its castle.
I do hope I'm talking utter rubbish here and somebody can show me how this is supposed to work.
The text was updated successfully, but these errors were encountered:
I might be missing something, but it looks to me like
warp-tls
can't authenticate clients properly, by which I mean, against a CA cert that it doesn't have the private key for.Where would the CA cert go? If I use
runTLS
orrunTLSServer
it'll want aTLSSettings
which has the fieldstlsCredentials
andcertSettings
. It can't be the former cos that's all cert+key pairs but CAs don't disclose their private keys to all the people they vouch for. If the latter, it could only be the "chain" member but as I reported on stack overflow here ...https://stackoverflow.com/questions/73293730/trying-to-make-haskell-warp-tls-authenticate-the-client
... the client was accepted both when that was empty and when it was populated with a CA cert for which the client offered no creds.
It seems to me that a TLS peer loads certificates for two reasons:
This distinction is well modelled in Network.TLS but gets lost in Network.Connection which then presents warp-tls with sand upon which to build its castle.
I do hope I'm talking utter rubbish here and somebody can show me how this is supposed to work.
The text was updated successfully, but these errors were encountered: