enforce_​mtls_​settings

Version: v2024-02-12Includes use: Yes

Behavior name: Enforce mTLS settings

This behavior repeats mTLS validation checks between a requesting client and the edge network. If the checks fail, you can deny the request or apply custom error handling. To use this behavior, you need to add either the hostname or client_certificate criteria to the same rule.

Default behavior

These samples reflect the behavior's default settings. You can use these as is in your configurations or make adjustments based on the behavior's available options.

data "akamai_property_rules_builder" "enforce_mtls_settings" {
  rules_v2025_02_18 {
    name     = "Enforce mTLS settings"
    comments = "Repeats mTLS validation checks between a requesting client and the edge network."
    behavior {
      enforce_mtls_settings {
        enable_auth_set    = false
        enable_ocsp_status = false
      }
    }
  }
}
"behaviors": [
  {
  "name": "enforceMtlsSettings",
  "options": {
    "enableAuthSet": false,
    "enableOcspStatus": false
    }
  }
]

Options

Option Description
enable_auth_set
Whether to require a specific mutual transport layer security (mTLS) certificate authority (CA) set in a request from a client to the edge network.
certificate_authority_set
Specify the client certificate authority (CA) sets you want to support in client requests. Run the List CA Sets operation in the mTLS Edge TrustStore API to get the setId value and pass it in this option as a string. If a request includes a set not defined here, it will be denied. The preset list items you can select are contingent on the CA sets you've created using the mTLS Edge Truststore, and then associated with a certificate in the Certificate Provisioning System.
enable_ocsp_status
Whether the mutual transport layer security requests from a client should use the online certificate support protocol (OCSP). OCSP can determine the x.509 certificate revocation status during the TLS handshake.
enable_deny_request
This denies a request from a client that doesn't match what you've set for the options in this behavior. When disabled, non-matching requests are allowed, but you can incorporate a custom handling operation, such as reviewing generated log entries to see the discrepancies, enable the Client-To-Edge authentication header, or issue a custom message.