Client Certificate Authentication
Currently, this feature is only available to select customers.
If you're using mutual authentication (mTLS), use this to send a header to your origin server that contains details from the mTLS certificate that was sent from the requesting client to the edge network.
How it works
With mTLS, both a requesting client and the Akamai edge server present a TLS certificate to the other, with each side validating the certificate during the "TLS handshake." Once both certificates are validated, the connection is allowed.
After the TLS handshake is approved, you can have this behavior pull various information from the client's successful certificate and forward it on to your origin server as header values. You can configure your origin server to review and trust the headers, to enable transitive trust.
This works with Enforce mTLS settings
This behavior is designed to use the Client Certificate match, serving in a child rule to a parent rule that includes the Enforce mTLS settings behavior. The Enforce mTLS behavior is what's used to check the certificates and validate the certificates during the TLS handshake.
For an example of its use, see the Enforce mTLS settings behavior.
Features and options
Field | What it does |
---|---|
Enable | With this enabled, an edge server builds the Client to Edge HTTP Authentication headers using information from the client to edge server mTLS handshake and sends it to your origin server. |
Complete client certificate | Enable this to include the complete client certificate in the |
Client certificate attributes | Use these options to select specific client's x.509 certificate attributes in the header, instead of including the entire certificate. To use this field, make sure you set the “Complete client certificate” to Off.
|
Certificate validation status | With this enabled, the edge server includes the current validation status of the client certificate in the The client cert validation status in
|
Updated 6 months ago