简单记录一下 ESXi 主机更换 HTTPS 证书的方法：
# castore 用处尚未查证，不建议修改 /etc/vmware/ssl/castore.pem # crt 使用 nginx 格式，将证书和中间证书合并在一个文件里 /etc/vmware/ssl/rui.crt /etc/vmware/ssl/rui.key services.sh restart
因为不建议开启 SSH 服务，所以不推荐远程更换的方法。
SSL
Nginx 诡异 SSL_PROTOCOL_ERROR 问题排查
这两天在检查一台 Nginx 配置的时候，遇到了一个极端诡异的问题。一段很通用的配置，配在这个服务器上，就会 100% 导致 Chrome 报 ERR_SSL_PROTOCOL_ERROR 。但是这段配置非常的通用，是用 Mozilla 提供的工具生成的。
而且在 iPhone 的 Safari 上访问又是完全正常的，服务器日志也看不到任何错误。看到的请求相应码也是完全正确的 200 。
先贴出配置：
# https://mozilla.github.io/server-side-tls/ssl-config-generator/
listen 443 ssl http2;
# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
# modern configuration. tweak to your needs.
ssl_protocols TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_prefer_server_ciphers on;
可以看到是在 Mozilla 网站上选择 和 Modern 生成出来的配置。
在测试过程中，排查了各种问题，包括但不限于 SSL 证书问题，HTTP Basic Auth 问题，http2 问题等等，然而都没有解决这个现象。
一次偶然的尝试，发现只要注释掉我给这个 server 特殊配置的这段逻辑，使用服务器通用的 ssl.ngx 文件中的 SSL 配置，就不会出现问题。于是开始先使用 ssl.ngx 文件中的配置，然后逐行替换，来查找具体出现问题的配置。
终于，当我将配置中的这行加上时，问题出现了：
ssl_session_tickets off;
于是以这个配置作为关键字搜索，找到了这么一篇文章：
https://community.letsencrypt.org/t/errors-from-browsers-with-ssl-session-tickets-off-nginx/18124/5
I’m posting this here both because this question was recently asked and because it took me many hours of troubleshooting to figure out the issue as while I found several references to the problem on Google, no one seemed to have a real solution. So here it is:
ssl_session_tokens off breaks if it’s not set the same for all ssl-enabled server{} blocks. So if you have 2 server configurations and and you have ssl_server_tokens set to on in one (which is the default so it counts even if you omit it) and set to off in another, it will break the one where it’s set to off in certain browsers. The easiest way to resolve this, unless you have multiple http{} blocks, is to just set it to off in the http{} block. I have not tested to see if you you can have different settings in different http{} blocks as I haven’t had need to set up more than one http{} block.
For others looking for this issue, I want to add that Chrome will respond with: ERR_SSL_PROTOCOL_ERROR while Firefox responds with: SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET and curl responds with: gnutls_handshake() failed: An unexpected TLS packet was received. IE seemed to work, surprisingly.
简单翻译一下，这里是说，如果你的 nginx 开了多个 https 的 server，其中某些 server 没有配置 ssl_server_tokens off; ，而有些 server 配置了这个选项，那么就会导致没有手动 off 的 server 采用默认值 on，而手动 off 掉的 server 采用 off。这种情况会导致 nginx 和浏览器之间的握手出现问题，从而导致 Chrome 报出 ERR_SSL_PROTOCOL_ERROR ，FireFox 则会报出 SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET 。
那么解决方法也很简单，只要在所有的 server 块统一这个配置就好了。要么都设置为 on，要么都设置为 off，问题解决。目前没有尝试多个 http 块隔离两个 server，建议还是将这个配置统一一下。
Nginx 配置 ECC RSA 双证书
Config Nginx for parallel ECC and RSA Certificate
先决条件
Nginx 1.11.0 以上
OpenSSL 1.0.2 以上
申请证书
首先申请 ECC 证书，这个不多说，很多方法都可以，大部分 CA 现在也都可以签署。生成 CSR 的命令是：
openssl ecparam -out 证书名.key -name prime256v1 -genkey && openssl req -new -key 证书名.key -nodes -out 证书名.csr
拿到证书之后，还是像之前一样将中级 CA 拼接在证书后面，得到给 Nginx 使用的 domain-cert.crt
配置 Nginx
首先是将两个证书链都加入 Nginx 的配置文件：
ssl_certificate example.com.rsa.crt; ssl_certificate_key example.com.rsa.key; ssl_certificate example.com.ecdsa.crt; ssl_certificate_key example.com.ecdsa.key;
如果要使用 CT 的话有两种方法：
1. 将两个证书的 CT 信息放到同一目录，并做如下设置：
ssl_ct on; ssl_ct_static_scts /path/to/sct/dir;
这样 Nginx CT 模块会自动在这个目录下查找相应证书的 CT 信息并发送
2. 可以单独配置每个证书的 CT 文件：
ssl_ct on; ssl_certificate example.com.rsa.crt; ssl_certificate_key example.com.rsa.key; ssl_ct_static_scts xample.com.rsa.scts; ssl_certificate example.com.ecdsa.crt; ssl_certificate_key example.com.ecdsa.key; ssl_ct_static_scts example.com.ecdsa.scts;
然后问题来了。很多盆友这么配置之后可能发现用 Chrome 之类的明明支持 ECC 的浏览器却并没有用 ECC 证书。这是为什么呢？
问题就出在 ssl_ciphers 这个配置项上面。
如果我们用各种网上推荐的配置，需要注意顺序问题。以 Cloud Flare 的配置为例：
#https://github.com/cloudflare/sslconfig/blob/master/conf ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5; ssl_prefer_server_ciphers on;
注意到这里面的算法都是优先使用 RSA 的，所以服务器和浏览器协商出来的一定是 RSA ，这就导致 Nginx 会自动发送 RSA 证书链给浏览器。
这里可以用 openssl 验证一下：
# openssl ciphers -V 'EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5' | column -t 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 0xC0,0x09 - ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x3C - AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 0xC0,0x0A - ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x3D - AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 0xC0,0x12 - ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 0xC0,0x08 - ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1 0x00,0x0A - DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
会看到第一个选择就是使用 RSA，而不是椭圆曲线 ECDSA。
再来验证一下 Mozilla 给出的配置：
# openssl ciphers -V 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS' | column -t 0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 0xC0,0x09 - ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 0xC0,0x0A - ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 0x00,0x33 - DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x39 - DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 0xC0,0x08 - ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1 0xC0,0x12 - ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 0x00,0x16 - EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x3C - AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 0x00,0x3D - AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x0A - DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
在这份配置中可以看到，每种套件中使用椭圆曲线部分都被排在了 RSA 前面，所以能尽量协商出支持椭圆曲线的算法。
或者我们还可以更激进一些：
# openssl ciphers -V 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK' | column -t 0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 0xC0,0x09 - ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 0xC0,0x0A - ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0xA2 - DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD 0x00,0xA3 - DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD 0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 0x00,0x33 - DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 0x00,0x40 - DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256 0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x38 - DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 0x00,0x39 - DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x3C - AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 0x00,0x3D - AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x6A - DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256 0xC0,0x32 - ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD 0xC0,0x2E - ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD 0xC0,0x2A - ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 0xC0,0x26 - ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 0xC0,0x0F - ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1 0xC0,0x05 - ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1 0x00,0x32 - DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 0xC0,0x31 - ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD 0xC0,0x2D - ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD 0xC0,0x29 - ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256 0xC0,0x25 - ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 0xC0,0x0E - ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1 0xC0,0x04 - ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1 0x00,0x88 - DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 0x00,0x87 - DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 0x00,0x84 - CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 0x00,0x45 - DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 0x00,0x44 - DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1 0x00,0x41 - CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
可以看到在这份配置中，我几乎将所有的支持椭圆曲线的套件都提到了最前面，来加大协商出支持椭圆曲线算法的套件的可能性。
综上，推荐的配置如下：
ssl_ciphers 'EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:!MD5'; ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS'; ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
三者任选其一即可。
参考：
https://imququ.com/post/ecc-certificate.html
https://www.zeroling.com/nginx-kai-qi-https-shuang-zheng-shu-zhi-nan/
https://n4l.pw/nginx-dual-certificates.html
https://imququ.com/post/certificate-transparency.html
https://seryo.net/use-ecc-algorithms-issued-a-certificate-request-file.Seryo
常用 openssl 命令
The Most Common OpenSSL Commands
One of the most versatile SSL tools is OpenSSL which is an open source implementation of the SSL protocol. There are versions of OpenSSL for nearly every platform, including Windows, Linux, and Mac OS X. OpenSSL is commonly used to create the CSR and private key for many different platforms, including Apache. However, it also has hundreds of different functions that allow you to view the details of a CSR or certificate, compare an MD5 hash of the certificate and private key (to make sure they match), verify that a certificate is installed properly on any website, and convert the certificate to a different format. A compiled version of OpenSSL for Windows can be found here.
If you don’t want to bother with OpenSSL, you can do many of the same things with our SSL Certificate Tools. Below, we have listed the most common OpenSSL commands and their usage:
General OpenSSL Commands
These commands allow you to generate CSRs, Certificates, Private Keys and do other miscellaneous tasks.
- Generate a new private key and Certificate Signing Request
openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key
- Generate a self-signed certificate (see How to Create and Install an Apache Self Signed Certificate for more info)
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt
- Generate a certificate signing request (CSR) for an existing private key
openssl req -out CSR.csr -key privateKey.key -new
- Generate a certificate signing request based on an existing certificate
openssl x509 -x509toreq -in certificate.crt -out CSR.csr -signkey privateKey.key
- Remove a passphrase from a private key
openssl rsa -in privateKey.pem -out newPrivateKey.pem
Checking Using OpenSSL
If you need to check the information within a Certificate, CSR or Private Key, use these commands. You can also check CSRs and check certificates using our online tools.
- Check a Certificate Signing Request (CSR)
openssl req -text -noout -verify -in CSR.csr
- Check a private key
openssl rsa -in privateKey.key -check
- Check a certificate
openssl x509 -in certificate.crt -text -noout
- Check a PKCS#12 file (.pfx or .p12)
openssl pkcs12 -info -in keyStore.p12
Debugging Using OpenSSL
If you are receiving an error that the private doesn’t match the certificate or that a certificate that you installed to a site is not trusted, try one of these commands. If you are trying to verify that an SSL certificate is installed correctly, be sure to check out the SSL Checker.
- Check an MD5 hash of the public key to ensure that it matches with what is in a CSR or private key
openssl x509 -noout -modulus -in certificate.crt | openssl md5 openssl rsa -noout -modulus -in privateKey.key | openssl md5 openssl req -noout -modulus -in CSR.csr | openssl md5
- Check an SSL connection. All the certificates (including Intermediates) should be displayed
openssl s_client -connect www.paypal.com:443
Converting Using OpenSSL
These commands allow you to convert certificates and keys to different formats to make them compatible with specific types of servers or software. For example, you can convert a normal PEM file that would work with Apache to a PFX (PKCS#12) file and use it with Tomcat or IIS. Use our SSL Converter to convert certificates without messing with OpenSSL.
- Convert a DER file (.crt .cer .der) to PEM
openssl x509 -inform der -in certificate.cer -out certificate.pem
- Convert a PEM file to DER
openssl x509 -outform der -in certificate.pem -out certificate.der
- Convert a PKCS#12 file (.pfx .p12) containing a private key and certificates to PEM
openssl pkcs12 -in keyStore.pfx -out keyStore.pem -nodes
You can add -nocerts to only output the private key or add -nokeys to only output the certificates.
- Convert a PEM certificate file and a private key to PKCS#12 (.pfx .p12)
openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt
Originally posted on Sun Jan 13, 2008
https://www.sslshopper.com/article-most-common-openssl-commands.html
使用 Nginx 反代 Apache 安装 WordPress
最近由于原先博客主机极度不稳定，所以准备了很久，准备进行主机迁移。由于迁移前的环境和迁移后还是有较大的区别，整体架构也不太一样，所以在这里说说迁移过程中遇到的问题。
环境对比
| 原主机 | 新主机 | |
| 操作系统 | CentOS 6 | CentOS 7 |
| Web 服务器 | Apache 2.2 | Openresty 1.9.7 + Apache 2.4 |
| PHP 版本 | 5.5 | 5.6 |
| 其他 | SELinux |
SELinux
很多人为了省事，在拿到主机的第一时间就直接禁用了 SELinux。不过在学习了一段时间之后，我发现其实 SELinux 是一个很好的保护机器的手段。
这里简单列举几个需要注意的 SELinux 的配置：
httpd_can_network_connect_db boolean 类型，控制 Apache 是否可以连接 DB http_port_t port 类型，控制 Apache 可以监听的端口 mysqld_port_t port 类型，控制 mysql 可以监听的端口和 Apache 可以连接的 DB 端口
由于我是将 Apache 作为只解析后端 PHP 请求使用，所以需要修改 http_port_t 加入我需要的端口。添加方法类似于：
semanage port -a -t http_port_t -p tcp 8090
另外由于我没有在本机安装 Mysql 而是使用的远程 Mysql 实例，并且开放的端口并不是标准的 3306，所以需要将端口号添加到 mysqld_port_t 中。
Apache
这玩意是主要的坑所在。下面来一一列举。
配置格式变更
Apache 2.2 和 2.4 的配置文件区别还是比较大的，加了很多新的参数，同时修改了很多配置的方法。最明显的是：
Options -Indexes Allow from all Deny from all
这三条配置已经完全被改掉了。如果在配置中出现第一种，会直接起不来。后面的 Allow Deny 的写法虽然不会有问题，但是已经不是官方推荐的了，建议改掉。
配置无效
在配置 Apache 2.4 的 Log Format 的时候，我发现了一个很蛋疼的问题，就是 CentOS yum 安装的版本（2.4.6）有些配置是使用不了的。如：
http://httpd.apache.org/docs/2.4/mod/mod_log_config.html
这个文档中的：
%{UNIT}T The time taken to serve the request, in a time unit given by UNIT. Valid units are ms for milliseconds, us for microseconds, and s for seconds. Using s gives the same result as %T without any format; using us gives the same result as %D. Combining %T with a unit is available in 2.4.13 and later.
很多参数都有类似的标注（available in 2.4.13 and later），告诉你在旧版本中不能使用。如果不仔细看的话很容易忽略。所以配置之前一定要仔细阅读。
HTTPS
WordPress
由于我的博客是全站 HTTPS 的，因此在 WordPress 上我是有做一些强制 HTTPS 的措施。但是！由于 WordPress 默认的检测 HTTPS 的方法是这样的：
/**
* Determine if SSL is used.
*
* @since 2.6.0
*
* @return bool True if SSL, false if not used.
*/
function is_ssl() {
if ( isset($_SERVER['HTTPS']) ) {
if ( 'on' == strtolower($_SERVER['HTTPS']) )
return true;
if ( '1' == $_SERVER['HTTPS'] )
return true;
} elseif ( isset($_SERVER['SERVER_PORT']) && ( '443' == $_SERVER['SERVER_PORT'] ) ) {
return true;
}
return false;
}
而我的 HTTPS 是在 Nginx 层做的，所以导致这两个条件均不满足，因此会遇到重定向循环（Redirect Loop）的问题。解决方法有两种：
修改 wp-config.php 文件：
if ( isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && ( 'https' == $_SERVER['HTTP_X_FORWARDED_PROTO'] ) ) {
$_SERVER['HTTPS'] = 'on';
}
这里的修改需要配合修改 Nginx 的 Proxy 设置，增加下面这行：
proxy_set_header X-Request-Protocol $scheme; #http or https
修改 wp-includes/functions.php 文件（4025行左右）：
找到上面说的那段代码，将其替换为：
/**
* Determine if SSL is used.
*
* @since 2.6.0
*
* @return bool True if SSL, false if not used.
*/
function is_ssl() {
if ( isset($_SERVER['HTTPS']) ) {
if ( 'on' == strtolower($_SERVER['HTTPS']) )
return true;
if ( '1' == $_SERVER['HTTPS'] )
return true;
} elseif ( isset($_SERVER['SERVER_PORT']) && ( '443' == $_SERVER['SERVER_PORT'] ) ) {
return true;
} elseif ( isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && ( 'https' == $_SERVER['HTTP_X_FORWARDED_PROTO'] ) ) {
return true;
}
return false;
}
同时这个修改方法也要配合修改 Nginx 的 Proxy 设置。
注意，虽然可以不做判断直接无脑 $_SERVER[‘HTTPS’] = ‘on’; 或者在那个 is_ssl() 方法中无脑返回 true，但是不建议这样修改。因为这样可能会导致安全上面的问题。
Apache .htaccess
由于我在某些目录中通过 .htaccess 的方式强制重定向了非 HTTPS 请求，因此在将 SSL 交给 Nginx 之后相关的跳转判断也要修改。原先的跳转逻辑是：
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*) https://%{SERVER_NAME}/$1 [L,R]
由于 %{HTTPS} 这个变量判断的是 Apache 传进来的内部参数，我们无法控制，所以需要将这段修改为：
RewriteEngine on
RewriteCond %{HTTP:X-Request-Protocol} ^http$
RewriteRule ^(.*) https://%{SERVER_NAME}/$1 [L,R]
这里判断的就是 Nginx 传进来的 X-Request-Protocol 头了。不过这种写法并不能在单独使用 Apache 作为 Web 服务器的时候使用，需要注意。
客户端证书
目前只针对某目录或文件的客户端证书配置还没有测试完成，将在后面更新。
SSL 双向认证的一个小问题
最近一直在研究 SSL 双向认证，工作中也经常用到。然后今天遇到了一个非常奇怪的问题，那就是就算配置了
ssl_verify_client optional_no_ca
客户端的访问仍然会失败，证书认证仍然不过。调试了半天，发现了两个问题，那就是：
1. optional_no_ca 并不会像 off 一样放过所有请求，而是对于提交了证书的请求，如果证书验证不过就会握手出错。
2. 对于下面这个配置项的设置存在错误：
ssl_verify_depth 1
经过查找资料，找到了这个选项相关的一些说明。（注：以下实验均在 Nginx 和 Apache2.2 上同时进行过）
The depth actually is the maximum number of intermediate certificate issuers, i.e. the number of CA certificates which are max allowed to be followed while verifying the client certificate. A depth of 0 means that self-signed client certificates are accepted only, the default depth of 1 means the client certificate can be self-signed or has to be signed by a CA which is directly known to the server (i.e. the CA’s certificate is under SSLCACertificatePath), etc.
也就是说，当 depth 设置为 1（Nginx 的默认值）的时候，服务端只会接受直接被 CA 签发的客户端证书或自签名的证书。
但是！这段话没说的是，当你放在 SSLCACertificatePath 的文件中的 CA 证书只有中级 CA 的时候，验证仍然是会不过的，看后台的报错会发现：（下面这个是 Apache 的日志，Nginx 的只有 “Error (2): unable to get issuer certificate” 一句）
[Wed Feb 24 04:19:39.975324 2016] [ssl:debug] [pid 13380] ssl_engine_kernel.c(1381): [client xx.xx.xx.xx:48806] AH02275: Certificate Verification, depth 1, CRL checking mode: none [subject: CN=IMM_CA,OU=ROOT,O=ROOT,ST=SH,C=CN / issuer: CN=ST,OU=UP,O=ROOT,ST=SH,C=CN / serial: 02 / notbefore: Jan 14 10:31:00 2013 GMT / notafter: Jan 14 10:31:00 2017 GMT] [Wed Feb 24 04:19:39.975409 2016] [ssl:info] [pid 13380] [client xx.xx.xx.xx:48806] AH02276: Certificate Verification: Error (2): unable to get issuer certificate [subject: CN=IMM_CA,OU=ROOT,O=ROOT,ST=SH,C=CN / issuer: CN=ROOT_CA,OU=ROOT,O=ROOT,ST=SH,C=CN / serial: 02 / notbefore: Jan 14 10:31:00 2013 GMT / notafter: Jan 14 10:31:00 2017 GMT]
也就是说，直接尝试使用中级 CA 来验证客户端是无法通过的，openssl 会自动的去找中级 CA 的签发者一层层验证上去，直到找到根。
所以，就算将 中级 CA 和 根 CA 都放在信任证书列表中，由于最终 depth 为 2 的缘故，验证还是过不了。
因此，在实际使用的时候，需要注意一下两点：
1. CA 文件中必须同时存在 中级 CA 和 根 CA，必须构成完整证书链，不能少任何一个；
2. 默认的验证深度 SslVerifyDepth ssl_verify_depth 是 1，也就是说只要是中级 CA 签发的客户端证书一律无法通过认证，需要增大该值。
同时还要注意 optional_no_ca 的问题，开了这个选项并不是会放过所有的请求，也会要求证书链完整才能通过。关于这一点个人比较奇怪，因为证书链完整了那就算开 require 应该也能通过了才对。。。
关于这一点做了一些尝试发现以下两种情况：
1. 如果 SSLCACertificateFile/ssl_trusted_certificate SSLCACertificatePath 这两个参数都不设置，那么 optional_no_ca 会放过所有有效的客户端证书（满足客户端证书的基本条件即可）；
2. 如果 SSLCACertificateFile/ssl_trusted_certificate SSLCACertificatePath 这两个参数设置了，但是客户端提交的证书并不是这里的 CA 签发的，也会验证成功
但是！如果 SSLCACertificateFile/ssl_trusted_certificate SSLCACertificatePath 这两个参数里设置的证书包括了中级 CA 证书，但是没有包括中级 CA 证书的完整证书链，那么就会报 Error (2): unable to get issuer certificate 错误，验证失败。
常用Openssl命令
申请证书
SSL常用于身份验证、数据加密等应用中，要使用SSL，我们密码有自己的证书。数字证书一般要向专业的认证公司(如VeriSign)申请，并且 都是收费的，某些情况下，我们只是想使用加密的数据通信，而不在乎认证，这时就可以自己制作一个证书，自己制作一个证书，有两种方式，一种是Self Signed,另一种是自己制作一个CA，然后由这个CA,来发布我们需要的证书。下面分别介绍这两个方法。
生成Self Signed证书
＃ 生成一个key，你的私钥,openssl会提示你输入一个密码，可以输入，也可以不输，
＃ 输入的话，以后每次使用这个key的时候都要输入密码，安全起见，还是应该有一个密码保护
> openssl genrsa -des3 -out selfsign.key 4096
# 使用上面生成的key，生成一个certificate signing request (CSR)
# 如果你的key有密码保护，openssl首先会询问你的密码，然后询问你一系列问题，
# 其中Common Name(CN)是最重要的，它代表你的证书要代表的目标，如果你为网站申请的证书，就要添你的域名。
> openssl req -new -key selfsign.key -out selfsign.csr
# 生成Self Signed证书 selfsign.crt就是我们生成的证书了
> openssl x509 -req -days 365 -in selfsign.csr -signkey selfsign.key -out selfsign.crt
＃ 另外一个比较简单的方法就是用下面的命令，一次生成key和证书
> openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt
生成自己的CA (Certificate Authority)
CA是证书的发布者，CA可以发布其他人的证书，把CA的证书加入系统信任的根证书后，由CA发布的证书也被系统所信任，所以，CA的key是必须小心保护的，一般都要加密保护，并且限制为root权限读写。
＃ 生成CA的key
> openssl genrsa -des3 -out ca.key 4096
# 生成CA的证书
> openssl req -new -x509 -days 365 -key ca.key -out ca.crt
# 生成我们的key和CSR这两步与上面Self Signed中是一样的
> openssl genrsa -des3 -out myserver.key 4096
> openssl req -new -key myserver.key -out myserver.csr
# 使用ca的证书和key，生成我们的证书
# 这里的set_serial指明了证书的序号，如果证书过期了(365天后)，
# 或者证书key泄漏了，需要重新发证的时候，就要加1
> openssl x509 -req -days 365 -in myserver.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out myserver.crt
查看证书
# 查看KEY信息
> openssl rsa -noout -text -in myserver.key
# 查看CSR信息
> openssl req -noout -text -in myserver.csr
# 查看证书信息
> openssl x509 -noout -text -in ca.crt
# 验证证书
# 会提示self signed
> openssl verify selfsign.crt
# 因为myserver.crt 是幅ca.crt发布的，所以会验证成功
> openssl verify -CAfile ca.crt myserver.crt
去掉key的密码保护
有时候每次都要输入密码太繁琐了,可以把Key的保护密码去掉
> openssl rsa -in myserver.key -out server.key.insecure
不同格式证书的转换
一般证书有三种格式：
- PEM(.pem) 前面命令生成的都是这种格式，
- DER(.cer .der) Windows 上常见
- PKCS#12文件(.pfx .p12) Mac上常见
# PEM转换为DER
> openssl x509 -outform der -in myserver.crt -out myserver.der
# DER转换为PEM
> openssl x509 -inform der -in myserver.cer -out myserver.pem
# PEM转换为PKCS
> openssl pkcs12 -export -out myserver.pfx -inkey myserver.key -in myserver.crt -certfile ca.crt
# PKCS转换为PEM
> openssl pkcs12 -in myserver.pfx -out myserver2.pem -nodes
测试证书
Openssl提供了简单的client和server工具，可以用来模拟SSL连接，做测试使用。
# 连接到远程服务器
> openssl s_client -connect www.google.com.hk:443
# 模拟的HTTPS服务，可以返回Openssl相关信息
# -accept 用来指定监听的端口号
# -cert -key 用来指定提供服务的key和证书
> openssl s_server -accept 443 -cert myserver.crt -key myserver.key -www
# 可以将key和证书写到同一个文件中
> cat myserver.crt myserver.key > myserver.pem
# 使用的时候只提供一个参数就可以了
> openssl s_server -accept 443 -cert myserver.pem -www
# 可以将服务器的证书保存下来
> openssl s_client -connect www.google.com.hk:443 remoteserver.pem
# 转换成DER文件，就可以在Windows下直接查看了
> openssl x509 -outform der -in remoteserver.pem -out remoteserver.cer
计算MD5和SHA1
# MD5 digest
> openssl dgst -md5 filename
# SHA1 digest
> openssl dgst -sha1 filename
生成Certificate Signing Request(CSR)
众所周知，申请SSL证书前需要先生成证书注册请求，这里一般使用
openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out server.csr
这条命令来生成。生成过程中会填写一些信息，随便写就好。当然最好按实际的填。
Country Name (2 letter code) [AU]: GB
State or Province Name (full name) [Some-State]: Yorks
Locality Name (eg, city) []: York
Organization Name (eg, company) [Internet Widgits Pty Ltd]: MyCompany Ltd
Organizational Unit Name (eg, section) []: IT
Common Name (eg, YOUR name) []: mysubdomain.mydomain.com
Email Address []:
Please enter the following ‘extra’ attributes to be sent with your certificate request
A challenge password []:
An optional company name []:
需要注意的是，CN(Common Name)这一项需要写你要申请的SSL证书所使用的域名。如果是通配符证书，则需要填写*.mydomain.com
生成结束之后，’server.csr’就是你的Certificate Signing Request(CSR)，用文本编辑器打开，粘贴到申请证书的地方即可。
‘myserver.key’文件是我们的私钥，这个文件一定要妥善保存不能泄露，否则任何人都可以使用我们的证书了。
在生成的时候，去掉’-nodes’选项会将私钥加密，但是需要一个额外的密码。虽然这样更安全，但是在你将证书部署到Apache或者Nginx的时候你会发现，每次启动服务你都需要输入密码。所以建议还是使用为加密的私钥，方便服务器管理。
[优惠]SSL支持通配符证书 2.5刀/年
产品简介：
SSL Certificates – AlphaSSL (Standard/Wildcard)
SSL Brand: AlphaSSL
Alpha SSL is powered by GlobalSign, the International Certification Authority with its own highly trusted root CA certificates.
Validation Type: Domain Validation
Issuance: 20 Minutes
Encryption: 256bit
Reissue Fee: Free
支持通配符*，即绑定了*.imlonghao.com后，aa.imlonghao.com，bb.imlonghao.com，均可以使用此SSL证书！
根据评论，该优惠码是经常性，即续费同价！
购买地址：https://billing.centriohost.com/cart.php?a=add&pid=21
促销代码： LET2SSL
使用方法：
在Promo code处填入优惠码，认证即可获得优惠
Kloxo面板后台SSL证书替换
最近在自己的服务器上搭建Kloxo面板造福大众，然后遇到了一点问题，就是Kloxo面板的后台7777端口访问的时候总是会提示证书是由不受信任的颁发机构颁发。做完一个重度强迫症患者（误），这是绝对不能忍的！
但是找来找去一直没有发现相关的文章。看了大家对不常用的东西一点都不在乎= =|||于是只好自己动手。
首先在你的命令行中输入：
ps -aux|grep kloxo.httpd
然后你会看到类似这样的显示：
lxlabs 16186 0.0 0.2 7256 3544 ? S 04:07 0:01 /usr/local/lxlabs/ext/lxlighttpd/sbin/kloxo.httpd -f /usr/local/lxlabs/kloxo/file/lighttpd.conf root 24325 0.0 0.0 3188 796 pts/0 S+ 17:26 0:00 grep kloxo.httpd
其中/usr/local/lxlabs/kloxo/file/lighttpd.conf就是Kloxo控制面板的Lighttpd配置文件。（找到它真不容易啊。。。在Apache那绕了一个小时的弯，突然灵光一闪看了下进程列表然后哭了。。。这货居然用的是独立的一套Lighttpd。。。）
打开拉到最下方，能看到：
$SERVER["socket"] == ":7777" {
server.document-root = "/usr/local/lxlabs/kloxo/httpdocs/"
ssl.engine = "enable"
ssl.pemfile = "/usr/local/lxlabs/kloxo/etc/program.pem"
ssl.ca-file = "/usr/local/lxlabs/kloxo/etc/program.ca"
ssl.use-sslv2 = "disable"
}
其中ssl.pemfile和ssl.ca-file就是我们需要修改的内容所指的文件就是我们要修改的内容。这里指向的是Kloxo自带的一个证书文件。现在我们修改这两项，将其指定到我们自己的证书文件。注意，ssl.pemfile我之所以没用ssl.crt是因为Lighttpd需要的证书文件比较特殊，是把Key私钥直接附加在crt证书后面生成的。为了不破坏原式证书，我起了一个不一样的名字来区分。 现在我们找到这两个program.pem和program.ca并将其替换成我们自己的证书。
接下来以StartSSL的免费SSL证书为例，说明这两个文件如何生成。
首先，我们从StartSSL拿到的证书文件包括：
ca.pem
ssl.crt
ssl.key
sub.class1.server.ca.pem
四个文件。其中ssl.key是预先解密好的私钥文件。当然不解密应该也可以，但是每次启动服务的时候都需要输入私钥密码，非常麻烦。
首先我们生成program.pem：
cat ssl.crt ssl.key > program.pem
这个ssl_key.crt就是我们最终需要的文件，即ssl.pemfile
然后生成ca-certs.crt：
cat sub.class1.server.ca.pem ca.pem > program.ca
此时生成的文件就是我们需要的文件。
然后将两个文件替换掉原来的文件，把Lighttpd重启一下，再访问就能看到效果了。