[转载]JavaEE学习篇之——网络传输数据中的密码学知识以及Tomcat中配置数字证书EE
原文链接：http://blog.csdn.net/jiangwei0910410003/article/details/21716557
今天是学习JavaWeb的第二天，我们来了解什么呢？就了解一下Tomcat中配置数字证书的相关内容，但是在说这部分内容的时候，我们貌似得先说一下数字证书的相关概念，那说到数字证书的时候我们还得了解一些密码学的相关知识，这就是连锁反应吗？好吧不多说了，先来看一下密码学中关于网络中数据传输的知识。
首先来了解一下网络上传输数据的加密方式：
第一种是对称加密：就是加密数据的密码和解密数据的密码是相同的。这种方式的优点就是简单，最大的缺点就是不安全，因为加密的密码和解密的密码是相同的，那么加密的人就必须将密码告诉解密的人，在这个过程中就存在不安全了，怎么告诉都不安全，打电话怕人偷听，写信怕被人拦截。。。而且只要拿到密码就可以进行解密数据，这种方式也是不安全的。
第二种是非对称加密：就是加密数据的密码和解密数据的密码是不相同的，原理就是产生一对公钥和私钥，公钥加密的数据只能私钥解，私钥加密的数据只能公钥解，所以当拿到公钥加密的数据，只能用私钥解，公钥是解不开的。
下面我就来通过一个例子来说明一下这个过程：
角色：接收者，发送者，拦截者
名词：CA机构，数字证书，数字签名
下面的就通过这张图来解释一下(这张图花了我一个上午的时间，眼睛都看花了，一定要保证我的版权呀！)：
下面就来模拟集中情况来说明一下：
第一种情况：接收者会生成一对公钥和私钥，并且将自己的公钥发送给发送者，然后发送者用这个公钥将需要发送的数据进行加密，然后再将加密之后数据发送给接收者，这时候接收者只需要用私钥进行解密就可以得到发送者的数据了，在传输的过程中即使有拦截者拿到了发送者发送的数据以及接收者的公钥，他仍然不能得到原始内容的，因为只能用私钥进行解密，而私钥只有接收者有。如图中的流程：
1 -> 2 -> 3 -> 4 -> 5
第二种情况：对于第一种情况，想想就是天衣无缝了吗？肯定不可能的了，现在有这种情况，有一个hacker,他拦截到接收者发送给发送者的公钥，然后自己生成一对公钥和私钥，然后他把自己的公钥发送给发送者，当发送者拿到这个公钥的时候(实际上他以为这还是接收者发送给他的公钥)，用这个公钥进行加密，然后发送给接收者，这时候hacker再次进行拦截，然后hacker拦截到数据后，就用自己的私钥进行解密，就得到了原始数据，而接收者得到内容之后解密是失败的，因为发送者发送的数据是用hacker的公钥进行加密的。如图中的流程：
1 -> 2(6 -> 7) -> 3 -> 4(8 -> 9 -> 10) -> 5
第三种情况：对于第二种情况的话，难道我们也就没有办法了吗？难道我们的信息只能无辜的被hacker进行读取吗？当然，道高一尺，魔高一丈，其实解决上面的问题的根本方法就是要让发送者相信他接收到的公钥是接收者发送的，而不是hacker发送的公钥。这个解决办法就是有一个中间的担保人，担保这个公钥是接收者的，同时接收者需要事前找到这个担保人说明一下。这时候就出现了一个机构：CA。这里的CA就是上面说到的担保人，这个机构一般是由政府机构管理的。接收者产生一对公钥和私钥，然后拿着公钥到CA机构认证说明一下，同时CA会颁发一份数字证书给接收者，其实这数字证书就是有CA认证之后的公钥。然后接收者就会将这份数字证书发送给发送者，当发送者拿到这份数字证书的时候，会先到CA机构去认证一下，确定公钥是不是接收者发送的。然后在用数字证书进行数据加密，发送给接收者。如图中的流程：
1 -> 11 -> 12 -> 13 -> 14 -> 5
第四种情况：对于第三种情况，难道hacker就没办法了吗？说到这里可能有人会说，hacker可以生成一对公钥和私钥，然后到CA机构认证拿到数字证书，然后再拦截。这里就要说说这个CA机构了，这个机构是由政府管理的，不是什么人什么机构想认证就能认证的，一般是银行，商业性的机构才有权认证，同时认证的时候也不是随随便便的，需要提供很多的信息的。这样一说你认为hacker有权利申请了吗？他敢申请吗？，所以这种方法就不行了。同时也说明了一点就是数字证书这东东可以防止hakcer拦截信息进而解密信息。但是hacker不解密信息，但是他仍然可以干坏事，他可以篡改信息。如下情景：hacker拦截了接收者发送给发送者的数字证书，然后在拦截发送者使用数字证书加密的数据，这时候不是为了解密，也解不了密，而是将这些信息保存或者丢弃，然后使用截取到的数字证书加密一段自己想发送给接收者的数据，然后发送给接收者，这时候，接收者收到的加密数据其实是hacker的，而不是发送者发送的，如图中的流程：
1 -> 11 -> 12(15) -> 13 -> 14(16) -> 5
第五种情况：对于第四种情况，难道我们有没有办法了吗？我们的信息就任hacker进行篡改，这肯定是不可能的，上有政策，下有对策。那我们该怎么办呢？解决的思路就是接收者要验证数据在传输的过程中没有被篡改过。那么这里又要说到一种技术：数字签名操作步骤：首先发送者也会生成一对公钥和私钥，同时向CA机构得到一份数字证书，同时这时候发送者将要发送的数据使用私钥进行加密A，同时使用私钥对数据的数据指纹(MD5)进行加密(数字签名)B，然后将A和B以及发送者的数字证书一起发送给接收者，接收者拿到数据之后：
第一步：然后向CA机构验证数字证书是不是发送者的，是的话，就用数字证书解密数据指纹(MD5)数据
第二步：使用数字证书解密发送者的数据
第三步：将第二步中得到的数据获取一下指纹，和第一步中获取到的数据指纹相比较，如果相等就表示发送内容没有被篡改，否则就被篡改了。
这样就可以防止信息发送的过程中防止被篡改了。
以上是介绍完了网络中传输数据中设计到的密码学的知识，下面就来介绍一下使用Tomcat来进行数字证书的配置：
首先我们使用java自带的一个命令生成一个密钥库keystore文件：
keytool -genkeypair -alias "tomcat" -keyalg "RSA"
这里需要给密钥库配置密码，然后是姓氏，这里面的这个姓氏就是给哪个网站配置数字证书，我们这里是localhost，这个信息一定要填写正确，不然没有效果的，其他的信息我们这里只做演示，所以可以不填的，按回车，最后输入y,这时候就会在你的本机用户目录中生成一个.keystore文件。这个就是密钥库文件了。
密钥库文件生成好了，接下来我们就来配置Tomcat文件了，找到server.xml文件，打开：
这时候我们将刚刚生成的.keystore放到conf文件夹下面，配置server.xml文件内容如上图所示，密码就是刚刚生成.keystore文件时敲入的密码。保存server.xml文件，然后重启tomcat
使用IE浏览器(Chrome看不到效果的)，在地址栏中输入：
https://localhost:8443
这里一定要使用https协议了，因为是加密访问的，还有这里要使用8443端口了，因为我们要访问我们的数字证书的连接器，在浏览器中看到：
这时候IE浏览器会提示我们这个数字证书不是由CA机构颁发的，不可信(因为IE浏览器中集成了这种数字证书的检查机制)，我们点击继续浏览此网站：
这时候就可以连接到了数字证书连接器，同时可以看到地址栏的右边多了一个图标：说是证书错误，我们点击这个图标，他再次弹出一个提示，说这个证书不可靠，我们不管他了，点击查看证书：
这时候他还是提示我们这个证书不安全，看到颁发者是localhost了，这时候我们点击安装证书，安装完成之后，到此为止我们就为我们自己的localhost网站安装了我们自己的localhost的数字证书了。这样用户在访问localhost网站的时候，用户提交的数据就会使用我们安装好的数字证书进行加密了。
总结：上面就大体上说了一下网络中传输数据中的相关加密的知识以及怎么使用tomcat配置一个数字证书。其实这些内容我们日常生活中都是会接触到的，最明显的例子就是网银了。你在访问银行网站的时候，他会提示你安装一下数字证书，这个就说明：该银行生成了一对公钥和私钥，然后到CA机构去认证一下得到了一份数字证书，然后在将这份数字证书配置到该网站上面即可。
