Actual behavior

ide fix-vpn-tls-problem <url> reports success and makes no changes when the given URL redirects (HTTP 30x) to another host whose certificate is the one actually being rejected.

Concrete case: ide rust fails while installing its msvc dependency when downloading https://aka.ms/vs/17/release/vs_BuildTools.exe:

java.lang.IllegalStateException: Download of msvc-17.0-windows-x64.exe failed after trying 1 URL(s).
...
Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed:
  sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Running the suggested fix does nothing useful:

$ ide fix-vpn-tls-problem https://aka.ms/vs/17/release/vs_BuildTools.exe
Successfully connected to aka.ms:443 without certificate changes.
No truststore update is required for the given address.

Root cause: the commandlet parses the URL down to host:port and probes reachability with a hand-rolled raw SSLSocket handshake (TruststoreUtil.isReachable) instead of reusing the central redirect-following HttpClient (HttpDownloader.createHttpClient() → followRedirects(ALWAYS)) that the real downloader uses. aka.ms is a redirector whose own certificate is publicly trusted, so the socket handshake to aka.ms:443 succeeds. The intercepted certificate lives on the redirect target (the Visual Studio CDN host), which the probe never contacts. Certificate capture (TruststoreUtil.fetchServerCertificate) has the same flaw — it would capture aka.ms's already-trusted certificate, not the offending one.

Reproduce

Steps to reproduce the bug:

1. Be on a network that performs TLS interception (e.g. corporate VPN) on the download CDN but not on aka.ms.
2. ide rust → fails with PKIX path building failed while downloading https://aka.ms/vs/17/release/vs_BuildTools.exe.
3. ide fix-vpn-tls-problem https://aka.ms/vs/17/release/vs_BuildTools.exe → prints Successfully connected to aka.ms:443 without certificate changes. No truststore update is required for the given address. and makes no changes.
4. ide rust still fails. Only manually creating a truststore and linking it via IDE_OPTIONS resolves the problem.

Expected behavior

fix-vpn-tls-problem should follow HTTP redirects exactly like the actual download (reusing the central followRedirects(ALWAYS) HttpClient), detect the untrusted certificate on the effective (post-redirect) host, capture it, add it to the custom truststore and configure IDE_OPTIONS — so that the subsequent ide rust / download succeeds.

IDEasy status

Output of ide -p status (paths/project name sanitized):

IDE_ROOT is set to D:\projects
IDE_HOME is set to D:\projects\<project>
You are online.
Your settings are up-to-date.
Your version of IDEasy is 2026.06.001
Your operating system is windows(11)@x64 [Windows 11@amd64]

Related/Dependent issues

TLS/proxy support — see documentation/proxy-support.adoc#tls-certificate-issues.

Comments/Hints

A central HttpClient builder with followRedirects(ALWAYS) already exists (HttpDownloader.createHttpClient()), duplicated in IdeaPluginDownloader and AbstractUrlUpdater, but it was not reused by the truststore commandlet. The fix should centralize that builder and route the reachability probe and certificate capture through it so redirects are followed consistently with the download path.