OpenSSL证书认证过程
游戏服务端这块，之前是很少用SSL的，毕竟游戏里的数据没有什么保密的必要，登录、充值也是传输签名，不涉及密码什么的。不过这几年，HTTPS普及得比较快，H5游戏发展迅速。H5游戏是基于web的，和后端通信一般走websocket，加不加SSL其实对于游戏影响不大。但是不少平台都要求加SSL的，一是用户通过浏览器玩游戏时，地址栏里有个锁头体验还是好点，二是丧心病狂的黑产会劫持链接加上广告，想象一下在玩游戏时，右下角弹个广告是啥体验。

虽说用上SSL，不过并不一定就要自己实现SSL，比如用Nginx做一层代理，在Nginx处理SSL，在游戏服务器处理逻辑。不过最近有时间，还是研究下SSL。这里不涉及如何用OpenSSL实现一个SSL链接，网上的例子已经太多。而是研究下证书的认证，即

浏览器地址栏里的这个锁头是怎么来的？它怎么判断当前连接是安全？

这里以OpenSSL为例，简单说下SSL的的建立过程。普通的socket通过accept/connect来建立连接，然后用SSL_set_fd把socket和OpenSSL关联起来，接着调用SSL_do_handshake来进行SSL握手，握手成功后，就可以通过SSL_read/SSL_write来进行加密的数据通信。

那证书的认证在哪里处理？证书认证属于SSL握手（SSL_do_handshake）的一部分，SSL连接分为二种：

单向认证
客户端认证服务端，服务端不认证客户端，这时服务端需要一个证书，客户端不需要。网站的HTTPS认证通常属于这一类，即网站的内容是公开的，它并不在意谁来访问这些内容，因此无需校验客户端。但对客户端而言，它要保证所访问的网站是正确的网站，而不是被劫持修改、假冒的钓鱼网站，因此需要校验服务端。

双向认证
客户端认证服务端，服务端也需要认证客户端，这时候服务端和客户端都需要有证书。假如一个员工下班后，需要在家登录公司的内部管理系统，那这时候，服务端需要确认登录的用户属于自己公司的员工，就需要校验客户端。

PS： 测试了下，不存在双方都不需要证书的SSL连接。

现在使用的证书一般是x509标准证书。可以用openssl s_client -servername cnblogs.com -connect cnblogs.com:443 </dev/null 2>/dev/null | openssl x509 -text来查看证书的内容，一般包括以下内容：

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0d:2e:94:94:ec:65:e6:e6:4a:a7:a9:4d:1b:bf:8d:e4
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL RSA CA 2018
Validity
Not Before: Mar 6 00:00:00 2020 GMT
Not After : Mar 6 12:00:00 2021 GMT
Subject: CN = *.cnblogs.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:bd:39:42:6b:62:fc:e7:24:3d:23:f9:1a:db:c4:
d1:4e:bc:8c:d4:b6:71:54:11:b1:24:d4:0f:a1:fe:
1e:8d:a8:cb:81:fb:72:e7:fe:2c:c1:40:1d:1b:4c:
96:f3:28:3c:cf:ba:20:3c:d7:6d:d6:18:bf:7f:a9:
f8:3e:6a:a6:50:46:b1:1a:36:b7:81:6f:b8:81:f0:
6a:64:77:20:05:6e:7c:5a:17:6b:4f:f5:0d:f5:59:
3c:93:7c:50:22:95:a0:4a:3c:43:63:f2:28:81:a2:
4e:e1:41:7e:6c:c9:c7:9b:56:72:1a:ce:6c:b5:78:
f9:0f:62:14:9e:38:e4:f4:4e:e7:40:dc