一张代码签名证书能签多少款软件
采购单上写着“三款软件”，下一行不必跟着填“三张代码签名证书”。如果这三款都是同一家公司发布的普通Windows软件，文件格式受支持，所购产品也允许这样使用，就可以共用一张证书。公司多做了一款程序，并不会因此自动多出一份证书采购需求。
不过，三款软件能共用，不等于只做一次签名，也不等于云签服务没有次数限制。公司名称、产品数量、每次发布的文件量，影响的是不同的事：名称决定以谁的身份签，文件决定实际签什么，套餐则决定服务能怎样用。把这几笔账分开，才不会一边重复买证书，一边又低估了发版时的工作量。
三个产品名，可以对应同一个签名主体
假设一家公司同时发布文档整理工具、图片处理程序和设备管理客户端。三款软件各有名字，各有图标，也分别面向不同用户。只要都由这家公司以自己的名义发布，适用用途和许可条件也符合要求，就可以分别使用同一份企业签名身份。
代码签名证书关联经过验证的主体。软件叫“图片助手”还是“图片工作台”，并不需要在企业证书里各占一个产品名额。企业给第二款、第三款软件签名时，签名信息里仍然可以是同一家经过核验的公司。
这里也用不上SSL证书里单域名、多域名的买法。把三款软件放在三个下载网站，不会因此把代码签名证书变成“三域名版本”。网站的HTTPS连接与下载文件的数字签名各有用途，下载页面用了什么域名，不直接决定软件需要几张签名证书。
产品改名也要分情况。只是给自家程序换了商品名称，发布企业没变，不必仅因为改名重新办理一张企业代码签名证书。公司登记名称发生变化，则涉及证书里的身份资料，需要按颁发机构的变更要求处理。这两种“改名”对应的工作差别很大。
当然，共用的是签名凭据，几款程序仍要各自完成签署。不能把第一个程序已经签好的那段结果复制给第二个程序。数字签名用于核验相应文件的完整性，新生成的待签文件应当进入自己的签名步骤。
更新了十二版，证书不会因此变成十二张
把软件数量换成版本数量，也容易多算一遍。公司今年准备更新十二个版本，不需要预先买十二张代码签名证书。在证书、私钥及相应服务仍适用的期间，可以继续为该主体发布的受支持文件签名。
但发了十二个版本，究竟产生多少签名操作，还得看每次交付了什么。一次更新可能只有一份安装程序，也可能同时提供两种处理器架构的安装包，再带一个独立下载的修复工具。版本号只增加一次，待签文件却可能有好几份。
用一个简单的工作量例子来算：某产品每月发布一次，每次确定有两份文件需要分别签名。全年按十二次发布安排，就有二十四份文件需要处理。如果同样安排适用于三款产品，便是七十二份。这个数字描述待签工作量，不代表七十二张证书，也不是任何服务商的统一计费标准。
如果每次还要签署自研组件，或者构建过程会自动处理包内文件，就把这些实际操作加进去。反过来，没有重新生成、没有在本次任务中再次签署的旧文件，不应仅因为它跟着新安装包一起分发，就被随手算成一次新的签名调用。
同一版本提供给十位客户，也不必把同一份已签文件再签十遍。直接分发同一成品即可。若为每位客户重新生成了不同的程序，里面写入的内容不同，就要把它们当作各自的待签成品处理。客户数量和签名数量，有时也对不上。
开发环境里反复构建的次数，更不能直接当成正式发布次数。假如流水线每次构建都会调用付费签名服务，测试包、失败后重做的包，也可能消耗服务资源。团队可以把正式签名安排在测试通过、准备交付之后，并根据实际需要保留专门的测试签名流程。
这也说明，软件从一款增到三款时，首先增加的是待处理文件和发布安排。原来的证书可能仍然够用，原来的操作习惯却未必还能跟得上。
云签套餐里另有一本“次数账”
看见“不限制应用数量”，不要顺手把后半句补成“所有签名调用都免费、无限次”。证书可供同一主体的多款软件使用，与云端服务怎样计量，是两项需要分别阅读的条件。
有的云签方案会设置签名额度、有效使用周期或操作人员名额。批量选中一个文件夹，界面上只点了一次按钮，后台仍可能按其中实际签署的文件逐个扣减。一次任务、一个安装包和一次计费签名，也未必采用同一种统计口径。
因此，前面算出的七十二份文件，只能作为这个假设项目的基础工作量。服务还处理了哪些包内文件，重复签署怎样计数，测试调用是否占额度，要与所选方案的规则对应。不能拿“每月一次发版”去直接购买“每月一次调用”的套餐。
公司已经在用云签服务时，可以拿最近一次正式发布的记录对照：提交了几份文件，服务记录实际增加多少次。遇到嵌套安装包或自动签署组件，这样比只数下载目录里的文件更接近真实用量。这里是在安排核算方法，并没有一个适合所有产品的固定换算比例。
本地Ukey方案则有另外的使用安排。几款产品都交给公司指定人员集中签名，可以围绕现有受保护的密钥和工具组织工作。若三个团队要同时在不同环境里操作，就要考虑受支持的调用方式和授权，不能把“一张证书能签三款软件”理解成“密钥可以随便复制三份”。
云签也一样。共用企业身份，不意味着每位开发人员都能共用同一个登录密码。团队应使用方案实际支持的人员授权和操作记录；若套餐只允许指定人员签署，就按这个条件安排。产品数量与账号人数，仍然要分开统计。
换了发布公司，张数就可能重新算
前面能共用，有一个一直没有变的条件：几款软件都由同一个适格主体发布。假如三款产品后来分别交给三家独立公司运营，并且要求在签名中体现各自经过核验的企业身份，就不能继续用母公司的一张证书，期待出现三家公司的名字。
证书中的主体信息不会随软件的品牌标志、收款账户或官网介绍自动切换。关联公司属于同一个集团，也不等于已经在同一份证书里分别完成身份核验。需要分别以各自企业身份签署，就应分别取得相应主体的签名凭据。
外包开发的情况也按发布身份处理。程序员属于哪家公司，不直接决定最后该用谁的证书。客户准备以自己的企业身份对外发布，可以由客户申请并控制签名凭据，把确认过的交付文件纳入客户的签名流程。开发方负责制作程序，与谁获准调用签名密钥，可以分别安排。
这不等于企业证书能够拿来随意替无关公司代签。给文件签上自己的身份，就建立了文件与该身份的对应关系。不能为了分摊年费，把证书借给不清楚软件来源、也无法管住发布内容的其他主体使用。
还有一种主动多办证书的情况：公司主体没有变，但内部要求不同产品使用独立密钥、独立审批。比如一个团队每天自动发版，另一个团队只在固定发布窗口由专人操作，公司可能决定把两套签名凭据分开管理。
这样增加张数，是为了落实权限隔离和发布制度。单靠多买一张证书还不够，两个密钥的访问权限、服务账号和操作流程也要相应分开；如果仍由同一个失控账号随意调用，两份凭据并不会自动形成有效隔离。
这里讨论的是受所选方案支持的普通软件签署。新增项目若变成Windows内核驱动，或要走苹果应用的分发流程，还需按对应平台要求办理。不能因为原来的三个Windows程序共用成功，就推断任何平台、任何发布渠道都能直接接入。
继续沿用现有证书之前，也保留一项时间检查：它是否仍能用于当前的新签名，密钥能否按授权调用，所需服务是否可用。旧产品以前签过名，不代表新的发布任务可以永远使用同一套凭据。
新增第四款软件时，可以先把它加入现有发布计划：发布企业是谁、交付哪些文件、预计增加多少操作。主体相同、用途适配、许可允许，便安排使用现有代码签名证书；身份或权限要求变了，再办理相应凭据。软件清单可以不断变长，证书采购单不必跟着逐项复制。