Getting certificate handle in verification callback

[wafflespeanut]

Hi! This is a follow-up to #25 where @Lukasa said:

I'm reluctant to go too far down the road of exposing certificate data here because it starts pushing swift-nio-ssl into the territory of a general-purpose crypto library

I agree that NIO-SSL shouldn't become a crypto lib, but right now we can't get any kind of useful information out of the certificate (other than SPKI). Would it be sensible to expose the underlying opaque pointer for users, so that they can call the necessary OpenSSL APIs and perform their own checks (and possibly warn the users about its unsafety)?

A typical use case would be verifying the signature of a self-signed client certificate, where I'm only concerned about whether the client is the actual owner of the presented public key and nothing else (other use cases include getting CNs, SANs or PEM data).

[Lukasa]

Rather than expose the underlying pointer, I’d rather expose the DER-encoded bytes. This is more in line with what we do with the public keys, and avoids users needing to work with unsafe pointers. Does that suit you?

[wafflespeanut]

Yep! That works for me!

[vlm]

rdar://58481718 (swift-nio-ssl: Expose certificate information to validation callbacks)

[Lukasa]

See: #172.

[Lukasa]

Resolved by #172, we should hopefully ship a release soon that contains this functionality.