[ 
https://issues.apache.org/jira/browse/GEODE-10561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jinwoo Hwang updated GEODE-10561:
---------------------------------
    Description: 
h2. Summary

Create official Apache Geode documentation that explains three supported TLS 
deployment models and migration guidance in response to the upcoming public CA 
removal of the Client Authentication EKU. The documentation will be an 
authoritative operator guide covering configuration, rotation, verification, 
and recommended automation patterns.

Note: This guidance applies only to environments using newly issued public-CA 
mTLS certificates where the public CA's issuance does not include client CA 
certificates in the chain. If your deployment already uses an 
enterprise/internal CA or a public-CA chain that includes client CA 
certificates, no action is required; those deployments are not affected by this 
guidance and should continue to follow the internal-CA or hybrid guidance where 
appropriate.
h2. Background

Public Certificate Authorities are removing or changing issuance behavior for 
client-auth EKUs on publicly-issued leaf certificates. This impacts users who 
relied on public-CA-signed client certificates for mutual TLS (mTLS) with 
Apache Geode. We must produce an official doc describing viable options and 
migration steps.
h2. Objective

Produce a concise, reviewable doc set and a single canonical HOWTO that covers:
 - Option A: Internal / enterprise CA for mTLS
 - Option B: Server-only TLS + application-layer client authentication (no 
client certs)
 - Option C: Hybrid — public-CA server certs + private-CA client certs

h2. Tasks
 * Create top-level doc `docs/TLS_MIGRATION_GUIDE.md` that aggregates content.
 * Finalize and land docs in `main` and backport to supported release branches.

h2. Priority & Due Date

Priority: High — public CA policy changes have a concrete timeline. Suggest 
target: 3 weeks.

  was:
h2. Summary

Create official Apache Geode documentation that explains three supported TLS 
deployment models and migration guidance in response to the upcoming public CA 
removal of the Client Authentication EKU. The documentation will be an 
authoritative operator guide covering configuration, rotation, verification, 
and recommended automation patterns.

Note: This guidance applies only to environments using newly issued public-CA 
mTLS certificates where the public CA's issuance does not include client CA 
certificates in the chain. If your deployment already uses an 
enterprise/internal CA or a public-CA chain that includes client CA 
certificates, no action is required; those deployments are not affected by this 
guidance and should continue to follow the internal-CA or hybrid guidance where 
appropriate.
h2. Background

Public Certificate Authorities are removing or changing issuance behavior for 
client-auth EKUs on publicly-issued leaf certificates. This impacts users who 
relied on public-CA-signed client certificates for mutual TLS (mTLS) with 
Apache Geode. We must produce an official doc describing viable options and 
migration steps.
h2. Objective

Produce a concise, reviewable doc set and a single canonical HOWTO that covers:
 - Option A: Internal / enterprise CA for mTLS
 - Option B: Server-only TLS + application-layer client authentication (no 
client certs)
 - Option C: Hybrid — public-CA server certs + private-CA client certs

h2. Tasks
 * Create top-level doc `docs/TLS_MIGRATION_GUIDE.md` that aggregates content.
 * Reuse and consolidate existing drafts: `docs/INTERNAL_CA_MTLS.md`, 
`docs/SERVER_ONLY_TLS_ALT_AUTH.md`, 
`docs/SERVER_PUBLIC_CLIENT_PRIVATE_CA_HYBRID.md`.
 * Finalize and land docs in `main` and backport to supported release branches.

h2. Priority & Due Date

Priority: High — public CA policy changes have a concrete timeline. Suggest 
target: 3 weeks.


> TLS Migration : Mitigations for Public‑CA Client‑Auth EKU Removal
> -----------------------------------------------------------------
>
>                 Key: GEODE-10561
>                 URL: https://issues.apache.org/jira/browse/GEODE-10561
>             Project: Geode
>          Issue Type: Improvement
>            Reporter: Jinwoo Hwang
>            Assignee: Jinwoo Hwang
>            Priority: Major
>
> h2. Summary
> Create official Apache Geode documentation that explains three supported TLS 
> deployment models and migration guidance in response to the upcoming public 
> CA removal of the Client Authentication EKU. The documentation will be an 
> authoritative operator guide covering configuration, rotation, verification, 
> and recommended automation patterns.
> Note: This guidance applies only to environments using newly issued public-CA 
> mTLS certificates where the public CA's issuance does not include client CA 
> certificates in the chain. If your deployment already uses an 
> enterprise/internal CA or a public-CA chain that includes client CA 
> certificates, no action is required; those deployments are not affected by 
> this guidance and should continue to follow the internal-CA or hybrid 
> guidance where appropriate.
> h2. Background
> Public Certificate Authorities are removing or changing issuance behavior for 
> client-auth EKUs on publicly-issued leaf certificates. This impacts users who 
> relied on public-CA-signed client certificates for mutual TLS (mTLS) with 
> Apache Geode. We must produce an official doc describing viable options and 
> migration steps.
> h2. Objective
> Produce a concise, reviewable doc set and a single canonical HOWTO that 
> covers:
>  - Option A: Internal / enterprise CA for mTLS
>  - Option B: Server-only TLS + application-layer client authentication (no 
> client certs)
>  - Option C: Hybrid — public-CA server certs + private-CA client certs
> h2. Tasks
>  * Create top-level doc `docs/TLS_MIGRATION_GUIDE.md` that aggregates content.
>  * Finalize and land docs in `main` and backport to supported release 
> branches.
> h2. Priority & Due Date
> Priority: High — public CA policy changes have a concrete timeline. Suggest 
> target: 3 weeks.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to