Elasticsearch Uses Outdated TLS Policy: Enforcing TLS 1.2 on AWS OpenSearch

Amazon's managed Elasticsearch service (now branded OpenSearch Service) lets you set a minimum TLS version for the HTTPS endpoint that clients use to query and index data. When a domain still allows TLS 1.0, it accepts handshakes from clients negotiating a protocol that the industry deprecated years ago. This check, elasticsearch_tlspolicy, looks at the TLSSecurityPolicy setting on each domain's domain endpoint options and fails any domain pinned to the legacy policy.

---

What this check detects

Every OpenSearch/Elasticsearch domain has a domain endpoint configuration that includes a TLSSecurityPolicy field. AWS offers two named policies:

• Policy-Min-TLS-1-0-2019-07 — allows TLS 1.0, 1.1, and 1.2. This is the default on older domains and is what trips the check.
• Policy-Min-TLS-1-2-2019-07 — requires TLS 1.2 as the minimum. (Newer accounts may also offer a TLS 1.2 PFS-only policy and TLS 1.3 support.)

If the domain reports Policy-Min-TLS-1-0-2019-07, Lensix marks it as failing because TLS 1.0 connections are permitted.

---

Why it matters

TLS 1.0 dates back to 1999 and carries a long list of cryptographic problems. It is vulnerable to attacks like BEAST and POODLE, supports weak cipher suites such as RC4 and 3DES, and lacks the authenticated encryption modes that make TLS 1.2 and 1.3 trustworthy. The PCI Security Standards Council banned TLS 1.0 for cardholder data back in 2018, and major browsers dropped support shortly after.

For an OpenSearch domain, the practical risk depends on where the endpoint lives and what it holds:

• Data exposure on the wire. OpenSearch domains often hold logs, application data, search indexes, and sometimes PII. A weak protocol increases the chance that a man-in-the-middle on the network path can downgrade or decrypt traffic.
• Compliance failures. If you are subject to PCI DSS, HIPAA, SOC 2, or FedRAMP, accepting TLS 1.0 is a direct finding. Auditors flag it quickly because it is trivial to verify.
• Downgrade attacks. Even if your clients all speak TLS 1.2, leaving 1.0 enabled means an attacker who can influence a connection may force a negotiation down to the weakest mutually supported version.

The cost of leaving it on is real, and the cost of fixing it is close to zero. There is no good reason to keep TLS 1.0 enabled on a domain unless you have a hard dependency on an ancient client, which is rare.

---

How to fix it

The fix is a single configuration change: update the domain's TLS security policy to require TLS 1.2 at minimum.

Option 1: AWS Console

1. Open the Amazon OpenSearch Service console.
2. Select the domain from the list.
3. Go to the Security configuration tab and choose Edit.
4. Under Network, find TLS security policy.
5. Select TLS 1.2 (or TLS 1.2 with PFS / TLS 1.3 if available).
6. Save changes. The domain enters a configuration-change state and applies the new policy with no data loss.

Option 2: AWS CLI

First, check the current policy so you know what you are changing:

aws opensearch describe-domain \
  --domain-name my-domain \
  --query 'DomainStatus.DomainEndpointOptions.TLSSecurityPolicy' \
  --output text

If it returns Policy-Min-TLS-1-0-2019-07, update it:

aws opensearch update-domain-config \
  --domain-name my-domain \
  --domain-endpoint-options "TLSSecurityPolicy=Policy-Min-TLS-1-2-2019-07"

For an even stricter posture, use the perfect-forward-secrecy-only policy if your account supports it:

aws opensearch update-domain-config \
  --domain-name my-domain \
  --domain-endpoint-options "TLSSecurityPolicy=Policy-Min-TLS-1-2-PFS-2023-10"

Confirm the change landed once the domain finishes processing:

aws opensearch describe-domain \
  --domain-name my-domain \
  --query 'DomainStatus.DomainEndpointOptions.TLSSecurityPolicy' \
  --output text

Option 3: Terraform

If you manage the domain with Terraform, set tls_security_policy in the domain_endpoint_options block:

resource "aws_opensearch_domain" "this" {
  domain_name    = "my-domain"
  engine_version = "OpenSearch_2.11"

  domain_endpoint_options {
    enforce_https       = true
    tls_security_policy = "Policy-Min-TLS-1-2-2019-07"
  }

  # ... cluster_config, ebs_options, etc.
}

Then apply:

terraform plan
terraform apply

Option 4: CloudFormation

{
  "Type": "AWS::OpenSearchService::Domain",
  "Properties": {
    "DomainName": "my-domain",
    "DomainEndpointOptions": {
      "EnforceHTTPS": true,
      "TLSSecurityPolicy": "Policy-Min-TLS-1-2-2019-07"
    }
  }
}

---

How to prevent it from happening again

Fixing one domain is easy. Keeping every future domain compliant takes a guardrail. A few layers work well together.

Enforce it in your IaC modules

If teams provision OpenSearch domains through a shared Terraform module, bake the secure policy into the module and do not expose TLS 1.0 as a valid input. Use a variable validation to reject anything older than 1.2:

variable "tls_security_policy" {
  type    = string
  default = "Policy-Min-TLS-1-2-2019-07"

  validation {
    condition     = !can(regex("TLS-1-0", var.tls_security_policy))
    error_message = "TLS 1.0 policies are not allowed. Use a TLS 1.2 minimum policy or stricter."
  }
}

Add a policy-as-code gate in CI/CD

Scan Terraform plans before they merge. With Checkov, the relevant rule is CKV_AWS_228 (Elasticsearch domain enforces TLS 1.2):

checkov -d . --check CKV_AWS_228

Or write a custom OPA/Conftest policy against the plan JSON to fail any domain with a TLS 1.0 policy:

package main

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_opensearch_domain"
  policy := resource.change.after.domain_endpoint_options[_].tls_security_policy
  contains(policy, "TLS-1-0")
  msg := sprintf("%s allows TLS 1.0; require a TLS 1.2 minimum policy", [resource.address])
}

Catch drift continuously

IaC gates only cover resources created through IaC. Someone may spin up a domain by hand or restore an old one with stale settings. Continuous monitoring closes that gap. Lensix runs the elasticsearch_tlspolicy check across your accounts on a schedule, so a domain that drifts to TLS 1.0 surfaces as a finding rather than waiting for an annual audit.

---

Best practices

• Standardize on TLS 1.2 as the floor, TLS 1.3 where available. Make the secure policy the default everywhere and require an explicit, documented exception for anything weaker.
• Always pair the TLS policy with enforced HTTPS. A strong minimum TLS version does nothing if the domain still answers on plain HTTP.
• Audit your clients before tightening. Inventory every application, ingestion pipeline, and dashboard that talks to the domain. Upgrade old TLS stacks proactively so the policy change is a non-event.
• Restrict network exposure too. A VPC-bound domain with tight security groups reduces the attack surface regardless of TLS version. Defense in depth beats relying on any single control.
• Encrypt at rest and node-to-node. The endpoint TLS policy protects data in transit to clients. Enable encryption at rest and node-to-node encryption to cover the full data path.
• Review TLS policies after major engine upgrades. AWS periodically adds newer, stricter policies (PFS-only, TLS 1.3). Revisit your domains so you adopt them rather than sitting on the minimum forever.

TLS 1.0 on an OpenSearch domain is a low-effort, high-clarity fix. Change the policy, confirm your clients are ready, and put a guardrail in place so it never comes back.