我们的服务器用 Docker 建立 nginx 环境，所以 ssl 直接丢在了 root 下，也没有太大关系。

服务端软件为： nginx-1.11.8 ， openssl-1.1.0c （已排除软件版本因素）

我的域名为 a.com ，他的域名为 b.com

以下是我能提供的所有信息，症状如标题，请大神赐教，谢谢！

Dockerfile 如下：

FROM ubuntu:latest
COPY crontabs /root
RUN apt update && \
	apt-get install -y -q libpcre3 libpcre3-dev zlib1g zlib1g-dev git wget gcc make cmake cpp autoconf automake cron && \
	cd /usr/local/src && \
	wget http://nginx.org/download/nginx-1.11.8.tar.gz && \
	tar xzf nginx-1.11.8.tar.gz && \
	wget https://www.openssl.org/source/openssl-1.1.0d.tar.gz && \
	tar xzf openssl-1.1.0d.tar.gz && \
	groupadd www && \
	useradd www -g www -s /sbin/nologin && \
	git clone https://github.com/grahamedgecombe/nginx-ct && \
	cd /usr/local/src/nginx-1.11.8 && \
	./configure --user=www --group=www --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --with-http_gzip_static_module --with-http_v2_module --with-openssl=../openssl-1.1.0d --add-module=../nginx-ct && \
	make -j2 && make install && \
	ln -s /usr/local/nginx/sbin/nginx /usr/local/bin/nginx && \
	rm -rf /usr/local/src/* && \
	apt remove -y -q git wget gcc make cmake cpp autoconf automake && \
	apt autoremove -y && \
	apt purge -y -q git wget gcc make cmake cpp autoconf automake && \
	mkdir -p /usr/local/nginx/conf/vhost && \
	mkdir -p /home/wwwroot && \
	crontab /root/crontabs
COPY ["nginx.conf","fastcgi.conf","/usr/local/nginx/conf/"]
COPY ["a.com.conf","b.com.conf","/usr/local/nginx/conf/vhost/"]
ADD ssl.tar.gz /root
EXPOSE 80
EXPOSE 443
CMD ["nginx","-g","daemon off;"]

a.com.conf:

server {
    server_name a.com www.a.com;
    listen 80;
    location ^~ /.well-known/acme-challenge/ {
        alias /home/wwwroot/challenges/;
        try_files $uri =404;
    }

    location / {
        rewrite ^/(.*)$ https://a.com/$1 permanent;
    }
}
server {
    server_name a.com www.a.com;
    listen               443 ssl http2 reuseport fastopen=3;
    root /home/wwwroot/hexo;
    server_tokens        off;
    ssl_ct on;
    ssl_certificate      /root/ssl/a/a.com.rsa.pem;
    ssl_certificate_key  /root/ssl/a/a.com.rsa.key;
    ssl_ct_static_scts   /root/ssl/a/scts/rsa;

    ssl_certificate      /root/ssl/a/a.ecc.pem;
    ssl_certificate_key  /root/ssl/a/a.ecc.key;
    ssl_ct_static_scts   /root/ssl/a/scts/ecc;
    ssl_dhparam          /root/ssl/a/dhparams.pem;
    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_prefer_server_ciphers  on;
    ssl_ecdh_curve secp384r1;
    ssl_protocols              TLSv1 TLSv1.1 TLSv1.2;
    ssl_session_cache          shared:SSL:50m;
    ssl_session_timeout        1d;
    ssl_session_tickets        on;
    ssl_stapling               on;
    ssl_stapling_verify        on;
    resolver                   8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout           10s;
    add_header    Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
    add_header    Public-Key-Pins 'pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=";pin-sha256="Fbs+o+IxVNTHBpjNQYfX/TBnxPC+OWLYxQLEtqkrAfM=";max-age=2592000; includeSubDomains';
    index index.html;
    location / {
    	expires 120s;
    }
    location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|flv|ico)$ {
    expires 30d;
    access_log off;
    }
location ~ .*\.(js|css)?$ {
    expires 7d;
    access_log off;
    }
}

b.conf:

server {
    server_name b.com,www.b.com;
    location ^~ /.well-known/acme-challenge/ {
        alias /home/wwwroot/challenges/;
        try_files $uri =404;
    }

    location / {
        rewrite ^/(.*)$ https://b.com/$1 permanent;
    }
}
server {
    server_name b.com,www.b.com;
    listen               443 ssl http2;
    index index.php;
    root  /home/wwwroot/b;

    if (!-e $request_filename) {
        rewrite ^(.*)$ /index.php$1 last;
    }

    location ~ .*\.php(\/.*)*$ {
        include fastcgi.conf;
        fastcgi_pass  cgi:9001;
    }

    server_tokens        off;
    ssl_ct on;
    ssl_certificate      /root/ssl/b/b.com.rsa.pem;
    ssl_certificate_key  /root/ssl/b/b.com.rsa.key;
    ssl_ct_static_scts   /root/ssl/b/scts/rsa;

    ssl_certificate      /root/ssl/b/b.com.ecc.pem;
    ssl_certificate_key  /root/ssl/b/b.com.ecc.key;
    ssl_ct_static_scts   /root/ssl/b/scts/ecc;
    ssl_dhparam          /root/ssl/b/dhparams.pem;
    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_prefer_server_ciphers  on;
    ssl_ecdh_curve secp384r1;
    ssl_protocols              TLSv1 TLSv1.1 TLSv1.2;
    ssl_session_cache          shared:SSL:50m;
    ssl_session_timeout        1d;
    ssl_session_tickets        on;
    ssl_stapling               on;
    ssl_stapling_verify        on;
    resolver                   8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout           10s;
    add_header    Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
    add_header    Public-Key-Pins 'pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=";pin-sha256="Fbs+o+IxVNTHBpjNQYfX/TBnxPC+OWLYxQLEtqkrAfM=";max-age=2592000; includeSubDomains';
}

error_log  /root/b_error.log  crit;

/root/ssl 目录的结构图：

/root/ssl
|-- b.com.ecc.pem
|-- a
|   |-- account.key
|   |-- acme_tiny.py
|   |-- ct-submit-1.0.0
|   |   |-- LICENSE
|   |   |-- README.markdown
|   |   |-- ct-submit
|   |   `-- ct-submit.go
|   |-- ct-submit.zip
|   |-- dhparams.pem
|   |-- intermediate.pem
|   |-- renew_ecc.sh
|   |-- renew_rsa.sh
|   |-- root.pem
|   |-- scts
|   |   |-- ecc
|   |   |   |-- b.com.ecc.sct
|   |   |   `-- a.com.ecc.sct
|   |   `-- rsa
|   |       `-- a.com.rsa.sct
|   |-- signed_ecc.crt
|   |-- signed_rsa.crt
|   |-- a.com.ecc.csr
|   |-- a.com.ecc.key
|   |-- a.com.ecc.pem
|   |-- a.com.rsa.csr
|   |-- a.com.rsa.key
|   `-- a.com.rsa.pem
|-- intermediate.pem
|-- root.pem
|-- signed_ecc.crt
`-- b
    |-- account.key
    |-- acme_tiny.py
    |-- b.com.ecc.csr
    |-- b.com.ecc.key
    |-- b.com.ecc.pem
    |-- b.com.rsa.csr
    |-- b.com.rsa.key
    |-- b.com.rsa.pem
    |-- ct-submit-1.0.0
    |   |-- LICENSE
    |   |-- README.m美国服务器arkdown
    |   |-- ct-submit
    |   `-- ct-submit.go
    |-- dhparams.pem
    |-- intermediate.pem
    |-- renew_ecc.sh
    |-- renew_rsa.sh
    |-- root.pem
    |-- scts
    |   |-- ecc
    |   |   `-- b.com.ecc.sct
    |   `-- rsa
    |       `-- b.com.rsa.sct
    |-- signed_ecc.crt
    `-- signed_rsa.crt

*.ecc.pem表示该域名的 ECC 证书，*.rsa.pem表示该域名的 RSA 证书，signed_*.crt表示 Let ‘ s encrypt 签发但还未进行证书链合并的证书；*.ecc.key表示对应域名 ECC 证书私钥，*.rsa.key表示对应域名 RSA 证书私钥；*.ecc.sct表示该域名 ECC 证书的 SCT 文件，*.rsa.sct表示该域名 RSA 证书的 SCT 文件。account.key为用户密钥。

renew_*.sh为对应证书更新脚本。 renew_ecc.sh:

#!/bin/bash
cd /root/ssl/a
python acme_tiny.py --account-key ./account.key --csr ./a.com.ecc.csr --acme-dir /home/wwwroot/challenges/ > ./signed_ecc.crt
wget -O - https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem > intermediate.pem
wget -O - https://letsencrypt.org/certs/isrgrootx1.pem > root.pem
cat signed_ecc.crt intermediate.pem > a.com.ecc.pem
./ct-submit-1.0.0/ct-submit ct.googleapis.com/pilot /root/ssl/a/scts/ecc/a.com.ecc.sct
kill -HUP `cat /usr/local/nginx/logs/nginx.pid`

renew_rsa.sh:

#!/bin/bash
cd /root/ssl/a
python acme_tiny.py --account-key ./account.key --csr ./a.com.rsa.csr --acme-dir /home/wwwroot/challenges/ > ./signed_rsa.crt
wget -O - https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem > intermediate.pem
wget -O - https://letsencrypt.org/certs/isrgrootx1.pem > root.pem
cat signed_rsa.crt intermediate.pem > a.com.rsa.pem
./ct-submit-1.0.0/ct-submit ct.googleapis.com/pilot /root/ssl/a/scts/rsa/a.com.rsa.sct
kill -HUP `cat /usr/local/nginx/logs/nginx.pid`

应该是 Nginx 没有开启 TLS 吧。参考 https://www.i7i8.com/2016/11/nginx-ip-https/

$ nginx -V
TLS SNI support disabled
参考楼上开启它即可

SNI 已开启

SNI 已开启……

同时配上两个单一域名的证书导致的。
根据 cipher 中 ecdsa 在 rsa 前，如果 b.com 这一个因为一些原因匹配不上(我估计 sct 搞的鬼)，那么优先返回默认 ecdsa 证书，正好有一个 a.com.ecc.crt 。
顺带说一句，@qgy18 的配置可能对于这种情况有 bug ，自己也碰到过。

配置里两处写错了
server_name b.com,www.b.com;
应该为
server_name b.com www.b.com;

试试注释掉 ssl_session_cache

六楼 正解。
逗号那个 nginx 读不出来可能就变成 default 了。

server_name b.com,www.b.com;




谢谢，但是目前的情况是，访问我的（ a.com ）会返回两个域名的四个证书，访问他的（ b.com ）只会返回他的证书。而且我用 F12 看了一下，访问我的不会返回 sct ，但是他的可以返回 sct 。
参照各位的解决方案，修改了配置文件，删除多余的 sct ，并且启用 Mozilla 的 cipher 配置之后，这个问题仍然存在……

补充一下，我选用 Mozilla 的 modern 配置，结果访问我的域名只返回了 3 个证书，两个域名的 ECC ，以及我自己的 RSA
Cipher ：
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;

nginx -V
贴上来

nginx version: nginx/1.11.9
built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
built with OpenSSL 1.1.0d 26 Jan 2017
TLS SNI support enabled
configure arguments: --user=www --group=www --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --with-http_gzip_static_module --with-http_v2_module --with-openssl=../openssl-1.1.0d --add-module=../nginx-ct

去掉 ct 所有配置，或者去掉 nginx-ct 模块编译试下。

好的

已关闭所有 ct 配置，仍然无效……

而且现在又有另一个诡异的问题，就是我的 session_cache 配置失效了，我怀疑是返回了其他域名的证书所致

这是双证书本身的缺点。
你的 cipher 是这样的：
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
或者是 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
这都是强行把 ECDHE-ECDSA 这种套件提前的设置方式（ EECDH 在我看来基本等价于 ECDHE ）。
所以，在大部分浏览器的套件选择默认以 ECDSA 为先的情况下，你又开了 ssl_prefer_server_ciphers on ，那无疑在取交集时，会优先选择 EECDH+ECDSA+CHACHA20 或 EECDH+ECDSA+AES128 ；因而这是必然：返回证书前两个一定都会是 ECDSA 证书了。
解决方案其实只能是保守的：使用 SAN 证书。在这种双证书的特殊情况下， SNI 扩展不是主要矛盾，套件和证书才是。

谢谢，这是我的理解：浏览器取交集最后剩下 ECDSA 的 cipher ，但是为什么会一次性返回两个 ECC 证书？而不是返回本域名的一个 ECC 证书呢？
另外 ququ 的 csr 生成命令中似乎就默认开启了 SAN 扩展，您这里的 SAN 证书还有什么需要额外注意的吗？

按照我的个人理解，这个问题还是在于 Nginx 在实现的时候把所有的 ECDSA 证书全返回去了。
我的 SAN 证书的 CSR 就是按照 的方式生成的


那就是说不能双站点共存？

我目前部署下来只发现两个解决方案：
1.放弃给每个站点单独设双证书
2.统一使用 SAN 来部署双证书

统一使用 SAN ？具体怎么操作呢？
我对 SAN 的了解仅限于指定备用名称？？？

我可能表达不清楚，就是分别签发 ECDSA 和 RSA 这两张证书，这两张证书要把四个域名都填上。就是备用名称。

啊， SAN 还能填非本域名的域名？

SAN 可以包含多个顶级域名
你看下淘宝和天猫的证书

涨姿势了，谢谢！


这个问题已经解决，但是 CT 策略失效了，是因为 SAN 有多个顶级域名的原因吗？

你是否知道,每签发一次证书,必须重新获取一次 SCT?

我的脚本里都是这么做的，签发一次就获取一次

你还有一个选择，试试我的 https://github.com/SteveLTN/https-portal

证书已经同一，那么 sct 必然是同一组啊。

是的，然并卵……

看这个 issue https://github.com/grahamedgecombe/nginx-ct/issues/13
nginx-ct 用 OpenSSL 1.1.0 并用 SNI 的话不会对非默认的 vhost 返回 ct 信息
我之前也遇到了这个问题 我觉得用 OpenSSL 1.0.2 的最新版就行 没必要上 1.1.0

这样啊，谢谢！

之前試過這個情況，臨時用 default_server 解決，暫時也沒研究出什麼好方法，因為以前就有一個 IP 一個證書的說法。

已经解决。方案如下：用
openssl req -new -sha256 -key double.ecc.key -subj "/" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:a.com,DNS:www.a.com,DNS:b.com,DNS:www.b.com")) > double.ecc.csr
生成带 SAN 的 CSR ，然后提交给 let ‘ s encrypt （如果是别家那得支持签发 SAN 证书）即可。 SAN 上限 100 个域名，这样一个证书可以给多个顶级域名使用。
如果用 nginx-ct 开启 CT ，不要使用 openssl1.1.0

另外我会单独加一个 default ，这样就算写错配置也不会很尴尬地进到其他 host 里

感謝，等我試試

同意 楼主没有加 default_server 的锅