情形一：接口的加、解密与加、验签
rsa不是只有加密解密，除此外还有加签和验签。之前一直误以为加密就是加签，解密就是验签。这是错误的！
正确的理解是：
数据传输的机密性：公钥加密私钥解密是密送，保证消息即使公开也只有私钥持有者能读懂，指的是加密与解密。
身份验证机制：私钥加密公钥解密是签名，保证消息来源是私钥持有者，指的是加签和验签。即数字签名
所以加/解密和加/验签这是两种不同的概念。 即：公加私解，私签公验
注：其实在RSA中公钥和私钥都可以加密或解密，即：1.公加私解，2.私加公解 都可以。但是一般没有人会用第2种.因为公钥是公开的，用私钥加密的话，很多人截取的话都可以用公钥进行解密。
情形二：ssl认证
https是在http基础上通过ssl进行网络传输的安全加密（安全套接层），在最新的ssl的3.0版本可以进行服务器段与客户端的双向认证，ssl都是由客户端进行发起的。tls是由ssl发展演变而来的，目前主要由于ssl使用的普及太广。ssl认证最常见的就是浏览器和web服务器之间通信的建立。
数字证书的概念
数字证书则是由证书认证机构（CA）对证书申请者真实身份验证之后，用CA的根证书对申请人的一些基本信息以及申请人的公钥进行签名（相当于加盖发证书机构的公章）即数字证书使在申请人的公钥后附加了用户信息及CA的签名（用CA的私钥进行签名的）
公钥、私钥、证书的生成
1、一个HTTPS服务器首先创建他自己的密钥对（key pair），包含公钥和私钥。
2、通过网络把他的公钥送到CA中心，公钥中包含了个人鉴别信息（他的名字、地址、所用设备的序列号等等）。
3、CA中心创建并签署一个包含公钥及个人信息的证书，从而保证密钥的确实性。
4、使用该证书的人可以通过检验CA中心的签名（检验CA签名需要CA的公钥）来验证证书的确实性。
那用户在浏览器怎么认证该服务端网站的数字证书是否可信？因为在操作系统存在权威的CA证书（即原始的系统中就包含了CA公钥）就可以验证浏览器得到的服务端数字证书，即用操作系统中CA的公钥 验证 CA用私钥签名的网站数字证书。
在HTTPS协议的握手阶段是公钥、私钥、证书的典型使用场景。HTTPS握手的典型时序图如下：
上图中实线部分是必须的，虚线部分是可选的。该流程完成了两个任务：服务器身份的验证、加密传输对称加密密钥。
1、client hello和 server hello表示双方要建立一个加密会话。
2、服务器把数字证书传输给客户端，证书中包含服务器公钥，客户端用公钥解析证书中的数字签名，可以验证服务器的身份。
3、Server Hello Done表示hello 流程结束。
4、客户端生成一个对称加密密钥，用于实际数据的加密传输，并用服务器的公钥加密，把对生成的密钥传递给服务器。同时携带一个用刚刚生成的加密密钥加密的“client finished”。
5、服务器收到对称加密密钥，并尝试用该密钥解密加密字段，如能得到明文“client finished”，认为该密钥有效，可以用于之后的数据加密传输。同时用该密钥加密“server finished”，传递给客户端。
6、客户端用对称机密密钥解密，如能得到明文“server finished”，客户端认为该服务器已经正确的接收到对称密钥。
7、加密数据传输开始。
虚线部分是服务器端要求验证客户身份。
在https中通过非对称加密（ras最为常见）传输秘钥（后面需对内容进行加、解密的对称会话秘钥（MD5或者SHA）和算法）。其实真正对通信内容进行加密的是对称加密，因为速度快，ras只是利用非对称密钥算法保证密钥本身的安全。
在浏览器与无服务器之间的通信，有的并没有加密而只是进行签名（例如快付通，商户把公钥给到kft，自己保留私钥；kft把自己公钥给商户，自己保留私钥；双方在自己发起请求时都是用自己的私钥签名，对方接受后用对方的公钥验签）。只签名不加密的话如果别人截取到请求，能看到未加密的内容，但是签名的字符串却破解不了（是用请求方的私钥签名的）就算把前面的内容篡改，在接收方公钥验签不通过。有的会在请求已签名的基础上再用公钥加密，来确保只能是正确的服务端能解密内容（因为是用服务端的公钥加密，只能由端午端的私钥解密，这样别人破解不了）这样更安全。
SSL身份认证原理： http://iluoxuan.iteye.com/blog/1736275
今天是学习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机构去认证一下得到了一份数字证书，然后在将这份数字证书配置到该网站上面即可。