最近不少同行在聊eCTD提交時遇到簽名驗證失敗的問題，那個紅叉叉確實讓人心里一緊。畢竟文件被打回來的滋味不好受，重新整理又要耗費不少時間。其實簽名無效的原因來來去去就那么幾種，今天咱們就把這些問題一條條掰開揉碎了講清楚，看完你基本就能自己判斷問題出在哪兒了。
在說原因之前，我覺得有必要先說說eCTD電子簽名的工作原理。你可能覺得這是技術人員才需要懂的東西，但了解基本邏輯后，你會發現排查問題其實沒那么玄乎。
eCTD里的電子簽名本質上用的是數字證書技術，你可以把它理解成一份電子身份證。這份證書由專門的機構頒發，里面包含了兩把"鑰匙"——一把公開的，一把保密的。簽名的時候，系統會用私鑰對文件內容進行加密處理，生成一串特殊的字符，這就是你的電子簽名。驗證的時候，其他人可以用對應的公鑰來確認這份文件確實是你簽的，而且內容沒有被修改過。
這個過程看起來挺酷的，但問題就出在其中的任何一個環節都可能出錯。證書過期了、證書被吊銷了、文件傳輸出問題了、甚至你電腦系統時間不對，都可能導致驗證失敗。下面我把這些情況一個個展開說。
這點我覺得不用多說啥，身份證過期了就不能用了，數字證書也一樣。很多朋友在整理老項目的時候容易忽略這一點——當初用來簽名的證書可能還有效，但等到提交的時候已經過期了。
這里有個小細節需要注意，證書的有效期通常是一年到三年不等，而eCTD項目的周期有時候會拉得很長。如果你手上有個兩年前簽名的文件，現在要提交，最好先檢查一下證書狀態。別等到系統提示才發現問題，那時候往往時間已經比較緊了。
這種情況相對少見，但確實會發生。證書頒發機構在某些情況下會吊銷已經頒發的證書，比如發現私鑰泄露、申請人信息變更、或者申請人主動申請撤銷等。
棘手的地方在于，證書吊銷往往沒有提前通知。你可能完全不知道自己的證書已經被吊銷了，直到提交時系統提示驗證失敗。所以定期檢查證書狀態是個好習慣，尤其是那些不怎么用的老證書。
這個問題在跨國藥企或者使用國外證書的時候比較常見。不同國家和地區對證書頒發機構有不同的信任名單，如果你的證書是由一個不在目標藥監機構信任列表里的機構頒發的，那系統就會認為這個證書不可靠，從而判定簽名無效。
舉個例子來說，歐盟有專門的eIDAS法規對電子簽名和信任服務有要求，而美國的FDA也有自己的相關規范。如果你的證書不符合當地的要求，即使技術上簽名是有效的，提交系統也會拒絕。
這個問題聽起來有點低級，但實際工作中真的能遇到。有的時候文件經歷過多次流轉，或者換過電腦操作，一不小心就把證書和密鑰搞混了。用A證書的私鑰簽名，卻用B證書的公鑰去驗證，那肯定是對不上的。
還有一些情況是密鑰丟失了。私鑰文件一旦丟失，就無法再生成有效的簽名，只能重新申請證書。這個問題其實是可以避免的——做好密鑰文件的備份和保管，別把雞蛋放在一個籃子里。
這是另一個非常常見的原因。你辛辛苦苦簽好名，然后把文件拷貝到U盤、發給同事、或者上傳到某個中間服務器。這一系列過程中，只要文件內容發生過任何細微的修改，簽名驗證就會失敗。
你可能會想，我沒動過文件啊？但有些操作是悄無聲息的。比如某些壓縮軟件在解壓時會自動轉換文件編碼，網盤在上傳下載時可能調整文件格式，甚至簡單的復制粘貼在特定情況下也可能引入問題。所以如果確定證書沒問題，那就要往文件完整性這個方向去查。
檢測文件完整性有一個辦法，就是對比文件的哈希值。簽名的時候系統會生成一個哈希值，驗證的時候再重新計算一次，兩個值必須完全一致才行。如果你有原始文件和新文件的哈希值，一對比就能發現問題。
eCTD對文件格式有嚴格要求，不是隨便什么PDF都能直接用的。有些文件雖然看起來沒問題，但內部的格式細節可能不符合規范。比如PDF的版本太低或太高、文件中包含某些不被允許的特殊字符、或者文件的元數據信息異常。
我見過一個案例，某個文件因為字體嵌入問題導致驗證失敗。看起來挺邪乎的，但歸根結底還是文件在簽名后發生了變化，只不過這個變化是字體渲染層面的，一般看不出來。
這個聽起來有點離譜，但確實有人把空文件或者損壞的文件拿去做簽名。簽名一個零字節的文件，生成的信息當然是不完整的。還有些文件可能已經損壞，系統無法正常讀取內容，簽名驗證自然也無法進行。
在eCTD簽名里，時間戳是個很重要的概念。簡單說，時間戳就是第三方機構給你的簽名加蓋的一個"時間證明"，證明這個簽名是在某個特定時間點完成的。
有了時間戳，即使你的證書后來過期了，只要簽名時證書有效，時間戳在有效期內，簽名仍然是有效的。但反過來，如果時間戳本身過期了或者不被認可，那簽名也會被判無效。
這里的問題通常出在時間戳服務器上。有些機構的時間戳服務不是持續穩定的，如果你在簽名時用的時間戳服務器臨時宕機或者證書過期，就會影響簽名的有效性。另外，不同地區對時間戳機構的要求也不同，最好使用目標藥監機構認可的時間戳服務。
沒想到吧，你電腦的系統時間也會影響簽名驗證。如果你的電腦時間設置不正確，比如日期設置到了過去或者未來，簽名驗證的時候就會出問題。因為證書的有效期判斷、時間戳的驗證，都依賴于準確的系統時間。
這個問題在時區設置不正確的電腦上特別容易發生。有次我看到同事的電腦顯示時間和實際差了十幾個小時，一問才知道是跨時區后沒調整設置。所以提交前花幾秒鐘檢查一下系統時間，是個小習慣，但能避免不少麻煩。
eCTD的簽名驗證需要特定的環境支持。如果你的操作系統缺少必要的組件，或者安裝的驗證軟件版本不對，都可能導致驗證失敗。
不同藥監機構使用的驗證系統可能有差異，有時候在你的電腦上驗證通過了，換個環境就不行。這種情況最好是用目標機構提供的驗證工具再做一次確認，別完全依賴自己的電腦判斷。
有些公司在不同部門使用不同的操作系統，Windows和Mac之間流轉文件時就可能出現兼容性問題。簽名算法、文件格式在不同平臺上的表現可能略有差異，雖然這種情況越來越少，但偶爾還是會遇到。
這點可能比較容易被忽略。不同國家和地區的eCTD提交系統對簽名的要求是有差異的，同樣一份文件，在A國可能順利通過，在B國就會被拒。
拿歐盟和美國來說，FDA對電子簽名有21 CFR Part 11的要求，而EMA則遵循歐盟的相關法規。證書的格式、加密算法、時間戳標準，都可能有細微的差別。如果你是一家global藥企，需要向多個地區提交eCTD，建議提前了解各地區的具體要求，準備相應規范的證書和簽名。
說了這么多問題，最后給幾點實操建議吧。這些都是平時工作中總結出來的經驗，未必全面，但應該能幫到你。
eCTD簽名驗證失敗確實讓人頭疼，但這些問題都是有解的。關鍵是要系統性地去排查，從證書狀態、文件完整性、時間戳、技術環境這幾個維度一一排除，總能找到原因。
如果你在這個過程中需要專業支持，可以找康茂峰這樣的服務機構幫忙。他們對各國eCTD法規要求比較熟悉，處理這類問題經驗豐富，有時候能幫你節省不少時間。
技術問題從來都是這樣，看起來復雜，拆解開來一點點解決，其實也沒那么可怕。祝你提交順利，一次通過。
