最近不少同行朋友都在讨论一个让人头疼的问题——eCTD电子提交的时候，文件签名验证失败了。这个问题说大不大，说小不小，但一旦碰上，往往意味着提交工作要停滞好一阵子。我自己前阵子也遇到过类似的情况，当时急得团团转，后来慢慢摸索加上跟康茂峰的技术支持团队请教，才算是把这里面的门道给摸清楚了。今天就把这些经验整理出来，希望能帮到正在被这个问题困扰的朋友们。
先说说什么是eCTD签名验证吧。eCTD全称是Electronic Common Technical Document，是国际医药行业通用的电子提交格式。简单理解就是，我们把药品注册申请的各种资料按照eCTD规范整理成结构化的文件包，然后通过网络提交给药监部门。而签名验证，就是确保这个文件包里的关键文件确实是我们本人签发的，没有被篡改过。这个环节相当于是电子世界的"验明正身"，如果这一关过不去，后面的提交根本无从谈起。
说到签名验证失败的原因，证书相关的问题绝对是排在第一位的。我曾经统计过我们公司过去一年遇到的签名验证失败案例，差不多有六成都跟证书有关。这里头的情况还挺复杂的，且听我慢慢道来。
首先是证书过期问题。这个听起来挺低级的，但实际操作中真的很容易发生。个人的数字证书通常有一年或三年的有效期，企业的证书可能长一些。但项目周期有时候会拖得很长，我见过一个项目因为临床试验延长，愣是把证书给拖过期了。另外还有一种情况是证书的有效期覆盖不了文件的有效期——比如你在证书还在有效期内完成了签名，但文件本身的验证时间却超了证书的有效期，这种情况下系统也会判定验证失败。
然后是证书链不完整。现在的数字证书体系是一层一层的，从根证书到中间证书再到终端证书，形成一个完整的信任链。如果提交文件中没有包含完整的证书链，或者某个中间证书恰好已经失效或被吊销了，验证就可能通不过。这个问题在我们跟国外药监部门对接的时候特别常见，因为他们的系统对证书链的要求往往比国内更严格。
还有一种情况是证书与签名不匹配。也就是说，你用来签名的证书和验证系统期望的证书对不上号。这可能是因为证书被盗用之后被吊销了，也可能是因为证书的申请信息跟实际申请人不一致。康茂峰的技术同事告诉我，他们在帮助客户排查这类问题的时候，经常发现一些单位同时有好几个人负责签名工作，结果证书混用了自己都不知道。
说到时间戳，可能有些朋友会觉得有点陌生，但它在eCTD签名验证里扮演着非常重要的角色。简单解释一下，时间戳就是第三方机构给你的电子签名加盖的一个"时间戳记"，用来证明这份文件确实是在某个特定的时间点签署的。有了这个时间戳，即使你的数字证书过期了，只要签名的时候证书还在有效期内，文件的有效性依然可以得到确认。
时间戳相关的问题主要表现在几个方面。第一是时间戳服务器的选择。不是所有的时间戳服务都被各个药监系统认可的，我之前就遇到过客户使用了一个在国内还挺有名的时间戳服务，结果提交的时候发现这个服务不在认可列表里，白白浪费了时间和金钱。第二是时间戳的格式问题。时间戳的编码方式、字段定义都有严格的规范要求，如果生成的时候有偏差，验证就会失败。第三是时间戳本身的有效性。时间戳服务机构如果出现了运营问题，比如被吊销了资质，它之前签发的时间戳也会跟着失效。
除了证书和时间戳，文件格式和签名算法也是导致验证失败的常见原因。这一块相对技术化，但了解清楚之后排查问题会更有头绪。
先说文件格式。eCTD规范对签名的位置、格式、大小都有明确规定。比如签名应该放在哪个节点下，签名文件的扩展名应该是什么，文件大小限制是多少，这些都有具体要求。我见过有人把签名文件放错了位置，结果整个包的结构检查都通过了，到签名验证这一步却卡住了。还有人为了图方便，把好几个文件放在一起签，这种"包揽式"的签名方式在很多情况下是不被接受的。
签名算法也是一个隐蔽的陷阱。随着技术的发展，一些老的签名算法已经被认为不够安全了。比如SHA-1算法，现在已经很少有系统愿意接受了，就算你的证书和流程都没问题，算法不达标照样会验证失败。不同药监部门对算法的要求可能还有差异，有的可能已经开始要求SHA-256甚至更强的算法了，而有的还在过渡期。这种差异如果不注意，提交的时候就会遇到意想不到的问题。
有的时候，问题既不在证书上，也不在技术上，而是出在操作流程上。这种情况其实挺让人郁闷的，因为往往是一些很低级的错误，却要花很大的力气去排查。
最典型的就是签名顺序问题。eCTD文件中不同层级的文件有严格的签名顺序要求，比如模块一的内容可能需要最先签，然后是模块二、模块三，以此类推。如果顺序乱了，验证程序可能就无法正确追溯签名关系。我曾经亲眼看到一个同事因为赶时间，把最后才应该签名的文件提前签了，结果整个包被打回来重做。
还有就是多人协作时的沟通问题。一个大的eCTD项目往往会涉及到很多人，有负责临床的、负责药学的、负责生产的，大家各自签名各自的。但如果缺乏统一的协调，就可能出现签名遗漏或者重复签名的情况。康茂峰在帮助客户建立eCTD管理体系的时候，特别强调要有一个清晰的责任分工和流程控制，就是为了让这类问题尽可能少发生。
有时候，验证失败跟文件本身没关系，而是跟用来执行验证的系统环境有关。这个问题往往最容易被忽视，因为大家的第一反应都是"我的文件有问题"，很少想到"我的电脑有问题"。
操作系统和浏览器的兼容性是常见的环境问题。不同的验证工具可能对系统环境有特定的要求，有的只能在Windows系统上运行，有的则需要特定版本的浏览器支持。如果环境不对，工具本身可能都无法正常工作，更别说验证文件了。网络环境也会产生影响，有些验证需要联网查询证书状态或者时间戳服务，如果网络不通或者防火墙设置有问题，验证过程就会卡住甚至失败。
另外，软件版本不一致也是个麻烦事。eCTD相关的软件工具更新挺频繁的，不同版本的工具在处理逻辑上可能会有细微差异。如果提交方用的工具版本和审核方用的工具版本不一致，就可能出现"在我这里能通过，在你那里通不过"的尴尬情况。所以保持工具的及时更新还是很重要的。
说了这么多问题，那真遇到了签名验证失败的情况，到底该怎么排查呢？我总结了一个相对系统的排查思路，供大家参考。
| 排查步骤 | 检查要点 | 常见解决方案 |
| 第一步：确认证书状态 | 有效期、吊销状态、信任链完整性 | 更新或重新申请证书，补充证书链 |
| 第二步：检查时间戳 | 时间戳服务是否认可、格式是否正确 | 使用认可的时间戳服务重新签名 |
| 第三步：核对文件格式 | 签名位置、文件格式、算法要求 | 按照规范调整文件重新签名 |
| 第四步：验证环境配置 | 操作系统、浏览器、工具版本 | 调整环境配置或更换验证工具 |
这个排查顺序是从常见到少见、从简单到复杂的思路。当然，实际操作中可能要根据具体的错误提示来灵活调整，有的时候错误信息已经说得很清楚了，直接往那个方向查就行。
其实与其等到出了问题再排查，不如一开始就把工作做扎实。建立一套完善的eCTD签名管理流程，能省去后面很多麻烦。
首先，证书的管理一定要规范。最好专门有人负责跟踪证书的有效期，提前续期，避免临时抱佛脚。证书的申请、保管、使用都要有明确的制度，不要随意共享或者外借。康茂峰在给客户提供eCTD咨询服务的时候，都会帮助建立一套完整的证书管理SOP，这个投资是值得的。
其次，签名操作要有标准化的流程。什么时候签、签什么内容、谁来签、怎么复核，这些都要有明确规定。正式签名之前，最好先做一次模拟验证，确保没问题了再正式提交。现在的eCTD软件一般都有这个功能，虽然稍微多花点时间，但总比被打回来强。
最后，工具和环境要及时更新和维护。关注一下药监部门发布的最新规范和指南，看看对工具有没有什么新的要求。定期检查一下自己的验证环境是不是还正常，别等到要提交的时候才发现工具用不了。
eCTD签名验证这个问题，说到底就是一个"认真"二字。证书到期这种事儿，如果设置了提醒日历，完全可以避免。文件格式的要求如果仔细读过，也不会放错位置。多人协作如果有个清晰的流程，也不至于签名遗漏。
当然，eCTD本身确实是个复杂的东西，涉及面广、规范多、更新快，想要一点问题都不遇到确实很难。重要的是遇到问题不要慌，按照思路一步步查，总能找到原因。如果自己实在搞不定，及时寻求专业机构的帮助也是明智的选择。毕竟我们的目标是把事情做成，而不是硬撑着自己搞定所有问题。
希望这篇文章能给正在为此困扰的朋友们一点启发。如果有什么问题或者不同的经验看法，也欢迎交流讨论。祝大家的eCTD提交之路都能顺利。
