7.9 PKIX支持
为了建立跨服务器、跨项目、跨组织机构的信任关系，Limax集成PKIX模块，提供创建CA，签署，回收X509证书的能力，为系统间安全互操作提供基础支持。同时，提供便利的管理工具，在确保安全的基础上，最大限度简化CA系统管理负担。
证书以及CRL的相关概念可以参考RFC5280，http://www.ietf.org/rfc/rfc5280.txt
OCSP服务相关概念可以参考RFC2560，http://www.ietf.org/rfc/rfc2560.txt
-
7.9.1 设计原则
-
ROOTCA离线管理，使用命令行工具操作，规避网络安全风险。
-
CA服务实现为网络服务，集成3个服务器。
1. 签署，回收证书采用近线方式，实现为HTTP服务，绑定在服务器的localhost:8080接口上，如果需要远程操作，必须架设自己的反向代理，所有的操作必须通过TOTP方式提供授权码。最大限度限制未授权访问。
2. 通过HTTPS方式向外提供自动Renew服务，允许签署短期证书，证书超出80%寿命之后，向服务器发起Renew请求，更换证书。使用短期证书，可以有效减少回收列表长度，降低回收管理负担；一旦证书不再使用，快速过期，减少盗用风险，降低管理负担。
3. 通过HTTP方式对外提供OCSP服务，同时自动发布CRL。
-
CA存在过期的问题，所以提供相应的解决方案，确保Renew的新证书由新CA签署，避免重新线下申请。
-
通过重新解释证书策略的方式，以CPS进行名字空间命名，为多个ROOTCA间互操作，提供基础支持。
-
允许使用支持PKCS11的智能卡设备，为Key安全提供进一步的保障。
-
应用端模块，自动维护私钥、证书链，执行Renew操作，隐藏实现复杂性，提供简单的接口，简化开发。
-
-
7.9.2 Location
Location对应了java.security.KeyStore.PrivateKeyEntry，是使用指定私钥及其证书链的基础。
Location用opaque URI方式描述，scheme:[alias@]path[#algorithm]
-
scheme
支持的scheme为FILE，PKCS11，PKCS12，JKS，JCEKS。约定了私钥、证书链的存放位置。
-
alias
alias与KeyStore定义的alias的含义相同。一个私钥、证书链容器，允许存放多份私钥、证书链条目，用alias索引。除了FILE，PKCS11不允许缺省alias外，其它scheme均可缺省，缺省的情况下通过KeyStore.aliases()方法查找第一个alias，作为隐含alias。
注意：JDK在alias的管理上没有明确的规范进行约定，实现上非常混乱。例如，PKCS12可以使用空串alias，但是javax.net.ssl.KeyManagerFactory，却搜索不出这样的alias，行为与JKS，JCEKS不一致。同样，PKCS11类型的KeyStore，可以通过KeyStore.aliases()搜索出这样的alias，KeyStore.loadKey()的时候却又失败。所以，尽量避免缺省alias。
-
path
path是一个文件系统路径，在不同的scheme下有不同的解释。
1. FILE的情况下，私钥、证书链分别存储为.key文件与.p7b文件。path是一个目录名。例如："file:abc@/work"，指定了私钥文件/work/abc.key，证书链文件/work/abc.p7b。
-
2. PKCS11的情况下，path指定了pkcs11配置文件，例如，对于epass2003这样一个支持PKCS11的TOKEN，可以找到PKCS11驱动，建立配置文件：
/work/epass2003-pkcs11.cfg: name = epass2003 library = c:/work/eps2003csp11.dll
那么，"abc@/work/epass2003-pkcs11.cfg" 这样一个location，指明了pkcs11容器中abc alias对应的私钥、证书链。
3. PKCS12、JKS、JCEKS的情况下, path为相应KeyStore文件的路径。 例如"pkcs12:/work/client.p12", 指明了使用client.p12文件里面的第一个alias对应的私钥、证书链。特别的, 因为CA可以签发PKCS12私钥证书包, 这样的证书包只放置一对私钥、证书链, 这样的证书包默认使用空串alias，也只有这种情况下，使用缺省alias是合理的。
-
algorithm
证书相关算法描述，构造为 PublicKeyAlgorithm/PublicKeyLength[/SignatureLength]
PublicKeyAlgorithm可取的值为RSA, DSA, EC。
PublicKeyLength，与相应的算法相关。
SignatureLength，可取的值为256, 384, 512。
除了初始化ROOTCA，签署CA证书之外，algorithm几乎都可以缺省，之后的命令行操作详细介绍。
-
-
7.9.3 开发工具
limax.pkix 包提供了Key管理工具，证书服务开发工具，证书服务客户端工具。
-
Key管理工具
limax.pkix.KeyInfo
所有相关工具的基础，解释Location，获取，保存相应的私钥、证书链，同时提供私钥、证书链的更新支持，更新过程保证事务完整性，PKCS11的情况下，有稍许安全性降低。更新的私钥、证书链首先会暂存到本地存储（当然，私钥是被启动时提供的密码加密的），然后执行一个拷贝过程，最后删除本地暂存数据。其它scheme下，必须保证Location指向的位置可写。另外，直接支持在KeyInfo的基础上创建SSLContext。
-
证书服务开发工具
limax.pkix.CAService
通过实现X509*Parameter系列接口，描述ROOTCA证书，CA证书，EndEntity证书，CRL请求，Renew请求，执行相应的签署操作。
具有相同Subject的CAService允许进行组合，使用过期时间最迟的CA证书签署新证书；使用被回收证书的发布CA签署CRL。这种方式可以确保提供可持续服务。
-
证书服务客户端工具
limax.pkix.SSLContextAllocator
使用Location指定的私钥、证书链，分配对应的SSLContext，提供给应用作进一步开发。短连接应用的情况下，每次获取SSLContext直接使用即可，长连接的情况下，可以注册一个Listener获取renew消息，适时更换新的SSLContext。
-
-
7.9.4 管理命令
limax.pkix.tool包，提供了pkix相关管理工具的实现。一共9条命令。以下命令，如果涉及到私钥访问的，都会提示输入私钥使用密码，涉及到私钥创建的，会2次确认私钥创建密码。
-
java -jar limax.jar pkix algo
显示支持的算法列表。
-
java -jar limax.jar pkix keygen <algo> <PathPrefix>
请求证书签名有两种方式，一是客户端生成私钥，提交公钥给CA，签署证书，生成证书链；二是CA直接生成公钥私钥对，签署证书，将私钥、证书链打包为PKCS12。第一种形式，私钥不会在网络上传输，具有更高的安全性。该命令为第一种方式提供支持。
例如, 执行java –jar limax.jar pkix keygen "rsa/1024" "/work/client"生成私钥文件/work/client.key, 公钥文件 /work/client.pub。将client.pub, 提交给CA签署证书。这种情况下，CA发还一个.p7b证书链文件，可以命名为client.p7b，放置在/work目录下，之后即可通过Location: "file:client@/work"使用。
-
java -jar limax.jar pkix copy <locationSRC> <locationDST>
Location转换工具，scheme之间进行拷贝，可能覆盖locationDST相应容器中的alias条目。
例如，java –jar limax.jar pkix copy "file:client@/work" "pkcs12:client@/work/client.p12" 将file方式描述的私钥、证书链转换为PKCS12方式。
注意，PKCS11不可能作为拷贝的源，因为PKCS11规范要求，私钥不可导出，这样的操作必然失败。
-
java -jar limax.jar pkix initroot <locationROOT> <subject> <yyyyMMdd> <yyyyMMdd>
初始化ROOTCA，例如：
java -jar limax.jar pkix initroot "file:ca@/work/pkix/root#rsa/2048/256" "dc=limax-project,dc=org" "20100101" "20500101"
以"dc=limax-project,dc=org"为subject签署有效期从2010-01-01到2050-01-01的自签名证书，使用算法rsa/2048，256位签名。在这里算法参数不可缺省。
-