Simplify TLS verifier, skip DNSName checking

[mclasmeier]

Simplify TLS verifier: skip DNSName checking

• Drop hostname/DNSName verification from centralVerifyFunc, keeping chain-only verification
• Remove isACentralCert, isLoopback, the central.stackrox fallback, and the ServiceCACommonName/CentralCommonName constants

Motivation

The latest roxie fails in CI on GKE clusters when Central uses custom TLS certificates:

x509: cannot validate certificate for 104.196.9.178 because it doesn't contain any IP SANs

The custom cert has DNS SANs but no IP SANs, and the GKE LoadBalancer exposes only an IP address — so hostname verification always fails.

roxctl sidesteps this entirely because CI invokes it with --insecure-skip-tls-verify --insecure --ca "", bypassing all TLS validation.

Why this is safe

The custom verifier only runs when a CA cert file is available, in which case the trust pool is a narrow, cluster-scoped x509.NewCertPool() — not the system root CAs. It contains only the StackRox internal CA (from central-tls) and, when configured, certs from the custom defaultTLSSecret. Forging a certificate trusted by this pool requires the CA private key, which is stored in the central-tls secret on the cluster. Reading that secret requires kubectl access — at which point the attacker can read the admin password directly.

Without a CA cert file, roxie falls back to Go's default TLS verification with system root CAs and full hostname checking.

Summary by CodeRabbit

• Bug Fixes
  • Updated TLS certificate verification for Central API connections.
  • Simplified certificate-chain validation to provide more consistent connection behavior.
  • Removed hostname-dependent verification that could interfere with valid Central service certificates.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Enterprise

Run ID: a90215d0-acef-4e1a-8c5f-6df9b9f6429c

📥 Commits

Reviewing files that changed from the base of the PR and between 0337b3b and 594df33.

📒 Files selected for processing (1)

• internal/deployer/crs.go

---

📝 Walkthrough

Walkthrough

Central CRS HTTP client TLS handling now uses unified certificate-chain verification. Hostname-based checks, connection-type branching, service certificate fallback logic, related constants, and endpoint parsing have been removed.

Changes

Central CRS TLS verification

Layer / File(s)	Summary
TLS client verification wiring internal/deployer/crs.go	centralHTTPClient wires centralVerifyFunc with only the logger and TLS configuration, while documenting narrow trust-pool and default Go TLS modes.
Chain-only certificate verification internal/deployer/crs.go	centralVerifyFunc validates certificate chains directly without DNS name checks or StackRox service certificate fallback behavior.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Possibly related PRs

• stackrox/roxie#253: Updates the same Central CRS TLS client wiring and certificate verification logic.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: simplifying TLS verification by skipping DNS name checking.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch mc/skip-hostname-verification

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[vladbologa]

LGTM. I also think that chain-only verification is safe here.

The trust pool is narrow (StackRox CA + optional default TLS certs), and modifying either requires cluster access, at which point hostname checking adds no value.