Hi,
证书用途一般是两个，1。server/client identity authentication, 证书里包含了代表的server name，可以通过SAN和CN （common name，虽然CN要被淘汰了）来验证连接的服务器（或者客户端) 是否代表目标host；证书需要形成证书验证链来验证证书的合法性；证书需要时时更新，过期证书作废。2 提供公钥，以便对方验证 TLS session handshake negotiation时对握手消息的签名，或者如你所说加密通信密钥（其实是一般叫pre-master key, 因为master key还是从pre-master key和握手双方互发几个随机数导出的）。具体握手过程可以看RFC和一些讲TLS的书，这里就不详细说了，值得注意说通信密钥用公钥加密传输的那种方式太古老，已经渐渐退出历史舞台。其依赖服务器的RSA私钥，不如DH(Diffie-Hellman)握手得到的秘钥安全， TLS1.3将完全弃用。
验证证书通常就是是验证第一个用途，比如证书过期了，比如证书链对不上，都是会使TLS握手失败， 证书验证默认关闭我觉得是nginx不够负责。关闭了验证，证书就是一个提供公钥的工具，TLS session negotiation照常能够进行。由于证书要保持更新，所以不适合静态测试使用，也许这也是为什么默认关闭的原因，如你所说，随便生成一个证书就行，测试相当简单。
On Tuesday, December 15, 2015 at 10:50:34 PM UTC-8, Paul Von wrote:
那backend证书的作用是啥呢？
nginx用backend证书里的公钥加密nginx下的随机
数（随机数用作ssl通信密钥）用？还是？
On Wednesday, December 16, 2015 at 1:51:54 PM UTC+8, agentzh wrote:Hello!
2015-12-15 19:03 GMT-08:00 Paul Von:
>
> 对于SSL_do_handshake，是openssl库的API，我gdb跟踪的时候会断掉？有没有弄过的？谢谢了
你的 openssl 库没有安装对应的调试符号吧？比如在 centos 上面应该安装 openssl-debuginfo 包。
> 还有proxy_pass https会是标准的ssl握手么，
当然是标准的。
> 我抓包的时候看到了client hello， server hello，server
> certificate，client key exchange，change cipher
> spec等包，但是我backend的https服务器配置的证书为随便的错误的证书（故意的），但是从抓包的情况看，proxy_pass
> https还是ssl加密的
ngx_proxy 模块默认并不验证后端服务器的证书的合法性（应当是出于性能方面的考虑）。你可以强制配置它进行后端证书的验证，见
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_verify
Regards,
-agentzh
