你好，
我在尝试使用在MS-Windows上严格防火墙后面的clojure工具下载项目依赖项时遇到了PKIX证书异常。
无法从中央仓库传输工件 ... 到/从
(https://repo1.maven.org/maven2/)
sun.security.validator.ValidatorException: PKIX路径构建失败
sun.security.provider.certpath.SunCertPathBuilderException: unable
to find valid certification path to requested target
我认为这是由于防火墙利用自签名根证书来控制以及监控流量造成的。
以下为分析内容，因篇幅较长，敬请谅解。
在大公司中，将工作站置于防火墙后方是一个标准做法，该防火墙控制并监控来自互联网的所有流量。公司通常会创建他们自己的自签名根证书，并替换掉https流量中找到的证书，以便解密和分析数据流，实际上利用中间人攻击来达到他们的目的。
为此，连接起源于的用户工作站必须在受信任的证书存储中安装自签名证书。在Windows上，这将是受信任根授权证书密钥库。
Java带有自己的证书存储，即java KeyStore，它与工作站上可用的通用密钥库分开。因此，通过防火墙通过Java https连接到互联网很可能会因未知证书错误而失败，因为自签名证书未安装在Java密钥库中。
这会对clojure/clj命令行工具在下载库时产生不利影响，因为它找不到Java密钥库中的自签名证书。例如，当试图从此类计算机访问互联网时，会抛出异常
> clojure -P
Error building classpath ...
org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to
read artifact descriptor for .... ... Caused by:
org.eclipse.aether.resolution.ArtifactResolutionException: Could not
transfer artifact ... from/to central
(https://repo1.maven.org/maven2/):
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target ...
...
我可以想到至少两个规避此问题的解决方案
1. 在Java密钥库中安装缺少的证书，或者
2. 指导Java实例查找通用密钥库。
似乎没有简单的方法可以直接发现缺失的证书，可能需要用户自己费劲力气使用java keytool将其安装到Java密钥库中（有关证书和SSL的信息，请参阅https://docs.oracle.com/cd/E19830-01/819-4712/ablqw/index.html）。
相反，似乎更容易指导Java使用java.next.ssl.*属性来查看通用或备用密钥库（请参阅https://stackoverflow.com/questions/5871279/ssl-and-cert-keystore）。
在Windows上，这是因为我假设大多数拥有如此限制性防火墙的用户都坐在那里，只需简单设置一个Java属性来指示Java使用通用的Windows密钥库（https://stackoverflow.com/questions/41257366/import-windows-certificates-to-java）
javax.net.ssl.trustStoreType=Windows-ROOT
基于这一点，我预计以下内容在Windows上应该能够工作
clojure -J-D'javax.net.ssl.trustStoreType=Windows-ROOT' -P
但它并没有。结果是，$JvmOpts变量在此 PowerShell 脚本中没有被传递给 prep 命令，如 https://github.com/clojure/brew-install/blob/b91fb78e321b5e39bedda594f5d578579d448d19/src/main/resources/clojure/install/ClojureTools.psm1#L388 所示
& $JavaCmd -classpath $ToolsCp clojure.main -m clojure.tools.deps.alpha.script.make-classpath2 --config-user $ConfigUser --config-project $ConfigProject --basis-file $BasisFile --libs-file $LibsFile --cp-file $CpFile --jvm-file $JvmFile --main-file $MainFile --manifest-file $ManifestFile @ToolsArgs
为了利用Java属性来解决这个一般问题，我可以想到一些选项，从最具侵略性/最具体到一般情况
- 将负责下载依赖的
clojure.tools.deps.alpha.script.make-classpath2函数设置为在Windows上运行时设置javax.net.ssl.trustStoreType=Windows-ROOT，.
- .例如，使用
(System/setProperty "javax.net.ssl.trustStoreType" "Windows-ROOT")。
- cons
- 这只能在Windows上工作。
- 这会强制使用通用的密钥库，而这可能不是用户始终想要的。
- 这可以通过有一个新的脚本选项（比如-W）来解决，该选项将作为选项传递给
clojure.tools.deps.alpha。缺点是用户/工具在每次调用时都必须始终传递此标志。
- 使用
System/setProperty运行时设置javax.net.ssl.tustStoreType属性可能没有任何效果，如果代码中的其他部分之前已建立任何SSL连接。
- 与之前相同，但引入一个新的脚本选项（例如-Sssl EDN），其中EDN是
javax.net.ssl.*属性，并将作为此类传递给clojure.tools.deps.alpha以在运行时设置。
- 例如，使用
clojure -Sssl {:trustStoreType "Windows-ROOT"} -P
- cons
- 与#1相同的缺点，而且用户在每次调用clojure时都必须输入edn地图，更麻烦。
- 发明一个新的deps.edn密钥（例如
:clojure.tools.deps.alpha/ssl），其配对应给出java.net.ssl.*属性，可以在用户配置的deps.edn中设置并解析通过clojure.tools.deps.alpha的make-classpath2函数在运行时设置属性，使用System/setProperty。
- 例如，示例clj用户配置为
{:clojure.tools.deps.alpha/ssl {:trustStore "Windows-ROOT"}}
- cons
- 使用
System/setProperty在运行时设置javax.net.ssl.*属性可能没有任何效果，如果代码中的其他部分之前已建立任何SSL连接。
- 更新脚本，以确保将-J jvm选项传递到-P命令的Java调用中（我已经测试过这可以工作）。
- 例如，使用
clojure -J-D'javax.net.ssl.trustStoreType=Windows-ROOT' -P
- cons
- 用户/工具仍在每次clojure调用时必须提供
-J-Djavax.net.ssl.*选项。
- 与之前相同，但引入一个环境变量
CLJ_JVMOPTS，其值插入到脚本的$JvmOpts变量中。
- 例如，使用
set CLJ_JVMOPTS=-D'javax.net.ssl.trustStoreType=Windows-ROOT'，然后clojure -P
我更倾向于#5，因为这似乎没有任何缺点，可以设置一次并在所有clojure调用中应用，为用户/工具皿创造更好的体验。
让我知道您的想法。很高兴看到脚本和/或tools.deps.alpha库中的更改。
谢谢
PS：我还在MAVEN_OPTS变量中也尝试过设置属性，如同 https://maven.apache.org/guides/mini/guide-repository-ssl.html，但它没有效果。我怀疑这只有在直接调用mvn命令行工具时才生效。
