Apache + WordPress + SSL 完全指南
似乎不少使用国外主机的站长都想弄个 https:// “玩”,但是许多人对 SSL/TLS、HTTPS、证书等概念了解有限,而中文互联网上相关的教程也不是很完备,各种杂乱。正好,本人这几天花了点时间研究了一下,给自己的站也部署了 HTTPS,写成这篇《Apache + WordPress + SSL 完全指南》,以飨中文读者。本文较长,但是我会尽量写得清楚明白的。
自制简易目录:
一、基本术语及证书原理介绍
本部分有点枯燥,不愿意读的读者可以直接跳过。以下出现的缩写鼠标悬浮于上可查看全称。
HTTPS
HTTPS 就是“超文本安全传输协议”,通俗地说就是建立在 SSL/TLS 上的 HTTP。HTTP 大家都知道是“超文本传输协议”,那 SSL/TLS 是什么呢?请往下看。
SSL/TLS
理论上讲这是两个协议,后者是前者的继任者,但其实 SSL 3.0 和 TLS 1.0 的差异很小,所以两者很多时候是混为一谈的……这两个都是传输层协议,在他们的基础上可以建议应用层的协议如 FTP 和 Telnet,上面说的 HTTPS 就是建立在 SSL/TLS 基础上的 HTTP。
证书
这里的证书主要指使用公私钥对加密的证书。下面主要会涉及到两种证书,一个是 S/MIME 证书,另一个就是 SSL/TLS 证书了。前者可以用在电子邮件上,这里用作“服务器身份识别”,可以理解为取代传统的“用户名+密码”的认证方式的一把“钥匙”。后者一般用于服务器加密(网页、邮件服务等),也就是我们部署 HTTPS 时所必须的。
本文出现的证书都是用公私钥加密的证书。这涉及到 [[非对称加密]] 技术,每张证书都由一个公钥和一个私钥组成,两个拼在一起才是一套。其中,正如它们的名字所暗示的,公钥是可以随便发给别人看的,而私钥一定是要保密的,如果私钥被偷了,后果很严重。
信任链与 CA
CA 就是“数字证书认证中心”,是证书的签发机构,而信任链是什么呢?正如街头随处可见的“办证”广告一样,谁都可以做证书,只是做出来的证书有没有人相信而已……所以在证书的世界里有一套信任体系,有几家特别靠谱的 CA,大家都愿意信任,所以把它们的根证书都 列为信任了,就是说,在我们的操作系统和浏览器中,都内置了这几家靠谱的 CA 的根证书,并列为可信任的证书。而这些 CA 签署的证书,由于信任链的关系,也是默认被信任的。大家可以去一些 https:// 的网站上看看,点击 https:// 的图标,可以见到几家比较有名的 CA,比如中国招商银行的网银页面就 是用的 VeriSign 签署的的证书。由于 VeriSign 是一家老牌的靠谱 CA,所以 Windows、Linux、OS X、Android 等操作系统以及 Firefox、Opera 等浏览器(他们的证书库是独立于操作系统的)默认都是信任 VeriSign 的根证书的,当然也就默认信任招商银行用的证书了。
如果有一家 CA,比较年轻,发展得还不够大,那么就会面临有的地方信任,有的地方不信任的问题。比如 CACert.org 就是这样一家 CA。这是一家靠社区驱动的 CA,它的根证书受到 Arch Linux 等一些 Linux 发行版的信任,但是却不受 Windows 和 OS X 的信任(完整的受信任列表见这里),所以它的网站(用了它自己的证书)若是用 https:// 浏览的话(点击这里),一些 Linux 用户会毫无压力地进入,而 Windows 和 OS X 用户则会看到证书警告说该网站的证书不受信任。以下两张截图便显示了这一点:
而如果有一家 CA 完全就像街头的“办证”广告那样完全胡来,那自然是没有任何一家去信任它的证书了,比如下面这个:
大家都懂的……
不过需要说明的是,如果你使用自签名证书的话,那么 CA 就相当于你自己,一般谁来信任你啊?所以人家浏览你的网站的时候也会看到像上图那样的证书警告的。至于啥是自签名证书,下面会讲到。
二、部署 HTTPS 的前提条件
简单地介绍完了证书的基本知识,下面说一下部署 HTTPS 的前提:
- 最好是 VPS 甚至独立服务器。如果是共享主机的,则需要主机商提供 SSL/TLS 功能(有的面板有这样的功能),否则不行。
- 服务器上必须开启了 mod_ssl。
- 最好有独立 IP。如果没有,则需要主机打开 SNI 功能(见 RFC 4366),而且,破烂 IE 是不支持 SNI 的,会报证书错误。
- 最好去申请/购买一张正规的第三方知名 CA 签署的证书,不要像铁道部那样胡乱搞一个。不过,如果你只是为了测试用途或是对网站数据进行特殊加密自己私下使用的话(你懂的),自签名的证书也是可以的。
- 推荐有一个 Linux 运行环境。如果已经是 Linux 服务器的话,直接 SSH 进服务器执行命令也是可以的。
三、自签名证书
上文提到,由于大家的电脑里都内置了一些靠谱的 CA 的根证书,所以找靠谱的 CA 签署的证书默认也是被信任的。但是,证书的确是人人都可以自己制作的。有的时候,我们使用 HTTPS 只是为了数据的加密,仅供自己使用,不用管别人信任与否,这时候就可以用到自签名证书。正如名字所暗示的,自签名证书就是自己给自己签名的,默认只有服务 器自己才信任,甚至连你从自己的桌面电脑上访问,桌面电脑也是不信任的。在这种情况下,你可以把自己创建的证书加入到自己的桌面电脑的信任列表,这样就不 会再有错误提示了。
Apache 的文档中有 Creating self-signed certificates 这一节教你怎么创建自签名证书,简单明了,十分傻瓜:
用自己的包管理器安装 ssl-cert
这个包,再执行
sudo make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /path/to/cert.pem
命令,按照提示输入一个 Common Name(CN,保持和主机名相同),便能按照 /usr/share/ssl-cert/ssleay.cnf
这个默认模板生成一份证书,这份证书是公钥和私钥合并在一个文件里的,用文本编辑器打开将看到这样的结构:(为了简洁我省略了一部分字符)
-----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQC3Y+VVgZ0R+tjV rH4ZAE4EnGhDUPSe+GHNFvz9SwpRl/hoCvlclTyV/kZwFC6gS1Gx3wIOM6eBFIMb 16koaOaXWsCNP9LZUjCNj8V497SVvdHqovzx7ztCrKzOcUMK6VwsF/ynJYor6oYQ jdVvLuCnb/fw1Na+9w5fVUees7lVXBY60TRvAS82yyzuwRaZcJHWqTzysKNz01Mk zhcNughh9ONfRC6Q0AeKVLWw -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIICpDCCAYwCCQDdTk8KetUkFTANBgkqhkiG9w0BAQUFADAUMRIwEAYDVQQDEwls b2NhbGhvc3QwHhcNMTIwNjEwMTE1NDUwWhcNMjIwNjA4MTE1NDUwWjAUMRIwEAYD 6JWaSpkY1WJ8XPMwc/eAdFi0b58GQtv5uMXwVnjGy/P1TKoP76REt4TVwKXuiTPB +4m/ZyTVbJ81JfSjm0xxTQl39kJjhzNenYOBSOy/1YH2vSRAVnuoy/aFSyXggUz2 PpZt4UZ0c7g= -----END CERTIFICATE-----
前面那段是私钥(如果这是真正的证书的话,一定要保密!),后面那段是证书信息和公钥(随便发)。这份证书默认的有效期是 3650 天(十年)。
其实刚才那个傻瓜式的命令实质上是执行了这个:
sudo openssl req -new -x509 -days 3650 -nodes -out /path/to/cert.pem -keyout /path/to/cert.pem
参数虽多,但是其意义还是容易看出来的:
- openssl req -new
- 用 OpenSSL 套件生成新的证书请求
- -x509
- 使用 X.509(PEM 编码的一种实现)
- -days 3650
- 有效期是十年,可以自己改
- -nodes
- 这个不是英文单词 “nodes”,而是 “No DES” 的意思,代表不用 DES 加密私钥,否则私钥默认是用 DES 加密的,每次启动 Apache 要输入密码
- -out
- 证书(包括证书信息和公钥)的文件名
- -keyout
- 私钥的文件名,如果此项和上一项同名的话,那么公钥和私钥是合并在同一文件里的(正如上面所贴的)
执行这个命令会让你输入一系列信息,比如 Common Name (CN)、公司名、地理位置、联系方式等,除了 CN 必须要和网站域名匹配之外,其他可以按照你的喜好自由填写……
证书生成好后,便是在 Apache 的配置文件中指定它了。具体的配置文件写法可以参考它自带的 /etc/apache2/sites-available/default-ssl
配置文件,主要是以下这几行要修改:
SSLEngine on SSLCertificateFile /path/to/cert.crt SSLCertificateKeyFile /path/to/cert-key.key
并且如果按照上文,把公钥和私钥放在同一个文件里的话,那只要提供 SSLCertificateFile 就好了,后面的 KeyFile 不用填(保持它们的注释状态)。
插播:Linux 是不分辨文件扩展名的,所以理论上上面的这些公钥
婆钥私钥的扩展名都是可以随便起的,甚至不填也可以,但是为了方便自己弄清楚,我习惯上是这样命名的:只包含证书信息和公钥的文件扩展名为crt
,同时包含了公钥和私钥的文件扩展名为pem
,只包含私钥的文件扩展名为key
。上面的例子中我就是这么命令的,大家可以参考一下。
保存配置文件后,用 sudo a2ensite
来启用它,再执行一下 sudo a2enmod ssl
确保 mod_ssl 已经开启(如果使用虚拟主机的话,还需要在 apache2.conf 加上 NameVirtualHost *:443
这一条),然后执行 sudo service apache2 restart
来重启 Apache。如果没有出现奇怪的错误的话,那么现在你的网站已经可以通过 https:// 协议访问了。当然,由于这个证书是不受信任的,浏览器会弹出安全警告,不用管,虽然证书是不受信任的,但是毕竟是 TLS,所以传输的内容已经是加密过的了,第三方无法知道你访问的网站内容。如果不想每次都看到证书警告的话,可以把这个证书导入到系统中,设为信任。在 Firefox 中也可以选择“添加例外”。
四、第三方签名证书
虽然自签名证书默认是不受操作系统或浏览器的信任的,但是这并不影响它能够加密传输内容的本质。自签名证书给自 己用是足够了,如果嫌证书警告烦人的话,自己添加为信任就好了,甚至在一小撮人中用也是足够了——你把证书发给你的朋友们,让他们也设为信任,这样他们访 问你的网站的时候也不会弹警告了。但是如果要全世界大部分人访问你的网站的时候都不会弹证书警告的话,你需要把你的证书发到每个人手里……开玩笑,这当然 是不现实的。所以比较好的方法就是找一些靠谱的第三方 CA,让它们帮你签名证书,由于大部分人的操作系统或浏览器都是信任这些靠谱 CA 的,所以由他们签名的你的证书也是受信任的(信任链嘛),所以访问你网站的时候就不会弹证书警告了。
注意:第三方签名证书不代表比自签名证书的加密更强悍更可靠!TLS 的加密强度由加密的位数决定,与证书是谁签名的无关。找第三方签名只是为了不弹证书警告。如果你只是自己用或是一小撮人用的话(思路提醒:twip),用自签名就足够了。
那么,怎么找第三方签名呢?首先你也得有个私钥:
openssl genrsa 1024 > ssl.key
这里的参数们也是挺容易看懂的:
- openssl genrsa 1024
- 显然就是用 OpenSSL 来生成一个 1024 位 RSA 加密的私钥(Generate RSA),这个位数是可以改的
- > ssl.key
- 这个是通过重定向命令,把生成的东西保存到 ssl.key 这个文件中。我的文件命名习惯上面提过了……
生成好了之后用一些图形化的证书查看器查看大概是这个样子的(当然,指纹肯定不一样……)
然后你也得告诉第三方 CA 你的 CN、地址、联系方式什么的吧?怎么告诉呢?有一种专门的东西叫 Certificate Request,就是“证书请求”,就是专门干这事的,它把私钥公钥和证书信息揉合在一起,交给第三方 CA,他们可以读取这个文件中的私钥公钥和证书信息,然后帮你签名。这个 Certificate Request 文件的扩展名一般用 csr
。
刚才你已经有私钥了,生成证书请求的命令是这个:
openssl req -new -key ssl.key > ssl.csr
有了刚才几个命令的经验,相信你也知道这命令啥意思了……执行了之后也会要求你输入证书的信息,然后把最终生成的结果放到 ssl.csr 中。如果用文本编辑器打开这个文件,看到的是类似这样的东西:(我省略了一部分字符)
-----BEGIN CERTIFICATE REQUEST----- MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEh MB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDXRbfQQP+TulvM8Qz5d/IhzLxav6VcX/Zhy5HTftCKeIhH B0bNH6PDxg5tmqY9g9hzgl5OLhkkTYEYsYugKYxdAx/aK3XXAGruguzSbc4fA2Rx leo0Ow9DQGo= -----END CERTIFICATE REQUEST-----
你要传给第三方 CA 的就是这个东西了,他们会帮你签的,签好之后把成品(公钥证书),你就可以把公钥和私钥添加到 Apache 的配置文件中了:
SSLEngine on SSLCertificateFile /path/to/cert.crt SSLCertificateKeyFile /path/to/cert-key.key SSLCertificateChainFile /path/to/chain.pem
嗯,是的,比上面的多了一行,因为这是第三方 CA 签名的,所以要有一个把你的证书和它的根证书相连接的过程。如下图:
那个 Chain 就是中间那一环。当然了,正如 KeyFile 可以和主证书文件合并一样,这个 ChainFile 也是可以和主文件合并的,这三个全部首尾相连地并成一个文件也是没有问题的,这样就只要填一个 SSLCertificateFile 就好了。
改好配置之后,像上面自签名那样,也重启一下 Apache,就可以用 https:// 协议访问了。并且,由于是大家都信任的靠谱 CA 签名的,这样的证书是不会弹证书警告的。
五、WordPress HTTPS 免插件部署指南
解决“混合内容”问题
这一节主要讲一下 WordPress 的 HTTPS 实现。在 WordPress 的插件库中,有一个叫 Force SSL 的插件,它的作用是当用户用 https:// 访问的时候,实时解析页面中所有的 URI,把 http:// 换成 https://。本来我觉得那插件还是不错的,后来我把 php 的内存限量稍微改小一些,就大量出现 500 错误,一看错误日志,竟然全是那个插件“试图分配超过限额的内存”,这才觉得这插件实在太耗资源了!所以我果断删除了那个插件,开始尝试无插件实现 WordPress 的 HTTPS 访问。
如果按照上面的教程,把证书什么的都设置好了的话,这时候 WordPress 已经可以通过 https:// 协议访问了,但是有问题:页面中的文章链接(← 新版本的 WordPress 似乎解决了这个问题)、图片、CSS、JavaScript 的 URI 都是 http:// 的,所以会有“混合内容”的问题,在 Chromium/Chrome 里是一个难看的红叉叉(高危内容,如 JavaScript)或灰色的锁上有个黄三角(低危内容,如图片),而在糟糕的 Internet Explorer 里则是显示为“混合内容”,弹出大量烦人的警告窗口。那个 Force SSL 插件的两大作用之一就是把这种资源的 URI 改成 https:// 的。
但是,让我们手工来改吧。这里要介绍一种神奇的思路,那就是“协议级相对路径“,例子可以见 Google HTML/CSS Style Guide 的建议:
Omit the protocol from embedded resources.
Omit the protocol portion (http:, https:) from URLs pointing to images and other media files, style sheets, and scripts unless the respective files are not available over both protocols.
Omitting the protocol—which makes the URL relative—prevents mixed content issues and results in minor file size savings.
相对路径我知道,可是协议级的相对路径我却没想过,没想到真的是可以的……连 IE6 都认的。把资源的 URI 省略掉协议,就可以实现“相对协议”了,比如把一个链接写成://example.org/index.html
, 那么,如果是在一个 http:// 页面上点击这个链接,用户就会来到 http://example.org/index.html ,而如果是在一个 https:// 页面上点击这个链接,用户就会来到 https://example.org/index.html !这样完全省去了各种判断协议的代码,也大量节省了服务器资源。不得不赞一下这个思路……
具体怎么实现呢?很简单,改主题……看看你的博客首页的源代码的头部和尾部,一般那些 CSS、JavaScript 就放在这里,认准它们的样子,再到主题文件里去找到它们对应的代码,比如源代码中有这样的:
<link rel="stylesheet" href="http://example.org/wp-content/themes/example-theme/style.css" />
在主题的 header.php 中可以发现对应的代码:
<link rel="stylesheet" href="<?php bloginfo( 'stylesheet_url' ); ?>" />
那么直接把它改成这样就好了:
<link rel="stylesheet" href="//example.org/wp-content/themes/example-theme/style.css" />
没错,就是这样,把 URI 由动态的 PHP 函数换成静态的协议级相对链接。当然,由于 WordPress 的主题千变万化,可能还有其他的资源如 JavaScript 甚至糟糕的 swf 等,要根据不同主题的实际情况进行修改。
除了主题自带的资源,还有一些插件可能会引用一些 JavaScript 什么的,这也需要在插件的文件中进行修改。大致思路也是根据 HTML 源代码,去找 PHP 代码,然后把里面的函数换成带有实际地址的“协议级相对链接”。
改完了 CSS、JavaScript 等“高危内容”之后,Chrome/Chromium 的协议图标会从 变成 ,不过,依然是有提示“混合内容”的标识,这主要是页面中的一些图片元素还是使用的 http:// 的 URI。如果你的目标是让它变成 的 话,那就必须要解决这个问题。要解决这个问题,比解决 JavaScript 和 CSS 要复杂一些。插件中的图片什么的,可以通过把插件中的函数改掉,使其变成“协议级相对路径”来解决。但是已经发表的文章中的图片,就只能一篇篇改了。文章 中图片不多的话,只需一篇篇编辑,然后在图片的属性中把 http://example.org/wp-content/uploads/path/to/file.png
这样的换成 //example.org/wp-content/uploads/path/to/file.png
就好了。如果文章比较多,这样一篇篇换显然是十分费神的,那就最好到数据库中指查找替换了,这里不再赘述。
强制跳转?选择性跳转?
如果顺利完成了上面的步骤,那么现在你的 WordPress 是既可通过 http:// 访问,也可通过 https:// 访问,但是,如果希望 http:// 的访问跳转到 https:// 呢?这就需要用到 mod_rewrite 了。由于这篇文章是针对 Apache 用户的,所以 nginx 的规则就不提了。
首先要确认 Apache 开启了 mod_rewrite(默认安装是不开的),如果没有开启的话,需要使用 sudo a2enmod rewrite
来开启并 sudo service apache2 restart
来重启 Apache。
如果有服务器的完全权限的话,可以在服务器的配置文件中加入以下代码,如果不能编辑配置文件的话,那在站点的目录中添加 .htaccess 文件加入以下代码也行。当然,站点配置中要设置 AllowOverride,才能使站点目录中的 .htaccess 起作用:(请把 wzyboy.im
换成你自己的 WordPress 域名)
RewriteEngine On RewriteCond %{HTTPS} !on [NC] RewriteRule (.*) https://wzyboy.im%{REQUEST_URI} [R=301,NC,L]
这段代码的意思是说:当检测到 HTTPS 未开启(!on
嘛)的时候,把请求重定向到 https:// 的对应 URI。Apache 的 mod_rewrite 是个很强悍且较通俗易懂的东西,完整的文档请看这里。如果是在站点配置文件中加入了这些代码,需要用 sudo service apache2 reload
重新载入配置文件才能生效。
嗯,现在再访问 http:// 的 WordPress 的话,全部会自动跳转到 https:// 版本的了。但是这样做有两个小问题:
- 目前搜索引擎中似乎只有 Google 能抓取 https:// 站点,而其他的搜索引擎都不抓取。
- 破烂 IE 是不支持 SNI 的(XP + IE8 及以下),因此对于这些用户来说,显示的依然是“证书错误”(其实是没有错误,是 IE 自己有错误)。
对应的解决方法自然也是有的,比如这样:(这段代码参考了 LvWind 的博客。请注意把 wzyboy.im
换成自己的域名)
RewriteEngine On RewriteCond %{HTTPS} !on [NC] RewriteCond %{HTTP_USER_AGENT} !(baiduspider|soso|bing|sogou|yahoo|sohu-search|yodao|robozilla|msnbot|msie|feedburner) [NC] RewriteRule (.*) https://wzyboy.im%{REQUEST_URI} [R=301,NC,L]
这段代码比刚刚那段多加了一个判断条件,即判断访客的 User Agent 是否是搜索引擎或者 IE 用户,如果不是,那才跳转到 https:// 版的页面。注意,这里面是不包含 Google Bot(Google 的爬虫)的,在因为 Google 本身就是能抓取 https:// 站点的,没必要重定向。而 IE 用户则是像其他的非 Google 的搜索引擎一般看待了,保持不跳转。
当然,这还不是最绝的,如果你打算彻底放弃 IE 用户的话(我就打算这么干,我的博客的 IE 访问量不足 25%,XP + IE8 及以下的比例更是只有 12% 左右),可以这么干:
RewriteEngine On RewriteCond %{HTTP_USER_AGENT} msie [NC] RewriteRule .* - [L,F] RewriteCond %{HTTPS} !on [NC] RewriteCond %{HTTP_USER_AGENT} !(baiduspider|soso|bing|sogou|yahoo|sohu-search|yodao|robozilla|msnbot|feedburner) [NC] RewriteRule (.*) https://wzyboy.im%{REQUEST_URI} [R=301,NC,L]
这样的话,所有 IE 用户直接返回一个 403 给他们……甚至,如果你不想照顾 Google 以外的搜索引擎的话,连判断搜索引擎的那一行都可以省了……
另外,如果你决定这么干之后,你还可以在 WordPress 的后台设置中,把站点主页和 WordPress 的安装位置两个选项都改成 https:// 的,这样的话,哪怕是新上传的图片,也都是自动 https:// 路径了,这样,你的站点就会完全沉浸在 的世界中!记得那个谁说过[谁?],理想的互联网中,一切都是 https:// 的……
事实上,我在某个新建的站点上就是这么干的:把所有 IE 用户重定向到 403,并且强制所有非 IE 用户跳转到 https:// 页面,并且 WordPress 中的站点地址和安装路径都设置为 https:// 的……现在的效果就是:Analytics 中完全没有 IE 用户的存在;Google 中搜索 site:某站点.org
全是 https:// 的收录;其他搜索引擎啥也收录不到。
六、申请 StartSSL 免费证书
虽然自签名证书和第三方靠谱 CA 签名的证书都能起到加密的作用,但是自签名的最多自己用用,而 WordPress 上用自签名证书就不太好了。这就需要第三方 CA 签名的。但是大部分靠谱 CA 签名的证书都是收费的,而且价格不是很低。好在,还是有人想打破这个垄断的,CACert.org 和 StartSSL 就是两家提供免费 SSL/TLS 证书签名的 CA。前者是开源社区弄的,所以不少 Linux 发行版都承认这个证书,但是在 Windows 里什么的就比较悲剧,比如一台 Windows 7 的电脑访问 https://cacert.org/ 就会提示证书错误,但是一台 Ubuntu 12.04 LTS 的电脑就没有问题。
而 StartSSL 受到承认的范围就稍大一些了,现在主流的操作系统和浏览器中,只有破烂 IE6 不支持(我写这句话的时候在想,IE6 这货还能算个浏览器吗?!),所以比较适合我等穷人来部署 HTTPS 啊。
StartSSL 是以色列公司 StartCom 旗下的 CA。申请免费的证书并不复杂,甚至比上面介绍的自己生成还要简单,因为它甚至提供了在线生成私钥的功能,连自己生成私钥都免了。
至于 StartSSL 的申请流程么,网上似乎是有很多的,但是不知是不是年代久远的关系,都用要审核的一条路子,太麻烦了,于是我干脆重新写一个简洁的:
使用 Chrome/Chromium 或者 Firefox(其他浏览器可能会有问题)打开 StartSSL Control Panel, 这里有三个选项,分别是 Authenticate、Sign up 和 Express Lane。第一个是登录认证用的,第二个是注册账号,第三个是“捷径”。很多人不仔细看那些说明就去点了 Sign up……但是其实呢,如果选择 Sign up 的话是要人工审核的(可能会被拒绝),而如果你只是想申请一个免费的 SSL/TLS 证书的话,直接点 Express Lane 就好了。点进去之后会让你填一张个人信息表,这个要真实填写。完成之后就会提示你安装一个证书,注意了,这个证书是 S/MIME 证书,而不是我们要申请的 SSL/TLS 证书。这个证书是安装到浏览器里的,是用户登录 StartSSL 网站用的,只是一个登录网站时的凭据,和最终我们要用在服务器上的证书完全无关。该网站不是用传统的用户名 + 密码的方式登录的,而是用这个证书进行登录,如果丢了这个证书的话,就相当于把用户名密码忘了,得要重新申请才行。StartSSL 会提示你备份这个证书的,从浏览器中导出就可以了。如果要在别的电脑上或是别的浏览器里登录这个 StartSSL 网站的话,需要把这个导出的证书复制到那个电脑上才行。
接下来是登录,登录的时候会提示选择证书:
当然是确认了,然后就可以登录到 StartSSL 的控制面板了。
首先需要在 Verification Wizard 中选择 Domain Name Verification 添加、验证域名,证明这个域名是属于你的。填写域名的时候只能填顶级域名哦,二级域名什么的是不被支持的,但是证明顶级域名归你所有之后,你就可以随意添 加二级域名了。验证的过程也很简单:StartSSL 会检查这个域名的 Whois 信息,读取其中填写的所有人邮箱,然后外加 webmaster、postmaster、hostmater 等常见的域名邮箱的收件人,让你任选一个邮箱,发送验证码。哪个邮箱能收到邮件就选择哪个喽:
收到邮件之后,把里面的验证码复制粘贴进去,就验证成功了,StartSSL 就知道这个域名是属于你的了。注意,这个域名验证的有效期是三十天,三十天后要重新验证,但是三十天之内不需要再次证明这个域名归你。接下来就是去选择 Certificate Wizard 开始准备生成证书!在下拉列表中,选择你需要生成的证书类型,当然是 Web Server SSL/TLS Certificate 了。接下来是生成私钥:
这个是在线生成了,你也可以自己用 OpenSSL 生成。不过用它的也一样。这里需要填一个密码。还记得我们上面自己生成私钥的时候,要加 -nodes
选项让它不用把私钥加密吗?而 StartSSL 默认是要加密的,你在这里输入一个 10 字符以上,32 字符以下的密码就好了,这个密码只是临时用一下的,十分钟后就可以忘掉了。至于下面的加密方式和强度什么的都可以保持默认。
下一步是保存这个私钥:
把图中文本框中的东西全部复制下来,然后保存成一个纯文本文件,比如 ssl.key。由于牵扯到 Windows/DOS 和 Linux/Unix 的换行符问题,建议还是在 Linux 环境下操作,比如在 SSH Shell 用 Vim 来保存这样一个文件。保存好之后是该把它解密了。用 openssl rsa -in ssl.key -out ssl.key
,然后输入刚才设置的那个临时密码,就可以解密了。之后临时密码就可以忘掉了。如果没有 Linux 环境的话,也可以用它提供的在线解密工具(在 Tool Box 里)。
接下来就可以添加子域名了!
图中填的域名将会被作为最终的 Common Name,而裸域则是作为 Alternative Name 出现的。
再次确认之后,就可以生成证书了:
把图中文本框里的内容也保存成一个纯文本文件,比如 ssl.crt。(还是建议在主机上直接用 Vim 什么的保存,否则可能会有换和符问题)然后图中还有一个 intermediate 证书,那个也要下载保存一下,那个就是上文中所说的 ChainFile 了。至于那个 root 证书,由于大家的电脑里都有,所以就没必要下载。
现在你已经集齐了证书的三个要素了:ssl.crt 是证书信息和公钥,ssl.key 是证书的私钥,而那个 sub.class1.server.ca.pem 则是 ChainFile。把这三个文件放到服务器里的合理的目录下,再在 Apache 配置文件里指定它们,大功告成!
此外,StartSSL 还发给过你一个 S/MIME 证书,那个是你登录 StartSSL 网站的唯一凭据,把它弄丢了的话就无法登录 StartSSL 的网站了(只能重新申请了),所以也要备份好。Firefox 和 Chrome/Chromium 的证书备份都不复杂,在此不再赘述。
七、尾声
这篇文章拖了估计有一两个月了……不过写得也的确辛苦。能一字一字看到这里的读者也辛苦了……
好像找不出别的想说点什么的了。算了,等有人留言再说吧……
补充1:经实验证明,FeedBurner 是不能识别 https:// 链接的,所以上文中判断 UA 的一节添加了 FeedBurner 的 UA。不使用 FeedBurner 的用户可以不加。