全站强制访问通过修改 .htaccess 文件实现。一般情况下用户访问网站时都不会专程加上 https:// 来使用 HTTPS 协议连接，因而就需要在用户通过 HTTP 连接时强制跳转至 HTTPS 协议下。但是，搜索引擎在抓取网站时可能会因为网站强制使用了 HTTPS 协议而抓取失败（应该是除了 Google 其他引擎都不支持），所以针对搜索引擎的蜘蛛需要将他们重新因导至 HTTP 协议下。

这里还有另外一个问题，引导强制转入 HTTPS 协议后，除了首页之外，其余自定义链接可能会遭遇 404 的情况。而我的网站就是全部采用了自定义链接，所以在刚配置好强制跳转后再点击其他页面就遭遇了全部 404 的问题，而且还是默认页面的 404 而非博客主题定制的 404 页面。因而除了 HTTP 转 HTTPS 外，还要配置与自定义链接相关的跳转。

配置如下：

RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post/.php*
RewriteCond %{HTTP_REFERER} !.*www.chrafz.com.* [OR] RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://www.chrafz.com/$ [R=301,L]
RewriteCond %{HTTPS} !on [NC]
RewriteCond %{HTTP_USER_AGENT} !(baiduspider|soso|bing|sogou|yahoo|sohu-search|yodao|robozilla|msnbot|msie|feedburner) [NC]
RewriteRule (.*) https://www.chrafz.com%{REQUEST_URI} [R=301,NC,L]
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

在使用时记得将域名改为自己的网站域名

基本上完成上述步骤后，网站就能够实现全站强制 HTTPS 访问了。但是按照 Chrome 的标准的话，此时也只能得到一个灰锁或带三角的灰锁而非完全的绿锁。

这其中可能有两个原因，一个是未使用新型加密套件，另一个是网站加载了不安全的脚本。前者是服务器的问题，后者是主题的问题。

提升服务器 SSL 安全性（以 Nginx 为例）

一般而言服务器的 SSL 模块默认并不会采用新型的加密套件，需要进行手动指定。如果是使用 Nginx 的用户，可以通过修改 nginx.conf 文件来指定采用新型的加密套件，从而增强 HTTPS 通信的安全性。

建议在 nginx.conf 添加的内容如下：

ssl_session_cache shared:SSL:10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on; ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-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:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA";
ssl_dhparam /your/path/to/dhparam.pem;
add_header Strict-Transport-Security max-age=15768000;
ssl_stapling on; ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 10s;
ssl_trusted_certificate /your/path/to/domain-trust-chian.pem;

第一部分应该是默认配置。

第二部分是指定采用 TLS 通讯协议，而不采用不安全的 SSL2 或 SSL3，你也可以写成 SSLProtocol all -SSLv2 -SSLv3 这样的形式来启用所有支持的协议但排除 SSLv2 和 SSLv3 。

第三部分，启用加密模组替换，当前列的加密模组不受支持时，再采用后面的模组。末尾以叹号开头的则代表不使用的不安全加密模组。

第四部分，不使用 OpenSSL 提供的默认 1024 位 DH 素数，而是使用自己运算出的 DH 素数组。运算 DH 素数可以通过 openssl dhparam-out dhparam.pem 4096 命令来生成，该命令将会在目录下生成 dhparam.pem 文件，之后将文件路径填入此参数中。有关为何要这么做可以阅读 WeakDH 上的页面。规避这一问题还可以通过采用 ECDHE 传输形式来实现，对此的建议是采用 ECC 算法签发证书。但是由于 ECDHE 算法在移动设备上不一定能够得到良好支持，所以还是需要为移动设备访问做出这一选项的预备。

第五部分，部署 HSTS 安全传输，要求网站直接发送 HTTPS 请求。

第六部分，OSCP 装订，用以在访问时主动验证提供的 SSL 证书状态，是否吊销或者符合在线证书列表提供的记录。由于每次主动请求 OSCP 信息可能会遭到攻击者的拦截，可以通过发送 OSCP 的缓存请求，绕开每次都需要向 OSCP 服务器发送请求的步骤。如果在配置 SSL 证书时并未提供对应的根证书与中级证书，需要自行生成一套证书链，并通过ssl_trusted_certificate 参数来指定可信赖的证书链。所谓的证书链文件，是指在一个文件中包含了从根证书到为你的网站证书签署的中级证书的全部文本，即复数的 -----BEGIN CERTIFICATE----- 与 -----END CERTIFICATE-----。本站的证书链是 UserTrust 网络的三份证书，分别是 AddTrust External CA Root和COMODO ECC Certification Authority还有COMODO ECC Domain Validation Secure Server CA。证书商在向你派发证书文件时，一般都会以 .ca 或 .ca-bundle 文件的形式为你提供证书链文件。