Baltimore CyberTrust 根证书 2025 年到期，对SAP CPI 集成有何影响

SAP Integration Suite / Cloud Integration (CPI) 服务的用户，近期会收到通知。内容是关于 Baltimore CyberTrust Root 这个根证书。它由 DigiCert 提供，将在 2025 年 5 月 12 日 正式过期。Baltimore CyberTrust Root 证书并非 SAP 或 CPI 自身拥有和颁发的证书。理论上，它可能出现在任何 SAP 或非 SAP 产品中。本文的讨论范围严格限定在与 CPI 服务相关的场景。

DigiCert 已经明确，Baltimore CyberTrust Root 证书到期后，不会再有任何延期或更新。这个根证书一旦过期并失效，SAP 会将其从 SAP 全局信任列表 (SAP Global Trust List) 以及 CPI 密钥库中移除。这对 CPI 服务本身意味着什么？

• SAP Integration Suite / Cloud Integration 服务本身与这个根 CA 证书没有直接的依赖关系。从 SAP 标准服务角度看，SAP 方面无需进行更改，预计不会对服务本身产生直接影响。
• 客户的特定集成场景可能会受到影响。如果你的某些集成场景依赖于这个即将过期的根 CA 证书，不采取措施就可能中断。
• 集成管理员需要评估这个根 CA 证书过期带来的具体影响，并做出相应处理。

核心风险在于：任何由 Baltimore CyberTrust Root 根证书签名的客户端证书 (Client Certificate / Key Pair)，在该根证书到期后将失效。这会影响到那些使用这类客户端证书进行认证的 CPI 入向或出向通信。其他涉及私钥操作的步骤，如签名、验签、加密、解密，若使用了基于此根证书的密钥对，同样会受影响。

所谓入向通信，指外部系统（发送方）调用 CPI 上的集成流 (iFlow) 端点。

• 什么情况下会受影响？ 只有当外部系统使用客户端证书认证方式调用 iFlow，并且这个客户端证书是由 “Baltimore CyberTrust Root CA” 签名颁发的，才会产生影响。
• 检查要点： 你需要确认你的 iFlow 入向调用是否配置了客户端证书认证。如果是，确认是哪个 CA 签发的客户端证书。租户的系统管理员或集成开发人员通常了解这些配置细节。
• 无需操作的情况：
  • 你的 iFlow 入向调用未使用客户端证书认证。
  • 使用了客户端证书认证，但发送方系统的客户端证书并非由 ‘Baltimore CyberTrust Root CA’ 签名。
• 需要采取行动： 如果入向调用确实使用了客户端证书认证，并且该证书由 ‘Baltimore CyberTrust Root CA’ 签名，你必须采取行动。
• 行动方案：
  1. 发送方系统管理员需要生成新的客户端证书。这个新证书必须由 SAP 全局信任列表（见 SAP Note 2801396）中列出的其他受支持的 CA 签名。
     • 重要提示： 生成证书签名请求 (CSR) 时，不要选择以下即将被移除或已不推荐的 CA：
       • Baltimore CyberTrust Root (本文讨论对象)
       • Starfield Class 2 Certificate Authority (参考 KBA 3587385)
       • Certinomis CA
       • GlobalSign Root CA
       • Go Daddy Class 2 Certification Authority
  2. 更新 Cloud Integration 端的配置，以识别新的客户端证书。
     • Cloud Foundry (CF) 环境租户：更新服务密钥 (Service Key) 中维护的客户端证书。 (参考 SAP Help – Client Certificate Authentication for Integration Flow Processing 及 KBA 3297437)
     • Neo 环境租户：可能需要在“证书到用户映射”或直接在发送方适配器配置中更新证书，具体看你的配置方式。 (参考 SAP Help – Setting Up Secure HTTP Inbound Connection with Client Certificates)

出向通信指 CPI 调用接收方系统。

• 常规情况： CPI 调用外部系统若需客户端证书认证，通常会选用标准的 sap_cloudintegrationcertificate 这个私钥。
• 什么情况下会受影响？ 少数客户可能会选择使用自定义的客户端证书进行出向认证。如果这个自定义证书恰好是由 Baltimore CyberTrust Root 签署的，那它也必须在 2025 年 5 月 12 日前被替换。
• 检查要点： 确认你的出向适配器（如 HTTP Receiver Adapter）到接收方系统的调用是否使用了客户端证书认证。如果是，检查适配器中配置的是哪个客户端证书，以及它是由哪个 CA 签发的。
• 无需操作的情况：
  • 出向调用未使用客户端证书认证。
  • 使用了客户端证书认证，但配置的证书并非由 Baltimore CyberTrust Root 签名（如使用的是 sap_cloudintegrationcertificate）。
• 需要采取行动： 如果你确实在出向场景中使用了由 Baltimore CyberTrust Root 签名的自定义客户端证书。
• 行动方案： 在适配器配置中，将此客户端证书替换为由其他 CA 签名的证书（比如使用 sap_cloudintegrationcertificate，或重新申请一个由其他受信任 CA 签名的自定义证书）。确保新的客户端证书（若是自定义的）已上传到接收方系统的信任库 (Trust Store)。 (参考 SAP Help – Setting Up Secure Outbound HTTP Connections Using the Keystore Monitor)

还有一种次要情况：CPI 需要调用的目标服务器，其本身的服务器证书是由 Baltimore CyberTrust Root CA 签署的。在该根证书过期后，CPI 对这类服务器的 API 请求会因 SSL 错误而失败。这首先是目标服务器管理员的责任，他们需要确保其服务器始终使用有效的证书链，并通知其用户（包括你的 CPI 系统）。一旦他们更新了服务器证书（使用了新的根 CA），你的 CPI 集成管理员可能需要将目标服务器新的根 CA 导入到 CPI 租户的密钥库中。

• 不行动的后果？ 依赖相关证书的集成场景可能会中断。Baltimore 证书即将到期，DigiCert 也不再推荐使用。
• SAP 能帮忙检查我的配置吗？ 这通常属于收费的专业服务范围，不能通过标准支持渠道解决。你需要联系你的 SAP CEE/CSP 或客户主管。
• 这个证书在我的 S/4HANA, SuccessFactors, Ariba 等系统里也存在，怎么办？ 本文仅讨论 Cloud Integration (CPI) 的范围。其他 SAP 产品或组件若受此影响，需要对应系统的管理员根据 SAP 官方针对该产品的指导进行处理。
• 为什么 Baltimore 根证书显示“由 SAP 创建”且无法移除？SAP 不拥有它吗？ Baltimore 根证书确实是 DigiCert 的产品。SAP BTP 平台信任一个包含许多流行根 CA 的列表，Baltimore 曾是其中之一。SAP 在之前已将其导入到 CPI 密钥库的默认信任列表中，这个导入动作在 CPI 密钥库中被标记为“由 SAP 创建”。客户不需要对此即将到期的根证书本身执行任何操作。 你的行动焦点应该是检查并更新那些由这个根证书签名的、且正在你的集成场景中实际使用的客户端证书或服务器证书。
• 我在 STRUST/PSE (On-Premise 系统) 中也看到了相同的证书？ 这超出了 CPI 的范围。CPI 从未要求客户在 STRUST 中导入 Baltimore 证书。本地系统的管理员需要评估其影响。
• 我们什么时候需要采取行动？ 尽快完成，务必在 2025 年 5 月之前。
• 我应该为新的 CSR 请求哪个根 CA？ SAP 对此没有特定偏好。选择 SAP Note 2801396 – SAP Global Trust List 中列出的任何受支持的根 CA 均可（但要排除该 Note 中明确列出的不应再使用的 CA，比如 Baltimore, Starfield 等）。
• 如何获取 CPI 相关的变更通知？ SAP 会不定期发送关于 CPI 服务更新的邮件。确保你的 S-User 订阅了相关的云通知。(参考 KBA 2900069, KBA 2765458)
• 谁应该订阅这些通知邮件？ 管理员是必须的。最终用户、开发人员也能从中受益。业务主管了解重大变更，有助于确保充分的规划和测试。

Baltimore CyberTrust Root 根证书的到期是一个需要关注的技术事件。使用 SAP Integration Suite / Cloud Integration 的企业，务必检查自己的集成场景中是否存在依赖此根证书签名的客户端证书或服务器证书。及时采取行动，更新相关证书和配置，是避免业务中断的关键。

企业在向SAP S/4HANA Cloud转型时，SAP 许可 (License) 从 On-Premise 时代的经典指定用户模型转向全新的 FUE 许可模式，且 SAP 产品的许可 (License) 包含诸如“组件授权、用户授权、计量模式”等复杂模型，这对企业来说如同一个黑匣子，难以理解其工作原理。此外，企业还面临 SAP 的 License 审计等合规性问题。郑州微酷在 SAP License 审计流程方面拥有丰富咨询经验，拥有自主研发的高效 SAP License 资产优化软件产品，欢迎企业在需要时随时联系我们，以获得我们的支持服务和软件产品试用体验。