1、PKI 基础简介
公钥基础设施（Public Key Infrastructure，缩写 PKI）的基础与核心。
PKI 采用证书进行公钥管理，通过第三方的可信任机构（认证中心 CA），把用户的公钥和用户的其它标识信息捆绑在一起，当中包含 username 和电子邮件地址等信息。
PKI 既不是一个协议，也不是一个软件，它是一个标准，在这个标准之下发展出的为了实现安全基础服务目的的技术统称为 PKI。
PKI 把公钥和对称秘钥结合起来，在 Internet 网上实现密钥的主动管理，保证网上数据的安全传输。
广义上来讲提供公钥加密和数字签名服务的系统，都可归结为 PKI 系统的一部分，PKI 的主要目的是通过自己主动管理密钥和证书，为用户建立起一个安全的网络执行环境，使用户能够在多种应用环境下方便的使用加密和数字签名技术。
从而保证网上数据的机密性、完整性、有效性：
数据的机密性是指数据在传输过程中，不能被非授权者偷看；
数据的完整性是指数据在传输过程中不能被非法篡改；
数据的有效性是指数据不能被否认。
一个有效的 PKI 系统必须是安全的和透明的，用户在获得加密和数字签名服务时，不须要具体地了解 PKI 的内部运作机制。
在一个典型、完整和有效的 PKI 系统中，除证书的创建和公布，特别是证书的撤销，一个可用的 PKI 产品还必须提供对应的密钥管理服务，包含密钥的备份、恢复和更新等。
目前 PKI 标准化主要有两个方面：
一是 RSA 公司的公钥加密标准 PKCS（Public Key Cryptography Standards）,它定义了很多基本 PKI 部件，包含数字签名和证书请求格式等；
二是由 Internetproject 任务组 IETF（Internet Engineering Task Force）和 PKI 工作组 PKIX（Public Key Infrastructure Working Group）所定义的一组具有互操作性的公钥基础设施协议。
PKI 的发展非常快，已经从几年前的理论阶段过渡到眼下的产品阶段，而且出现了大量成熟技术、产品和解决方式，正逐步走向成熟。
PKI 的发展受应用驱动的影响，如早期的 Internet 商务和 Web 安全要求主要依赖于 SSL，并要求应用首先对证书进行处理。
目前 PKI 产品的生产厂家非常多，主要有 VeriSign 和 Entrust。
2、PKI 组成
PKI 作为一组在分布式计算系统中利用公钥技术和 X.509 证书所提供的安全服务，企业或组织可利用相关产品建立安全域，并在当中公布密钥和证书。
在安全域内，PKI 管理加密密钥和证书的公布，并提供诸如密钥管理（包含密钥更新，密钥恢复和密钥托付等）、证书管理（包含证书产生和撤销等）和策略管理等。
PKI 产品也同意一个组织通过证书级别或直接交叉认证等方式来同其它安全域建立信任关系。
这些服务和信任关系不能局限于独立的网络之内。而应建立在网络之间和Internet之上。为电子商务和网络通信提供安全保障，所以具有互操作性的结构化和标准化技术成为 PKI 的核心。
PKI 在实际应用上是一套软硬件系统和安全策略的集合，它提供了一整套安全机制。使用户在不知道对方身份或分布地非常广的情况下，以证书为基础。
通过一系列的信任关系进行通讯和电子商务交易。
一个典型的 PKI 包含 PKI 策略、软硬件系统、证书机构 CA、注冊机构 RA、证书公布系统和 PKI 应用等。
一个简单的 PKI 系统包含证书机构 CA、注冊机构 RA 和对应的 PKI 存储库。
CA 用于签发并管理证书；RA 可作为 CA 的一部分，也能够独立，其功能包含个人身份审核、CRL 管理、密钥产生和密钥对备份等；PKI 存储库包含 LDAP 文件夹 server 和普通数据库，用于对用户申请、证书、密钥、CRL 和日志等信息进行存储和管理并提供一定的查询功能。
3、证书认证机构 CA
3.1、数字证书基础
数字证书是一种数字标识，能够说是 Internet 上的安全护照或身份证明。当人们到其它国家旅行时，用户护照能够证实其身份，并被获准进入这个国家。
数字证书提供的是网络上的身份证明。
数字证书是一个经证书授权中心数字签名的包括公开密钥拥有者信息和公开密钥的文件。
最简单的证书包括一个公开密钥、名称以及证书授权中心的数字签名。
普通情况下证书中还包括密钥的有效时间，发证机关（证书授权中心）的名称，该证书的序列号等信息，证书的格式遵循 ITUT X.509 国际标准。
3.1.1、证书格式
在 Internet 网络中，应用程序使用的证书都来自不同的厂商或组织。为了实现可交互性，要求证书可以被不同的系统识别，符合一定的格式，并实现标准化。
X.509 为证书及其 CRL 格式提供了一个标准，但 X.509 本身不是 Internet 标准，而是国际电联 ITU 标准，它定义了一个开放的框架并在一定的范围内可以进行扩展。
PKIX 工作组就提供了一个 Internet草案"Part I: X.509 Certificate and CRL Profile"（具体内容可见：ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-11.txt），用于定义在Internet PKI中使用X.509和CRL的方法和规范。该草案把X.509作为标准，并对各标准项和扩展做了说明，基本接收了X.509作为Internet中的证书标准，但也定义了被PKI应用的X.509 V3和CRL V2标准格式的设置。这些设置包括了PKIX工作组对X.509所做的一些新的扩展。
X.509眼下有三个版本号：V1、V2和V3，当中V3是在V2的基础上加上扩展项后的版本号，这些扩展包含由ISO文档（X.509-AM）定义的标准扩展。
也包含由其它组织或团体定义或注冊的扩展项。
X.509由ITU-T X.509（前身为CCITT X.509）或ISO/IEC 9594-8定义。最早以X.500文件夹建议的一部分发表于1988年，并作为V1版本号的证书格式。
X.500于1993年进行了改动。并在V1基础上添加了两个额外的域，用于支持文件夹存取控制，从而产生了V2版本号。
为了适应新的需求ISO/IEC和ANSI X9发展了X.509 V3版本号证书格式，该版本号证书通过添加标准扩展项对V1和V2证书进行了扩展。
另外，依据实际须要。各个组织或团体也能够添加自己的私有扩展。
X.509 V1和V2证书所包括的主要内容例如以下：
证书版本号号（Version）：版本号号指明X.509证书的格式版本号，如今的值能够为0、1、2，也为将来的版本号进行了提前定义。
证书序列号（SerialNumber）：序列号指定由CA分配给证书的唯一的数字型标识符。当证书被取消时，实际上是将此证书的序列号放入由CA签发的CRL中，这也是序列号唯一的原因。
签名算法标识符（Signature）：签名算法标识用来指定由CA签发证书时所使用的签名算法。
算法标识符用来指定CA签发证书时所使用的公开密钥算法和hash算法，须向国际知名标准组织（如ISO）注冊。
签发机构名（Issuer）：此域用来标识签发证书的CA的X.500 DN名字。包含国家、省市、地区、组织机构、单位部门和通用名。
有效期（Validity）：指定证书的有效期。包含证书開始生效的日期和时间以及失效的日期和时间。
每次使用证书时。须要检查证书是否在有效期内。
证书username（Subject）：指定证书持有者的X.500唯一名字。包括国家、省市、地区、组织机构、单位部门和通用名，还可包括email地址等个人信息等
证书持有者公开密钥信息（subjectPublicKeyInfo）：证书持有者公开密钥信息域包括两个重要信息：证书持有者的公开密钥的值；公开密钥使用的算法标识符。
此标识符包括公开密钥算法和hash算法。
签发者唯一标识符（Issuer Unique Identifier）：签发者唯一标识符在第2版增加证书定义中。此域用在当同一个X.500名字用于多个认证机构时，用一比特字符串来唯一标识签发者的X.500名字。可选。
证书持有者唯一标识符（Subject Unique Identifier）：持有证书者唯一标识符在第2版的标准中增加X.509证书定义。此域用在当同一个X.500名字用于多个证书持有者时，用一比特字符串来唯一标识证书持有者的X.500名字。
签名值（Issuer's Signature）：证书签发机构对证书上述内容的签名值。
X.509 V3证书是在v2的基础上一标准形式或普通形式添加了扩展项，以使证书可以附带额外信息。标准扩展是指由X.509 V3版本号定义的对V2版本号添加的具有广泛应用前景的扩展项，不论什么人都可以向一些权威机构，如ISO。来注冊一些其它扩展，假设这些扩展项应用广泛，或许以后会成为标准扩展项。
3.1.2、CRL 格式
证书废除列表CRL（Certificate revocation lists，又称证书黑名单）为应用程序和其他系统提供了一种检验证书有效性的方式。不论什么一个证书废除以后。证书机构CA会通过公布CRL的方式来通知各个相关方。
眼下，同X.509 V3证书对相应的CRL为X.509 v2 CRL，其所包括的内容格式例如以下：
CRL的版本号号：0表示X.509 V1 标准；1表示X.509 V2 标准。眼下经常使用的是同X.509 V3证书相应的CRL V2版本号。
签名算法：包括算法标识和算法參数，用于指定证书签发机构用来对CRL内容进行签名的算法。
证书签发机构名：签发机构的DN名，由国家、省市、地区、组织机构、单位部门和通用名等组成。
此次签发时间：此次CRL签发时间，遵循ITU-T X.509 V2标准的CA在2049年之前把这个域编码为UTCTime类型，在2050或2050年之后年之前把这个域编码为GeneralizedTime类型。
下次签发时间：下次CRL签发时间，遵循ITU-T X.509 V2标准的CA在2049年之前把这个域编码为UTCTime类型，在2050或2050年之后年之前把这个域编码为GeneralizedTime类型。
用户公钥信息。当中包含废除的证书序列号和证书废除时间。废除的证书序列号是指要废除的由同一个CA签发的证书的一个唯一标识号，同一机构签发的证书不会有同样的序列号。
签名算法：对CRL内容进行签名的签名算法。
签名值：证书签发机构对CRL内容的签名值。
另外。CRL中还包括扩展域和条目扩展域。CRL扩展域用于提供与CRL有关的额外信息部份，同意团体和组织定义私有的CRL扩展域来传送他们独有的信息。CRL条目扩展域则提供与CRL条目有关的额外信息部份，同意团体和组织定义私有的CRL条目扩展域来传送他们独有的信息。
3.1.3、证书的存放
数字证书作为一种电子数据格式，能够直接从网上下载。也能够通过其它方式。
使用IC卡存放用户证书。即把用户的数字证书写到IC卡中。供用户随身携带。这样用户在全部可以读IC卡证书的电子商务终端上都可以享受安全电子商务服务。
用户证书直接存放在磁盘或自己的终端上。户将从CA申请来的证书下载或拷贝到磁盘或自己的PC机或智能终端上。当用户使用自己的终端享受电子商务服务时，直接从终端读入就可以。
另外，CRL一般通过网上下载的方式存储在用户端。
3.2、CA 框架模型
证书机构CA用于创建和公布证书，它通常为一个称为安全域（security domain）的有限群体发放证书。创建证书的时候，CA系统首先获取用户的请求信息，当中包含用户公钥（假设用户端是个人使用或者測试用。则公钥一般由用户端产生，如电子邮件程序或浏览器等或者使用第三方开发的具有独立CSP的智能终端如USBkey），CA将依据用户的请求信息产生证书。并用自己的私钥对证书进行签名。其它用户、应用程序或实体将使用CA的公钥对证书进行验证。
假设一个CA系统是可信的。则验证证书的用户能够确信，他所验证的证书中的公钥属于证书所代表的那个实体。
CA还负责维护和公布证书废除列表CRL（certificate revocation lists，又称为证书黑名单）。
当一个证书，特别是当中的公钥由于其它原因无效时（不是由于到期）。CRL提供了一种通知用户和其它应用的中心管理方式。CA系统生成CRL以后。要么是放到LDAPserver中供用户查询或下载，要么是放置在Webserver的合适位置，以页面超级连接的方式供用户直接查询或下载。
一个典型的CA系统包含安全server、注冊机构RA、CAserver、LDAP文件夹server和数据库server等。
安全server：安全server面向普通用户。用于提供证书申请、浏览、证书撤消列表以及证书下载等安全服务。安全server与用户的的通信採取安全信道方式（如SSL的方式，不须要对用户进行身份认证）。用户首先得到安全server的证书（该证书由CA颁发），然后用户与server之间的全部通信。包含用户填写的申请信息以及浏览器生成的公钥均以安全server的密钥进行加密传输，仅仅有安全server利用自己的私钥解密才干得到明文，这样能够防止其它人通过窃听得到明文。从而保证了证书申请和传输过程中的信息安全性。
CAserver：CAserver使整个证书机构的核心，负责证书的签发。
CA首先产生自身的私钥和公钥（密钥长度至少为1024位），然后生成数字证书，而且将数字证书传输给安全server。CA还负责为操作员、安全server以及注冊机构server生成数字证书。安全server的数字证书和私钥也须要传输给安全server。CAserver是整个结构中最为重要的部分，存有CA的私钥以及发行证书的脚本文件，出于安全的考虑，应将CAserver与其它server隔离。不论什么通信採用人工干预的方式，确保认证中心的安全。
注冊机构RA：登记中心server面向登记中心操作员，在CA体系结构中起承上启下的作用。一方面向CA转发安全server传输过来的证书申请请求，还有一方面向LDAPserver和安全server转发CA颁发的数字证书和证书撤消列表。
LDAPserver：LDAPserver提供文件夹浏览服务，负责将注冊机构server传输过来的用户信息以及数字证书增加到server上。这样其它用户通过訪问LDAPserver就行得到其它用户的数字证书。
数据库server：数据库server是认证机构中的核心部分。用于认证机构中数据（如密钥和用户信息等）、日志合统计信息的存储和管理。实际的的数据库系统应採用多种措施，如磁盘阵列、双机备份和多处理器等方式，以维护数据库系统的安全性、稳定性、可伸缩性和高性能。
3.3、证书的申请和撤销
证书的申请有两种方式，一是在线申请，另外一个就是离线申请。在线申请就是通过浏览器或其它应用系统通过在线的方式来申请证书。这样的方式一般用于申请普通用户证书或測试证书。
离线方式一般通过人工的方式直接到证书机构证书受理点去办理证书申请手续。通过审核后获取证书，这样的方式一般用于比較重要的场合，如server证书和商家证书等。
以下讨论的主要是在线申请方式。
当证书申请时，用户使用浏览器通过Internet訪问安全server，下载CA的数字证书（又叫做根证书），然后注冊机构server对用户进行身份审核，认可后便批准用户的证书申请。然后操作员对证书申请表进行数字签名，并将申请及其签名一起提交给CAserver。
CA操作员获得注冊机构server操作员签发的证书申请。发行证书或者拒绝发行证书，然后将证书通过硬拷贝的方式传输给注冊机构server。注冊机构server得到用户的证书以后将用户的一些公开信息和证书放到LDAPserver上提供文件夹浏览服务。而且通过电子邮件的方式通知用户从安全server上下载证书。
用户依据邮件的提示到指定的网址下载自己的数字证书。而其它用户能够通过LDAPserver获得他的公钥数字证书。
证书申请的过程例如以下：
3.3.1、用户申请
用户首先下载CA的证书，又叫根证书，然后在证书的申请过程中使用SSL安全方式与server建立连接，用户填写个人信息。浏览器生成私钥和公钥对，将私钥保存client特定文件里，而且要求用口令保护私钥。同一时候将公钥和个人信息提交给安全server。安全server将用户的申请信息传送给注冊机构server。
3.3.2、注冊机构审核
用户与注冊机构人员联系，证明自己的真实身份，或者请求代理人与注冊机构联系。 注冊机构操作员利用自己的浏览器与注冊机构server建立SSL安全通信，该server须要对操作员进行严格的身份认证。包含操作员的数字证书、IP地址。为了进一步保证安全性，能够设置固定的訪问时间。
操作员首先查看眼下系统中的申请人员，从列表中找出对应的用户，点击username。核对用户信息。而且能够进行适当的改动。假设操作员允许用户申请证书请求。必须对证书申请信息进行数字签名。操作员也有权利拒绝用户的申请。
操作员与server之间的全部通信都採用加密和签名。具有安全性、抗否认性。保证了系统的安全性和有效性。
3.3.3、CA 发行证书
注冊机构RA通过硬拷贝的方式向CA传输用户的证书申请与操作员的数字签名，CA操作员查看用户的具体信息。而且验证操作员的数字签名，假设签名验证通过，则允许用户的证书请求，颁发证书。
然后CA将证书输出。假设CA操作员发现签名不对，则拒绝证书申请。 CA颁发的数字证书中包括关于用户及CA自身的各种信息。如：能唯一标识用户的姓名及其它标识信息。如个人的email地址；证书持有者的公钥。公钥用于为证书持有者加密敏感信息、签发个人证书的认证机构的名称、个人证书的序列号和个人证书的有效期（证书有效起止日期）等
3.3.4、注冊机构证书转发
注冊机构RA操作员从CA处得到新的证书，首先将证书输出到LDAP文件夹server以提供文件夹浏览服务，最后操作员向用户发送一封电子邮件。通知用户证书已经发行成功。而且把用户的证书序列号告诉用户到指定的网址去下载自己的数字证书。
而且告诉用户怎样使用安全server上的LDAP配置。让用户改动浏览器的client配置文件以便訪问LDAPserver，获得他人的数字证书。
3.3.5. 用户证书获取
用户使用证书申请时的浏览器到指定的网址。键入自己的证书序列号，server要求用户必须使用申请证书时的浏览器，由于浏览器须要用该证书对应的私钥去验证数字证书。仅仅有保存了对应私钥的浏览器才干成功下载用户的数字证书。
这时用户打开浏览器的安全属性，就能够发现自己已经拥有了CA颁发的数字证书，能够利用该数字证书与其它人以及webserver（拥有同样CA颁发的证书）使用加密、数字签名进行安全通信。
认证中心还涉及到CRL的管理。用户向特定的操作员（仅负责CRL的管理）发一份加密签名的邮件。申明自己希望撤消证书。操作员打开邮件，填写CRL注冊表。而且进行数字签名，提交给CA，CA操作员验证注冊机构操作员的数字签名。批准用户撤消证书。而且更新CRL，然后CA将不同格式的CRL输出给注冊机构。发布到安全server上。这样其它人能够通过訪问server得到CRL。
证书撤销流程过程例如以下：
1) 用户向注冊机构操作员CRLManager发送一封签名加密的邮件。声明自己自愿撤消证书。
2) 这冊机构允许证书撤消，操作员键入用户的序列号，对请求进行数字签名。
3) CA查询证书撤消请求列表，选出当中的一个，验证操作员的数字签名，假设正确的话，则允许用户的证书撤消申请。同一时候更新CRL列表，然后将CRL以多种格式输出。
4) 注冊机构转发证书撤消列表。操作员导入CRL，以多种不同的格式将CRL发布于众。
5) 用户浏览安全server，下载或浏览CRL。
在一个PKI，特别是CA中，信息的存储是一个很核心的问题。它包含两个方面：一是CAserver利用数据库来备份当前密钥和归档过期密钥。该数据库需高度安全和机密。其安全等级同CA本身同样；另外一个就是文件夹server。用于分发证书和CRL，一般採用LDAP文件夹server。
3.4 密钥管理
密钥管理也是PKI（主要指CA）中的一个核心问题。主要是指密钥对的安全管理，包含密钥产生、密钥备份、密钥恢复和密钥更新等。
1）密钥产生
密钥对的产生是证书申请过程中重要的一步，当中产生的私钥由用户保留，公钥和其它信息则交于CA中心进行签名。从而产生证书。依据证书类型和应用的不同。密钥对的产生也有不同的形式和方法。
对普通证书和測试证书。一般由浏览器或固定的终端应用来产生。这样产生的密钥强度较小。不适合应用于比較重要的安全网络交易。而对于比較重要的证书，如商家证书和server证书等，密钥对一般由专用应用程序或CA中心直接产生。这样产生的密钥强度大，适合于重要的应用场合。
另外，依据密钥的应用不同，也可能会有不同的产生方式。比方签名密钥可能在client或RA中心产生，而加密密钥则须要在CA中心直接产生。
2）密钥备份和恢复
在一个PKI系统中。维护密钥对的备份至关重要。假设没有这样的措施，当密钥丢失后。将意味着加密数据的全然丢失。对于一些关键数据，这将是灾难性的。
所以，密钥的备份和恢复也是PKI密钥管理中的重要一环。
使用PKI的企业和组织必须恩可以得到确认：即使密钥丢失。受密要加密保护的重要信息也必须可以恢复。而且不能让一个独立的个人全然控制最重要的主密钥。否则将引起严重后果。
企业级的PKI产品至少应该支持用于加密的安全密钥的存储、备份和恢复。
密钥一般用口令进行保护，而口令丢失则是管理员最常见的安全疏漏之中的一个。所以，PKI产品应该可以备份密钥，即使口令丢失。它也可以让用户在一定条件下恢复该密钥，并设置新的口令。
比如，在某些情况下用户可能有多对密钥，至少应该有两个密钥：一个用于加密，一个用于签名。签名密要不须要备份。由于用于验证签名的公钥（或公钥证书）广泛公布，即使签名私钥丢失，不论什么用于对应公要的人都能够对已签名的文档进行验证。
但PKI系统必须备份用于加密的密钥对，并同意用户进行恢复。否则，用于解密的私钥丢失将意味着加密数据的全然不可恢复。
另外，使用PKI的企业也应该考虑所使用密钥的生命周期，它包含密钥和证书的有效时间，以及已撤销密钥和证书的维护时间等。
3）密钥更新
对每个由CA颁发的证书都会有有效期。密钥对生命周期的长短由签发证书的CA中心来确定，各CA系统的证书有效期限有所不同。一般大约为2-3年。
当用户的私钥被泄漏或证书的有效期快到时，用户应该更新私钥。这时用户能够废除证书，产生新的密钥对。申请新的证书。
3.5、证书的使用
在实际应用中，为了验证信息的数字签名。用户首先必须获取信息发送者的公钥证书，以及一些额外须要的证书（如CA证书等，用于验证发送者证书的有效性）。
证书的获取能够有多种方式，如发送者发送签名信息时附加发送自己的证书，或以另外的单独信息发送证书。或者能够通过訪问证书公布的文件夹server来获得。或者直接从证书相关的实体处获得。在一个PKI体系中，能够採取某种或某几种上述方式获得证书。
在电子商务系统中。证书的持有者能够是个人用户、企事业单位、商家、银行等。
不管是电子商务中的哪一方，在使用证书验证数据时，都遵循相同的验证流程。
一个完整的验证过程有下面几步：
1）将client发来的数据解密 (如解开数字信封)。
2）将解密后的数据分解成原始数据。签名数据和客户证书三部分。
3）用CA根证书验证客户证书的签名完整性。
检查客户证书是否有效 (当前时间在证书结构中的所定义的有效期内)。
检查客户证书是否作废 (OCSP方式或CRL方式)。
验证客户证书结构中的证书用途。
客户证书验证原始数据的签名完整性。
以上各项均验证通过。则接受该数据。
4、PKI 应用
PKI 技术的广泛应用能满足人们对网络交易安全保障的需求，作为一种基础设施，PKI 的应用范围很广泛。
4.1、虚拟专用网络（VPN）
VPN 是一种架构在公用通信基础设施上的专用数据通信网络。
利用网络层安全协议（尤其是IPSec）和建立在PKI上的加密与签名技术来获得机密性保护。
基于PKI技术的IPSec协议如今已经成为架构VPN的基础，它能够为路由器之间、防火墙之间或者路由器和防火墙之间提供经过加密和认证的通信。
4.2、安全电子邮件
作为Internet上最有效的应用。电子邮件凭借其易用、低成本和高效已经成为现代商业中的一种标准信息交换工具。随着Internet的持续增长，商业机构或政府机构都開始用电子邮件交换一些秘密的或是有商业价值的信息。
这就引出了一些安全方面的问题，包含：消息和附件能够在不为通信两方所知的情况下被读取、篡改或截掉。发信人的身份无法确认。
电子邮件的安全需求也是机密、完整、认证和不可否认。而这些都能够利用PKI技术来获得。
眼下发展非常快的安全电子邮件协议是S/MIME (The Secure Multipurpose Internet Mail Extension)。这是一个同意发送加密和有签名邮件的协议。
该协议的实现须要依赖于PKI技术。
4.3、Web 安全
浏览Web页面是人们最经常使用的訪问Internet的方式。
假设要通过Web 进行一些商业交易，该怎样保证交易的安全呢？为了透明地解决Web的安全问题，在两个实体进行通信之前，先要建立SSL连接，以此实现相应用层透明的安全通信。
利用PKI技术，SSL协议同意在浏览器和server之间进行加密通信。此外server端和浏览器端通信时两方能够通过数字证书确认对方的身份。-结合SSL协议和数字证书，PKI技术能够保证Web 交易多方面的安全需求，使Web上的交易和面对面的交易一样安全。
5、应用编程接口 API
协议标准是系统具有可交互性的前提和基础，它规范了PKI系统各部分之间相互通信的格式和步骤。
而应用编程界面API（Application programming interfaces）则定义了怎样使用这些协议。并为上层应用提供PKI服务。
当应用须要使用PKI服务，如获取某一用户的公钥、请求证书废除信息或请求证书时将会都会用到API。眼下API没有统一的国际标准。大部分都是操作系统或某一公司产品的扩展，并在其产品应用的框架内提供PKI服务。
眼下。有非常多能够让开发人员选择的API类型。IETF建议标准为通用安全服务API：GSS-API（Generic Security Service Application Program Interface），它提供了一种接口与网络机制和网络协议相互独立的实现。
欧洲建立的SESAME（Secure European System for Applications in a Multi-Vendor Environment）定义了一些安全界面。并作为该组织发展的安全技术的一部分，该接口得到了欧洲很多著名厂商的支持，如Bull SA、ICL和Seimens等，但没有在美国得到支持，特别是一些大的厂商。如Microsoft和Netscape等。
Entrust也为其产品提供了一套API，如Entrust证书管理服务API（CMS API。Entrust's Certificate Management Services API），该API同意应用使用Entrust的证书管理和分发服务。在1996年指定。并与1997年更新的PKIX Internet草案"Architecture for Public Key Infrastructure"定义了PKI结构，并建议了很多标准，当中就包含API。
眼下，在API市场处于率先地位的是Microsoft的CryptoAPI和Intel的公用数据安全框架CDSA（Common Data Security Architecture），他们凭借自己的产品优势相互竞争。Microsoft利用其广泛的操作系统市场，而Intel则凭借其PC芯片的优势，并与其他厂商。如IBM、Entrust和Netscape等进行联合。共同支持CDSA。
如今也有非常多厂商的PKI产品同一时候支持这两种API，如Entrust等。PKIX在非常多情况下支持CDSA，并建议其为"Architecture for Public Key Infrastructure"草案的标准。
除此之外，Entrust、IBM、Intel、 Netscape和TIS等联合向开放组织（Open Group）提议了一个基于CDSA的加密和证书管理接口，并使用了Entrust的CMS API、IBM的密钥恢复API。
但开放组织同一时候也在考虑使用PKCS #11作为安全API接口。
以下介绍眼下两个比較经常使用的安全API接口：CryptoAPI和CDSA接口。
5.1、CryptoAPI
微软加密应用程序接口CryptoAPI（Microsoft Cryptographic Application Programming Interface）为Win32应用程序提供了认证、编码、加密和签名等安全处理，它可使用户在对复杂的加密机制和加密算法不了解的情况下，而相应用程序添加安全功能。这样非常符合Windows的设计风格。就像用户但是使用图形库而不须要了解图形硬件一样。
眼下CryptoAPI的最新版本号是2.0版，在包括CryptoAPI 1.0的所有功能外，还添加了证书管理功能。为网络身份认证提供的基本保证。
CryptoAPI通过一系列的库函数来相应用程序提供PKI安全服务。
CryptoAPI的编程模型同Windows系统的图形设备接口 GDI比較类似，当中加密服务提供者CSP（Cryptographic Service Providers）等同于图形设备驱动程序 ，加密硬件（可选）等同于图形硬件，其上层的应用程序也类似，都不须要同设备驱动程序和硬件直接打交道
CryptoAPI共同拥有五部分组成：简单消息函数（Simplified Message Functions）、低层消息函数（Low-level Message Functions）、基本加密函数（Base Cryptographic Functions）、证书编解码函数（Certificate Encode/Decode Functions）和证书库管理函数（Certificate Store Functions）。
当中前三者可用于对敏感信息进行加密或签名处理。可保证网络传输信心的私有性；后两者通过对证书的使用。可保证网络信息交流中的认证性。
5.2、CDSA
CDSA（Common Data Security Architecture）为安全应用服务提供了一个总体框架和解决方式，提供了诸如证书管理等很多 PKI 功能。
CDSA 是以一个分层的服务提供者框架为基础。
其的应用模式可分为四层：
最上层是应用程序；
应用程序的下层是中间件，比如SSL、IPSEC接口、语言接口转换器等；
接下来是 CSSM 层，CSSM 层是 CDSA 的核心层；
CSSM 的下层是详细的服务提供者，如加密服务、证书服务、政策服务、数据存储服务等。
CSSM 是 CDSA 的核心部分，它表现为一组公开的应用编程接口（API），为应用程序提供安全功能的调用。共包括4个主要的安全模块。
加密服务提供（Cryptographic Service Provider。CSP）模块，CSP负责加/解密、数字签名和私钥保存等工作，是整个CDSA结构的基础。
信任策略（Trust Policy，TP）模块。
TP负责信任策略的详细实施，判定特定行为（如开支票或訪问涉密信息）所需的信任级别。因为具有模块化的结构，TP可以对不同的机构应用不同的策略。比方，对商业银行和政府机构运用的策略就有所不同。
证书库（Certificate Library，CL）模块。CL提供证书的维护、撤销和数字签名等功能。
数据存储库（Data Storage Library，DL）模块。DL进行安全相关数据对象的存储，包含证书、密钥和信任规则对象等。而实际的存储位置可能在大型数据库、原始的文件系统或某种特定的硬件设备中。
另外，不论什么软、硬件厂商都能够建立自己的服务提供模块。无缝嵌入到CDSA的开放式框架中。在CDSA 2.0中又添加任选模块管理，支持更方便地添加模块。
另外，还能够对CSSM进行更高一层的抽象。提供高层的API，使开发人员更easy使用CDSA提供的PKI安全功能。
6、PKI 标准
PKI 的标准可分为两个部分：一类用于定义 PKI，而还有一类用于 PKI 的应用。
在 PKI 技术框架中，很多方面都经过严格的定义，如用户的注冊流程、数字证书的格式、CRL 的格式、证书的申请格式以及数字签名格式等。
国际电信联盟 ITU X.509 协议是 PKI 技术体系中应用最为广泛、也是最为基础的一个国际标准。
它的主要目的在于定义一个规范的数字证书的格式，以便为基于 X.500 协议的文件夹服务提供一种强认证手段。
但该标准并不是要定义一个完整的、可互操作的 PKI 认证体系。
PKCS 是由美国 RSA 数据安全公司及其合作伙伴制定的一组公钥 password 学标准，当中包含证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。
到 1999 年底，PKCS 已经发布了下面标准：
PKCS#1：定义RSA公开密钥算法加密和签名机制。主要用于组织PKCS#7中所描写叙述的数字签名和数字信封。
PKCS#3：定义Diffie-Hellman密钥交换协议。
PKCS#5：描写叙述一种利用从口令派生出来的安全密钥加密字符串的方法。使用 MD2 或 MD5 从口令中派生密钥，并采用 DES-CBC 模式加密。
PKCS#6：描写叙述了公钥证书的标准语法，主要描写叙述X.509证书的扩展格式。
PKCS#7：定义一种通用的消息语法，包含数字签名和加密等用于增强的加密机制，PKCS#7与PEM兼容，所以不需其它password操作，就能够将加密的消息转换成PEM消息。
PKCS#8：描写叙述私有密钥信息格式，该信息包含公开密钥算法的私有密钥以及可选的属性集等。
PKCS#9：定义一些用于PKCS#6证书扩展、PKCS#7数字签名和PKCS#8私钥加密信息的属性类型。
PKCS#10：描写叙述证书请求语法。
PKCS#11：称为Cyptoki，定义了一套独立于技术的程序设计接口，用于智能卡和PCMCIA卡之类的加密设备。
PKCS#12：描写叙述个人信息交换语法标准。
PKCS#13：椭圆曲线password体制标准。
PKCS#14：伪随机数生成标准。
PKCS#15：password令牌信息格式标准。
另外 PKCS#2 和 PKCS#4 已经合并到 PKCS#1 之中。
PKIX 是由 IETF 组织中的 PKI 工作小组制定的系列国际标准。
此类标准主要定义基于 X.509 和 PKCS 的 PKI 模型框架。PKIX 中定义的四个主要模型为用户、认证中心 CA、注冊中心 RA 和证书存取库。
refer：
https://blog.csdn.net/gui694278452/article/details/46373319
http://baike.baidu.com/view/7615.htm?fr=aladdin
http://www.ibm.com/developerworks/cn/security/se-pkiusing/index.html?ca=drs
http://www.ibm.com/developerworks/cn/security/s-pki/
http://en.wikipedia.org/wiki/X.509
http://zh.wikipedia.org/wiki/PKCS
http://blog.csdn.net/rztyfx/article/details/6919220
http://weekend.blog.163.com/blog/static/7468958201131591422649/
http://linux.chinaunix.net/techdoc/beginner/2009/06/29/1120721.shtml
http://www.360doc.com/content/12/0414/19/3725126_203594495.shtml
http://blog.sina.com.cn/s/blog_436fe8b10100r5p3.html
http://blog.csdn.net/allwtg/article/details/4982507
http://rhythm-zju.blog.163.com/blog/static/310042008015115718637/
http://www.mike.org.cn/articles/ubuntu-config-apache-https/