这是 Itext 中的错误吗？
正如您在 Adobe Acrobat Pro 11.0.09 的预检中所见，CRL 的长度为 67107 个字符，而这个特定的 PDF 标准要求字符串的最大长度不得超过 32767 个字节
考虑到问题字符串被引用为1 0 obj/Contents 似乎表明它实际上是为 CMS 签名容器保留的字符串，而不是普通的 CRL。
查看 PDF/A 规范（我手头只有第 3 部分，但此处第 2 部分和第 3 部分应该一致）有两个部分似乎相互矛盾：
符合标准的文件不得包含任何长度超过 32767 字节的字符串。
（第 6.1.13 节实施限制）
和
时间戳和撤销信息应包含在 [PDF 签名（DER 编码的 PKCS#7 二进制数据对象）中]，以提高签名的长期不可否认性。
（附件 B 对 PDF/A 中数字签名的要求）
在您的情况下，遵循后一个建议会破坏前一个要求，因为 PKCS#7 / CMS 对象作为字符串嵌入到 PDF 中。
但是，由于我们对推荐有要求，因此只要不违反要求，就需要遵循该推荐。规范甚至明确表示：
在生成签名外观和任何其他 PDF 对象作为签名过程的一部分时，
符合标准的读者应确保它不会使对 ISO 19005 的这一部分的符合性无效
（第 6.4.3 节数字签名）
因此，确实，iText 签名应该在签名过程中失败...如果您使用了 PDF/A 感知 API，也就是说。很遗憾您没有提供源代码，因此不清楚您使用的是PdfAStamper 还是仅仅PdfStamper。
或者有没有办法在这种情况下保持 PDF/A-2B 的一致性？
你没有提供你的源代码，所以只能用更一般的方式来回答。
首先检查为签名容器预留的空间是否真的需要，或者是否有很多填充字节。在后一种情况下，微调预订代码。
如果这还不够，将 CRL 嵌入签名容器会自动导致违反 PDF/A 一致性，因此是不允许的。
然后，一种选择是尝试在此处使用 OCSP 响应而不是 CRL。 OCSP 响应通常只包含一个或最多很少几个证书的信息，而 CRL 可能会变得非常大。
如果 CA 没有 OCSP 服务器，我看不到真正的 PDF/A-2'ish 解决方案。您可能希望尝试将验证相关信息嵌入 PAdES 第 4 部分 (ETSI TS 102 778-4) DSS（文档安全存储）结构而不是签名容器中。普通的 PDF/A 查看器很可能无法识别，更不用说使用那里的 CRL，但更多功能的查看器，例如当前的 Adobe Reader 版本，应该。