https通过根证书公钥解密摘要信息，然后和证书信息做hash后的值做了对比，从而判断证书的真伪。这里为什么不能直接省掉做hash的过程，直接对整个证书内容进行CA私钥加密，如果客户端用根证书中的公钥能解密则证书是真的，当然这里的能解密不是严格意义上的能解密，而是解密后的格式和正常格式一致，就认为能解密。而不能解密则认为证书是假的。
我自己的猜测：
1.数字证书需要找到这个证书的颁发者来验证证书真假，意味着颁发者一定是不能加密传输的，所以造成证书一部分加密，一部分非加密。很不整齐，虽然现在也是一部分加密，一部分非加密，但是加密部分仅是摘要信息，除摘要信息外部分是没有加密的。
2.如果整个证书加密，那客户端解密时根本不确定这个证书是真还是假，相比较对hash解密而言，对整个证书解密效率肯定会差很多。
3.如果整个证书加密，意味者证书发送到客户端，客户端完全不发看到证书的任何信息，除证书的颁发者。对维护、问题定位造成很大困难。
4.如果证书恰巧被篡改，而且篡改完的用户名和用户公钥随便通过一个私钥加密后传给客户端，客户端此时拿着本地CA公钥解密恰好解密出一个和正常公钥用户信息格式一样的数据，会骗过所有认证。客户端误认为这个证书是真的。虽然这种情况发生后，客户端拿到的公钥一定是不正确的（因为被篡改的证书不是通过CA私钥加密的），但客户端依然会用这样的一个错误公钥加密信息传递数据。这样的数据即无法被服务器解析也无法被篡改者解析，直接造成了https不可用。
hash是为了防止传输过程中被篡改，你公钥能解只能说明是这个私钥加密的，但是内容是否正确，要用解密后hash比较来验证
http://blog.csdn.net/u013401853/article/details/52781072
可以了解一下非对称加密算法，私钥加密信息的长度是有限制的。比如RSA算法，每次加密的字节数，不能超过密钥的长度值减去11，1024位的私钥，只能最多加密1013位的信息，如果证书的内容长度超过这个长度，就会加密失败。这才是需要hash的本质原因。当然，加密长度越短的信息，速度越快，这也是事实。hash碰撞就不用考虑了，如果有那么大计算能力，差不多可以破解私钥了。