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
Yes, this is necessary information. Not just to extract certain fields, but the whole certificate.
@YangzhenZhao already sent pull request #25, which implemented exactly this, but has been rejected because it publicly exposes a rustls type. This is easily fixed, because the rustls certificate type is simply a byte vector: pub struct Certificate(pub Vec<u8>);.
@skade: I can send a pull request if you indicate that such a solution would be accepted.
I'll reply to the closing comment by @skade on #35 here, so the discussion isn't fragmented all over the place.
I'm not interested in a design that exposes the client certificate raw. async-tls was rather initially designed to implement high level operations on TLS connections ("Client authentication" rather than "here's the client certificate, implement client auth").
I think this makes a lot of sense, when it comes to implementing client auth (i.e. verifying that the client cert matches some criteria). However, a certificate isn't just authentication information that needs to be checked, but also part of the connection payload. Similar to what @Earthson describes in the OP, I need to retrieve the certificate, but not to implement authentication, which I do via the rustls ClientCertVerifier.
In my opinion rustls has a good approach by offering only a set of correctly implemented ClientCertVerifiers, but allowing access to the certificate as data afterwards.
Activity
FlorianUekermann commentedon Sep 2, 2020
Yes, this is necessary information. Not just to extract certain fields, but the whole certificate.
@YangzhenZhao already sent pull request #25, which implemented exactly this, but has been rejected because it publicly exposes a rustls type. This is easily fixed, because the rustls certificate type is simply a byte vector:
pub struct Certificate(pub Vec<u8>);
.@skade: I can send a pull request if you indicate that such a solution would be accepted.
FlorianUekermann commentedon Dec 7, 2020
I'll reply to the closing comment by @skade on #35 here, so the discussion isn't fragmented all over the place.
I think this makes a lot of sense, when it comes to implementing client auth (i.e. verifying that the client cert matches some criteria). However, a certificate isn't just authentication information that needs to be checked, but also part of the connection payload. Similar to what @Earthson describes in the OP, I need to retrieve the certificate, but not to implement authentication, which I do via the rustls
ClientCertVerifier
.In my opinion rustls has a good approach by offering only a set of correctly implemented
ClientCertVerifier
s, but allowing access to the certificate as data afterwards.