本文详解 openshift 0.3.3 样例应用中因工作目录切换不当导致的自签名证书校验失败问题，指出 x509: certificate signed by unknown authority 错误本质是客户端无法定位到生成的本地 ca 证书，核心解法在于严格遵循子目录上下文执行命令。
在 OpenShift Origin v0.3.3 的 sample-app 快速入门流程中，证书相关错误（如 Get https://localhost:8443/...: x509: certificate signed by unknown authority）并非 TLS 配置缺陷或证书损坏，而是典型的路径上下文错位问题。该版本采用分阶段证书生成机制：OpenShift 启动时会在当前工作目录下自动生成一套临时 PKI（含 ca.crt、server.crt、server.key 等），而客户端工具（如 openshift ex policy 和 openshift ex registry）默认从当前目录或 $KUBECONFIG 指向的配置中读取证书信任链。
关键陷阱在于官方文档中隐含的目录依赖关系：
- ✅ 步骤 1（启动 OpenShift 并生成证书）：必须在 origin/examples/sample-app/ 目录下执行（例如 ./openshift start --write-config=openshift.local.config），此时证书将生成于该目录下的 openshift.local.config/master/ 子路径中；
- ❌ 步骤 4（执行策略与 registry 命令）：若此时已切换至 origin/ 根目录（常见于 make build 后），则 openshift ex 工具将无法自动发现上一步生成的 ca.crt，导致所有 HTTPS 请求因证书不被信任而失败。
正确操作流程如下：
# 1. 进入 sample-app 示例目录（务必在此目录执行启动） cd origin/examples/sample-app/ # 2. 启动 OpenShift 并生成本地配置（证书由此产生） ./openshift start --write-config=openshift.local.config & # 3. 确保服务就绪后，在同一目录下执行策略命令 openshift ex policy add-user view anypassword:test-admin # 4. 创建 registry（仍在同一目录！） openshift ex registry --create --credentials="$(pwd)/openshift.local.config/master/admin.kubeconfig"
⚠️ 注意事项：不要修改源码（如注释 Fatal()）或手动编辑证书路径——这会破坏安全模型且不可维护；$KUBECONFIG 环境变量需显式指向 openshift.local.config/master/admin.kubeconfig（推荐使用绝对路径或 $(pwd)/...）；若已发生目录错位，可直接复制证书：cp openshift.local.config/master/ca.crt ~/.kube/ca.crt 并在 kubeconfig 中更新 certificate-authority 字段，但推荐重走标准流程以避免状态不一致。
本质上，这是早期 OpenShift 版本对“工作目录即配置根目录”这一约定的强依赖。后续版本（v1.0+）已通过 --master、--certificate-authority 等显式参数解耦路径耦合，但在 v0.3.3 中，坚守目录上下文就是最简洁、最安全的解决方案。
