根证书是什么ipssl证书

本文想简单谈谈那个所谓的“根证书”。在访问铁道部网上售票官网后，有一个醒目的提示，为保证顺畅购票，需要下载安装根证书。那么什么是根证书？为什么买火车票的时候需要下载和安装，在淘宝等在线交易网站购物时候为什么就不需要这样做？

今年开始，人民群众们终于可以通过互联网购买火车票了。虽然说在线买的难度不比以往排队购买低多少，但这总算是一次值得鼓励的尝试。不过在线购票系统一经退出，在技术上就已经被人批得体无完肤。

为了确保安全，很多涉及在线交易的网站，例如网上银行、购物网站等，都会使用SSL技术对页面内容进行加密。SSL技术在这里的主要用途有两个：

试试看访问“”这个域名，随后可以看到，在浏览器的地址栏，“Http”协议后面出现了“s”这个字母，并且IE地址栏的右侧显示了一个锁头图标，因此证明该网站是SSL加密的。点击这个锁头图标后，还可以看到网站所用证书的相关信息。

加密功能基本上没什么需要解释的，因此下文的重点将放在身份可靠性这块。在上图所示界面上点击“查看证书”链接，随后可以看到该网站SSL证书的详情：

上图显示的“VeriSignClass3InternationalServerCA–G3”是证书颁发机构，而“”是证书持有人。那么到底应该怎样通过这些信息判断网站是否可靠？

在这里一个很通用的规则是：如果浏览器检测到加密网站所用的证书是正常的，那么地址栏就会显示为绿色（使用EVSSL证书）或者白色（使用普通SSL证书），这种情况下可以放心地浏览该网站，并提交自己的数据；如果浏览器检测到网站的证书有问题，那么地址栏就会显示为红色，提醒我们注意，同时取决于具体情况，地址栏右侧会显示有“证书错误”按钮，而且网站内容不会显示，取而代之的是浏览器的警告信息。基本上主流浏览器的最新版本都已经具备这样的功能。

这个过程的基本原理是：假设我们信任A公司，而A公司信任B公司，那么我们就可以信任B公司。很明显，“”的证书是“VeriSignClass3InternationalServerCA–G3”颁发的，这表示后者信任前者，可以证明前者的真实身份，但是我们又凭什么信任后者这个证书颁发机构？

上述文字里不止一次提到“信任”一词，那么“信任”在这里是什么意思？是否像我们平时讲话时说的“我信任他”那样，代表我们相信他是个好人，不会干坏事？其实完全不是这样。这里所说的“信任”，只是说明证书持有人的身份是真实可靠的，至于持有人用这个证书干什么事情，不在“信任”的范畴内。例如，网上很多臭名昭着的恶意软件，现在都带有数字证书（倒是很多正规用途的软件因为开发商缺乏安全观念不带证书），同时因为这些数字证书的“根”都是我们信任的根证书颁发机构，因此，操作系统和浏览器是信任这些公司的身份的，但并不代表这些公司的软件不会干坏事。只要肯花钱，任何人都可以在商业性质的证书颁发机构买到直接被我们的系统所信任的证书。

其实Windows和任何操作系统本身就包含一些受信任证书颁发机构的根证书，要查看这些根证书，可以运行“certmgr.msc”打开证书控制台，然后从控制台窗口左侧的控制台树中依次进入“证书-当前用户”→“受信任的根证书颁发机构”→“证书”，随后右侧的窗口中会显示本机预置的所有根证书颁发机构，其中就有“CA–G3”，这表示我们信任“CA–G3”，而“CA–G3”信任“”，因此我们可以信任“”。如果从证书控制台中删除“CA–G3”的根证书，表示我们不再信任它，那么它所信任的公司也将不再被我们信任。

按照上文的方法打开证书控制台，并进入到“不信任的证书”→“证书”节点后，还会发现里面列出了多个颁发给大量知名企业的证书，例如Microsoft、Google、Skype、Yahoo等。为什么会不信任这些大牌互联网企业？就是因为某家根证书颁发机构被黑客攻破，导致这些大企业所用的证书私钥被窃取。因此为了保证安全，这些被盗证书已经被吊销。因而将原本被盗的证书都添加到“不信任的证书”节点下，这样盗取证书的黑客就算使用这些证书给病毒签名，伪装成这些大企业，也会因为证书吊销的缘故不会让人轻易上当。这家倒霉的公司就是荷兰的DigiNotar，该公司因为这次事件现在已经破产，而从中也足以证明证书吊销机制的重要性。这一点会在下文详细介绍。微软已经通过KB补丁将受影响的证书全部设置为不信任。

这里要重点提出“根证书”这个概念，全世界具有提供数字证书业务的公司有很多，而Windows自带的“根证书”很少，默认情况下，我们是如何信任这么多不同公司颁发的不同证书的？其实这就是“根”这个字的含义，因为可以颁发证书的公司虽然很多，但最基本的根证书颁发机构只有有限的几个，默认情况下都是被操作系统所信任的。那么既然操作系统能信任根证书颁发机构，自然也就可以信任被根证书颁发机构信任的公司，进而可以信任被这些公司所信任的下一级公司。

如何证明这一点？可以单击上图中的“查看证书”链接，随后打开“证书”对话框，切换到“证书路径”选项卡后，可以看到下图所示界面。从该图中可以看出，整个证书信任链的路径分为三个层次，最顶层的是我们信任的根证书颁发机构，该机构给“InternationalServerCA–G3”颁发了证书，因此，我们信任“CA-G3”；随后“CA-G3”又给“”颁发了证书，因此也可以信任“”。如果“”再给别人颁发证书，那么这个人的身份依然可以被我们信任。

而铁道部的在线订票网站并没有走这个一般意义上，涉及金融交易的商业化网站都严格遵守的方法。也就是说，铁道部并没有花钱在商业性质的CA（证书颁发机构）购买受信证书，他们直接自己给自己颁发证书。这样的做法一般主要是用于测试或学习等非正式场合，但如果一个商业化网站想要正式上线运营，通常并不会这样做，因为对用户来说风险太大。

当我们查看这个网站的证书信息时就会发现，这个证书根本没有一个有效的受信任CA，完全是自己给自己发着玩的。

上图信息显示，该证书的颁发者以及根证书是“SRCA”，不知道这个缩写代表什么意思，可能是铁道部内部的某个系统。因为SRCA的身份不被系统自带的任何一个根证书所信任，因此网站所用的证书默认也不会被任何一个系统所信任。因而铁道部要求安装根证书的原因，就是让访客将这个证书手工添加到“受信任的根证书颁发机构”节点下。

很遗憾的是，这种做法虽然很不安全，可国内的大佬们很喜欢使用。例如在我的系统中，这里就有建行和工行网银自行添加的根证书。

在订票的很多人可能会看到过“该站点安全证书的吊销信息不可用，是否继续”这样的信息。这是什么意思？

还是以上文那个DigiNotar的例子来说，假设某个大型CA被攻击，私钥被窃取，这时候有两种方法尽量避免损失：

第一种方式比较好理解，但并不是所有公司都能获此殊荣。毕竟主流操作系统的用户数量庞大，根本不可能针对一个地区性的，或者规模很小的公司的被盗证书发布更新，强制不信任。因此第二种情况就至关重要了。每个证书中都包含CRL，其实这个可以理解为一个网址，通过这个网址可以获得证书吊销的相关信息。

因此如果一个小公司通过商业性CA购买的证书被盗了，只要将相关信息告知CA，这家CA就会将这个证书的内容添加到CRL中。随后任何一个用户在执行涉及到证书的操作，例如安装带有数字签名的软件，或者访问SSL网站的时候，系统都会通过这个CRL地址检索吊销清单，并查看当前软件或网站使用的证书是否位于清单中。如果不在，就证明这个证书依然是可信任的；如果在，就证明该证书已经被盗，因此软件或网站存在仿冒的可能。

而因为使用了自己给自己颁发的证书，因此也就根本无法在自己的证书中包含CRL信息，所以会看到“吊销信息不可用”的提示，这意味着浏览器在告诉你，你所访问的网站，不一定能完全证明其可靠，这可能是真网站，但也有是钓鱼网站的可能。

而如果的证书私钥丢失或被盗（看看去年底的大规模泄密事件，谁敢保证没有这种可能性），持有该证书的人想要伪造一个钓鱼网站，或者以铁道部的身份发布恶意软件，那真是轻而易举，并且铁道部对此会束手无策。

毕竟在线购买火车票的人全都安装了这个根证书，而该证书根本无法通过CRL吊销。此外还有一个更重要的问题，如果盗取该证书的人继续使用“SRCA”的身份给其他人以其他身份颁发证书，例如以银行或支付中介的名义，结果会怎样？因为所有在线购买过火车票的人，由于根证书的关系，系统已经信任SRCA的根证书，因此这些伪造的证书也会直接被信任。最坏的情况下，所有热门的SSL加密网站（购物、银行、股票….）要想被伪造都是轻而易举的。

真心希望这种情况永远不会发生。同时更加希望国内这些大佬们有更多安全意识，尽快认识到目前这种做法的不足。商业受信证书虽然需要花钱买，但不是太贵，真的！

当然，上述希望可能永远不会成真，因此作为一般用户，如果你已经成功在线购买到火车票（恭喜你啊，你要不要去买个彩票试试手气），那么建议你在“受信任的根证书颁发机构”节点下将SRCA的根证书彻底删除。

Java编程语言的一个杰出之处就在于开源社区可以以较低的成本或者甚至是免费地提供优秀的应用程序。其中一个例子就是ApacheTomcat，它为使用servlet或JSP技术的开发提供了一个健壮的Web服务器。现在Web服务技术正日趋成熟，所以有些应用程序就有可能利用Swing特性丰富的前端瘦客户端结合Web或ejb层已经开发出来的数据验证和业务逻辑。此类应用程序只有在受到保护的情况下才能正常运行，不过，安全性不一定意味着昂贵的成本。本文的目的就是要演示Web服务客户端如何通过安全的HTTPS协议使用自签名的安全证书。

HTTPS通常可以无缝地与不安全的HTTP协议一起使用，而不中断用户的体验。这是由于SSL被设计为由可信的第三方进行验证和签名。Verisign是一家流行的认证机构。如果您的Web应用程序要求安全的通信，那么您就可以付钱给Verisign来签名您的SSL证书。经过Verisign签名之后，您的Web站点上的用户就可以不中断地在HTTP与HTTPS之间进行切换，因为所有主流Web浏览器都信任由Verisign签名的证书。但是Verisign并不是获得签名证书的惟一选择。为了节省运作成本，或者为了个人使用方便，您也可以自签名自己的证书。但是，自签名证书会中断Web站点用户的体验。通常Web浏览器会显示一个对话框，询问您是否希望信任一个自签名证书。

Web浏览器的这一特性很好，因为当其获得一个由未知认证机构签名的证书时，还有机会进行处理。在开发用于通过HTTPS进行通信的Web服务客户端时，这就没那么容易了。在运行Java代码时，不会出现询问是否信任一个不可信的认证机构的对话框。JRE会抛出一个异常，说明试图通过HTTPS连接到一个具有不可信证书的Web站点：

Causedby:sun.security.validator.ValidatorException:Notrustedcertificatefound

无法捕获此异常并继续。要让Web服务使用自签名证书，JRE必须以某种方式将您当作认证机构信任。

JDK附带了一个工具，keytool.exe，用于管理SSL公钥/私钥。密钥在文件系统的一个二进制文件中进行添加和删除。默认的密钥库文件是JAVA_HOMEjrelibsecuritycacerts。该文件包含了JRE所信任的认证机构的列表。一个知名可信公司（比如Verisign）的列表已经存在于密钥库中了。要查看该列表，可使用口令changeit执行以下代码：

D:>keytool-list-rfc-keystoreJAVA_HOMEjrelibsecuritycacerts

Keytool应用程序可用于编辑此文件。但是，为了防止出错，最好还是创建一个新文件。如果不告知keytool使用哪个文件，它就会默认地创建HOME/.keystore。

D:>keytool.exe-genkey-aliasTomcat-keyalgRSA-storepassbigsecret-keypassbigsecret-dname=localhost"

执行完该命令后，就会在HOME目录下生成一个.keystore文件。下面是各种切换命令的含义：

一旦keytool应用程序创建了一个新的公钥/私钥对，它就自动自签名该密钥。我们刚刚生成了自己的自签名证书，它可用于HTTPS通信。只需提取出自签名公钥。后面我将展示如何做。

当JRE启动时，它将自动找到HOME/.keystore文件，并且Tomcat会试着使用口令“bigsecret”访问它。在Tomcat启动时，控制台应该有如下输出：

Feb4,:11:.apache.coyote..ssl.trustStore和.ssl.trustStorePassword来指向CustomKeystore文件，并提供访问该文件的口令。jdj.wsclient.truststore包中的示例Web服务客户端使用的就是这种方法（参见清单4）。

main()方法设置系统属性，然后创建使用该Web服务的对象。当JRE需要访问密钥库时，它就在文件系统中寻找classpath/resources/keystore/CustomKeystore文件。虽然这只是一个简单的解决方案，但它还是存在问题，因为密钥库文件必须放在文件系统中，而客户端代码也必须知道在哪里找到它。

第二种解决方案具有更好的可移植性，它将资源放在jar文件中，从而避免了文件系统问题。客户端代码负责读取CustomKeystore文件，并以某种方式使用它创建到服务器的安全连接。jdj.wsclient.socketfactory包中的示例Web服务客户端使用的就是这种方法（参见清单5）。

清单5显示了如何将CustomKeystore文件作为资源读取，并使用它来创建.ssl.SSLSocketFactory。配置Axis可插入架构，然后可使用MySocketFactory类从该工厂创建安全的Socket对象。

本文以一个简单的问题开始：我希望使用自签名的证书保护通过HTTPS的Web服务通信。默认情况下，JRE会拒绝应用程序的自签名证书，因为它不是来自于可信的认证机构。要让安全的通信可运行，必须让Web服务客户端JRE信任自签名证书。为此，我使用keytool应用程序生成一个新的公钥/私钥对，提取出自签名公钥，然后创建一个新的密钥库，并导入该自签名证书。然后我创建一个不需要任何客户端配置的、完全自包含的Web服务客户端

平仲08:找不到本地用户和组的可以管理员运行cmd然后输入命