We want that users can do additional verification of the peer certificate without completely disabling the default certificate chain verification. additionalPeerCertificateVerificationCallback is called after the normal certificate chain verification was successful but still gives the user the possibility to accept or reject a connection asynchronously based on the peer certificate.
Modifications
rename AdditionalCertificateChainVerificationCallback to _NIOAdditionalPeerCertificateVerificationCallback as we do not pass in the full certificate chain but just the peers leaf certificate.
move the callback from NIOSSLContext to NIOSSLHandler so users can capture variables in a closure per channel
make the API public but prefixed with an underscore to indicate that this is not a stable feature. We would like to eventually provide the full certificate chain instead of just the the leaf certificate once we can request it from BoringSSL.
Result
Users can now easily do custom peer certificate validation while still getting the system/BoringSSL provided full certificate chain validation.
Motivation
We want that users can do additional verification of the peer certificate without completely disabling the default certificate chain verification.
additionalPeerCertificateVerificationCallbackis called after the normal certificate chain verification was successful but still gives the user the possibility to accept or reject a connection asynchronously based on the peer certificate.Modifications
AdditionalCertificateChainVerificationCallbackto_NIOAdditionalPeerCertificateVerificationCallbackas we do not pass in the full certificate chain but just the peers leaf certificate.NIOSSLContexttoNIOSSLHandlerso users can capture variables in a closure per channelResult
Users can now easily do custom peer certificate validation while still getting the system/BoringSSL provided full certificate chain validation.