刚进公司实习做实施工程师的时候，领导的要求是熟练安装公司的CA系统。当时只给了文档，玩客户端很久，心想安装软件不就是一路next最后点击个完成安装不就完了吗？结果发现完全不是那么回事，当点击安装完毕才是旅程的真正开始。
真正安装好能够发出一张用户证书后感受是：第一是安装的复杂度很高，按照手册来安装都有很大的几率安装不成功；第二是出现错误不知道哪里出了问题，唯一的解决办法是打电话求助研发，让研发从开发环境上调试到底是哪里配置不正确。
后来为了深入了解CA系统能够快速定位问题，终于知道CA产品的各部分的作用以及相互的关系，那么我们看看当时的CA的架构是如何的：
CA系统介绍
四层架构简述
第一层是资源层有密码设备比如有加密机，加密卡，LDAP目录服务器、DB数据库
第二层是资源层的代理服务用：有加密设备代理服务、LDAP代理服务、DB代理服务QM，这些服务将系统解耦，使得可以对接各种类型的服务和设备，而与上一层的服务无关，适配的过程只在这一层进行。
第三层是基于C++实现的CA核心逻辑：有签名服务、CA服务、RA服务
第四层是业务展示层像目前MVC架构里面的V这一层，通过web的友好可视化来实现证书的生命周期管理，数据交互通过java与C++的桥来处理。
这个阶段架构模式是仿照国外的成熟CA机构，这个模型灵活度高能够适应多种部署模式，当然太灵活的代价就是无法形成标准产品化程度较低。
CA系统的信任模型介绍
上图描述了一个标准的CA系统的信任关系模型。它就像一个倒着的树，根是信任的基础一般由CA机构产生，下面的中级证书代表了某个客户公司，用户证书由中级证书签发。从用户的角度看自己的证书是由自己的公司签发的，同时自己公司是由天威诚信提供证书服务的，这样的信任模式是符合组织架构和逻辑关系的。
CA系统的账户体系介绍
账户体系是天威诚信CA系统的核心所在，主要是在业务展现层中进行配置。其过程是按照从上到下依次进行步骤不能乱，这里是最容易出错的。第一步建立超级账户、加载根证书、申请和下载超级管理员，第二步申请ESA账户，配置ESA账户信息和加载根证书和中级证书，由超级管理员批准后下载ESA管理员证书，第三步按照上面的顺序，申请RA账户，配置RA账户信息和加载中级证书，由ESA管理员批准账户申请下载RA管理员证书，第四步下载用户证书，用户在用户申请站点填写申请信息，由RA管理员批准后下载用户证书到U盾中。为何如此复杂，证书系统是一个高安全要求的系统，通过层层审批，可以降低风险。
证书应用
证书颁发出来后，业务系统要识别证书以及符合证书的使用规范，这是就需要将证书的一套接口集成到业务系统中才可以正常使用，证书的应用接口包括服务端和客户端：
服务端接口
服务端的主流语言一般为Java和.net，偶尔会碰到c，主要提供前两个语言。这里主要讲讲JAVA接口的构成，java语言下的开源密码应用接口包主要有bouncycastle和jdk自带的jce，为了通用性主要采用bouncycastle和jce结合的方式，将这两个封装在一起提供给平台开发者的是比较简单易懂的接口。
客户端接口
客户端比较特殊，使用的是BS的结构但是要访问外设U盾，所以通过JS调浏览器插件。我们就需要维护JS的代码和插件的代码。一开始的时候产品还有一部分VBscript的代码，后来逐渐过渡到全部使用Javascript。js代码主要处理页面数据与后台数据的交互、页面的展现、页面数据与插件的数据交互。这个版本插件是由activeX框架组成，其中密码相关功能采用微软自带的库cryptoAPI。
