SAP BTP Custom Domain配置实战与DNS验证技巧

1. 项目背景与核心价值

在SAP BTP Cloud Foundry环境中配置Custom Domain Manager的初始设置，是企业级应用上云过程中不可或缺的关键环节。这个看似基础的操作实际上直接影响着后续所有服务的访问安全性和品牌一致性。我最近在金融行业客户项目中亲历了一次完整的配置流程，深刻体会到其中几个容易被忽视的技术细节。

简单来说，Custom Domain Manager允许你将默认的*.cfapps.sap.hana.ondemand.com域名替换为自己的企业域名（如api.yourcompany.com）。这不仅仅是URL美观的问题，更是企业IT治理的基本要求——想象一下你的生产环境API还在用第三方域名，这在安全审计时绝对会被打上问号。

2. 环境准备与权限配置

2.1 Entitlement分配实战

在SAP BTP Cockpit中分配权限时，90%的配置错误都源于对Entitlement机制的误解。不同于传统IaaS的权限模型，BTP的Entitlement是服务级别的资源配额。为Cloud Foundry环境添加Custom Domain Manager时，需要特别注意：

1. 进入Global Account级别的"Entitlements"页面
2. 点击"Configure Entitlements"后选择"Add Service Plans"
3. 在搜索框输入"Custom Domain"会显示两个关键服务：
   • "Custom Domains" (服务名：custom-domains)
   • "Custom Domain Manager" (服务名：custom-domain-manager)
4. 分配时建议选择"standard"计划

关键提示：即使子账户(Subaccount)已经显示有Custom Domain服务，如果Global Account未分配配额，实际部署时仍会报403错误。这是我踩过的典型坑——以为在子账户能看到服务就代表可用。

2.2 订阅服务的隐藏逻辑

完成Entitlement分配后，在Subaccount级别创建服务实例时，SAP的控制台交互存在一个设计反模式：

bash复制# 正确的CLI创建命令示例
cf create-service custom-domain-manager standard my-custom-domain

但通过Web控制台操作时，你会发现下拉菜单中可能找不到这个服务。这不是权限问题，而是UI加载机制导致的——需要先点击左侧菜单的"Service Marketplace"，等待全部服务加载完成后，再搜索"custom domain"才会显示。这个加载延迟经常被误认为是权限配置错误。

3. DNS配置的魔鬼细节

3.1 CNAME与TXT记录的双验证

配置DNS记录时，大多数文档只强调CNAME记录指向your-subdomain.cfapps.sap.hana.ondemand.com，但实际企业部署中，TXT记录的验证同样关键。以阿里云DNS为例：

1. 先添加CNAME记录：

   • 记录类型：CNAME
   • 主机记录：api (对应最终域名api.yourcompany.com)
   • 记录值：your-subdomain.cfapps.sap.hana.ondemand.com
   • TTL：建议600秒（10分钟）

2. 必须同步添加TXT记录：

   • 记录类型：TXT
   • 主机记录：_cf-custom-hostname.api.yourcompany.com
   • 记录值：由Custom Domain Manager生成的一串哈希值
   • TTL：同样建议600秒

血泪教训：某次生产部署时，团队只配了CNAME导致域名状态始终显示"Pending"。后来发现Cloud Foundry会主动向_cf-custom-hostname子域名发起TXT记录验证，这是很多企业防火墙会拦截的请求类型。建议提前在安全组放行*.sap.hana.ondemand.com的DNS查询。

3.2 企业级DNS的特殊处理

在金融行业部署时，经常遇到拆分式DNS架构（内部/外部不同解析）。此时需要特别注意：

1. 如果企业使用Akamai等CDN做DNS代理，需要确保代理层传递原始DNS查询
2. 对于有DNSSEC要求的场景，SAP的验证服务目前不支持ED25519算法签名
3. 跨国企业要注意DNS记录的传播延迟，建议先在测试环境验证各region的解析速度

4. 证书管理进阶技巧

4.1 自动证书续期的陷阱

Custom Domain Manager支持自动从Let's Encrypt获取证书，但在企业环境要注意：

1. 防火墙必须放行ACME协议（TCP 443到acme-v02.api.letsencrypt.org）
2. 证书更新周期是60天，但首次申请可能因DNS传播延迟失败
3. 企业网络如果出站流量需要认证，需要在BTP侧配置Proxy设置：

bash复制# 通过环境变量配置Proxy
cf set-env my-app HTTP_PROXY http://proxy.yourcompany.com:8080
cf set-env my-app HTTPS_PROXY http://proxy.yourcompany.com:8080

4.2 自定义证书的最佳实践

对于需要企业自有CA证书的场景，上传证书时要注意：

1. 证书链必须完整（从叶子证书到根CA）
2. 私钥必须是PKCS#8格式（非PKCS#1）
3. RSA密钥长度至少2048位，ECC只支持prime256v1曲线

转换证书格式的典型OpenSSL命令：

bash复制# 将PKCS#1私钥转为PKCS#8
openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in private.key -out private-pkcs8.key

# 合并证书链
cat leaf.crt intermediate.crt root.crt > fullchain.crt

5. 故障排查手册

5.1 状态监控与日志获取

当域名状态卡在"Pending"时，按以下步骤排查：

1. 检查服务实例状态：

   bash复制cf service my-custom-domain
   

2. 获取最新日志：

   bash复制cf logs my-custom-domain --recent
   

3. 验证DNS解析：

   bash复制dig +short TXT _cf-custom-hostname.api.yourcompany.com
   nslookup api.yourcompany.com
   

5.2 常见错误代码解析

6. 企业级部署建议

对于生产环境，建议采用以下增强配置：

1. 多地域容灾：在不同BTP Region（如ap21, eu20）部署相同的Custom Domain配置
2. 监控集成：通过Service Binding将证书过期事件连接到Alert Notification服务
3. 变更管理：使用Terraform自动化配置，示例代码片段：

hcl复制resource "btp_subaccount_service_instance" "custom_domain" {
  subaccount_id = var.subaccount_id
  name          = "prod-custom-domain"
  serviceplan   = "standard"
  parameters = jsonencode({
    "domains" = ["api.yourcompany.com"]
  })
}

在完成所有配置后，建议用SSL Labs的测试工具全面验证：

bash复制curl -sSL https://api.yourcompany.com | openssl s_client -connect api.yourcompany.com:443 -servername api.yourcompany.com | openssl x509 -noout -dates

这个看似简单的域名配置，实际上涉及网络、安全、DNS、证书等多个领域的知识交叉。我在某次跨国部署中，曾因为忽略时区问题导致DNS记录生效判断失误——TXT记录在美国总部已经生效，但亚洲办公室的递归DNS服务器缓存尚未更新。最终通过强制刷新本地DNS缓存解决：

powershell复制# Windows系统刷新DNS
ipconfig /flushdns
# Linux系统刷新DNS
systemd-resolve --flush-caches

这些实战经验，希望能帮你避开我踩过的那些坑。