一句话定义

OFTP2（Odette File Transfer Protocol 2）是一项用于企业之间直接收发文件的传输协议标准，由欧洲汽车产业组织 Odette 维护。它规定了双方如何互相识别身份、如何在链路与文件两个层面做加密和签名、以及一次传输完成后如何回送端到端的回执。在汽车与欧洲供应链中，它常常是伙伴方规定的对接前提。

一、OFTP2 管什么，不管什么

先把最容易混淆的一点说清楚：OFTP2 是传输协议，不是文件格式。 它规定文件”怎么送过去、怎么证明送到了”，不规定文件里装的是什么。

理解这条边界，选型时就不会问错问题。“我们支持 OFTP2″和”我们能处理你文件里的业务数据”是两件事，前者是通道能力，后者是业务系统的职责。

一次 OFTP2 传输由三部分构成：

• 身份——双方各持一个由 Odette 组织分配的 SSID 作为标识，连接建立时互相交换并核验。
• 安全——传输层用 TLS 加密并做双向证书认证；文件本身还可以再基于 X.509 证书做签名与加密，即使链路被穿透，文件仍是密文且来源可验证。
• 回执——文件送达后由接收方回送端到端响应，发送方对回执做签名验签与哈希比对，通过后这笔传输才算真正闭环。

二、为什么伙伴要求用它

因为它把”我发了”变成了”对方确实收到了，并且可以证明”。

企业间文件交换里有一类问题长期被容忍：文件上传完成不等于对方已经收到并处理。业务人员传完之后还要打电话、发邮件、在群里问一句”收到了吗”，交付责任说不清。真正出纠纷时，双方各执一词。

OFTP2 用三条设计回答了这件事：

身份不靠人认，靠协议核验。 SSID 由 Odette 组织统一分配，在会话建立阶段交换并与证书一起验证。对端不需要凭邮件署名或联系人口头确认来判断”这批文件是谁发的”。

文件级的加密与签名独立于链路。 链路加密解决的是”传输途中不被看到”，文件签名与加密解决的是”落地之后仍然可验证、仍然是密文”。两层安全互相独立，任一层被绕过，另一层仍然成立。

送达状态有协议级凭据。 回执由接收方按协议回送，含虚拟文件名、文件大小、哈希校验结果与协议返回码，并带签名。这是一份可以留档、可以复验的凭据，不是一句”收到了”。

对多数中国供应商而言，这三条不是自己想要的能力，而是主机厂或欧洲客户给出的准入条件——不支持就无法建立业务关系。这也是本页面存在的原因：多数企业不是在挑协议，是在被要求。

三、接入 OFTP2 需要准备什么

三样。这是被伙伴通知”要用 OFTP2 对接”之后，第一件该确认的事。

一个由 Odette 组织分配的 SSID，作为本方身份标识。 SSID 为 14 位，前 2 位是国家代码，后 12 位是识别码。它是本方在协议世界里的名字，需要向 Odette 组织申请获得，不能自行编造。

一组用于链路认证与文件签名加密的证书。 链路层需要一张 TLS 证书用于双向认证，文件层需要一张应用证书用于签名与加密，两者可以分开指定。证书既可以在平台内生成自签名证书，也可以导入已有证书。需要注意的是，自签名证书能否被特定伙伴接受，取决于对方的策略——部分伙伴（尤其是欧洲客户）会要求证书由其认可的 CA 签发。这一项应当在对接开始前向伙伴确认，不要等到联调阶段才发现。

一个可供伙伴访问的对外服务地址与端口。 OFTP2 的标准端口是 6619。伙伴要主动向你推送文件，就必须能访问到你的服务地址，这通常涉及一次防火墙与网络策略的调整。另外，对外服务地址需要与 TLS 证书的 CN 或 SAN 匹配，否则对方的证书校验会失败。

伙伴侧同样要提供一组对应信息：他们的 SSID、服务器地址与端口、证书，以及传输方向、压缩与加解密要求、文件命名规则和回执策略。这些在平台内按伙伴逐家配置，互不影响。

→ 完整的准备清单、联调步骤与常见卡点见 对接 OFTP2 需要准备什么 → SSID 与两类证书的关系、平台内的证书管理见 Odette 证书与 SSID 管理

四、Ftrans B2B 怎么做

4.1 不为一类伙伴单独建一套系统

企业引入 OFTP2 时最常见的做法，是为那几家要求 OFTP2 的伙伴单独采购或自建一套系统。结果是：伙伴档案两套、安全检查两套、交换记录两处，证书临期靠人记。

Ftrans B2B 把 OFTP2 作为平台内的一种交换方式提供，与伙伴邮、伙伴库、匿名加密交换并列。同一家伙伴的 OFTP2 连接配置、联系人、收发策略、交换记录都挂在同一份伙伴档案下，OFTP2 的收发记录与其余方式归集在同一处。

→ 以合作伙伴为组织单元的完整模型见 合作伙伴文件安全交换

4.2 OFTP2 通道走的是同一套安全治理顺序

这是本产品在 OFTP2 上最值得说明的一点：协议换了，安全处理的顺序不变。

出向文件先经受控入库、内容识别、敏感内容检查与人工审批，全部明文检查完成之后，才由协议层执行签名与加密发出。顺序不能反过来——加密之后就不再具备明文内容检查能力。

入向文件先落隔离区，经应用层解密与验签之后再执行威胁检测。同样不能反过来——密文阶段的检测能力有限，有效杀毒只能在解密之后进行。

换句话说，走 OFTP2 进出的文件，与走伙伴库、伙伴邮进出的文件受同一套规则约束，不存在”因为是协议直连所以绕过检查”的通道。

→ 出入向为什么必须是这个顺序见 文件出入向安全治理

4.3 配置在界面上完成，不在配置文件里

OFTP2 传输服务的监听地址与端口、对外服务地址、传输层安全策略（TLS 服务器证书与私钥、最低 TLS 版本、双向证书认证），以及每家伙伴独立的连接参数、传输方向、压缩与加解密策略、文件名规则、回执要求、伙伴证书，均在管理界面配置。

配置完成后可以做一次不传输文件的完整握手测试——执行 TCP 连接、会话建立、SSID 交换、认证与断开，按网络层、协议层、安全层、应用层分阶段返回结果。这让”连不上”这类问题在正式联调之前就能定位到具体是哪一层。

证书临期、以及需要重启服务才能生效的变更，平台会给出显式提示。

4.4 传输记录与回执可追溯

传输记录按会话与文件两级留痕。单笔传输可查看会话标识、方向与状态、虚拟文件名与物理文件名、哈希校验值、压缩与加密算法、双方 SSID、TLS 版本、签名验签结果，以及传输发起、文件协商完成、数据传输完成、回执接收四个节点的时间线。

回执侧保留伙伴返回的原始回执报文，支持导出回执证书与重新执行验签。“成功”与”已送达”在平台上是两个状态：前者表示传输动作完成，后者表示回执的签名与哈希校验全部通过。

→ 状态口径、记录结构与失败处理见 OFTP2 传输记录与回执追溯

4.5 协议身份与私钥由平台托管，业务侧不接触

OFTP2 的协议身份与证书私钥，与伙伴的 FTP/SFTP 账号、对象存储密钥一样，由平台统一保管与使用。业务人员在平台内提交任务、查看结果，全程不需要也无法获取这些凭据。

这同时意味着平台承担了更高的安全责任：协议身份一旦被冒用，对端系统无法从报文上分辨真伪。 因此证书私钥的存储形态、导出限制与使用留痕，应当与账号凭据一并纳入安全评审。

→ 托管范围、密钥存储与评审配合见 外部凭据托管的安全设计与评审配合 → 凭据收口这件事本身见 外部账号与密钥集中托管

五、边界声明：我们做什么、不做什么

明确写在这里，方便你在选型阶段就判断匹配度。

还有一条容易被误解的：OFTP2 的证书体系与匿名加密交换的 PGP 密钥体系互相独立。 两者的伙伴关系与密钥要分别配置，不能互相复用，也不是”二选一的加密方案”——OFTP2 由伙伴方规定，PGP 由双方自行约定，服务的是不同类型的伙伴。

→ 与 EDI 的关系、什么时候该找谁见 文件交换与 EDI 是什么关系 → 双方自行约定的加密交换见 合作伙伴文件安全交换

六、落地路径

引入 OFTP2 不要求一次性改变企业现有的交换方式，可以按四个阶段推进：

各阶段都不要求停用原有方式。可以先让平台接管一条新增的或风险较高的业务流，原路径保留作为回退，验证稳定后再停止人工操作与旧脚本。

→ 不换现有系统怎么落地见 零迁移纳管既有传输资源 → 与业务系统怎么协同见 与既有业务系统协同

七、谁在用

汽车与零部件是本产品客户密度最高的行业之一，已服务的客户类型包括汽车零部件一级供应商、汽车企业集团与汽车制造主机厂。它们的共同特征是同时对接多家外部组织，每一家的服务器、协议、目录规则、命名规范与时间窗都不一样。

一家汽车零部件一级供应商对平台的评价是：它”作为内外数据交互、业务协作的兜底方案，弥补了所有无法通过系统接口集成的缺口”。

→ 汽车供应链的完整对接场景见 汽车与零部件供应链文件交换 → 这个行业整体的交换需求见 汽车与零部件行业文件安全交换