PKI 实践指南：构建完整的证书服务系统

1. 引言

本文是一份基于 EJBCA 的证书服务实践教程，目标是在 Demo 环境中快速跑通 CA/RA 全流程，包括证书模板创建、终端实体模板配置、审批流程启用，以及 RA 端的终端证书申请与下载。教程聚焦“能跑起来”，适合实验、PoC 或内部演示，不涉及生产环境的安全加固与合规细节。

• 主要收获：掌握 EJBCA 的核心操作路径，完成从模板配置到证书签发的全过程

2. 方案架构与术语

• RA：负责终端实体注册与身份审核。
• 证书模板（Certificate Profile）：预设密钥用法、SAN、有效期等。

3. 实验环境与前置条件

• 操作系统：Ubuntu 20.04 Server（离线安装）
• 前置软件：Docker ，docker-compose (apt 包)

4. EJBCA Docker 部署与持久化

本文将详细介绍如何在 Docker 中部署 EJBCA 证书服务，并确保其数据持久化存储在独立数据盘上，避免因容器或虚拟机重启导致数据丢失。内容包括使用内部数据库（默认 H2）的持久化配置、docker-compose 方式运行容器、开放远程访问所需的配置。

4.1 环境准备与代理配置

由于部分 EJBCA Docker 镜像（如 keyfactor/ejbca-ce ）需要从公网拉取，为确保环境可用，请先配置 Docker Daemon 的 HTTP/HTTPS 代理。

配置 systemd 代理

Docker Daemon 运行在 systemd 管理下，需添加配置以继承系统代理。

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf

内容如下：

[Service]
Environment="HTTP_PROXY=http://192.168.xxx.xxx:7890"
Environment="HTTPS_PROXY=http://192.168.xxx.xxx:7890"
Environment="NO_PROXY=127.0.0.1,localhost,192.168.13.119"//ip需要改成自己虚拟机主机ip

重新加载并重启 Docker

sudo systemctl daemon-reload
sudo systemctl restart docker
sudo systemctl status docker --no-pager -l

若输出中含有 Active: active (running) 即表示代理配置生效。

验证代理是否生效

docker info | grep -i proxy

出现如下输出说明代理生效：

HTTP Proxy: http://192.168.xxx.xxx:7890
HTTPS Proxy: http://192.168.xxx.xxx:7890

4.2 数据持久化配置

• 使用文件方式保存 H2 数据库：将数据库配置为 jdbc:h2:/mnt/persistent/ejbcadb;DB_CLOSE_DELAY=-1
• 宿主机挂载路径：/opt/ejbca-data:/mnt/persistent
• 避免使用 --rm 启动容器
• 设置宿主机权限：chown -R 10001:10001 /opt/ejbca-data

📌 提示：正式环境建议切换到 PostgreSQL / MySQL 等外部数据库，提升可靠性与容灾能力。

4.3 使用 Docker Compose 部署

1. 创建目录结构：

mkdir -p /opt/ejbca-compose
cd /opt/ejbca-compose
mkdir -p /opt/ejbca-data
chown -R 10001:10001 /opt/ejbca-data

1. 当前目录下创建docker-compose.yml，编写 docker-compose.yml：

version: "3.3" # 使用 Docker Compose 文件格式版本 3.3

services:
  ejbca: # 定义名为 ejbca 的服务
    image: keyfactor/ejbca-ce:latest # 使用 Keyfactor 提供的 EJBCA 社区版镜像，使用最新版本
    container_name: ejbca # 容器名称为 ejbca
    hostname: myejbca.test.local # 容器内部主机名，影响证书中的 CN 等字段

    environment: # 设置环境变量配置 EJBCA 的启动行为
      - DATABASE_JDBC_URL=jdbc:h2:/mnt/persistent/ejbcadb;DB_CLOSE_DELAY=-1 # 使用嵌入式 H2 数据库，数据保存在挂载目录下
      - TLS_SETUP_ENABLED=true # 启用自动 TLS 设置（用于 HTTPS 接入）
      - SMTP_DESTINATION=192.168.xx.xx # 设置 SMTP 邮件服务器地址（用于发送通知邮件）
      - SMTP_DESTINATION_PORT=25 # SMTP 服务端口，默认 25（未启用加密）
      - SMTP_FROM=ejbca@example.local # 设置邮件发送的发件人地址
      - SMTP_TLS_ENABLED=false # 不启用 SMTP 的 STARTTLS
      - SMTP_SSL_ENABLED=false # 不启用 SMTP 的 SSL/TLS 加密

    ports: # 映射容器端口到宿主机
      - "80:8080" # 宿主机 80 端口映射到容器的 8080（HTTP）
      - "443:8443" # 宿主机 443 端口映射到容器的 8443（HTTPS）

    volumes: # 数据卷挂载，将容器中的目录映射到宿主机，以持久化数据
      - /opt/ejbca-data:/mnt/persistent # 将宿主机的 /opt/ejbca-data 目录挂载到容器中，持久化数据库等数据

    restart: unless-stopped # 如果容器异常退出则自动重启，除非人为停止

1. 启动容器服务：

docker-compose up -d
docker-compose logs -f

⚙️ 使用 Compose 可轻松管理配置版本，便于团队协作和恢复。

4.4 远程访问配置

1. 提前设置容器 hostname（影响 TLS 证书 CN）：

hostname: myejbca.test.local

4.5 管理证书信任

• 下载超级管理员证书 .p12 后需双击导入证书存储

4.6 登录流程摘要

1. docker-compose logs -f查找容器日志中 SuperAdmin URL 和一次性密码：

ejbca    | 2025-08-05 09:11:31,656+0000 INFO  [/opt/keyfactor/bin/start.sh] (process:1) *                                                                                                    *
ejbca    | 2025-08-05 09:11:31,656+0000 INFO  [/opt/keyfactor/bin/start.sh] (process:1) *   URL:      https://myejbca.test.local:443/ejbca/ra/enrollwithusername.xhtml?username=superadmin *
ejbca    | 2025-08-05 09:11:31,656+0000 INFO  [/opt/keyfactor/bin/start.sh] (process:1) *   Password: urAMy0He5c/hHy+DYyDFNy4E                                                               *
ejbca    | 2025-08-05 09:11:31,656+0000 INFO  [/opt/keyfactor/bin/start.sh] (process:1) *                                                                                                    *
ejbca    | 2025-08-05 09:11:31,656+0000 INFO  [/opt/keyfactor/bin/start.sh] (process:1) * Once the P12 is downloaded, use "urAMy0He5c/hHy+DYyDFNy4E" to import it.                           *
ejbca    | 2025-08-05 09:11:31,656+0000 INFO  [/opt/keyfactor/bin/start.sh] (process:1) *                                                                                                    *
ejbca    | 2025-08-05 09:11:31,656+0000 INFO  [/opt/keyfactor/bin/start.sh] (process:1) ******************************************************************************************************

1. 访问领取 URL 填写密码 → 设置导出密码 → 下载 .p12
2. 导入浏览器后访问：https://myejbca.test.local/ejbca/adminweb
3. 若提示未提供客户端证书，检查是否导入成功、代理关闭、域名正确解析

✅ 至此，EJBCA 部署 + 持久化 + 管理登录流程即告完成。

4.7 重要提示（请务必遵守以下要求）

✅ 必须 先将 myejbca.test.local 添加到 hosts 文件，或搭建本地 DNS 服务器，否则浏览器可能无法解析域名。

✅ 超级管理员证书算法默认是 DILITHIUM2（根据版本默认算法会不一样），但 Windows 大概不能识别，建议改为 RSA 4096，以确保兼容性。

✅ 不能开代理，否则 EJBCA 可能无法正确处理客户端证书认证。

✅ 确保 Windows/macOS/Linux 证书存储正确导入，避免 No client certificate was presented 错误。

✅ 第一次建议使用 chrome 浏览器无痕模式，避免缓存问题导致No client certificate was presented。

5. 初始 CA 创建与证书层级搭建

5.1 进入证书 Profile 管理

• 登录 EJBCA 管理控制台。
• 依次点击 CA Functions → Certificate Profiles 进入管理页面。

5.2 创建证书 Profile

方法 1：克隆现有 Profile

• 在列表中找到合适的 Profile（如 ENDUSER）。
• 点击 Clone，输入新名称，保存。

方法 2：手动创建 Profile

• 点击 Add，输入名称后进入编辑页面。
• 根据实际需求设置 Key Usage、Extended Key Usage、有效期、Subject DN 设置等。
• 保存后返回列表查看。

5.3 创建 Crypto Token

1. 进入 CA Functions → Crypto Tokens。
2. 点击 Create new 并填写：
   • Name：输入 Crypto Token 名称。
   • Type：选择 SOFT。
   • Auto-activation：可选，勾选可自动激活。
   • Allow export of private keys：如需导出私钥，勾选 Allow。
   • Authentication Code：输入认证码并重复确认。
     dd if=/dev/random bs=1 count=128 2>&1| sha256sum | awk '{print $1}
3. 保存并在列表中确保状态为 Active。

5.4 生成密钥对

• 进入 Crypto Token 详情页面。
• 在 Crypto Token currently does not contain any key pairs. 处输入密钥名称（如 signKey）。
• 选择密钥算法（如 RSA 4096）。
• 点击 Generate new key pair 生成密钥。

注意：默认 Profile 不能修改，需克隆后新建。

5.5 创建 CA

1. 打开 CA Functions → Certification Authorities。
2. 在顶部列表中会看到默认的 ManagementCA (Active)；无需选中它。
3. 滚动到页面底部的 Add CA 区域：
   • 在文本框中输入新 CA 名称，例如 DemoCA。
   • 点击右侧 Create… 按钮，进入 CA 配置向导。
4. 在 Create CA 页面完成相关字段：
5. 点击最下方 Create 保存。若配置正确，页面将跳转回 CA 列表并看到 DemoSubCA (Active) 状态。
6. （可选）若要手动上传由根 CA 签发的证书，可在列表中选中新 CA，然后使用 Import CA certificate… 功能上传链文件。

到此，中间 CA 创建完成，后续即可用它签发终端实体证书。

5.6 Root CA 创建简要步骤案例

1️⃣ CA 类型与密钥配置

2️⃣ 证书策略（Directives）

3️⃣ 证书数据（CA Certificate Data）

4️⃣ CRL 配置（证书吊销列表）

5️⃣ 审批设置

6️⃣ 其他数据

7️⃣ 外部签名 CA 创建或更新（Externally signed CA creation/renewal）

8️⃣ 完成 CA 创建

检查所有参数，确认无误后，点击 Create 生成 CA。

① 下载并验证 Root CA 证书：

使用以下 OpenSSL 命令验证证书格式和有效性：

# 验证 PEM 格式证书
openssl x509 -in rootca.pem -text -noout

# 验证 DER 格式证书
openssl x509 -in rootca.der -inform DER -text -noout

# 检查证书 SHA256 指纹信息
openssl x509 -noout -fingerprint -sha256 -in rootca.pem

# 验证证书的有效性（自签名证书验证）
openssl verify -CAfile rootca.pem rootca.pem

② 部署并验证 CRL（证书吊销列表）：

若配置了 CRL URL，执行：

# 验证 CRL 文件
openssl crl -in rootca.crl -text -noout

确保 CRL 可通过 Web 正常访问。

🚀 Root CA 现在已成功创建，可用于签发中间 CA！ 🎉

5.7 中间 CA 创建简要步骤案例

1️⃣ CA 类型与密钥配置

2️⃣ 证书策略（Directives）

3️⃣ 证书数据（CA Certificate Data）

4️⃣ CRL 配置（证书吊销列表）

5️⃣ 默认 CA 验证数据（Default CA defined validation data）

6️⃣ 审批设置与其他数据

审批设置目前只有None选项，表示无需额外审批流程，如需开启需检查 EJBCA 的全局审批策略，Supervision Fuctions。

7️⃣ 完成中间 CA 创建

检查所有参数，确认无误后，点击 Create 生成 CA 请求文件 (CSR)。

提交 CSR 给 Root CA 签名后，下载签名后的证书并验证：

openssl x509 -in intermediate_ca.pem -text -noout
openssl verify -CAfile rootca.pem intermediate_ca.pem

🚀 中间 CA 已成功创建，可用于签发终端实体证书！🎉

6. RA 普通用户创建与权限配置

6.1 创建 RA 角色（Role）

1. 进入 RA 管理界面（RA Web），选择菜单：
   Role Management →Roles →Create New Role
   

2. 填写角色信息：

   字段	推荐填写值
   Namespace	No namespace
   Role name	test RA Users

3. 设置 Certificate Authorities 权限：
   • 从Available列表选择对应CA（如 Intermediate CA, Root CA），点击Add。
4. 设置 End Entity 权限（permissions）（推荐配置）：
   • ✅ Create end entities
   • ✅ Create certificates
     • ✅ ...by using username and password
     • ✅ ...by using a request ID
   • ✅ View end entities and certificates
5. 设置 End Entity Profiles 权限：
   • 从 Available 列表选择EMPTY，点击Add。
6. 点击Add保存创建好的角色。

6.2 创建 RA 普通用户 (End Entity)

1. 进入 EJBCA Admin Web 界面，选择：
   RA Functions → Add End Entity
   

2. 填写用户详细信息：

   字段	推荐填写值
   End Entity Profile	EMPTY
   Username	test_signuser
   Password	123
   Confirm Password	123
   Batch generation	不勾选
   E-mail	cert-user@example.com
   CN	test RA user S1
   O	test
   C	CN
   Certificate Profile	ENDUSER
   CA	test Intermediate CA
   Token	P12 file

3. 点击Add，完成 End Entity 创建。

6.3 用户证书下载

1. 用户进入RA Web 界面，选择：
   Enroll → Use Username
   

2. 使用刚创建的用户名和密码登录：
   • Username: test_signuser
   • Password: 123
3. 登录后选择密钥算法：
   • 选择RSA 4096算法，生成并下载.p12用户证书。

6.4 将用户加入 RA 角色

1. 进入 RA Web 界面，选择菜单：
   Search → End Entities
   

2. 查找并复制刚才创建证书的 CN 。
3. 进入 RA 管理界面，选择菜单：
   Role Management → Roles → Members → Add Role Member
   

4. 填写 Role Member 信息：

   字段	推荐填写值
   Role	test RA Users
   Token Type	Certificate
   CA	test Intermediate CA
   Match with	CN Common Name
   Match Value	粘贴刚复制的证书 CN
   Description	RA 普通用户

5. 点击Add，完成角色成员添加。
6. 重启 EJBCA 服务，使权限生效（推荐）：
   docker restart ejbca
   

6.5 用户登录 RA 界面

1. 非管理员角色将下载的.p12证书导入浏览器。
2. 访问 RA Web 界面，自动认证并登录。
3. 用户即可执行授权内的 RA 操作（如创建和查看证书等）。

6.6 重要提示（请务必遵守以下要求）

✅ 第一次建议使用 chrome 浏览器无痕模式快速启动验证，避免缓存问题导致No OAuth providers configured. Please log in using a valid certificate.。

✅ 访问时候 使用 https 访问，https://192.168.xxx.xxx/ejbca/ra/,避免出现No OAuth providers configured. Please log in using a valid certificate.。

7. 证书模板设置说明

本节用于解释 EJBCA 中终端证书模板（Certificate Profile）设置项的具体含义及推荐用途，适用于 HTTPS/Web/设备/客户端等常见终端证书签发需求。

7.1 基本信息

7.2 权限控制（Permissions）

✅ 建议：在生产环境中保持模板统一性，除非明确需要，否则尽量关闭 Override 类权限项，避免 CSR/End Entity 越权操作。

7.3 X.509v3 扩展 - 基础信息

7.4 X.509v3 扩展 - 密钥用途（Key Usage）

7.5 X.509v3 扩展 - 扩展密钥用途（Extended Key Usage）

7.6 名称扩展

7.7 验证扩展（Validation Data）

7.8 私钥使用期限制

7.9 🇪🇺 ETSI 合规扩展（一般用于合规性要求高的 PKI 环境）

7.10 其他扩展（Other Extensions）

7.11 审批设置 & 附加字段

7.12 CA & 发布设置

如需配置 "代码签名证书" 模板，请在此基础上调整 keyUsage 与 extendedKeyUsage 字段即可。

📌 建议对不同应用（如：VPN、HTTPS、代码签名、客户端认证）创建不同模板，便于管理和合规控制。

8. 审批配置与管理

8.1 创建 Approval Profile（审批配置）

1. 进入：

监察员功能 → Approval Profiles

1. 在底部输入名称（如 test）→ 点击 添加。
2. 在列表中点击 编辑 进入详细设置。

8.2 基本参数设置

8.3 审批步骤（Approval Steps）

1. 设置 Number of Required Approvals：
   • 开发/测试：1（1-of-1）。
   • 生产/敏感操作：2（2-of-2）或分区审批。
2. 通知邮件：
   • Notification message email recipient：approval-admin-group@example.org supervisor@example.org
   • Notification message email sender：no-reply@192.168.xxx.xx
   • 主题模板示例：
     [AR-${approvalRequest.ID}-${approvalRequest.STEP_ID}-${approvalRequest.PARTITION_ID}] Approval Request
     

   • 正文可引用变量：${approvalRequest.TYPE}、${approvalRequest.REQUESTOR}、${approvalRequest.WORKFLOWSTATE} 等。

8.4 绑定到具体动作

End Entity Profile：

CA Functions → End Entity Profiles → <Profile> → Approval Settings → 勾选需要审批的操作（如Add/Edit End Entity） → 选择上面创建的 Approval Profile → Save

常用勾选：Add/Edit End Entity、Key Recovery（若启用）。

Certificate Profile：

CA Functions → Certificate Profiles → <Profile> → Approval Settings → 勾选相关操作 → 选择 Approval Profile → Save

管理员敏感动作： 中间 CA 变更、吊销等建议使用 2-of-2 或分区审批。

8.5 测试与验证

1. 用一个普通 RA 账号在 RA Web 发起一次需要审批的操作（如创建 End Entity）。
2. 到 监察员功能 → Approvals 查看待审批队列，使用另一个审批员账号完成审批。
3. 确认操作自动执行，且邮件通知正常到达。

8.6 常见问题

• 邮件收不到：检查 SMTP 配置、防火墙、收件人拼写；查看容器日志。
• 一直待审批：Number of Required Approvals 设置过高或审批人不具备权限。
• 能自批：误勾选了 Allow Self Approved Request Editing；生产应关闭。
• 过期作废：Request/Approval Expiration 设置过短；可调到 8–24h。

9. 终端实体模板设置

位置：RA Functions → End Entity Profiles。终端实体模板（End Entity Profile）决定了“能填哪些字段”“哪些必填/可改”“默认使用哪个证书模板/CA/Token”。

9.1 新建与进入

1. 进入：

RA Functions → End Entity Profiles

1. 在底部输入模板名（如 test）→ 添加模板。
2. 在列表中选中该模板 → 编辑终端实体模板。

9.2 基本信息（用户名/密码/邮箱）

是否必须提前填？ 通常 不需要 在模板里写死具体“用户名/密码”。模板里只定义“规则与方式”，具体的 Username/Password/Enrollment Code 在创建 End Entity 或申请时填写即可。

推荐做法

• Username：选择 Auto-generated（批量/自动化最方便），或在创建 End Entity 时手动指定。
• Password (or Enrollment Code)：勾选 Required，作为一次性 Enrollment Code 使用；具体值在创建 End Entity 或 RA 端申请时再填。
• Minimum password strength / length：保持策略（如长度 ≥ 8），但不在模板里填具体密码。
• Maximum number of failed login attempts：按需限制；可勾 Modifiable 便于临时调整。
• Batch generation：一般关闭；避免明文存储 Enrollment Code。
• E-mail：按业务是否 Required/Modifiable，便于通知与标识。

不同申请路径对 Username/Password 的影响

• RA Web → Enroll → Use Username：创建 End Entity 时需要指定 Username 与 Password/Enrollment Code，用户用该账号登录领取证书。
• RA Web → Enroll → Use Request ID：由系统分配 Request ID，Password/Enrollment Code 在创建时设置，申请人用 ID+Code 领取。
• User Generated（CSR 提交）：Token=User Generated；保留 Required 以生成一次性代码，申请人用 CSR+Code 完成签发。

Directives（指令）

• Reverse Subject DN and Subject Alt Name Checks：不勾也可以。
• Allow merge DN for all interfaces：通常 不勾，仅在多接口需要聚合 DN 时启用。
• Allow multi-value RDNs：仅特殊需求启用（默认关闭更安全）。

9.3 主体 DN 属性（Subject DN Attributes）—需要自己添加

左侧是“可选属性”，右侧是“已选属性”。把需要的字段添加到右侧，并为每个字段设置 Required / Modifiable / Validation。

常见推荐（客户端/通用）：

若需要更严格的校验，可在 Validation 指定正则/格式规则。

9.4 其他主体属性（Other Subject Attributes）—需要自己添加

Subject Alternative Name（SAN）：

• 客户端证书：RFC 822 Name (e-mail address)（与账户邮箱一致）
• 服务器证书：DNS Name、IP Address（按域名/IP 添加）
• 设备证书：OtherName（写入设备 ID/OID）

Subject Directory Attributes（可选）：

• 仅在需要存档/合规时使用，例如 Date of birth (YYYYMMDD) 等；默认不建议开启过多目录属性。

添加方法：在 Other Subject Attributes 区域选择条目 → 添加 到右侧；如界面支持，可设置 Required/Modifiable。

9.5 主要证书数据（Main Certificate Data）

9.6 其他证书数据（Other Certificate Data）

• Custom certificate serial number：默认关闭
• Certificate Validity Start/End Time：默认由 Certificate Profile 控制；如需临时证书可开启并 Modifiable
• Name Constraints (Permitted/Excluded)：一般用于中间 CA；终端实体模板通常不启用
• Custom certificate extension data / ETSI PSD2 QC Statement / CA/B Forum Organization Identifier：按合规需要开启

9.7 其他数据与限制（Other Data / Restrictions）

9.8 保存与授权

1. 点击 保存。
2. 到 RA Web → Role Management 确认相关角色已被授权“使用此 End Entity Profile”（可见/可创建）。
3. 在 Search → End Entities 使用该模板创建测试用户，验证：
   • DN/SAN 是否按规则入库；
   • 证书是否使用了期望的 Certificate Profile/CA/Token；
   • 下载/导入是否成功（P12/PEM/CSR 流程）。

10. RA 普通用户申请终端证书

位置：RA Web → Enroll。

默认建议：优先使用 By the CA（CA 端生成密钥），无需 CSR，流程最稳、最少出错。

10.1 路径与前置

• 已在 End Entity Profiles（第 9 节）与 Certificate Profiles 准备好模板；用户具备访问权限。
• 若启用审批（第 8 节），提交后会进入待审队列，审批通过才签发。

10.2 推荐：By the CA（无需 CSR）

1. 进入：

Enroll → Make New Request

1. 选择 Certificate Type（End Entity Profile）与 Certificate subtype（Certificate Profile）。
2. 在 Key‑pair generation 选择 By the CA。
3. 展开 Provide request info，按模板要求填写 Subject DN / SAN（如 CN、Email、DNS/IP）。
4. 下载 *.p12。

10.3 可选：Provided by user（上传 CSR）

仅当必须在客户端/服务器本地生成密钥（如合规要求、HSM/专用设备、已有密钥迁移）时使用。

1. 本地生成私钥与 CSR：
2. 在页面选择 Provided by user，将完整 CSR（含 BEGIN/END CERTIFICATE REQUEST）粘贴到输入框。
3. 提交并按提示下载证书（不会包含你的私钥）。

10.4 审批联动与通知

• 当 Profile 绑定了 Approval Profile 时，提交即进入待审；通过后自动签发或开放下载。
• 邮件主题/正文遵循第 8 节的通知模板。

10.5 常见问题

• 字段不通过：DN/SAN 与 Profile 约束不一致；按第 9 节调整。
• 不能下载 P12：浏览器拦截或口令策略冲突；更换浏览器/检查口令长度与字符集。
• CSR 被拒：CSR 中 Subject/SAN 与模板冲突；按模板重建 CSR 或改用 By the CA。
• 审批卡住：审批人数未满足或审批人权限不足；去“监察员功能 → Approvals”。