客户端和服务器不支持一般ssl协议或加密套件

客户端和服务器确实不支持一般ssl协议或加密套件。

HTTPS作为站点安全的最佳实践之一，已经得到了最广泛的支持。然而在实际生产过程中，由TLS/SSL握手失败引起的连接异常问题依然十分常见。

HTTPS的主要作用是在不安全的网络上创建一个基于TLS/SSL协议安全信道，对窃听和中间人攻击提供一定程度的合理防护。解决方案：

1、更换其他CA机构签发的证书，保证其CA根证书的在特定设备上已默认信任。

2、手动在受影响的设备上安装该CA根证书及中间证书，并配置为信任状态。

3、客户端App预置该CA根证书，并通过客户端代码配置信任该证书。

ssl协议支持哪几个加密算法：

1、RSA

RSA作为一种国际通用算法，是建立在大整数因子分解的假设基础上的。假定没有整数分解的有效算法，则认为RSA密文的完全解密是不可行的。用户创建并发布RSA的两个大质数的乘积和作为其公钥的次要值。关键要素必须保密。每个人都可以使用公钥加密信息，但是只有理解关键要素的人才能对信息进行解码。现在基本每款SSL证书都支持RSA算法。

2、ECC

ECC算法于2004年投入使用，ECC算法是在有限域上，椭圆曲线密码学依赖于椭圆曲线的代数结构。假定发现随机椭圆曲线元素与公知基点有关的离散对数是不现实的。与RSA算法相比，ECC算法的优势在于密钥较小，提高了速度和安全性。不利之处是，并非所有服务和应用程序都能与基于ECC的SSL证书进行互操作。

ECC算法成为了新一代算法趋势主流，加密速度更快，效率更高，更安全，抗攻击性更强，但在兼容性上不及RSA广泛。

您的问题是：

“客户端和服务器不支持常用的 SSL 协议版本或加密套件。导致此问题的原因通常是服务器要求使用 SSLv3服务器加密

别的网站都可以正常打开 想打开这样的网站需要怎么设置  工具  Internet 高级 安全 里面 SSL1 SSL2点对号 也不行 原理的少说 结果我能打开网站就好”

回答：

你好，这是chrome内核的浏览器的实验性功能设置不正确导致的。

下面附上完美解决方案。请按以下步骤进行操作。

在地址栏输入并访问 chrome://flags

开启页面后,按热键“Ctrl+F”打开页面内搜索框。

在搜索框中键入“ssl"并找到类似如下内容——

"Minimum SSL/TLS version supported. Mac, Windows, Linux, Chrome OS,..."

在下拉选择列表中选中SSLv3，如下图：

（注意选择启用,我是将该功能停用了的，所以状态是“已停用”）

保存并立即重启浏览器后生效。

示例

由于个人手误，导致步骤1这行的出了一个输入拼写错误，现已纠正。

感谢用户@sirius_huang在评论中指出。

解释: Hypertext Transfer Protocal, 超文本传输协议，属于TCP/IP第五层、OSI第七层协议栈。是B/S架构应用体系中应用最广的协议。

用法：在要访问的URL或URI前，加http://即可。

优点：规则统一，便于使用，消耗较小。

缺点：明文传输，很容易被中间人拦截（窃听、篡改、冒充），不安全。

默认端口：80

解释：Secure HTTP，即HTTP + 安全套件（SSL、TLS、Cert等）

用法：需要在访问的URL或URI前，加https://即可。（前提是该网站已加过安全套件）

优点：规则统一，便于使用，且由于对信息加密，安全性较高。

缺点：消耗较大，需要管理安全套件

默认端口：443

解释：SSL(Secure Sockets Layer), TLS(Transport Layer Security), 均为安全套件， TLS用于替代SSL。

作用：

所有信息加密传播，第三方无法窃听

完整性校验机制，因此无法篡改传输内容

对身份进行验证，防止冒充

优点：安全

缺点：消耗大，需要维护

最常用：TLS1.1 TLS1.2

第一次握手：客户端发SYNbit包，指明客户端要访问的端口；并发出初始序列号X；然后客户端进入SYN_SENT状态。

第二次握手：服务器发ACK包应答，即SYNbit和ACKbit均为1；ACK应答设置为x+1；Seq为y ；然后服务器进入SYN_RCVD状态。

第三次握手：客户端发ACK包确认收到，故ACKbit为1，ACKnum为y+1，进入Establish状态；服务器收到这个包后，也进入Establish状态，TCP连接建立。

第一次挥手：客户端发送离线请求，即FINbit=1；表明自己不会主动发数据了，但是可以收数据；然后客户端进入FIN_WAIT_1状态。

第二次挥手：服务器收到此请求并回复，即ACKbit=1，ACKnum=x+1表明自己已接收断开连接的请求，但是尚未准备好关闭连接；然后服务器进入CLOSE_WAIT状态。客户端收到此确认包之后，进入FIN_WAIT_2状态。

第三次握手：服务器做好关闭连接的准备，并发送断开连接的请求，故ACKbit=1, seq=y；然后服务器进入LAST_ACK状态。

第四次握手：客户端收到此请求后发送确认包，进入TIMED_WAIT状态；服务器收到断开连接的确认包后，断开连接，并进入CLOSED阶段。客户端在2个最大生命周期内未收到回复时，会断开与服务器的连接，并将状态置于CLOSED。

由于HTTPS是基于HTTP的，只是加了一步认证的过程。所以此处只讲加密这一部分。

对于HTTPS的加密，TLS使用的是公私钥+证书的方式。

具体的图示如下：

第一次握手：客户端向服务器发送ClientHello请求。

可提供以下信息：

1) 支持的协议版本，例如TLS1.0

2) 一个客户端生成的随机数，稍后用于生成"对话密钥"。

3) 支持的加密方法，比如RSA公钥加密。

4) 支持的压缩方法。

第二次握手：服务器回应客户端的请求。

可提供以下信息：

1) 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。

2) 一个服务器生成的随机数，稍后用于生成"对话密钥"。

3) 确认使用的加密方法，比如RSA公钥加密（包含在服务器证书里）。

4) 服务器证书。

第三次握手：客户端回应。如果证书有问题（不是可信任机构颁发、实际域名不一致、证书过期等），就会报出一个警告来；如果证书没问题，就会提供以下信息给服务器：

1) 一个随机数。该随机数用服务器公钥加密，防止被窃听。

2) 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

3) 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

上面三次握手有三个随机数，可用来生成本次连接的会话密钥。

第四次握手：服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。

1) 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

2) 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，TLS的加密完成。之后的通讯采用HTTP方式进行，只不过明文都需要被加密。

---