在密码学和计算机安全领域中，根证书是未被签名的公钥证书或自签名的证书。
一、HTTPS和根证书到底有什么用？
第一步：浏览器与某宝建立TCP连接
第二步：服务器会弹出一个页面提醒安装数字证书，如果不安装，接下来一切都不会顺利进行
第三步：浏览器需要认证某宝是真实的服务器（不是山寨的），服务器发来了自己的数字证书。
插一句：某宝的数字证书从哪里来？
某宝自己的认证中心简称CA（CertificateAuthority），CA给某宝颁发了一个证书，这个证书有：
签发者
证书用途
某宝的公钥
某宝的加密算法
某宝用的HASH算法
设想一下，如果不加密那个HASH，任何人都可以先篡改证书，然后再计算HASH，附在证书的后面，传给某宝时，某宝无法发现是否有人篡改过。而用CA私钥加密后，就生成了类似人体指纹的签名，任何篡改证书的尝试，都会被数字签名发现。
第四步：浏览器接到某宝的数字证书，从第二步得到的CA公钥值，可以解密数字证书末尾的数字签名（CA私钥加密，可以用CA公钥解密，此为非对称加密），得到原始的HASHs
然后自己也按照证书的HASH算法，自己也计算一个HASHc，如果HASHc==HASHs，则认证通过，否则认证失败。假设认证成功，否则故事无法编下去了…
第五步：双方会运行DiffieHellman算法，简称DH算法。通俗地说：双方会协商一个master-key，这个master-key不会在网络上传输、交换，它们独立计算出来的，其值是相同的，只有它们自己双方知道，任何第三方不会知道，俗称的天不知，地不知，你知，我知。
然后以master-key推导出session-key，用于双方SSL数据流的加密/解密，采用对称加密，保证数据不被偷窥，加密算法一般用AES。
以master-key推导出hash-key，用于数据完整性检查（IntegrityCheckVerification）的加密密钥，HASH算法一般有：MD5、SHA，通俗滴说，保证数据不被篡改。
第六步：然后就可以正常发送订单了，用HASHkey生成一个MAC（MessageAuthenticationCode），附在HTTP报文的后面，然后用sessionkey加密所有数据（HTTP+MAC），然后发送出去
第七步：服务器先用sessionkey解密数据，得到HTTP+MAC，然后自己用相同的算法计算自己的MAC，如果两个MAC相等，则数据没有被篡改。
第八步：所有购物安全无误地完成……
二、根证书的具体组成
从技术上讲，证书其实包含三部分，用户的信息，用户的公钥，还有CA中心对该证书里面的信息的签名。验证一份证书的真伪（即验证CA中心对该证书信息的签名是否有效），需要用CA中心的公钥验证，而CA中心的公钥存在于对这份证书进行签名的证书内，故需要下载该证书，但使用该证书验证又需先验证该证书本身的真伪，故又要用签发该证书的证书来验证，这样一来就构成一条证书链的关系，这条证书链在哪里终结呢？答案就是根证书，根证书是一份特殊的证书，它的签发者是它本身，下载根证书就表明您对该根证书以下所签发的证书都表示信任，而技术上则是建立起一个验证证书信息的链条，证书的验证追溯至根证书即为结束。所以说用户在使用自己的数字证书之前必须先下载根证书。
数字证书（CertificateAuthority）
数字证书简称CA，它由权威机构给某网站颁发的一种认可凭证，这个凭证是被大家（浏览器）所认可的，为什么需要用数字证书呢，难道有了数字签名还不够安全吗？有这样一种情况，就是浏览器无法确定所有的真实服务器是不是真的是真实的，举一个简单的例子：A厂家给你们家安装锁，同时把钥匙也交给你，只要钥匙能打开锁，你就可以确定钥匙和锁是配对的，如果有人把钥匙换了或者把锁换了，你是打不开门的，你就知道肯定被窃取了，但是如果有人把锁和钥匙替换成另一套表面看起来差不多的，但质量差很多的，虽然钥匙和锁配套，但是你却不能确定这是否真的是A厂家给你的，那么这时候，你可以找质检部门来检验一下，这套锁是不是真的来自于A厂家，质检部门是权威机构，他说的话是可以被公众认可的。
同样的，因为如果有人（张三）用自己的公钥把真实服务器发送给浏览器的公钥替换了，于是张三用自己的私钥执行相同的步骤对文本Hash、数字签名，最后得到的结果都没什么问题，但事实上浏览器看到的东西却不是真实服务器给的，而是被张三从里到外（公钥到私钥）换了一通。那么如何保证你现在使用的公钥就是真实服务器发给你的呢？我们就用数字证书来解决这个问题。数字证书一般由数字证书认证机构（CertificateAuthority）颁发，证书里面包含了真实服务器的公钥和网站的一些其他信息，数字证书机构用自己的私钥加密后发给浏览器，浏览器使用数字证书机构的公钥解密后得到真实服务器的公钥。这个过程是建立在被大家所认可的证书机构之上得到的公钥，所以这是一种安全的方式。