Provide way to log TLS client authentication information

Graylog clients may identify and authenticate themselves through a TLS negotiation if TLS and client authentication are turned on for the input. It would be good to be able to record some of the client authentication information so one could determine which client injected a message. This is particularly important for forensics since clients may put arbitrary information in the message itself, allowing attackers to generate messages that appear to come from any client they like.

## Background

When TLS client authentication is enabled (whether optional or required), the client may [present a certificate to the server](https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake). In the case where it's required, the server will also have a list of trusted certificates and the will ensure that some part of the information in the certificate the client presents (at the very least, the client's public key) appears in a certificate in that list.

It's important to remember here that the only thing that's sure to be cryptographically verified is the client's public key. Any further information in the certificates is trusted only because the certificate is in the authorized certificates list or, potentially, via verification of the issuer signatures on certificate the client sent if the server chooses to do that and has available the chain of issuer certificates leading back to a trusted CA. (Intermediate certificates in the chain can be presented by the client; the server must have its own copy of the trusted CA certificate).

Given that currently the server does not appear to verify the certificate chain (it will allow clients to connect using certificates for which it does not have a root CA cert for the chain, so long as that certificate is in the authorized certificates list) I would suggest that the only certificate information used in logging be that from the certificate from the authorized list, and the certificate sent by the client be ignored except for the public key presumably used to find the certificate in the authorized certs list.

## Suggested Implementation

I'm not very familiar with Graylog so I can't provide concrete suggestions on implementation. However, it would probably be useful to be able to record something less than the full certificate or public key in the Graylog entries.

If recording large but frequently repeated data is cheap in Elasticsearch, adding a `gl2_remote_cert` field with the entire certificate contents would be advisable since analysts then do not have to try to find the certificate in an external file listing the authorized certs (if any of those files even still contain the cert—it might have been changed or removed since the log entry was made). If that's too expensive a hash of the certificate could be recorded, but one would want to be careful to record hash of the _entire_ certificate, not just part of it (such as the Subject or Issuer).

For ease of analysis, it would be nice if parts of the certificate, such as just the issuer and subject, just the subject, or just part of the subject (such as the Common Name) could be recorded in separate fields. For example, if working within a PKI where all certificates are signed (directly or indirectly) by the same Certificate Authority, and all certificates have common parts to the subject identifier, it would be convenient to record just the non-common parts. E.g., for a subject `C=CA/ST=Alberta/L=Edmonton/O=Bioware/OU=Server Ops/CN=some client` we might wish to record only the CN `some client` in a field.

## Context

See my [Recording Authenticated Source (Client Certificate) for Forensics](https://community.graylog.org/t/recording-authenticated-source-client-certificate-for-forensics/1126/2) post in the Graylog community forums.

## Environment

* Graylog Version: 2.2.3