Keytool和OpenSSL生成和签发数字证书

• KeyTool 简介
• OpenSSL 简介

 根据非对称密码学的原理，每个证书持有人都有一对公钥和私钥，这两把密钥可以互为加解密。公钥是公开的，不需要保密，而私钥是由证书持人自己持有，并且必须妥善保管和注意保密。数字证书则是由证书认证机构（CA）对证书申请者真实身份验证之后，用CA的根证书对申请人的一些基本信息以及申请人的公钥进行签名（相当于加盖发证书机构的公章）后形成的一个数字文件。
 CA完成签发证书后，会将证书发布在CA的证书库（目录服务器）中，任何人都可以查询和下载，因此数字证书和公钥一样是公开的。可以这样说，数字证书就是经过CA认证过的公钥，而私钥一般情况都是由证书持有者在自己本地生成的，由证书持有者自己负责保管。
 具体使用时，签名操作是发送方用私钥进行签名，接受方用发送方证书来验证签名；加密操作则是用接受方的证书进行加密，接受方用自己的私钥进行解密。 因此，如果说数字证书是电子商务应用者的网上数字身份证话，那么证书相应的私钥则可以说是用户的私章或公章.

1. 创建CA的自签名证书，做RootCA使用
openssl req -new -x509 -keyout test_ca.key -out test_ca.cer -days 3650

2. 利用keytool生成server端的证书，信息和创建CA时需要保持一致
keytool -genkeypair -alias server -keyalg RSA -keystore server.keystore

3. 生成server端证书签名请求
keytool -certreq -alias server -file server.csr -keystore server.keystore

4. 使用OpenSSL RootCA 签发server端证书签名请求的证书
openssl ca -in server.csr -out server.cer -cert test_ca.cer -keyfile test_ca.key -notext

上面问题：
有时候,CA颁发机构和签名请求方极低可能是同一家公司或组织,即使是同一家公司或组织也可能是不同的部门,比如说,Android 组的朋友使用 Java 自带的 KeyTool 生成了一个签名请求文件(*.csr)给我来签名,尽管我们所有关键域的值都是一样,但还是签不过,总是报如下问题:
The xxx field needed to be same
为什么 sichuang和 sihchuang 不相同呢????
原因就在于 Java 的 KeyTool 生成的签名请求文件的编码格式与 OpenSSL 的默认编码格式不一致,Java KeyTool默认使用就是全部 PRINTABLE 而 OpenSSL 既有PRINTABLE 也有 ASN 1.12。
解决方法：修改/etc/pki/tls/openssl.cnf 中如下选项
vim /etc/pki/tls/openssl.cnf

问题解决，成功签名证书

5. 导入CA根证书到keystore，信任此证书
keytool -import -trustcacerts -alias ca_root -file test_ca.cer -keystore server.keystore

server.keystore包含两个条目，类型不同

6. 将RootCA签名后的server.cer 证书添加到server.keystore
keytool -import -alias serverbyCA -file server.cer -keystore server.keystore

我们一般将RootCA自签名证书，可信任的证书放到truststore中
keytool -importcert -alias ca_root -file test_ca.cer -keystore truststore.jks

keystore和truststore从其文件格式来看其实是一个东西，只是为了方便管理将其分开
keystore中一般保存的是我们的私钥，用来加解密、为别人做签名或者保存签名证书。
truststore中保存的是一些可信任的证书，存放的是只包含公钥的数字证书，代表了可以信任的证书，而keystore是包含私钥的，如RootCA自签名证书，主要是java在代码中访问某个https的时候对被访问者进行认证的，以确保其实可信任的。

参考文章：
https://blog.csdn.net/rznice/article/details/39555043
https://www.aliyun.com/jiaocheng/60736.html
http://wmljava.iteye.com/blog/1102725