Insert Client Certificate in HTTP header and forward to the upstream

Current behavior

Since APIcast is a NGINX based product, it should provide the same features a vanilla NGINX does.

With NGINX you can:

• Make the TLS termination at NGINX level
• Enable mTLS
• Do not validate against any CA the client certificate (skip client certificate validation)
• Pass the client certificate to a backend in the "x-ssl-client-cert" header.

All of that can be done in NGINX with the following configuration:

 server \{
        listen 443 ssl;
        ssl_password_file      /etc/keys/ssl_passwords.txt;
        ssl_certificate        /etc/keys/server.crt;
        ssl_certificate_key    /etc/keys/server.key;
        ssl_protocols          TLSv1.2 TLSv1.3;
        # client
        ssl_verify_client      optional_no_ca;
        ssl_verify_depth       2;

        location / {
            proxy_pass         http://*.*.*.*:8080;
            ....
            proxy_set_header   x-ssl-client-cert $ssl_client_escaped_cert;
        }
    }

However, currently APIcast doesn't allow you to set up a similar configuration to implement the same use case.

Expected behavior:
You want to terminate the SSL/TLS communication at APIcast level (without doing any Client Certificate validation) and forward the Client Certificate to the backend server, by inserting it into a HTTP header.

The default http header name could be "x-ssl-client-cert". This http header name should be configurable in order to get more flexibility.

Additionally, the content of that header (client certificate in PEM format) should be encoded in base64 if needed.

Format of possible configuration fields:

certificate_header = "<Header Name>"

#This property needs to be true if the certificate should be encoded when it is passed from the Gateway to the upstream.
client_certificate_base64_encode  = false

Example of a possible configuration (being flexible to allow to use values different from the default ones)

certificate_header = "x-apicast-client-cert"
client_certificate_base64_encode = true

 Why the need ?

This use case is necessary in those cases where, for security reasons, validation of the client certificate must be done at the upstream level and therefore cannot be done at the gateway level.