我正在尝试使用rsa_sha1（Adobe.PPKLite＆gt; adbe.x509.rsa_sha1）签署PDF，我有两个问题/问题：
答案 0 :(得分：2)
我正在尝试使用rsa_sha1签名PDF（Adobe.PPKLite＆gt; adbe.x509.rsa_sha1）
您确定要使用此子过滤器吗？有关集成PDF签名的所有进一步开发都使用了集成的CMS容器，而不是裸露的PKCS＃1签名......
不知道ByteRange指定的实际PDF内容是否应该签名，还是该内容的摘要值？
与 adobe.pkcs7.sha1 样式签名相反，就像 adobe.pkcs7.detached 样式签名一样，整个字节范围都是在 adobe中签名的。 x509.rsa_sha1 样式签名，而不仅仅是该内容的摘要值。在这方面， adobe.x509.rsa_sha1 优于 adobe.pkcs7.sha1 ，因为（尽管名称中出现 sha1 ） 不强制您使用SHA1，但您可以使用更好的摘要算法。
（这就是说，签名过程当然包括创建签名数据的摘要值，但这完全是另一回事......）
如果证书放在签名字段之前，或者在？
之后，是否有区别？
证书和签名都是PDF字典对象中的元素，根据定义，这种字典中元素的顺序无关紧要。但是，显然，一旦创建签名，订单必须保持固定（实际上不仅仅是订单，而是确切的位置和内容）。
字典中的条目表示关联表，因此即使在写入文件时可能对它们施加任意顺序，也应该是无序的。该顺序应被忽略。
（ISO 32000-1中的第7.3.7节）
PS：规范说明了签名
应在文件中的字节范围内计算，该字节应由签名字典中的ByteRange条目指示。此范围应该是整个文件，包括签名字典，但不包括签名值本身（内容条目）。可以使用其他范围，但由于它们不检查文档的所有更改，因此不建议使用它们。
（ISO 32000-1中的第12.8.1节）
这似乎允许其他字节范围而不是推荐的字节范围（除了实际的签名字节之外的所有字节）。实际上，你也会找到
对于字节范围签名，Contents应为带有“＆lt;”和“＆gt;”分隔符的十六进制字符串。 它应恰好适合ByteRange 指定范围之间的空格。
（ISO 32000-1中的第12.8.3.3.2节）
如果需要互操作性，则会在实际should之前的引文中生成shall。例如。 Adobe Reader需要这种范围定义。
较新的标准，例如ETSI PAdES技术规范文档，甚至更明确地要求它。