2026年7月1日
引言
从技术上来说，您可以制作自己的数字签名证书，但自签名证书通常只对测试、内部开发或风险较低的身份验证实验有用。对于合同、受监管的文档、政府申报，或需要外部信任的协议，通常需要由受信任的证书颁发机构（CA）颁发的证书，以及能够保留身份证据、文档完整性、审计记录和签名记录归档的签署流程。
本指南将介绍数字签名证书的作用、何时自建证书是可接受的、如何获取用于业务签署的证书，以及当您的签署流程需要跨 APAC 或其他多区域协议时如何选择平台。
数字签名证书实际证明了什么
数字签名证书将公钥与已识别的个人、组织或系统关联起来。在文档签署流程中，该证书可帮助接收方或审核方回答三个实际问题：
- 谁是签署人或证书持有者？
- 已签署的文档在签署后是否被修改？
- 信任链是否可以追溯到接收方接受的证书颁发机构？
这与基础电子签名不同。电子签名可以是键入的名称、复选框、点击签署动作或上传的签名图片。数字签名则使用加密签署方法和证书数据来帮助证明完整性和身份。
这种区别很重要，因为许多业务团队常常宽泛地使用"数字签名"这一表述。在 PDF 上放置的签名图片不会自动创建受信任的数字证书。在您笔记本电脑上生成的证书不会自动被银行、监管机构、法院、客户或政府门户接受。证书必须在文档将被审核的上下文中被信任。
如果您的团队需要在依赖之前检查现有证书，请使用结构化流程，例如审查证书到期时间、颁发者链、吊销状态和文档完整性。Nota Sign 有关在信任数字证书之前如何检查的指南，为此类尽职调查提供了实用的审查路径。
您可以制作自己的数字签名证书吗
是的，您可以使用加密工具创建自签名证书。开发人员、IT 管理员或具备技术能力的用户可以生成私钥、公钥和证书文件，然后使用该证书签署测试文件或内部文档。
关键的限制在于信任。自签名证书实质上是在说"此证书为自身背书"。它不能证明受信的第三方已验证签署人的身份、企业注册或签署授权。这就是为什么自签名证书通常不足以用于合同、采购文件、受监管的记录或必须由对手方独立信任的文档。
对于业务签署而言，问题不仅在于证书是否存在。实际问题是接收方是否接受该证书、颁发者是否被该司法管辖区或流程认可，以及签署流程是否会创建审核方日后可以使用的记录。
自签名证书何时是可接受的
当信任边界受到控制且风险较低时，自签名证书可以发挥作用。常见示例包括软件测试、沙箱环境、原型签署流程、内部文档实验，或每个用户都已知道并接受证书来源的私有系统。
自签名证书应明确标记。如果内部测试文档使用自建证书签署，接收方不应将其误认为是法律认可的证书或经过身份验证的签署记录。在涉及多个地区的财务、人力资源、法律、采购和合同工作流中，这一点尤其重要，因为审核方可能在数月或数年后依赖该签署记录。
仅当以下所有条件均满足时，才使用自签名证书：
- 文档不会发送给外部对手方以供法律依赖。
- 签署人身份已在组织内部知晓。
- 工作流用于测试、开发或风险较低的内部审查。
- 证书不会作为来自受信任证书颁发机构的证明。
- 组织对何时需要受信任证书有明确的政策。
如果上述任一条件不满足，请转为受信任的 CA 路径或能够帮助保留正确证据记录的签署平台。
如何获取用于业务签署的证书
对于业务签署，更安全的路径是从受信任或被认可的证书颁发机构获取证书。确切的流程因司法管辖区、文档类型和接收方而异，但工作流通常包括五个步骤。
确认签署目的。 首先确定证书是用于合同、政府申报、董事会批准、雇佣文件、受监管的记录、API 签署还是内部审批。依赖程度越高，证书和身份流程就必须越严格。
检查司法管辖区和接收方规则。 适用于一个市场的证书在另一个市场可能不被接受。香港、新加坡、马来西亚、欧盟和美国都有不同的法律框架和信任期望。如果接收方是银行、监管机构、政府门户或企业客户，请在购买或签发任何东西之前确认其接受规则。
选择受信任的证书颁发机构。 CA 负责验证身份并颁发证书。例如，香港的《电子交易条例》框架通过官方的数字政策和认证机构规则进行管理，新加坡则在其电子交易框架下为认证机构提供监管结构。这些不是普通的软件选择，而是信任基础设施决策。
完成身份验证。 对于个人，可能包括政府身份证和地址检查。对于公司，还可能包括企业注册文件、签署人授权和管理员批准。企业签署需要格外小心，因为审核方可能需要证据证明该人有权代表组织签署。
安全地安装和管理证书。 证书可以存储在令牌、安全设备、浏览器存储、软件环境或签署平台中。私钥必须受到保护。如果密钥被共享、随意导出或在政策外使用，则证书可能产生比价值更多的风险。
签署后验证证书。 即使文档已签署，也应对数字签名证书进行检查。证书信任可能失败的原因包括：证书已过期、链不完整、颁发者不被信任、文档被修改或吊销状态无法确认。
实用的签署后检查应涵盖证书主题、颁发者、有效期、证书链、通过 CRL 或 OCSP（如果可用）的吊销状态、时间戳数据、文档完整性警告、可见的审计跟踪，以及已签署文件和相关的证据保留。有关更深入的操作步骤，请参阅 Nota Sign 有关如何为业务验证数字签名的指南。如果您的团队需要了解根 CA 和文档签名证书之间的关系，CA 列表指南也是有用的相关资源。
APAC 团队在依赖证书之前应检查什么
APAC 签署工作流通常涉及多个司法管辖区、区域对手方和混合证据期望。香港实体可能与新加坡对手方签署；中国大陆签署人可能需要访问区域总部使用的工作流；财务或法律团队可能需要在交易结束后证明身份、文档完整性、授权和记录保留。
对于香港，关于《电子交易条例》的官方指南是了解何时承认电子和数字签名的起点。对于新加坡，IMDA 关于《电子交易法》和认证机构法规的材料是 CA 相关要求的有用来源。
在 APAC 依赖证书之前，团队应确认：
- 对于目标用例，CA 是否被认可、许可或以其他方式被接受；
- 证书是否颁发给个人签署人、组织或系统；
- 签署人身份是如何验证的；
- 已签署的 PDF 或记录是否保留证书链和完整性数据；
- 吊销、到期、时间戳和审计跟踪数据日后是否可以审查；
- 中国大陆、香港、新加坡或其他 APAC 市场的签署人是否实际可以访问该平台；
- 最终法律审查是否取决于文档类型、签署人位置、接收方规则和顾问审查。
最常见的错误是将"已生成证书"等同于"文档已具备法律效力"。证书只是一层，围绕它的工作流同样重要。
基于证书的签署平台如何比较
如果您的团队仅需要用于测试系统的证书，则自签名设置可能就足够了。如果您需要用于外部协议的基于证书的文档签署，则应评估整个签署平台，而不仅仅是证书文件。
DocuSign：成熟的 enterprise 签署方案
DocuSign 可能适合拥有成熟全球采购、管理员资源和现有签署治理的组织。买家仍应在采购期间确认证书选项、身份验证范围、审计导出需求、API 访问、区域签署人访问和计划条款。目标不是假设一个大型全球品牌自动解决每个基于证书的签署要求。
Adobe Acrobat Sign：以 PDF 为中心的文档团队
对于已经以 Adobe 和 PDF 审核为中心的团队，Adobe Acrobat Sign 可以是自然的评估路径。对于 APAC 或与中国大陆相关的工作流，买家应在入围之前验证区域访问和用户角色。2025 年伊利诺伊大学 IT 公告报告了 Acrobat Sign 对中国大陆 IP 地址的访问限制，这会影响发送方、签署人、审批人、查看者、管理员和集成。务实的买家应在依赖工作流之前测试真实签署人所在位置的访问。
Dropbox Sign：轻量级审批流程
Dropbox Sign 可用于简单的签署需求、较小的团队和较轻的审批流程。当团队需要更深入的证书审查、区域身份证据、多部门治理或长期签署记录保留时，它可能不太合适。买家应确认工作流是否支持其文档附带的证书、审计和法律审查期望。
Nota Sign 在 APAC 协议控制中的位置
当签署流程涉及 APAC 对手方、跨区域审批、签署人身份证据、审计记录和签署记录保留时，Nota Sign 是更优的评估路径。Nota Sign 不将证书视为独立文件，而是帮助团队管理围绕协议的整个工作流：签署人访问、身份审查、路由、完成证据，以及业务审核方日后可以检查的记录。
对于评估基于证书的签署的团队来说，关键问题不是"哪家供应商可以在 PDF 上放置签名？"，更好的问题是"哪家工作流能为我们实际签署的文档提供足够的身份、完整性、访问和审计证据供我们的审核方使用？"
总结
您可以为测试、开发和严格控制的内部使用制作自己的数字签名证书。除非接收方已明确接受该信任模型，否则不应将自签名证书视为用于外部合同或受监管文档的可信业务签署方法。
对于业务签署，请选择受信任的 CA 路径，确认每个司法管辖区的法律和操作规则，并使用能够保留身份证据、文档完整性、审计记录和签署记录保留的签署流程。如果您的协议涉及 APAC 实体、区域签署人访问或基于证书的审查，请就签署工作流审查联系 Nota Sign 销售，并提供您的签署人区域、文档类型、身份需求、审计要求和迁移约束。
