API Gateway stages should not use client SSL certificates
API Gateway client certificates authenticate the gateway to your backend, not the caller to your API. That's a useful capability but also a cert lifecycle problem: API Gateway-issued certificates are valid for exactly 365 days and rotation requires coordinated changes across the stage and all backend trust stores. This control keeps client_certificate_id unset, avoiding that dependency unless you have a deliberate backend mutual TLS requirement that's been explicitly provisioned.
Retrofit consideration
client_certificate_id without coordinated backend changes can break traffic.Implementation
Choose the approach that matches how you manage Terraform.
Use AWS provider resources directly. See docs for the resources involved: aws_api_gateway_stage.
resource "aws_api_gateway_rest_api" "this" {
name = "pofix-abc123"
}
resource "aws_api_gateway_stage" "this" {
access_log_settings {
destination_arn = "arn:aws:logs:us-east-1:123456789012:log-group:example-log-group"
format = "$context.requestId"
}
client_certificate_id = "abc123"
deployment_id = "abc123"
rest_api_id = "abc123"
stage_name = "example"
}What this control checks
To pass, each aws_api_gateway_stage resource must omit client_certificate_id or set it to null. It fails when client_certificate_id is set to any certificate ID. This applies to REST APIs (aws_api_gateway_rest_api) only, not HTTP APIs (aws_apigatewayv2_api).
Common pitfalls
Certificate lifecycle still creates operational risk
API Gateway-generated client certificates are valid for exactly 365 days and aws_api_gateway_client_certificate gives you no argument to change that. Rotation means creating a new resource, updating the stage reference, and updating backend trust stores, all in a coordinated change. Get any step out of order and your backend rejects the gateway.
Control scope differs from backend mTLS design
This control evaluates the presence of client_certificate_id, not whether mutual TLS to the backend is a good idea. If your backend is designed around API Gateway client-certificate authentication, that architecture will conflict with this control by design. Document the exception with risk acceptance rather than assuming the control doesn't apply.
Inline stage settings on deployment are limited
Use a standalone aws_api_gateway_stage resource rather than setting stage_name on aws_api_gateway_deployment. The deployment resource doesn't expose client_certificate_id, so older configurations relying on inline stage names can't be evaluated or managed for this setting.
Stage updates vs API redeployments
Removing client_certificate_id is a stage-level change and doesn't require a new API deployment snapshot. Reserve aws_api_gateway_deployment redeployments for API configuration changes, not stage setting updates like this one.
Audit evidence
Auditors check that REST API stages show no value in the API Gateway Stage 'Client Certificate' field and that aws_api_gateway_stage in IaC does not set client_certificate_id. CloudTrail CreateStage and UpdateStage events are reviewable for clientCertificateId in request parameters, showing when a certificate was attached or removed.
Framework-specific interpretation
PCI DSS v4.0: Requirement 4 calls for protecting transmissions with strong cryptography. Whether this control is directly applicable depends on where cardholder data flows through your API Gateway configuration and what compensating controls are in place.
HIPAA Omnibus Rule 2013: 45 CFR 164.312(e)(1) requires transmission security, and this control is one part of that picture. It doesn't satisfy the requirement on its own, but contributes to a broader encryption and integrity program.
NIS2 Directive (EU 2022/2555): NIS2 Article 21 expects appropriate authentication and encryption across network and information systems. This control generally aligns with those expectations, though NIS2 doesn't prescribe specific AWS mechanisms.
NIST SP 800-53 Rev 5: SC-8 (Transmission Confidentiality and Integrity) and SC-23 (Session Authenticity) are most directly relevant, but applicability depends on implementation context.
FedRAMP Moderate Baseline Rev 4: SC-8 and SC-23 are the most relevant controls here. Whether this stage configuration supports or conflicts with them depends on system design and how your boundary protections are documented.
Related controls
Tool mappings
Use these identifiers to cross-reference this control across tools, reports, and evidence.
- Compliance.tf Control:
apigateway_rest_api_stage_use_ssl_certificate - AWS Config Managed Rule:
API_GW_SSL_ENABLED - Checkov Check:
CKV2_AWS_51 - Powerpipe Control:
aws_compliance.control.apigateway_rest_api_stage_use_ssl_certificate - Prowler Check:
apigateway_restapi_client_certificate_enabled - AWS Security Hub Control:
APIGateway.2 - KICS Query:
0b4869fc-a842-4597-aa00-1294df425440
Last reviewed: 2026-03-08