摘要：通过 Atlas 集中申请 SSL/TLS 证书前，企业需要先确认服务已开通、身份配置适用、域名控制权可验证，并为所选接入方式准备凭据。OV、EV 的组织身份审核不能由域名验证替代，DV 的身份配置也不等于域名已经验证。提前对应法定主体、业务域名与验证负责人，可以减少资料错配造成的返工。
准备一批证书申请，最先交给技术人员的通常是域名清单。但只有域名，还不能确定这批请求是否具备签发条件。
在 Atlas 中，申请使用的服务、身份配置与域名验证需要匹配。本文以企业网站和业务系统使用的公开信任 SSL/TLS 证书为范围，说明批量申请前的准备工作；其他证书产品的身份字段和审核要求应按对应服务另行确认。
企业可以先整理一份内部申请底表：每个域名对应哪个法定主体、使用哪类证书、由谁配合验证，以及最终交付到哪里。随后再向相关人员收集材料、完成平台审核和接入配置。这样，采购、法务和运维处理的是同一批明确的申请对象，而不是分别维护几份对不上的名单。
先确认申请主体和已开通服务
GlobalSign Atlas 使用 Identity Profile，即身份配置，承载与产品相关的身份信息。正式申请前，应确认相应报价已经接受、服务可用，再核对这批证书需要使用的身份配置。
不同验证等级不能套用同一套准备方式。Atlas 的 DV 产品在接受报价后会自动创建并审核相应的 DV 身份配置，不需要企业像 OV、EV 那样另行提交组织身份申请。但这个过程不代表业务域名的控制权已经验证完成。
OV、EV 则需要申请相应身份配置并完成审核。集团统一付款、统一操作账户，并不意味着子公司的组织身份可以直接填写成母公司名称。提交前先确定证书中应体现的法定主体，避免把品牌简称、事业部名称或内部项目名误当成组织名称。
如果同一批业务涉及多个法人主体，应先列清各自的服务与身份配置对应关系，再安排申请。不要为了少建几个配置，把不同主体的信息拼在一起。
组织资料应当由熟悉法定信息的人复核
准备 OV、EV 身份资料时，可以先由企业行政、法务或指定联系人核对登记信息，技术人员再按 Atlas 对应产品的字段提交。建议内部备查内容包括法定名称、注册地及地址信息、适用的登记编号、可配合审核的联系人和联系方式。
营业执照等登记材料可以提前备好，但不应将内部准备清单误解为每次申请都必须上传的固定附件。具体需要补充哪些证明、如何配合核验，应以所选产品和验证团队的要求为准；也不必把无关的个人敏感资料一并收集。
有两处值得在提交前多核对一次。其一，英文名称或地址如需填写，应采用可核验的信息，避免不同部门各自翻译；其二，联系人需要知道这批申请对应什么业务，能够及时回应核验，而不只是留下一个无人维护的邮箱。
Atlas 的身份配置提交后会进入审核流程。“已提交”与“审核可用”是不同状态。批量任务应等待所用身份达到可用状态；如法定名称或地址需要调整，也应先确认身份配置的处理方式，不要仅修改本地表格后继续沿用原配置。
域名验证要准备的是实际操作能力
组织资料说明申请者是谁，域名验证确认申请者能否控制对应名称。两项检查不能相互替代。企业已经拥有域名注册记录，或能够打开网站后台，也不等于能够完成本次选定的验证。
Atlas 的域名管理流程需要选择相应 Identity Profile，再添加域名并完成验证。门户文档列出了 DNS TXT、HTTP 和邮件等验证方式；实际应使用当前产品与申请流程提供的方法，不能把某条门户指引原样套到所有 API 或 ACME 请求上。
| 拟采用的验证方式 | 申请前应确认的操作权限
|
| DNS 验证 | 谁能在实际生效的权威 DNS 区域发布指定记录，能否按时完成变更 |
| HTTP 文件验证 | 谁能按要求放置验证文件，指定路径是否能从公网访问
|
| 邮件验证 | 所选流程允许的验证邮箱是否可用，是否有人能接收并处理确认邮件 |
不要只在清单里写“DNS 归运维”。域名可能由集团管理，解析托管在云平台，具体子域又委派给另一支团队。负责注册的人未必有权限修改验证所需的记录。把操作人、账号归属和变更审批时间提前确认，才能判断验证能否赶上上线排期。
域名清单应填写准确的完全限定域名，例如api.example.com，而不是一个带路径的网页地址。对通配符、父域及子域的验证覆盖范围，应核对实际服务规则和当前验证状态；不能因为一个名称曾经签发成功，就假定整个批次所有名称都已满足条件。
把接入凭据与申请资料分开管理
通过门户操作、直接调用Atlas API，以及使用 ACME 客户端，准备的接入项并不完全相同。应先确定采用哪条路径，再交付对应凭据，而不是把账户密码发给所有参与人员。
直接接入相应 Atlas API 时，需要按官方流程准备 API Key、Secret，以及该接口要求的 mTLS 客户端证书。生成 API 凭据时要关联适用的有效服务和身份配置。mTLS 客户端证书用于调用方身份认证，不是要部署到业务网站上的那张 SSL 证书。
如果采用GlobalSign ACME 服务，则应按 ACME 接入指引准备账户绑定所需的信息，例如 Key ID、MAC Key 和服务目录地址。不要默认把直接 API 的 mTLS 配置搬到 ACME 客户端中。两种接入方式都需要妥善保管秘密信息，但认证过程不同。
凭据可以由指定人员通过受控的凭据管理机制交付，内部申请表只记录负责人、用途及受控存放位置，不记录Secret、MAC Key 或私钥原文。测试接入与正式业务也应分别核对服务、身份和凭据，避免测试成功后未经检查就批量提交生产请求。
CSR 准备完成后先验证一条完整申请
身份与域名条件确认后，再核对每个证书请求的CSR，即证书签名请求，以及它对应的业务系统和私钥保管位置。CSR 的算法等参数应与所选产品匹配，申请中的域名应与实际需要保护的名称一致。
私钥不属于交给 CA 审核的组织证明材料。企业应在受控环境中生成和保管密钥，提交所需的 CSR，而不是为了方便批量处理，把所有私钥压缩后随资料一起发送。不同系统是否共用密钥，也应由企业安全策略决定，不能由一张采购清单顺带决定。
建议先挑选一个有代表性的域名，完整走通身份选择、域名验证、申请、证书获取和测试部署。如果其余域名由不同团队管理、属于其他主体或采用其他验证方式，还要分别验证这些差异，不能用一个成功结果代替整批检查。
真正可以复用的准备成果，是已经核对的资料及其对应关系。为每项申请保留服务、IdentityProfile、域名验证状态和负责人的记录，新增业务时就能知道哪些条件可以继续使用、哪些需要补做。已验证的信息也不能永久免检，后续申请仍需满足当时有效的验证要求。
Q1：申请 DV 证书也要上传一套企业组织证明吗？ A：不能把 OV、EV 的组织资料要求直接套到 DV。Atlas 的 DV 身份配置由对应产品流程自动创建，但业务域名仍需满足域名控制权验证条件，不能因为配置已生成就跳过验证。 Q2：集团有一份营业执照，能用于旗下所有子公司的申请吗？ A：先确定各项申请实际需要体现的法定主体。集团集中采购不等于各子公司身份相同；若使用不同主体，应核对各自适用的身份配置及审核资料，而不是只看付款方是谁。 Q3：组织审核通过了，为什么仍然不能申请某些域名的证书？ A：检查该名称是否已在适用的身份与服务下完成有效的域名验证，再查看申请参数及产品限制。不要重复上传组织资料来代替域名验证，也不要把能够登录 DNS 控制台当成验证已经完成。 Q4：交给开发人员的资料包里需要包含网站私钥吗？ A：不应把网站私钥放进普通申请资料包。让负责系统在受控环境保管私钥，并提供所需 CSR；开发接入使用的 API 秘密信息也应通过受控方式交付，与组织证照、域名清单分开管理。
FAQ
关于 GlobalSign Atlas
GlobalSign Atlas 数字身份平台提供证书服务与 REST API 集成能力，企业可在平台中管理身份配置、域名验证及证书申请。对于需要持续批量申请 SSL/TLS 证书的团队，Atlas 的使用应从准确关联服务、身份与域名开始，再接入企业自己的申请和交付流程。平台能够支持集中处理，但不会免除所选证书产品应完成的身份与域名验证。
资料来源
GlobalSign：Atlas 数字身份平台、https://www.globalsign.cn/atlas