SSLZOO 专业的SSL技术分享平台 - 最新问答

已回答：IIS服务器私钥丢了怎么办？

Fri, 15 Dec 2017 03:06:41 +0000

IIS中取回密钥很简单，但前提你有过备份pfx

假如你是第一次申请SSL证书，IIS可能会丢失私钥，参考：https://www.sslzoo.com/99?show=99#q99

如果你是迁移过服务器，丢失私钥，而且你是做过备份pfx文件，如果有密码，你还得记得密码，使用openssl工具可以找回，参考：https://www.infinisign.com/faq/iis-miss-private-key

已回答：GeoTrust证书在Firefox中被提示网站不安全

Tue, 12 Dec 2017 14:11:32 +0000

参考：SSL证书链不完整导致浏览器不受信任

中国公司的邓白氏码免费申请方法

Mon, 11 Dec 2017 01:51:44 +0000

邓白氏相当于我们国家的第三方工商信息查询，其具备全球公认的信息真实度，邓白氏的申请收录是免费的，但代申请的公司会收取一定费用，目前Apple(苹果)公司面向苹果开发者账号提供免费申请通道。

前往https://developer.apple.com/ios/enroll/dunsLookupForm.action，登录企业或个人的开发者账号。

登录后，进入页面https://developer.apple.com/support/D-U-N-S/

点击页面下方的D-U-N-S Number look up tool

进入新的页面后，填写您的企业信息（请填写英文信息）

很快您会收到来自DB公司的提醒邮件：

Thank you for submitting your D-U-N-S Number request / update to D&B. It should be completed by 09/05/2017, or sooner.Your request id is: 102XXX-20XXXX. A D&B representative may be contacting you directly. Your cooperation will help to expedite the resolution of this request.Please contact applecs@dnb.com if you have any questions.

在此之后，会有DB在中国的分支机构，例如“华夏邓白氏”与您进行联系，以确认您的企业信息。

经实际确认企业信息无误后，邓白氏会收录您的企业信息，您将会收到一封名为“D-U-N-S Number Request/Update Completed”的邮件告之您的邓白氏码，并且告之您的邓白氏码会在14天后生效。

请注意，邓白氏码只是CA机构对企业认证的一种方式，其它信息如企业营业执照、电话、财务申报电话、114能够查到的信息等多种方式。

开启HSTS防御SSLStrip(HTTPS降级攻击)

Mon, 11 Dec 2017 01:48:12 +0000

网站开启全站https后，在“Nginx中最安全的SSL证书配置”中我们做的是301跳转使访问者强制从http跳转到https来实现全站https，但这个请求过程第一次http请求实际上有可能被劫持，于是构成了https降级劫持，故采用HSTS(HTTP Strict Transport Security，RFC6797)来解决这个漏洞。

HSTS简介

HSTS(HTTP Strict Transport Security)是国际互联网工程组织IETF发布的一种互联网安全策略机制。采用HSTS策略的网站将保证浏览器始终连接到该网站的HTTPS加密版本，不需要用户手动在URL地址栏中输入加密地址，以减少会话劫持风险。

HSTS响应头格式

Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload]

max-age，单位是秒，用来告诉浏览器在指定时间内，这个网站必须通过HTTPS协议来访问。也就是对于这个网站的HTTP地址，浏览器需要先在本地替换为HTTPS之后再发送请求。
includeSubDomains，可选参数，如果指定这个参数，表明这个网站所有子域名也必须通过HTTPS协议来访问。
preload，可选参数，一个浏览器内置的使用HTTPS的域名列表。

HSTS Preload List

虽然HSTS可以很好的解决HTTPS降级攻击，但是对于HSTS生效前的首次HTTP请求，依然无法避免被劫持。浏览器厂商们为了解决这个问题，提出了HSTS Preload List方案：内置一份可以定期更新的列表，对于列表中的域名，即使用户之前没有访问过，也会使用HTTPS协议。

目前这个Preload List由Google Chrome维护，Chrome、Firefox、Safari、IE 11和Microsoft Edge都在使用。如果要想把自己的域名加进这个列表，首先需要满足以下条件：

拥有合法的证书(如果使用SHA-1证书，过期时间必须早于2016年)；
将所有HTTP流量重定向到HTTPS；
确保所有子域名都启用了HTTPS；
输出HSTS响应头：
max-age不能低于18周(10886400秒)；
必须指定includeSubdomains参数；
必须指定preload参数；

即便满足了上述所有条件，也不一定能进入HSTS Preload List，更多信息可以查看：https://hstspreload.org/。

通过Chrome的chrome://net-internals/#hsts工具，可以查询某个网站是否在Preload List之中，还可以手动把某个域名加到本机Preload List。

HSTS缺点

HSTS并不是HTTP会话劫持的完美解决方案。用户首次访问某网站是不受HSTS保护的。这是因为首次访问时，浏览器还未收到HSTS，所以仍有可能通过明文HTTP来访问。

如果用户通过HTTP访问HSTS保护的网站时，以下几种情况存在降级劫持可能：

以前从未访问过该网站
最近重新安装了其操作系统
最近重新安装了其浏览器
切换到新的浏览器
切换到一个新的设备，如：移动电话
删除浏览器的缓存
最近没访问过该站并且max-age过期了

解决这个问题目前有两种方案：

方案一：在浏览器预置HSTS域名列表，就是上面提到的HSTS Preload List方案。该域名列表被分发和硬编码到主流的Web浏览器。客户端访问此列表中的域名将主动的使用HTTPS，并拒绝使用HTTP访问该站点。

方案二：将HSTS信息加入到域名系统记录中。但这需要保证DNS的安全性，也就是需要部署域名系统安全扩展。

其它可能存在的问题

由于HSTS会在一定时间后失效(有效期由max-age指定)，所以浏览器是否强制HSTS策略取决于当前系统时间。大部分操作系统经常通过网络时间协议更新系统时间，如Ubuntu每次连接网络时，OS X Lion每隔9分钟会自动连接时间服务器。攻击者可以通过伪造NTP信息，设置错误时间来绕过HSTS。

解决方法是认证NTP信息，或者禁止NTP大幅度增减时间。比如：Windows 8每7天更新一次时间，并且要求每次NTP设置的时间与当前时间不得超过15小时。

支持HSTS浏览器

目前主流浏览器都已经支持HSTS特性，具体可参考下面列表：

Google Chrome 4及以上版本
Firefox 4及以上版本
Opera 12及以上版本
Safari从OS X Mavericks起
Internet Explorer及以上版本

HSTS部署

服务器开启HSTS的方法是：当客户端通过HTTPS发出请求时，在服务器返回的超文本传输协议响应头中包含Strict-Transport-Security字段。非加密传输时设置的HSTS字段无效。

最佳的部署方案是部署在离用户最近的位置，例如：架构有前端反向代理和后端Web服务器，在前端代理处配置HSTS是最好的，否则就需要在Web服务器层配置HSTS。如果Web服务器不明确支持HSTS，可以通过增加响应头的机制。如果其他方法都失败了，可以在应用程序层增加HSTS。

HSTS启用比较简单，只需在相应头中加上如下信息：

Strict-Transport-Security: max-age=63072000; includeSubdomains;preload;

Strict-Transport-Security是Header字段名，max-age代表HSTS在客户端的生效时间。 includeSubdomains表示对所有子域名生效。preload是使用浏览器内置的域名列表。

HSTS策略只能在HTTPS响应中进行设置，网站必须使用默认的443端口；必须使用域名，不能是IP。因此需要把HTTP重定向到HTTPS，如果明文响应中允许设置HSTS头，中间人攻击者就可以通过在普通站点中注入HSTS信息来执行DoS攻击。

Apache上启用HSTS

$ vim /etc/apache2/sites-available/hi-linux.conf
# 开启HSTS需要启用headers模块
LoadModule headers_module /usr/lib/apache2/modules/mod_headers.so

  ServerName www.hi-linux.com
  ServerAlias hi-linux.com
...
 #将所有访问者重定向到HTTPS,解决HSTS首次访问问题。
  RedirectPermanent / https://www.hi-linux.com/


...
# 启用HTTP严格传输安全
  Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
...

重启Apache服务

$ service apche2 restart

Nginx上启用HSTS

service nginx restart

IIS启用HSTS

要在IIS上启用HSTS需要用到第三方模块，具体可参考：https://hstsiis.codeplex.com/

测试设置是否成功

设置完成了后，可以用curl命令验证下是否设置成功。如果出来的结果中含有Strict-Transport-Security的字段，那么说明设置成功了。

参考文档

http://www.google.com
http://t.cn/RSzfyBb
https://yuan.ga/hsts-strict-https-enabled-site/
https://imququ.com/post/sth-about-switch-to-https.html
http://www.ttlsa.com/web/hsts-for-nginx-apache-lighttpd/
http://www.jianshu.com/p/66ddc3124006

原文来自：https://www.hi-linux.com/posts/3714.html

使用openSSL开源工具进行SSL/TLS 安全测试

Sun, 03 Dec 2017 06:18:14 +0000

本文介绍了使用半自动化工具执行SSL＆TLS安全性评估的过程，以及如何使用手动及工具的测试方法验证并发现问题。目的是优化TLS和SSL安全测试流程，帮助信息安全顾问在渗透测试时在TLS / SSL上花费更少的时间。

什么是TLS和SSL？

安全套接层（SSL）和传输层安全（TLS）加密用于通过互联网提供通信安全（传输加密）和来保护网络流量和互联网上的隐私，用于诸如网络，电子邮件，即时消息（IM）和一些虚拟专用网络（VPN）。

因此，TLS安全配置很重要，应花时间学习如何识别常见的漏洞和安全配置错误。

TLS / SSL安全测试工具

testssl.sh

testssl.sh是我们首选的测试工具，它涵盖了TLS和SSL评估所需的所有测试所需工具，并定期更新。

安装

您可以通过执行其git clone来安装最新版本的tesetssl.sh：

git clone https://github.com/drwetter/testssl.sh.git

testssl.sh示例

有许多可以用于testssl.sh的测试选项，您应该使用的选项将在很大程度上取决于您的测试要求。以下是部分有关testssl.sh命令行选项的示例。运行./testssl.sh可以看到所有选项。

测试单个主机上的所有内容并输出到控制台

./testssl.sh -e -E -f -p -y -Y -S -P -c -H -U TARGET-HOST

测试单个主机上的所有内容并输出到HTML

./testssl.sh -e -E -f -p -y -Y -S -P -c -H -U TARGET-HOST | aha> OUTPUT-FILE.html

测试子网上的所有主机并输出到HTML

./testssl.sh -e -E -f -p -y -Y -S -P -c -H -U 192.168.1.0/24 | aha> OUTPUT-FILE.html

...

查看原文：https://www.infinisign.com/faq/tls-ssl-security-testing

文章来源：http://www.mottoin.com/101154.html

已回答：Nginx配置问题

Wed, 15 Nov 2017 01:34:14 +0000

提问题不给日志。。。查看一下 /var/log/nginx/error.log

Nginx 安全性设置：https://www.sslzoo.com/112

配置SSL完整配置：https://www.infinisign.com/faq/the-best-safe-ssl-config-in-nginx

添加自签发的 SSL 证书为受信任的根证书

Mon, 03 Jul 2017 09:02:26 +0000

通过 SSL 加密的 HTTPS 连接访问网站时，需要安装并配置一个受信任的 CA 根证书（Trusted CA Root Certificate）。平常访问一些加密网站之所以不需要自己安装证书，是因为系统或浏览器已经提前安装了一些受信任机构颁发的证书。但有些时候访问一些组织或个人自己签发证书的网站的时候，就会收到浏览器发出的警告。此时可以将该证书添加到“受信任的根证书颁发机构”存储区，然后就不会再收到安全提示了。

1. 前言

为什么要自己签发安全证书（Self-signed CA）呢？因为一些受信任机构颁发的证书年费通常不菲，而且有些时候公司或者组织内部小范围使用的话没有信任问题，这时就可以自己签发一个安全证书。

对于这种安全证书，能否被信任就需要用户自己练就火眼金睛去识别了。比如我签发的证书，我的朋友就多半认为可以被信任，其他人不了解我的话就多半不信任。

在 VPS 上部署了 SSL 服务之后，因为证书（CA）是自己签发的，通过 HTTPS 加密链接访问网站的时候会提示证书不被信任之类的。可以将证书添加到 Windows 证书管理器的“受信任的根证书”目录中，以后 HTTPS 加密访问自己的网站就不会再收到安全提示了。

警告：只有当你确认要安装的安全证书是可以信任的情况下才能安装，否则可能带来严重的安全问题，甚至造成财产损失。下面将介绍如何安装非授权机构发行的安全证书为受信任的根证书。

因为安全证书管理机制不同，下面介绍中涉及到：

Internet Explorer 9 —— 微软系的都差不多，以下简称 IE。
Chrome —— Chrome 版本变动频繁，下面以 21.0.1180.60 版本为例，而且因为 Chrome 使用的就是 Windows 系统里的证书，没有独立的证书存储单元，所以搞定 IE 也就搞定 Chrome 了。从 Chrome 中打开证书管理器的方法是，设置（Settings）——> 高级设置（Advanced Settings）——> HTTPS / SSL ——> 管理证书（Manage Certificates …）。
Firefox —— Firefox 现在版本升级也很快了，好在界面、功能和操作变化不是太大，下面举例用的是 Firefox 15。Firefox 的安全证书管理是独立的，请参考另一篇文章：将自签发的 SSL 证书导入为 Firefox 中的受信任根证书。

2. 从Windows 自带的浏览器 Internet Explorer 中导入

使用 IE 通过 HTTPS 打开相应网站，会收到如下图所示的安全警告：

此网站的安全证书有问题。
此网站出具的安全证书不是由受信任的证书颁发机构颁发的。

安全证书问题可能显示试图欺骗您或截获您向服务器发送的数据。建议关闭此网页，并且不要继续浏览该网站。

单击此处关闭该网页。
继续浏览此网站(不推荐)。

详细信息
如果通过单击链接到达此页面，请检查地址栏中的网站以确保该地址是您希望到达的页面。转到如 https://example.com 等网站时，请尝试将 “www” 添加到地址中，变为 https://www.example.com。有关详细信息，请参阅 Internet Explorer 帮助中的“证书错误”。

在出现上图所示的证书错误警告时，如果幸运的话，可以在浏览器地址栏的最右边看到红色背景的文字“证书错误”（Certificate Error），如下图所示。

单击这个错误提示靠下位置的“查看证书（View certificates）”就可以看到该证书的详情，并可以直接安装该证书到 Windows 系统的证书管理器中。如下图所示。

因为是自己签发的安全证书而不是经过认证的机构签发的，所以 Windows 无法自动信任该证书：此 CA 根目录证书不被信任。要启用信任，请将该证书安装到“受信任的根证书颁发机构”存储区。单击“安装证书”按钮即可打开 Windows 证书导入向导，单击“下一步”即可开始安装证书，如下图所示。

然后系统会询问该证书的存储位置。因为是未经认证的组织或个人自己签发的证书，如果选择让 Windows “根据证书类型，自动选择证书存储”的话，一般会给存储到“中级证书颁发机构”中。以后加密访问该网站的时候还是会收到安全警告。

根据我们的需要 —— 以后打开自己的网站时候不会再发出安全警告，也就是本文的目的，而且又是自己签发的证书，信任不成问题，咱就直接给添加到“受信任的根证书颁发机构”存储中。如下图所示。

点选“将所有的证书放入下列存储(P)”，然后单击“浏览(R)”，打开“选择证书存储”窗口来选择。有些时候可能需要选择“显示物理存储区(S)”，然后勾选“受信任的根证书颁发机构”下面的“本地计算机（Local Computer）”来存储。

选择后单击“确定”按钮，然后“下一步”。此时可能会收到安全警告（如下图），提示添加的是“根（root）”证书（信任级别最高）。下图中所示证书就是水景一页自己签发的了。

剩下的就是确认几次，任务完成！然后关闭浏览器重新打开，就可以试试效果了。

3. 通过 Windows 证书管理器安装

因为 Windows 和 IE 都是微软自家的，管理的是同一个证书管理器。所以不管是从 Windows 系统的证书管理器中导入安装证书，还是直接根据 IE 的提示来安装，效果都是一样的。唯一不同的是，通过 Windows 证书管理器来安装证书的话，需要先将安全证书（.crt 类型的那个文件）保存到本地磁盘。如果不能直接获取该证书，请先看另一篇文章介绍的从 Firefox 证书管理器中导出安全证书一节吧。

在 Windows 7 中（via 微软），要查看或管理证书，必须以管理员身份进行登录，才能执行这些步骤。可以使用“证书管理器”查看有关证书的详细信息，修改、删除这些证书，或者申请新证书。要打开证书管理器：

通过单击“开始”按钮，在“搜索”框中键入 certmgr.msc，然后按 Enter，打开“证书管理器”。‌ 如果系统提示输入管理员密码或进行确认，则需要键入密码或提供确认。

先展开左边栏里的“受信任的根证书颁发机构”，选中其下的“证书”，然后点击菜单栏的“操作”——>“所有任务”——>“导入”，即可打开证书导入向导。然后就可以接着前面的“证书导入向导”那幅图（快速跳转）开始往下操作了。

另外，在查看证书详情那一步，如果打开详细信息标签页，可以看到有个复制到文件的按钮，单击此按钮即可保存该证书为一个 CA 文件。

4. Chrome 中的安全证书错误提示

因为 Chrome 使用的就是 Windows 系统里的证书，没有独立的证书存储单元，所以搞定 IE 也就搞定 Chrome 了。从 Chrome 中打开证书管理器的方法是，设置（Settings）——> 高级设置（Advanced Settings）——> HTTPS / SSL ——> 管理证书（Manage Certificates …）。

在 Chrome 中遇到网站证书问题时会收到类似下面的错误提示：

该网站的安全证书不受信任！
您尝试访问的是 cnzhx.net，但服务器出示的证书是由您计算机的操作系统不信任的实体所颁发。这可能表明服务器已自行生成了安全凭据，Google Chrome 浏览器认为其中的身份信息不可靠；也可能表明攻击者正试图拦截您的通信内容。
您不应再继续，尤其是如果您以前从未在此网站看到这一警告信息，则更不应继续操作。

仍然继续
返回安全连接
帮助我了解
连接安全网站时，网站所在的服务器会向您的浏览器出示所谓的“证书”，用于验证其身份。这种证书包含网站地址等身份信息，已经过您计算机信任的第三方验证。通过核实证书中的地址是否与网站地址相符，可以证实自己正与所要访问的网站进行安全通信，而不是正与第三方（如您网络中的攻击者）进行通信。这种情况下，证书未经过您计算机信任的第三方进行验证。任何人都可以创建证书，随意声称自己是任何网站，因此必须要由受信任的第三方对证书进行验证。如果未经上述验证，证书中的身份信息就没有意义。因此，您无法验证与自己通信的对象是真正的 cnzhx.net，还是某个自行生成证书，声称自己是 cnzhx.net 的攻击者。您应该就此停止操作。但是，如果您为之工作的组织机构会自行生成证书，而且您要尝试用此类证书连接本组织机构的内部网站，则您可以安全地解决此问题。您可将本组织机构的根证书作为“根证书”导入，由本组织机构颁发或验证的证书随即会得到信任，下次尝试连接内部网站时就不会出现此错误。请联系贵组织机构的支持人员，让他们协助您向计算机中添加新根证书。

文章来自：添加自签发的 SSL 证书为受信任的根证书

自己做CA，如何让用户导入证书来访问

Mon, 03 Jul 2017 08:46:29 +0000

有个项目，客户又需要https访问，又不想手动信任，现在想个办法，就像12306那样，手动导入证书。
请问这个证书怎么做

绕过自签名证书服务器的ssl认证，请求数据

Thu, 29 Jun 2017 06:45:33 +0000

自签名证书，通俗地解释就是自己作为CA颁发者，客户端访问时信任即可正常访问，以下引用：关于SSL中证书颁发机构（CA）的一些基本概念

一般自签名证书不能用来进行身份认证，如果一个服务端使用自签名证书，客户端两种方法，一种就是无条件信任该证书，另外一种则需要将自签名证书的公钥和私钥加入受信任列表。但这样一来就增加了服务器的私钥泄露风险。

那么在一些特定环境场景中，我们需要使用ajax方式请求来自自签名证书服务器的接口，在浏览器中我们可以手动信任，在数据请求中，我们通常只能绕过证书认证来获取到数据

1、jQuery中最简单粗暴地使用jsonp方式

$.ajax({
    url : '//sslzoo.com',
    type : "POST",
    dataType : 'jsonp',
    data : params,
    jsonp: 'callback'//传递给后台程序，用来获取jsonp回调函数名的参数名
    success : function(data) {}
})

url参照非同源接口的方式请求，返回的数据格式为jsonp

参考：http://www.cnblogs.com/koleyang/p/4654439.html

http://blog.csdn.net/xiangnan129/article/details/54409089

2、PHP下解决思路还是跳过ssl认证

在curl请求时，加入以下代码

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); // 跳过证书检查  
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true);  // 从证书中检查SSL加密算法是否存在

原文引用来自：http://blog.csdn.net/fdipzone/article/details/39611461

<?php
/** curl 获取 https 请求
* @param String $url        请求的url
* @param Array  $data       要發送的數據
* @param Array  $header     请求时发送的header
* @param int    $timeout    超时时间，默认30s
*/
function curl_https($url, $data=array(), $header=array(), $timeout=30){

    $ch = curl_init();
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); // 跳过证书检查
    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true);  // 从证书中检查SSL加密算法是否存在
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_HTTPHEADER, $header);
    curl_setopt($ch, CURLOPT_POST, true);
    curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($data));
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); 
    curl_setopt($ch, CURLOPT_TIMEOUT, $timeout);

    $response = curl_exec($ch);

    if($error=curl_error($ch)){
        die($error);
    }

    curl_close($ch);

    return $response;

}

// 调用
$url = 'https://www.example.com/api/message.php';
$data = array('name'=>'fdipzone');
$header = array();

$response = curl_https($url, $data, $header, 5);

echo $response;
?>

3、JAVA中绕过SSL认证

JAVA中主要使用HttpClient进行POST请求（HTTPS），用一个类继承DefaultHttpClient类，忽略校验过程。

原文来自：http://blog.csdn.net/rongyongfeikai2/article/details/41659353#

a. 写一个SSLClient类，继承至HttpClient

import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;
import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManager;
import javax.net.ssl.X509TrustManager;
import org.apache.http.conn.ClientConnectionManager;
import org.apache.http.conn.scheme.Scheme;
import org.apache.http.conn.scheme.SchemeRegistry;
import org.apache.http.conn.ssl.SSLSocketFactory;
import org.apache.http.impl.client.DefaultHttpClient;
//用于进行Https请求的HttpClient
public class SSLClient extends DefaultHttpClient{
	public SSLClient() throws Exception{
        super();
        SSLContext ctx = SSLContext.getInstance("TLS");
        X509TrustManager tm = new X509TrustManager() {
                @Override
                public void checkClientTrusted(X509Certificate[] chain,
                        String authType) throws CertificateException {
                }
                @Override
                public void checkServerTrusted(X509Certificate[] chain,
                        String authType) throws CertificateException {
                }
                @Override
                public X509Certificate[] getAcceptedIssuers() {
                    return null;
                }
        };
        ctx.init(null, new TrustManager[]{tm}, null);
        SSLSocketFactory ssf = new SSLSocketFactory(ctx,SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
        ClientConnectionManager ccm = this.getConnectionManager();
        SchemeRegistry sr = ccm.getSchemeRegistry();
        sr.register(new Scheme("https", 443, ssf));
    }
}

b. 写一个利用HttpClient发送post请求的类

import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
import java.util.Map.Entry;
import org.apache.http.HttpEntity;
import org.apache.http.HttpResponse;
import org.apache.http.NameValuePair;
import org.apache.http.client.HttpClient;
import org.apache.http.client.entity.UrlEncodedFormEntity;
import org.apache.http.client.methods.HttpPost;
import org.apache.http.message.BasicNameValuePair;
import org.apache.http.util.EntityUtils;
/*
 * 利用HttpClient进行post请求的工具类
 */
public class HttpClientUtil {
	public String doPost(String url,Map<String,String> map,String charset){
		HttpClient httpClient = null;
		HttpPost httpPost = null;
		String result = null;
		try{
			httpClient = new SSLClient();
			httpPost = new HttpPost(url);
			//设置参数
			List<NameValuePair> list = new ArrayList<NameValuePair>();
			Iterator iterator = map.entrySet().iterator();
			while(iterator.hasNext()){
				Entry<String,String> elem = (Entry<String, String>) iterator.next();
				list.add(new BasicNameValuePair(elem.getKey(),elem.getValue()));
			}
			if(list.size() > 0){
				UrlEncodedFormEntity entity = new UrlEncodedFormEntity(list,charset);
				httpPost.setEntity(entity);
			}
			HttpResponse response = httpClient.execute(httpPost);
			if(response != null){
				HttpEntity resEntity = response.getEntity();
				if(resEntity != null){
					result = EntityUtils.toString(resEntity,charset);
				}
			}
		}catch(Exception ex){
			ex.printStackTrace();
		}
		return result;
	}
}

当然了，大费周折只是为了绕过ssl认证，而廉价的DV数字证书足以应付基本的安全需求，又何来自签名证书场景呢。

macOS 10.12升级之后要做的事

Thu, 29 Jun 2017 06:04:47 +0000

Mac升级之后因为xcode的版本原因，诸如Maven，SVN，JAVA等工具失效，报出一些常规错误，下述现象基于你各种环境变量配置正确前提之下。

1、SVN和Git一类的工具，多数因为xcode升级原因，打开终端工具（命令行），安装xcode

xcode-select --install

跳出安装界面等待完成之后，SVN和Git一类工具正常使用。

2、Maven和Java使用时报JAVA_HOME is not defined correctly错误

这类问题，软连接的问题导致，Mac在升级之后，缺少CurrentJDK的软连接，报错信息如下：

Error: JAVA_HOME is not defined correctly. 
We cannot execute /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/bin/java

创建软连接

cd /System/Library/Frameworks/JavaVM.framework/Versions/
sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents CurrentJDK

在macOS 10.12版本中会有提示Operation Not Permitted错误，原因是权限不够，重启电脑按住command + R 进入恢复模式后，选择“实用工具 - 终端”，键入命令允许操作受保护文件的操作权限：

csrutil disable
reboot

该解释，请参考：http://bbs.pcbeta.com/viewthread-1605186-1-1.html

再次执行上述软连接，成功。

多IP部署SSL检测功能推出

Tue, 09 May 2017 10:56:57 +0000

接到匿名反馈的需求，需要多IP部署的SSL检测功能，引用邮件原文：

我在国外和国内各部署了一套服务器，想检测一下ssl的安全性，但是你们的服务器解析到了国外的ip地址。请问如何才能监测国内的服务器呢？

现访问：https://sslzoo.com/sslcheck/ 尝试在IP栏输入IP，检测指定IP的网站SSL部署情况，不输入IP，默认第一个结果的评估结果。

如果并不知道IP地址，可以不输入，系统会检测出所有IP地址。

增强 nginx 的 SSL 安全性

Wed, 15 Mar 2017 08:08:53 +0000

本站注：上图是基于ssllabs API开发的SSL验证部署评级工具，涵盖了SSL证书、证书链、传输协议、加密套件、握手模拟设备兼容性测试、漏洞检测等所有功能，请扫描右侧二维码或添加公众号：sslzoo 使用本工具，可直接访问：https://sslzoo.com/sslcheck/

原文如下：

本文向你介绍如何在 nginx 服务器上设置健壮的 SSL 安全机制。我们通过禁用 SSL 压缩来降低 CRIME 攻击威胁；禁用协议上存在安全缺陷的 SSLv3 及更低版本，并设置更健壮的加密套件（cipher suite）来尽可能启用前向安全性（Forward Secrecy）；此外，我们还启用了 HSTS 和 HPKP。这样我们就拥有了一个健壮而可经受考验的 SSL 配置，并可以在 Qually Labs 的 SSL 测试中得到 A 级评分。

如果不求甚解的话，可以从 https://cipherli.st 上找到 nginx 、Apache 和 Lighttpd 的安全设置，复制粘帖即可。

本教程在 Digital Ocean 的 VPS 上测试通过。如果你喜欢这篇教程，想要支持作者的站点的话，购买 Digital Ocean 的 VPS 时请使用如下链接：https://www.digitalocean.com/?refcode=7435ae6b8212 。

本教程可以通过发布于 2014/1/21 的 SSL 实验室测试的严格要求（我之前就通过了测试，如果你按照本文操作就可以得到一个 A+ 评分）。

如果不求甚解的话，可以从 https://cipherli.st 上找到 nginx 、Apache 和 Lighttpd 的安全设置，复制粘帖即可。

本教程可以通过发布于 2014/1/21 的 SSL 实验室测试的严格要求（我之前就通过了测试，如果你按照本文操作就可以得到一个 A+ 评分）。

本教程也可用于 Apache
本教程也可用于 Lighttpd
本教程也可用于 FreeBSD, NetBSD 和 OpenBSD 上的 nginx ，放在 BSD Now 播客上: http://www.bsdnow.tv/tutorials/nginx

你可以从下列链接中找到这方面的进一步内容：

我们需要编辑 nginx 的配置，在 Ubuntu/Debian 上是 /etc/nginx/sited-enabled/yoursite.com，在 RHEL/CentOS 上是 /etc/nginx/conf.d/nginx.conf。

本文中，我们需要编辑443端口（SSL）的 server 配置中的部分。在文末你可以看到完整的配置例子。

在编辑之前切记备份一下配置文件！

野兽攻击（BEAST）和 RC4

简单的说，野兽攻击（BEAST）就是通过篡改一个加密算法的 CBC（密码块链）的模式，从而可以对部分编码流量悄悄解码。更多信息参照上面的链接。

针对野兽攻击（BEAST），较新的浏览器已经启用了客户端缓解方案。推荐方案是禁用 TLS 1.0 的所有加密算法，仅允许 RC4 算法。然而，针对 RC4 算法的攻击也越来越多，很多已经从理论上逐步发展为实际可行的攻击方式。此外，有理由相信 NSA 已经实现了他们所谓的“大突破”——攻破 RC4 。

禁用 RC4 会有几个后果。其一，当用户使用老旧的浏览器时，比如 Windows XP 上的 IE 会用 3DES 来替代 RC4。3DES 要比 RC4 更安全，但是它的计算成本更高，你的服务器就需要为这些用户付出更多的处理成本。其二，RC4 算法能减轻野兽攻击（BEAST）的危害，如果禁用 RC4 会导致 TLS 1.0 用户会换到更容易受攻击的 AES-CBC 算法上（通常服务器端的对野兽攻击（BEAST）的“修复方法”是让 RC4 优先于其它算法）。我认为 RC4 的风险要高于野兽攻击（BEAST）的风险。事实上，有了客户端缓解方案（Chrome 和 Firefox 提供了缓解方案），野兽攻击（BEAST）就不是什么大问题了。而 RC4 的风险却在增长：随着时间推移，对加密算法的破解会越来越多。

怪物攻击（FREAK）

怪物攻击（FREAK）是一种中间人攻击，它是由来自 INRIA、微软研究院和 IMDEA 的密码学家们所发现的。怪物攻击（FREAK）的缩写来自“Factoring RSA-EXPORT Keys（RSA 出口密钥因子分解）”

这个漏洞可上溯到上世纪九十年代，当时美国政府禁止出口加密软件，除非其使用编码密钥长度不超过512位的出口加密套件。

这造成了一些现在的 TLS 客户端存在一个缺陷，这些客户端包括：苹果的 SecureTransport 、OpenSSL。这个缺陷会导致它们会接受出口降级 RSA 密钥，即便客户端并没有要求使用出口降级 RSA 密钥。这个缺陷带来的影响很讨厌：在客户端存在缺陷，且服务器支持出口降级 RSA 密钥时，会发生中间人攻击，从而导致连接的强度降低。

攻击分为两个组成部分：首先是服务器必须接受“出口降级 RSA 密钥”。

中间人攻击可以按如下流程：

在客户端的 Hello 消息中，要求标准的 RSA 加密套件。
中间人攻击者修改该消息为‘export RSA’（输出级 RSA 密钥）。
服务器回应一个512位的输出级 RSA 密钥，并以其长期密钥签名。
由于 OpenSSL/SecureTransport 的缺陷，客户端会接受这个弱密钥。
攻击者根据 RSA 模数分解因子来恢复相应的 RSA 解密密钥。
当客户端编码‘pre-master secret’（预主密码）给服务器时，攻击者现在就可以解码它并恢复 TLS 的‘master secret’（主密码）。
从这里开始，攻击者就能看到了传输的明文并注入任何东西了。

本文所提供的加密套件不启用输出降级加密，请确认你的 OpenSSL 是最新的，也强烈建议你将客户端也升级到新的版本。

心血漏洞（Heartbleed）

心血漏洞（Heartbleed）是一个于2014年4月公布的 OpenSSL 加密库的漏洞，它是一个被广泛使用的传输层安全（TLS）协议的实现。无论是服务器端还是客户端在 TLS 中使用了有缺陷的 OpenSSL，都可以被利用该缺陷。由于它是因 DTLS 心跳扩展（RFC 6520）中的输入验证不正确（缺少了边界检查）而导致的，所以该漏洞根据“心跳”而命名。这个漏洞是一种缓存区超读漏洞，它可以读取到本不应该读取的数据。

哪个版本的 OpenSSL 受到心血漏洞（Heartbleed）的影响？

各版本情况如下：

OpenSSL 1.0.1 直到 1.0.1f （包括）存在该缺陷
OpenSSL 1.0.1g 没有该缺陷
OpenSSL 1.0.0 分支没有该缺陷
OpenSSL 0.9.8 分支没有该缺陷

这个缺陷是2011年12月引入到 OpenSSL 中的，并随着 2012年3月14日 OpenSSL 发布的 1.0.1 而泛滥。2014年4月7日发布的 OpenSSL 1.0.1g 修复了该漏洞。

升级你的 OpenSSL 就可以避免该缺陷。

SSL 压缩（罪恶攻击 CRIME）

罪恶攻击（CRIME）使用 SSL 压缩来完成它的魔法，SSL 压缩在下述版本是默认关闭的： nginx 1.1.6及更高/1.0.9及更高（如果使用了 OpenSSL 1.0.0及更高）， nginx 1.3.2及更高/1.2.2及更高（如果使用较旧版本的 OpenSSL）。

如果你使用一个早期版本的 nginx 或 OpenSSL，而且你的发行版没有向后移植该选项，那么你需要重新编译没有一个 ZLIB 支持的 OpenSSL。这会禁止 OpenSSL 使用 DEFLATE 压缩方式。如果你禁用了这个，你仍然可以使用常规的 HTML DEFLATE 压缩。

SSLv2 和 SSLv3

SSLv2 是不安全的，所以我们需要禁用它。我们也禁用 SSLv3，因为 TLS 1.0 在遭受到降级攻击时，会允许攻击者强制连接使用 SSLv3，从而禁用了前向安全性（forward secrecy）。

如下编辑配置文件：

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

卷毛狗攻击（POODLE）和 TLS-FALLBACK-SCSV

SSLv3 会受到卷毛狗漏洞（POODLE）的攻击。这是禁用 SSLv3 的主要原因之一。

Google 提出了一个名为 TLS_FALLBACK_SCSV 的SSL/TLS 扩展，它用于防止强制 SSL 降级。如果你升级到下述的 OpenSSL 版本会自动启用它。

OpenSSL 1.0.1 带有 TLS_FALLBACK_SCSV 1.0.1j 及更高。
OpenSSL 1.0.0 带有 TLS_FALLBACK_SCSV 1.0.0o 及更高。
OpenSSL 0.9.8 带有 TLS_FALLBACK_SCSV 0.9.8zc 及更高。

更多信息请参照 NGINX 文档。

加密套件（cipher suite）

前向安全性（Forward Secrecy）用于在长期密钥被破解时确保会话密钥的完整性。PFS（完备的前向安全性）是指强制在每个/每次会话中推导新的密钥。

这就是说，泄露的私钥并不能用来解密（之前）记录下来的 SSL 通讯。

提供PFS（完备的前向安全性）功能的是那些使用了一种 Diffie-Hellman 密钥交换的短暂形式的加密套件。它们的缺点是系统开销较大，不过可以使用椭圆曲线的变体来改进。

以下两个加密套件是我推荐的，之后Mozilla 基金会也推荐了。

推荐的加密套件：

ssl_ciphers 'AES128+EECDH:AES128+EDH';

向后兼容的推荐的加密套件（IE6/WinXP）：

ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

如果你的 OpenSSL 版本比较旧，不可用的加密算法会自动丢弃。应该一直使用上述的完整套件，让 OpenSSL 选择一个它所支持的。

加密套件的顺序是非常重要的，因为其决定了优先选择哪个算法。上述优先推荐的算法中提供了PFS（完备的前向安全性）。

较旧版本的 OpenSSL 也许不能支持这个算法的完整列表，AES-GCM 和一些 ECDHE 算法是相当新的，在 Ubuntu 和 RHEL 中所带的绝大多数 OpenSSL 版本中不支持。

优先顺序的逻辑

ECDHE+AESGCM 加密是首选的。它们是 TLS 1.2 加密算法，现在还没有广泛支持。当前还没有对它们的已知攻击。
PFS 加密套件好一些，首选 ECDHE，然后是 DHE。
AES 128 要好于 AES 256。有一个关于 AES256 带来的安全提升程度是否值回成本的讨论，结果是显而易见的。目前，AES128 要更值一些，因为它提供了不错的安全水准，确实很快，而且看起来对时序攻击更有抵抗力。
在向后兼容的加密套件里面，AES 要优于 3DES。在 TLS 1.1及其以上，减轻了针对 AES 的野兽攻击（BEAST）的威胁，而在 TLS 1.0上则难以实现该攻击。在非向后兼容的加密套件里面，不支持 3DES。
RC4 整个不支持了。3DES 用于向后兼容。参看 #RC4_weaknesses 中的讨论。

强制丢弃的算法

aNULL 包含了非验证的 Diffie-Hellman 密钥交换，这会受到中间人（MITM）攻击
eNULL 包含了无加密的算法（明文）
EXPORT 是老旧的弱加密算法，是被美国法律标示为可出口的
RC4 包含的加密算法使用了已弃用的 ARCFOUR 算法
DES 包含的加密算法使用了弃用的数据加密标准（DES）
SSLv2 包含了定义在旧版本 SSL 标准中的所有算法，现已弃用
MD5 包含了使用已弃用的 MD5 作为哈希算法的所有算法

更多设置

确保你也添加了如下行：

ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;

在一个 SSLv3 或 TLSv1 握手过程中选择一个加密算法时，一般使用客户端的首选算法。如果设置了上述配置，则会替代地使用服务器端的首选算法。

前向安全性和 Diffie Hellman Ephemeral （DHE）参数

前向安全性（Forward Secrecy）的概念很简单：客户端和服务器协商一个永不重用的密钥，并在会话结束时销毁它。服务器上的 RSA 私钥用于客户端和服务器之间的 Diffie-Hellman 密钥交换签名。从 Diffie-Hellman 握手中获取的预主密钥会用于之后的编码。因为预主密钥是特定于客户端和服务器之间建立的某个连接，并且只用在一个限定的时间内，所以称作短暂模式（Ephemeral）。

使用了前向安全性，如果一个攻击者取得了一个服务器的私钥，他是不能解码之前的通讯信息的。这个私钥仅用于 Diffie Hellman 握手签名，并不会泄露预主密钥。Diffie Hellman 算法会确保预主密钥绝不会离开客户端和服务器，而且不能被中间人攻击所拦截。

所有版本的 nginx（如1.4.4）都依赖于 OpenSSL 给 Diffie-Hellman （DH）的输入参数。不幸的是，这意味着 Diffie-Hellman Ephemeral（DHE）将使用 OpenSSL 的默认设置，包括一个用于密钥交换的1024位密钥。因为我们正在使用2048位证书，DHE 客户端就会使用一个要比非 DHE 客户端更弱的密钥交换。

我们需要生成一个更强壮的 DHE 参数：

cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 4096

然后告诉 nginx 将其用作 DHE 密钥交换：

ssl_dhparam /etc/ssl/certs/dhparam.pem;

OCSP 装订（Stapling）

当连接到一个服务器时，客户端应该使用证书吊销列表（CRL）或在线证书状态协议（OCSP）记录来校验服务器证书的有效性。CRL 的问题是它已经增长的太大了，永远也下载不完了。

OCSP 更轻量级一些，因为我们每次只请求一条记录。但是副作用是当连接到一个服务器时必须对第三方 OCSP 响应器发起 OCSP 请求，这就增加了延迟和带来了潜在隐患。事实上，CA 所运营的 OCSP 响应器非常不可靠，浏览器如果不能及时收到答复，就会静默失败。攻击者通过 DoS 攻击一个 OCSP 响应器可以禁用其校验功能，这样就降低了安全性。

解决方法是允许服务器在 TLS 握手中发送缓存的 OCSP 记录，以绕开 OCSP 响应器。这个机制节省了客户端和 OCSP 响应器之间的通讯，称作 OCSP 装订。

客户端会在它的 CLIENT HELLO 中告知其支持 status_request TLS 扩展，服务器仅在客户端请求它的时候才发送缓存的 OCSP 响应。

大多数服务器最多会缓存 OCSP 响应48小时。服务器会按照常规的间隔连接到 CA 的 OCSP 响应器来获取刷新的 OCSP 记录。OCSP 响应器的位置可以从签名的证书中的授权信息访问（Authority Information Access）字段中获得。

阅读我的教程：在 NGINX 中启用 OCSP 装订

HTTP 严格传输安全（HSTS）

如有可能，你应该启用 HTTP 严格传输安全（HSTS），它会引导浏览器和你的站点之间的通讯仅通过 HTTPS。

阅读我关于 HSTS 的文章，了解如何配置它

HTTP 公钥固定扩展（HPKP）

你也应该启用 HTTP 公钥固定扩展（HPKP）。

公钥固定的意思是一个证书链必须包括一个白名单中的公钥。它确保仅有白名单中的 CA 才能够为某个域名签署证书，而不是你的浏览器中存储的任何 CA。

我已经写了一篇关于 HPKP 的背景理论及在 Apache、Lighttpd 和 NGINX 中配置例子的文章。

配置范例

server {

  listen [::]:443 default_server;

  ssl on;
  ssl_certificate_key /etc/ssl/cert/raymii_org.pem;
  ssl_certificate /etc/ssl/cert/ca-bundle.pem;

  ssl_ciphers 'AES128+EECDH:AES128+EDH:!aNULL';

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_session_cache shared:SSL:10m;

  ssl_stapling on;
  ssl_stapling_verify on;
  resolver 8.8.4.4 8.8.8.8 valid=300s;
  resolver_timeout 10s;

  ssl_prefer_server_ciphers on;
  ssl_dhparam /etc/ssl/certs/dhparam.pem;

  add_header Strict-Transport-Security max-age=63072000;
  add_header X-Frame-Options DENY;
  add_header X-Content-Type-Options nosniff;

  root /var/www/;
  index index.html index.htm;
  server_name raymii.org;

}

结尾

如果你使用了上述配置，你需要重启 nginx：

# 首先检查配置文件是否正确
/etc/init.d/nginx configtest
# 然后重启
/etc/init.d/nginx restart

现在使用 SSL Labs 测试来看看你是否能得到一个漂亮的“A”。当然了，你也得到了一个安全的、强壮的、经得起考验的 SSL 配置！

via: https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html
作者：Remy van Elst 译者：wxy 校对：wxy，译文地址：LCCT
本文由 LCTT 原创翻译，Linux中国荣誉推出

本站注：

原著中配置add_header X-Frame-Options DENY 会导致前端框架报X-Frame-Options错，比如上传组件，此功能是为了SSL安全而设，意为不允许用 frame 来嵌套，所以这里要改为：

 add_header X-Frame-Options SAMEORIGIN; ## 只允许本站用 frame 来嵌套

已回答：Apache下的Comodo证书不被iOS信任或者服务器缺少中间证书

Thu, 16 Feb 2017 01:59:30 +0000

所有证书都会存在中级根证书的需求，如果要通过IOS验证

已回答：Question2Answer 响应式模板sslzoo开源免费共享

Wed, 08 Feb 2017 02:17:03 +0000

开源精神，欢迎开帖咨询。

已回答：joomla能够和question2answer整合吗？

Wed, 08 Feb 2017 01:04:57 +0000

1、一篇旧的整合文章

具体参考文章：http://www.question2answer.org/qa/20758/how-to-integrate-joomla-with-q2a-single-sign-on-solved

我不太建议用Joomla管理用户组，Joomla还是比较适合做内容展示。

上述方案目前我还没测试过，简单先看一下，有时间我测试翻译一下

2、Q2A 1.8.x 支持

此外，在Q2A 1.8.x 中官方已经对Joomla!进行了支持，参考：

https://github.com/q2a/question2answer/tree/1.8

Out-of-the-box Joomla! 3.0+ integration (in conjunction with a Joomla! extension).

3、Joomla中安装插件

下载插件：https://github.com/SFWLtd/plg_q2a_integration/releases

Joomla官网：https://extensions.joomla.org/extensions/extension/communication/question-a-answers/integration-for-question2answer/

已回答：IIS下证书迁移

Tue, 07 Feb 2017 06:31:56 +0000

导出备份时注意记住pfx密码

开通腾讯免费企业邮箱用于申请SSL数字证书的域名所有权验证

Wed, 25 Jan 2017 03:25:53 +0000

我们知道，企业邮箱其实和企业关系不是太大，也许我们只是要开通一个postmaster@sslzoo.com的邮箱而已，也不必因此要购买高大上的企业邮箱服务，那么免费的企业邮箱就是必选方案了，企业邮箱免费又好用想必就是腾讯免费企业邮箱了。

在这里主要由于申请SSL数字证书时候，需要对域名所有权进行验证，通常在域名注册商注册域名的时候留下个人邮箱可以证明拥有该域名所有权，但是一些注册商可能提供了隐私保护服务，那么这个时候SSL证书验证域名所有权就发现不了该个人邮箱，所以需要借助企业邮箱。

如上图所示，我们需要创建一个postmaster@sslzoo.com的邮箱

前往 http://exmail.qq.com 看到如此配置，已经知足了，2G容量

立即开通，使用微信扫码注册

填写管理员信息，账号信息而已，还没到邮箱配置

添加企业域名，域名自选

注册成功后，首先要添加域名的MX解析记录，主机记录可不填。其它保持默认。

记录值：mxbiz1.qq.com 优先级：5
记录值：mxbiz2.qq.com 优先级：10

登录刚才创建的账号，添加成员

通常我们首先创建的是postmaster账号，它是一个验证域名所有权的邮箱账号，例如在申请SSL数字证书的时候，就需要这个邮箱账号：

填入postmaster名称，增加邮箱密码，如果希望一直使用该密码，下方不要勾选“首次登录修改初始密码”。

如果勾选了，下方初次登录邮箱要修改密码。

退出登录，然后直接使用邮箱登录

IIS8.x中安装证书及常见错误

Mon, 23 Jan 2017 12:34:19 +0000

以Windows Server 2012中的IIS8为例，本文主要介绍如何生成CSR证书请求文件，以及在IIS8中安装数字证书遇到的问题及解决方案。

1、生成服务器CSR证书请求文件

打开IIS，点击服务器名称，主界面找到“服务器证书（Server Certificates）”

点击右侧按钮“创建证书申请（Create Certificate Request...）”

弹开对话框输入以下内容

通用名称(M) / Common Name - 就是输入你的域名，例如sslzoo.com或者www.sslzoo.com
组织(O) / Organization - 可以是域名也可以是英文简称或者是公司名称
组织单位(U) / Organizational unit - 通常是IT Support
城市/地点(L) / City/locality - 英文简称HeFei
省/市/自治区(S) / State/province - 英文简称AnHui
国家/地区(R) / Country/region - 一般你肯定是CN

小技巧：通用名称(M) / Common Name 可以直接用顶级域名，这样做nginx部署的时候，可以用 https://sslzoo.com/ 做静态服务， https://www.sslzoo.com 做主服务，相当于这个证书两用了，省去了通配符证书的钱。

下一步，选择Microsoft RSA SChannel..，加密位为2048位

点击下一步，选择输入CSR文件路径

到这里我们输出的CSR文件就已经结束了，把这个CSR文件提交给sslzoo.com申请CA机构的数字证书

2、申请数字证书注意事项

如果你的域名是在国内注册商注册，鉴于有隐私保护之类的原因，申请数字证书的时候，你可能要准备一下免费企业邮箱。

不管是域名型证书（DV）还是机构型证书（OV）都需要验证域名所有权。如下图所示域名是在aliyun注册的，所以真实的注册者邮箱无法使用，这时候需要配置该域名的企业邮箱，建议申请腾讯的免费企业邮，详情参考：开通腾讯免费企业邮箱用于申请SSL数字证书的域名所有权验证

GeoTrust和Symantec支持在线重新签发证书，Comodo需要通过sslzoo.com提交工单申请重新签发，重新签发都是免费的。详情参考：重新签发你的数字证书

3、安装数字证书

回到第一步开始，点击面板右侧按钮“完成证书申请（Complete Certificate Request..）”

将CA机构发给你的邮件中的证书或者代码保存为`*.cer`格式的文件，然后下图窗口中选择该证书文件。并创建一个友好名称。

通常上图点击确认（OK）之后能顺利导入，这时候主面板会出现名为yourdomain.com的证书，如果刷新或者按F5之后这个证书不见了，实际上这个证书已经导入成功，有可能是你的私钥被删除了，需要进行私钥恢复，此外IIS8中会有个人、WEB宿主的区别，请参考“IIS中恢复SSL数字证书私钥”

证书导入成功后，需要进行证书绑定（Bindings...）

添加一个https类型

选择https后，填入443端口、选择安装好的数字证书。

确定后可以看到此时多了一个443的端口

重启IIS服务器。

如果需要安装多个数字证书，重复上述步骤后，在绑定端口的时候注意的是，钩选“需要服务器名称显示（Require Server Name Indication）”

IIS中恢复SSL数字证书私钥

Mon, 23 Jan 2017 12:28:09 +0000

通常下图点击确认（OK）之后能顺利导入，这时候主面板会出现名为yourdomain.com的证书，如果刷新或者按F5之后这个证书不见了，实际上这个证书已经导入成功，有可能是你的私钥被删除了，需要进行私钥恢复，所以需要进行下述操作：

开始 > 运行 > MMC，启动控制台程序 -> 选择菜单“文件” > “添加/删除管理单元” > 列表中选择“证书” > 点击“添加” > 选择“计算机帐户” > 点击完成。在控制台的左侧显示证书树形列表。

此时点击左侧“个人” > “证书”，右侧可以看到刚才导入的证书，选择“属性”

找到序列号，复制序列号，并去掉空格

然后使用管理员运行cmd，命令行中输入代码开始恢复私钥

certutil -repairstore my 00D30C9A09DF00BCD9449298481E8C2117

回车之后如果提示下图，即表示成功恢复证书对应的私钥

这时候再看看MMC中的“个人” > “证书”，右侧的数字证书会多出一把小钥匙的样式，表示该数字证书与私钥匹配成功。

以下在IIS8中存在，如果选择是WEB宿主，导入证书时提示错误更为粗暴

那么可以借助上述“个人”证书的方式，在MMC中将“个人”下面证书复制到“WEB宿主”的证书中，WINDOWS下的CTRL+C、CTRL+V就可以了。

右击此时的证书，选择“属性”，给其定义一个友好名称。

此时在IIS主面板中就应该可以看到这个“WEB宿主证书了”，剩下就可以进行IIS8.x中安装证书

已回答：Tomcat环境怎么跑安装SSL

Sat, 06 Aug 2016 10:04:34 +0000

Windows下：http://www.sslzoo.com/96

Windows + Tomcat 6 安装SSL数字证书

Sat, 06 Aug 2016 10:03:10 +0000

1. 生成证书请求
1.1 安装JDK

安装Tomcat需要JDK支持。JDK1.6默认只支持 SSLv3 和 TLSv1 两个版本的https协议，JDK 1.7 版本默认禁用SSLv3，并支持 TLSv1、TLSv1.1及TLSv1.2。Tomcat 6及以下版本在使用 JDK 1.6及以下版本的运行环境时，可能存在无法禁用 SSLv3的情况。此时建议您升级 Tomcat 及 JDK版本，或变更使用 APR模块来配置SSL证书，以确保安全方式安装及使用服务器证书。

1.2 生成keystore文件

生成密钥库文件keystore.jks需要使用JDK的keytool工具。命令行进入JDK或JRE下的bin目录，运行keytool命令（示例中粗体部分为可自定义部分，可根据实际配置情况相应修改）。

keytool -genkey -alias server -keyalg RSA -keysize 2048 -keystore D:\keystore.jks -storepasspassword -keypass password

以上命令中，server为私钥别名(-alias)，生成的keystore.jks文件默认放在D盘根目录下。

1.3 生成证书请求文件(CSR)

keytool -certreq -alias server -sigalg SHA256withRSA -file D:\certreq.csr -keystore D:\keystore.jks -keypass password -storepass password

请备份密钥库文件keystore.jks，并稍后提交证书请求文件certreq.csr，等待证书签发。密钥库文件keystore.jks丢失将导致证书不可用。

2. 导入服务器证书

2.1 获取服务器证书

将证书签发邮件中的从BEGIN到 END结束的服务器证书内容（包括“-----BEGIN CERTIFICATE-----”和“-----END CERTIFICATE-----”）粘贴到记事本等文本编辑器中，并修改文件扩展名，保存为server.cer文件

2.2 获取CA证书

将证书签发邮件中的从BEGIN到 END结束的两张 CA证书内容（包括“-----BEGIN CERTIFICATE-----”和“-----END CERTIFICATE-----”）分别粘贴到记事本等文本编辑器中，并修改文件扩展名，保存为ca1.ce r和 ca2.cer文件。

2.3 查看keystore文件内容

进入JDK安装目录下的bin目录，运行keytool命令查询keystore文件信息。

keytool -list -keystore D:\keystore.jks -storepass password

查询到PrivateKeyEntry（或KeyEntry）属性的私钥别名(alias)为server。记住该别名，在稍后导入服务器证书时需要用到（示例中粗体部分为可自定义部分，可根据实际配置情况相应修改）。

注意，导入证书时，一定要使用生成证书请求文件时生成的keystore.jks文件。keystore.jks文件丢失或生成新的keystore.jks文件，都将无法正确导入您的服务器证书。

2.4 导入证书(如果只有一张CA证书，则只需要导入一张CA证书)

导入第一张中级CA证书

keytool -import -alias ca1 -keystore D:\keystore.jks -trustcacerts -storepass password -file D:\ca1.cer -noprompt

导入第二张中级CA证书

keytool -import -alias ca2 -keystore D:\keystore.jks -trustcacerts -storepass password -file D:\ca2.cer -noprompt

导入服务器证书

keytool -import -alias server -keystore D:\keystore.jks -trustcacerts -storepass password -keypass password -file D:\server.cer

导入服务器证书时，服务器证书的别名必须和私钥别名一致。请留意导入中级CA证书和导入服务器证书时的提示信息，如果您在导入服务器证书时使用的别名与私钥别名不一致，将提示“认证已添加至keystore中”而不是应有的“认证回复已安装在keystore中”。

证书导入完成，运行keystool命令，再次查看keystore文件内容

keytool -list -keystore D:\keystore.jks -storepass password

3. 安装服务器证书

3.1 配置Tomcat

复制已正确导入认证回复的keystore.jks文件到Tomcat安装目录下的conf目录。打开conf目录下的server.xml文件，找到并修改以下内容

<!--
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS" />
SSL访问端口
-->

修改为

<Connector port="443" protocol="org.apache.coyote.http11.Http11Protocol" SSLEnabled="true" 
maxThreads="150" scheme="https" secure="true" 
keystoreFile="conf\keystore.jks" keystorePass="password" 
clientAuth="false" sslProtocol="TLS" 
ciphers="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256"  />

默认的SSL访问端口号为443，如果使用其他端口号，则您需要使用https://yourdomain:port 的方式来访问您的站点。

3.2 访问测试

重启Tomcat，访问https://youdomain:port，测试证书的安装。

4. 服务器证书的备份及恢复

在您成功的安装和配置了服务器证书之后，请务必依据下面的操作流程，备份好您的服务器证书，以防证书丢失给您带来不便。

4.1 服务器证书的备份

备份服务器证书密钥库文件keystore.jks文件即可完成服务器证书的备份操作。

4.2服务器证书的恢复

请参照服务器证书安装部分，将服务器证书密钥库keystore.jks文件恢复到您的服务器上，并修改配置文件，恢复服务器证书的应用。

使用Atom编写Markdown文档并转为pdf

Sat, 14 May 2016 13:46:37 +0000

工作需要经常写技术文档，无奈Word插入代码并不好用，后染上Markdown无法自拔！但又不能要求别人使用Markdown，故目标要将其转换为国际通用的pdf文档，本文将介绍如何使用Atom编辑Markdown文档并将其转换为pdf。

Atom使用说明

综合评估基于Windows的编辑器中，Atom表现更优秀，Atom是GitHub推出的一款开源编辑器，其强大的插件系统是其最大的特色，比如我们这里要用到的MD文档转PDF就是基于Atom的插件完成。

Atom并不仅限于作为md文档的编辑器，它同大多数编辑器一样，可以作为其它编程语言使用的。

下载安装

前往Atom官网：https://atom.io/ 即可下载最新版

Atom的安装非常简单，双击下载的应用程序即可完成安装，其应用程序默认安装在：C:\Users\yourname\AppData\Local\atom中，而其插件配置目录在：C:\Users\yourname\.atom中，每次使用只需要点击快捷方式即可。

使用Atom

我们为了写作md文档，所以只需用Atom打开一个md文档，或者新建一个md文档，就可以按照md格式写作了。使用ctrl+shift+M可以预览文档在html中的表现。

安装插件

根据我们实际需要，仅需安装md转pdf的插件（markdown-themeable-pdf）即可，这里我们推荐一款有趣的插件：activate-power-mode，电脑配置足够强大的话，可以尝试颤抖的力量（https://9turn.com/xuan-ku-de-atomcha-jian-activate-power-mode ）。

Atom的插件是可以使用apm命令来进行在线安装，实际因为一些原因，我们只能使用npm进行安装，所以我们需要先安装nodejs

安装NodeJS

前往NodeJS官网下载：https://nodejs.org/en/

安装完成之后也是因为一些原因，需要将npm源改为国内淘宝源，方法如下：

npm config set registry http://registry.npm.taobao.org/

安装md转pdf的插件

前往GitHub下载该插件的压缩包：https://github.com/cakebake/markdown-themeable-pdf

将压缩包解压至目录C:\Users\yourname\.atom\

用管理员方式打开Windows的命令行提示符，进入插件目录

cd C:\Users\yourname\.atom\packages\markdown-themeable-pdf-master

输入npm install，等待安装完成，用Atom打开md文档，右击文档任意处，选择Markdown to PDF，等待片刻完成转换，如下图：

转换后的pdf完美表现

原文来自：使用Atom编写Markdown文档并转为pdf

SSL/TLS原理详解

Sat, 14 May 2016 02:28:30 +0000

关于证书授权中心CA以及数字证书等概念，请移步 OpenSSL 与 SSL 数字证书概念贴，如果你想快速自建CA然后签发数字证书，请移步基于OpenSSL自建CA和颁发SSL证书。

SSL/TLS作为一种互联网安全加密技术，原理较为复杂，枯燥而无味，我也是试图理解之后重新整理，尽量做到层次清晰。正文开始。

1. SSL/TLS概览

1.1 整体结构

SSL是一个介于HTTP协议与TCP之间的一个可选层，其位置大致如下：

SSL：（Secure Socket Layer，安全套接字层），为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取。当前版本为3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。
SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。
TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL 3.1，它是写入了 RFC 的。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。

SSL/TLS协议提供的服务主要有：

认证用户和服务器，确保数据发送到正确的客户机和服务器；
加密数据以防止数据中途被窃取；
维护数据的完整性，确保数据在传输过程中不被改变。

1.2 TLS与SSL的差异

版本号：TLS记录格式与SSL记录格式相同，但版本号的值不同，TLS的版本1.0使用的版本号为SSLv3.1。
报文鉴别码：SSLv3.0和TLS的MAC算法及MAC计算的范围不同。TLS使用了RFC-2104定义的HMAC算法。SSLv3.0使用了相似的算法，两者差别在于SSLv3.0中，填充字节与密钥之间采用的是连接运算，而HMAC算法采用的是异或运算。但是两者的安全程度是相同的。
伪随机函数：TLS使用了称为PRF的伪随机函数来将密钥扩展成数据块，是更安全的方式。
报警代码：TLS支持几乎所有的SSLv3.0报警代码，而且TLS还补充定义了很多报警代码，如解密失败（decryption_failed）、记录溢出（record_overflow）、未知CA（unknown_ca）、拒绝访问（access_denied）等。
密文族和客户证书：SSLv3.0和TLS存在少量差别，即TLS不支持Fortezza密钥交换、加密算法和客户证书。
certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息计算MD5和SHA-1散列码时，计算的输入有少许差别，但安全性相当。
加密计算：TLS与SSLv3.0在计算主密值（master secret）时采用的方式不同。
填充：用户数据加密之前需要增加的填充字节。在SSL中，填充后的数据长度要达到密文块长度的最小整数倍。而在TLS中，填充后的数据长度可以是密文块长度的任意整数倍（但填充的最大长度为255字节），这种方式可以防止基于对报文长度进行分析的攻击。

TLS的主要增强内容

TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上，提供了以下增强内容：

更安全的MAC算法
更严密的警报
“灰色区域”规范的更明确的定义

TLS对于安全性的改进

对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。
增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。
改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。
一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。
特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

2. 密钥协商过程——TLS握手

SSL协议分为两部分：Handshake Protocol和Record Protocol。其中Handshake Protocol用来协商密钥，协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。

由于非对称加密的速度比较慢，所以它一般用于密钥交换，双方通过公钥算法协商出一份密钥，然后通过对称加密来通信，当然，为了保证数据的完整性，在加密前要先经过HMAC的处理。

SSL缺省只进行server端的认证，客户端的认证是可选的。以下是其流程图（摘自TLS协议）。

2.1 客户端发出请求（ClientHello）

由于客户端(如浏览器)对一些加解密算法的支持程度不一样，但是在TLS协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。在TLS握手阶段，客户端首先要告知服务端，自己支持哪些加密算法，所以客户端需要将本地支持的加密套件(Cipher Suite)的列表传送给服务端。除此之外，客户端还要产生一个随机数，这个随机数一方面需要在客户端保存，另一方面需要传送给服务端，客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret 。

综上，在这一步，客户端主要向服务器提供以下信息：

支持的协议版本，比如TLS 1.0版
一个客户端生成的随机数，稍后用于生成”对话密钥”
支持的加密方法，比如RSA公钥加密
支持的压缩方法

2.2 服务器回应（SeverHello)

上图中，从Server Hello到Server Done，有些服务端的实现是每条单独发送，有服务端实现是合并到一起发送。Sever Hello和Server Done都是只有头没有内容的数据。

服务端在接收到客户端的Client Hello之后，服务端需要将自己的证书发送给客户端。这个证书是对于服务端的一种认证。例如，客户端收到了一个来自于称自己是www.alipay.com的数据，但是如何证明对方是合法的alipay支付宝呢？这就是证书的作用，支付宝的证书可以证明它是alipay，而不是财付通。证书是需要申请，并由专门的数字证书认证机构(CA)通过非常严格的审核之后颁发的电子证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存，不可泄漏。公钥则是附带在证书的信息中，可以公开的。证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被串改。另外，证书还有个有效期。

在服务端向客户端发送的证书中没有提供足够的信息（证书公钥）的时候，还可以向客户端发送一个 Server Key Exchange，

此外，对于非常重要的保密数据，服务端还需要对客户端进行验证，以保证数据传送给了安全的合法的客户端。服务端可以向客户端发出 Cerficate Request 消息，要求客户端发送证书对客户端的合法性进行验证。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。

跟客户端一样，服务端也需要产生一个随机数发送给客户端。客户端和服务端都需要使用这两个随机数来产生Master Secret。

最后服务端会发送一个Server Hello Done消息给客户端，表示Server Hello消息结束了。

综上，在这一步，服务器的回应包含以下内容：

确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信
一个服务器生成的随机数，稍后用于生成”对话密钥”
确认使用的加密方法，比如RSA公钥加密
服务器证书

2.3 客户端回应（Certificate Verify）

Client Key Exchange

如果服务端需要对客户端进行验证，在客户端收到服务端的 Server Hello 消息之后，首先需要向服务端发送客户端的证书，让服务端来验证客户端的合法性。

Certificate Verify

接着，客户端需要对服务端的证书进行检查，如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥。然后，向服务器发送下面三项信息：

一个随机数。该随机数用服务器公钥加密，防止被窃听
编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送
客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验

上面第一项的随机数，是整个握手阶段出现的第三个随机数，它是客户端使用一些加密算法(例如：RSA, Diffie-Hellman)产生一个48个字节的Key，这个Key叫 PreMaster Secret，很多材料上也被称作 PreMaster Key。

ChangeCipherSpec

ChangeCipherSpec是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了。

在ChangecipherSpec传输完毕之后，客户端会使用之前协商好的加密套件和Session Secret加密一段 Finish 的数据传送给服务端，此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。

2.4 服务器的最后回应（Server Finish）

服务端在接收到客户端传过来的 PreMaster 加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，也会使用跟客户端同样的方式生成 Session Secret，一切准备好之后，会给客户端发送一个 ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了。之后，服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。

根据之前的握手信息，如果客户端和服务端都能对Finish信息进行正常加解密且消息正确的被验证，则说明握手通道已经建立成功，接下来，双方可以使用上面产生的Session Secret对数据进行加密传输了。

2.5 几个secret

Secret Keys

上面的分析和讲解主要是为了突出握手的过程，所以PreMaster secret，Master secret，session secret都是一代而过，但是对于Https，SSL/TLS深入的理解和掌握，这些Secret Keys是非常重要的部分。所以，准备把这些Secret Keys抽出来单独分析和讲解。

我们先来看看这些Secret Keys的生成过程以及作用流程图：

PreMaster secret

PreMaster Secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成 Master Secret。在客户端使用服务端的公钥对PreMaster Secret进行加密之后传送给服务端，服务端将使用私钥进行解密得到PreMaster secret。也就是说服务端和客户端都有一份相同的PreMaster secret和随机数。

PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。

关于PreMaster Secret(Key)的计算请参考 Https SSL/TLS PreMaster/Master Secret(Key)计算。

Master secret

上面已经提到，由于服务端和客户端都有一份相同的PreMaster secret和随机数，这个随机数将作为后面产生Master secret的种子，结合PreMaster secret，客户端和服务端将计算出同样的Master secret。

Master secret是有系列的hash值组成的，它将作为数据加解密相关的secret的 Key Material 的一部分。Key Material最终解析出来的数据如下：

其中，write MAC key，就是session secret或者说是session key。Client write MAC key是客户端发数据的session secret，Server write MAC secret是服务端发送数据的session key。MAC(Message Authentication Code)，是一个数字签名，用来验证数据的完整性，可以检测到数据是否被串改。

关于Session Secret(Key)的计算请参考 Https SSL/TLS Session Secret(Key)计算。

2.6 应用数据传输

在所有的握手阶段都完成之后，就可以开始传送应用数据了。应用数据在传输之前，首先要附加上MAC secret，然后再对这个数据包使用write encryption key进行加密。在服务端收到密文之后，使用Client write encryption key进行解密，客户端收到服务端的数据之后使用Server write encryption key进行解密，然后使用各自的write MAC key对数据的完整性包括是否被串改进行验证。

2.7 总结

SSL客户端（也是TCP的客户端）在TCP链接建立之后，发出一个ClientHello来发起握手，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，SSL的服务器端会回应一个ServerHello，这里面确定了这次通信所需要的算法，然后发过去自己的证书（里面包含了身份和自己的公钥）。Client在收到这个消息后会生成一个秘密消息，用SSL服务器的公钥加密后传过去，SSL服务器端用自己的私钥解密后，会话密钥协商成功，双方可以用同一份会话密钥来通信了。

3. 附：密钥协商的形象化比喻

如果上面的说明不够清晰，这里我们用个形象的比喻，我们假设A与B通信，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动作的说明用圆括号（）括起。

A：我想和你安全的通话，我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH，摘要算法有MD5和SHA。

B：我们用DES－RSA－SHA这对组合好了。
这是我的证书，里面有我的名字和公钥，你拿去验证一下我的身份（把证书发给A）。
目前没有别的可说的了。

A：（查看证书上B的名字是否无误，并通过手头早已有的CA的证书验证了B的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了B的公钥的真实性）
（产生一份秘密消息，这份秘密消息处理后将用作加密密钥，加密初始化向量（IV）和hmac的密钥。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密，封装成称作ClientKeyExchange的消息。由于用了B的公钥，保证了第三方无法窃听）
我生成了一份秘密消息，并用你的公钥加密了，给你（把ClientKeyExchange发给B）
注意，下面我就要用加密的办法给你发消息了！
（将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥）
[我说完了]

B：（用自己的私钥将ClientKeyExchange中的秘密消息解密出来，然后将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥，这时双方已经安全的协商出一套加密办法了）
注意，我也要开始用加密的办法给你发消息了！
[我说完了]

A: [我的秘密是…]

B: [其它人不会听到的…]

4. SSL安全性

SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的讨论，目前也有一些成熟的工具如dsniff（http://www.monkey.org/~dugsong/dsniff/ ）可以通过man in the middle攻击来截获https的消息。

从上面的原理可知，SSL的结构是严谨的，问题一般出现在实际不严谨的应用中。常见的攻击就是middle in the middle攻击，它是指在A和B通信的同时，有第三方C处于信道的中间，可以完全听到A与B通信的消息，并可拦截，替换和添加这些消息。

SSL可以允许多种密钥交换算法，而有些算法，如DH，没有证书的概念，这样A便无法验证B的公钥和身份的真实性，从而C可以轻易的冒充，用自己的密钥与双方通信，从而窃听到别人谈话的内容。
而为了防止middle in the middle攻击，应该采用有证书的密钥交换算法。
有了证书以后，如果C用自己的证书替换掉原有的证书之后，A的浏览器会弹出一个警告框进行警告，但又有多少人会注意这个警告呢？
由于美国密码出口的限制，IE，netscape等浏览器所支持的加密强度是很弱的，如果只采用浏览器自带的加密功能的话，理论上存在被破解可能。

5. 代理

下面探讨一下SSL的代理是怎样工作的
当在浏览器里设置了https的代理，而且里输入了https://www.example.com 之后，浏览器会与proxy建立tcp链接，然后向其发出这么一段消息：

CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443

然后proxy会向webserver端建立tcp连接,之后，这个代理便完全成了个内容转发装置。浏览器与web server会建立一个安全通道，因此这个安全通道是端到端的，尽管所有的信息流过了proxy,但其内容proxy是无法解密和改动的（当然要由证书的支持，否则这个地方便是个man in the middle攻击的好场所，见上面的安全部分）。

CA证书以及如何使用OpenSSL自签署，见文章OpenSSL自签署证书

6. 参考

本文原文出处：SSL/TLS原理详解

已回答：Question2Answer如何破内容8000上限

Tue, 10 May 2016 02:54:15 +0000

按照官方的说法，Question2Answer将在1.8版本中会将此上限改为12000

Question2Answer 1.7版本中可以在qa-include/db/maxima.php中看到配置文件

@define('QA_DB_MAX_EMAIL_LENGTH', 80);
@define('QA_DB_MAX_HANDLE_LENGTH', 20);
@define('QA_DB_MAX_TITLE_LENGTH', 800);
@define('QA_DB_MAX_CONTENT_LENGTH', 8000);
@define('QA_DB_MAX_FORMAT_LENGTH', 20);
@define('QA_DB_MAX_TAGS_LENGTH', 800);
@define('QA_DB_MAX_NAME_LENGTH', 40);
@define('QA_DB_MAX_WORD_LENGTH', 80);
@define('QA_DB_MAX_CAT_PAGE_TITLE_LENGTH', 80);
@define('QA_DB_MAX_CAT_PAGE_TAGS_LENGTH', 200);
@define('QA_DB_MAX_CAT_CONTENT_LENGTH', 800);
@define('QA_DB_MAX_WIDGET_TAGS_LENGTH', 800);
@define('QA_DB_MAX_WIDGET_TITLE_LENGTH', 80);
@define('QA_DB_MAX_OPTION_TITLE_LENGTH', 40);
@define('QA_DB_MAX_PROFILE_TITLE_LENGTH', 40);
@define('QA_DB_MAX_PROFILE_CONTENT_LENGTH', 8000);
@define('QA_DB_MAX_CACHE_AGE', 86400);
@define('QA_DB_MAX_BLOB_FILE_NAME_LENGTH', 255);
@define('QA_DB_MAX_META_TITLE_LENGTH', 40);
@define('QA_DB_MAX_META_CONTENT_LENGTH', 8000);

其中内容长度代码是这个：

@define('QA_DB_MAX_CONTENT_LENGTH', 8000);

再打开qa-config.php文件，找到代码：

define('QA_HTML_COMPRESSION', true);
define('QA_MAX_LIMIT_START', 19999);
define('QA_IGNORED_WORDS_FREQ', 10000);
define('QA_ALLOW_UNINDEXED_QUERIES', false);
define('QA_OPTIMIZE_LOCAL_DB', false);
define('QA_OPTIMIZE_DISTANT_DB', false);
define('QA_PERSISTENT_CONN_DB', false);
define('QA_DEBUG_PERFORMANCE', false);

在其后面加入内容长度代码配置，加入代码并修改8000为16000，注意@要去掉：

define('QA_HTML_COMPRESSION', true);
define('QA_MAX_LIMIT_START', 19999);
define('QA_IGNORED_WORDS_FREQ', 10000);
define('QA_ALLOW_UNINDEXED_QUERIES', false);
define('QA_OPTIMIZE_LOCAL_DB', false);
define('QA_OPTIMIZE_DISTANT_DB', false);
define('QA_PERSISTENT_CONN_DB', false);
define('QA_DEBUG_PERFORMANCE', false);
define('QA_DB_MAX_CONTENT_LENGTH', 16000);

改完之后还要改一下数据库的数据长度

使用数据库软件编辑表结构：qa_posts 中修改content的varchar长度限制，在1.7.x之前，这个数据表可能是qa_content

截图来自阿里云RDS软件

这样就OK了!

OpenSSL 与 SSL 数字证书基本概念

Tue, 10 May 2016 01:48:49 +0000

首先简单区分一下HTTPS、SSL、OpenSSL三者的关系：

SSL是在客户端和服务器之间建立一条SSL安全通道的安全协议，而OpenSSL是TLS/SSL协议的开源实现，提供开发库和命令行程序。常说的HTTPS是HTTP的加密版，底层使用的加密协议是SSL。

1. PKI、CA与证书

PKI 就是 Public Key Infrastructure 的缩写，翻译过来就是公开密钥基础设施。它是利用公开密钥技术所构建的，解决网络安全问题的，普遍适用的一种基础设施;是一种遵循既定标准的密钥管理平台,它能够为所有网络应用提供加密和数字签名等密码服务及所必需的密钥和证书管理体系。

PKI既不是一个协议，也不是一个软件，它是一个标准，在这个标准之下发展出的为了实现安全基础服务目的的技术统称为PKI。可以说CA(认证中心)是PKI的核心，而数字证书是PKI的最基本元素，还有如apache等服务器、浏览器等客户端、银行等应用，都是pki的组件。这篇文章可以帮助理解：PKI/CA 技术的介绍。

1.1 CA

为保证用户之间在网上传递信息的安全性、真实性、可靠性、完整性和不可抵赖性

CA 机构，又称为证书认证中心 (Certificate Authority) 中心，是一个负责发放和管理数字证书的第三方权威机构，它负责管理PKI结构下的所有用户(包括各种应用程序)的证书，把用户的公钥和用户的其他信息捆绑在一起，在网上验证用户的身份。CA机构的数字签名使得攻击者不能伪造和篡改证书。

认证中心主要有以下5个功能：

证书的颁发：接收、验证用户(包括下级认证中心和最终用户)的数字证书的申请。可以受理或拒绝
证书的更新：认证中心可以定期更新所有用户的证书，或者根据用户的请求来更新用户的证书
证书的查询：查询当前用户证书申请处理过程；查询用户证书的颁发信息，这类查询由目录服务器ldap来完成
证书的作废：由于用户私钥泄密等原因，需要向认证中心提出证书作废的请求；证书已经过了有效期，认证中心自动将该证书作废。认证中心通过维护证书作废列表 (Certificate Revocation List,CRL) 来完成上述功能。
证书的归档：证书具有一定的有效期，证书过了有效期之后就将作废，但是我们不能将作废的证书简单地丢弃，因为有时我们可能需要验证以前的某个交易过程中产生的数字签名，这时我们就需要查询作废的证书。

1.2 Certificate
1.2.1 X.509标准

"SSL证书"这个词是一个相对较大的概念，整个PKI体系中有很多SSL证书格式标准。PKI的标准规定了PKI的设计、实施和运营，规定了PKI各种角色的"游戏规则"，提供数据语法和语义的共同约定。x.509是PKI中最重要的标准，它定义了公钥证书的基本结构，可以说PKI是在X.509标准基础上发展起来的：

SSL公钥证书
证书废除列表CRL(Certificate revocation lists 证书黑名单)

参考 http://en.wikipedia.org/wiki/X.509

1.2.2 ssl公钥证书格式

1. 证书版本号(Version)
版本号指明X.509证书的格式版本，现在的值可以为:
    1) 0: v1
    2) 1: v2
    3) 2: v3
也为将来的版本进行了预定义

2. 证书序列号(Serial Number)
序列号指定由CA分配给证书的唯一的"数字型标识符"。当证书被取消时，实际上是将此证书的序列号放入由CA签发的CRL中，
这也是序列号唯一的原因。

3. 签名算法标识符(Signature Algorithm)
签名算法标识用来指定由CA签发证书时所使用的"签名算法"。算法标识符用来指定CA签发证书时所使用的:
    1) 公开密钥算法
    2) hash算法
example: sha256WithRSAEncryption
须向国际知名标准组织(如ISO)注册

4. 签发机构名(Issuer)
此域用来标识签发证书的CA的X.500 DN(DN-Distinguished Name)名字。包括:
    1) 国家(C)
    2) 省市(ST)
    3) 地区(L)
    4) 组织机构(O)
    5) 单位部门(OU)
    6) 通用名(CN)
    7) 邮箱地址

5. 有效期(Validity)
指定证书的有效期，包括:
    1) 证书开始生效的日期时间
    2) 证书失效的日期和时间
每次使用证书时，需要检查证书是否在有效期内。

6. 证书用户名(Subject)
指定证书持有者的X.500唯一名字。包括:
    1) 国家(C)
    2) 省市(ST)
    3) 地区(L)
    4) 组织机构(O)
    5) 单位部门(OU)
    6) 通用名(CN)
    7) 邮箱地址

7. 证书持有者公开密钥信息(Subject Public Key Info)
证书持有者公开密钥信息域包含两个重要信息:
    1) 证书持有者的公开密钥的值
    2) 公开密钥使用的算法标识符。此标识符包含公开密钥算法和hash算法。
8. 扩展项(extension)
X.509 V3证书是在v2的基础上一标准形式或普通形式增加了扩展项，以使证书能够附带额外信息。标准扩展是指
由X.509 V3版本定义的对V2版本增加的具有广泛应用前景的扩展项，任何人都可以向一些权威机构，如ISO，来
注册一些其他扩展，如果这些扩展项应用广泛，也许以后会成为标准扩展项。

9. 签发者唯一标识符(Issuer Unique Identifier)
签发者唯一标识符在第2版加入证书定义中。此域用在当同一个X.500名字用于多个认证机构时，用一比特字符串
来唯一标识签发者的X.500名字。可选。

10. 证书持有者唯一标识符(Subject Unique Identifier)
持有证书者唯一标识符在第2版的标准中加入X.509证书定义。此域用在当同一个X.500名字用于多个证书持有者时，
用一比特字符串来唯一标识证书持有者的X.500名字。可选。

11. 签名算法(Signature Algorithm)
证书签发机构对证书上述内容的签名算法
example: sha256WithRSAEncryption

12. 签名值(Issuer's Signature)
证书签发机构对证书上述内容的签名值

示例：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 9 (0x9)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=CN, ST=GuangDong, L=ShenZhen, O=COMPANY Technologies Co., Ltd, OU=IT_SECTION, CN=registry.example.com.net/emailAddress=zhouxiao@example.com.net
        Validity
            Not Before: Feb 11 06:04:56 2015 GMT
            Not After : Feb  8 06:04:56 2025 GMT
        Subject: C=CN, ST=GuangDong, L=ShenZhen, O=TP-Link Co.,Ltd., OU=Network Management, CN=172.31.1.210
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a4:b0:dd:eb:c1:cf:5d:47:61:a6:ea:ef:8b:aa:
                    4b:f0:b4:2c:d8:96:c7:7c:ac:fa:c7:35:88:53:d0:
                    ...
                    8a:76:dc:8f:8c:44:c8:0b:3c:36:88:5f:01:f0:44:
                    4e:81:e6:7a:2b:ff:ba:da:33:a5:27:11:c6:f0:08:
                    6e:f3
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                07:C6:87:B7:C1:1E:28:E8:96:3F:EB:40:1E:82:41:45:CA:81:B6:3D
            X509v3 Authority Key Identifier: 
                keyid:A4:C2:14:6A:39:D1:95:1E:BD:DF:3B:92:4A:5C:12:42:1B:BC:53:B8

    Signature Algorithm: sha256WithRSAEncryption
         0c:c6:81:70:cd:0a:2d:94:4f:cb:a4:1d:ef:9e:8e:e4:73:ae:
         50:62:a8:9c:64:ef:56:0f:41:fe:6b:b4:d3:07:37:39:2c:ed:
         ...
         6f:62:61:b8:03:d7:97:31:ab:05:44:20:07:65:8b:ad:e2:cc:
         ad:65:73:f6:82:0f:9e:65:d0:ae:b7:1e:fd:9f:c1:d7:41:6c:
         0f:06:95:ee
-----BEGIN CERTIFICATE-----
MIIEMDCCAxigAwIBAgIBCTANBgkqhkiG9w0BAQsFADCBtTELMAkGA1UEBhMCQ04x
EjAQBgNVBAgMCUd1YW5nRG9uZzERMA8GA1UEBwwIU2hlblpoZW4xJjAkBgNVBAoM
...
ujwwRar6pPzusO95WuS93HsNmL2ZFZ63DS4LcW9iYbgD15cxqwVEIAdli63izK1l
c/aCD55l0K63Hv2fwddBbA8Gle4=
-----END CERTIFICATE-----

2. 附：数据加密的基础知识

对称密钥加密

对称密钥加密（一个密钥），也叫做共享密钥加密或机密密钥加密，使用发件人和收件人共同拥有的单个密钥。这种密钥既用于加密，也用于解密，叫做机密密钥。对称密钥加密是加密大量数据的一种行之有效的方法。

对称密钥加密有许多种算法如DES,RC4,IDEA等，但所有这些算法都有一个共同的目的：以可还原的方式将明文（未加密的数据转换为暗文。暗文使用加密密钥编码，对于没有解密密钥的任何人来说它都是没有意义的。由于对称密钥加密在加密和解密时使用相同的密钥，所以这种加密过程的安全性取决于是否有未经授权的人获得了对称密钥。

衡量对称算法优劣的主要尺度是其密钥的长度。密钥越长，在找到解密数据所需的正确密钥之前必须测试的密钥数量就越多。需要测试的密钥越多，破解这种算法就越困难。

公钥加密

公钥加密使用两个密钥:一个公钥和一个私钥，这两个密钥在数学上是相关的。为了与对称密钥加密相对照，公钥加密有时也叫做不对称密钥加密。在公钥加密中，公钥可在通信双方之间公开传递，或在公用储备库中发布，但相关的私钥是保密的。只有使用私钥才能解密用公钥加密的数据。使用私钥加密的数据只能用公钥解密。下图中，发件人拥有收件人的公钥，并用它加密了一封邮件，但只有收件人掌握解密该邮件的有关私钥。

公钥算法的主要局限在于，这种加密形式的速度相对较低。实际上，通常仅在关键时刻才使用公钥算法，如在实体之间交换对称密钥时，或者在签署一封邮件的散列时（散列是通过应用一种单向数学函数获得的一个定长结果，对于数据而言，叫做散列算法）。将公钥加密与其它加密形式（如对称密钥加密）结合使用，可以优化性能，如数字签名和密钥交换。

常用公钥算法：

RSA：适用于数字签名和密钥交换。是目前应用最广泛的公钥加密算法，特别适用于通过 Internet 传送的数据，RSA算法以它的三位发明者的名字命名。
DSA：仅适用于数字签名。数字签名算法 (Digital Signature Algorithm, DSA) 由美国国家安全署 (United States National Security Agency, NSA) 发明，已作为数字签名的标准。DSA 算法的安全性取决于自计算离散算法的困难。这种算法，不适用于数据加密。
Diffie-Hellman：仅适用于密钥交换。 Diffie-Hellman 是发明的第一个公钥算法，以其发明者 Whitfield Diffie 和 Martin Hellman 的名字命名。Diffie-Hellman 算法的安全性取决于在一个有限字段中计算离散算法的困难。

单向散列算法：

散列，也称为散列值或消息摘要，是一种与基于密钥（对称密钥或公钥）的加密不同的数据转换类型。散列就是通过把一个叫做散列算法的单向数学函数应用于数据，将任意长度的一块数据转换为一个定长的、不可逆转的数字，其长度通常在128～256位之间。所产生的散列值的长度应足够长，因此使找到两块具有相同散列值的数据的机会很少。如发件人生成邮件的散列值并加密它，然后将它与邮件本身一起发送。而收件人同时解密邮件和散列值，并由接收到的邮件产生另外一个散列值，然后将两个散列值进行比较。如果两者相同，邮件极有可能在传输期间没有发生任何改变。

下面是几个常用的散列函数：

MD5：是RSA数据安全公司开发的一种单向散列算法，MD5被广泛使用，可以用来把不同长度的数据块进行暗码运算成一个128位的数值。
SHA-1：与 DSA 公钥算法相似，安全散列算法1（SHA-1）也是由 NSA 设计的，并由 NIST 将其收录到 FIPS 中，作为散列数据的标准。它可产生一个 160 位的散列值。SHA-1 是流行的用于创建数字签名的单向散列算法。
MAC（Message Authentication Code）：消息认证代码，是一种使用密钥的单向函数，可以用它们在系统上或用户之间认证文件或消息，常见的是HMAC（用于消息认证的密钥散列算法）。
CRC（Cyclic Redundancy Check）：循环冗余校验码，CRC校验由于实现简单，检错能力强，被广泛使用在各种数据校验应用中。占用系统资源少，用软硬件均能实现，是进行数据传输差错检测地一种很好的手段（CRC 并不是严格意义上的散列算法，但它的作用与散列算法大致相同，所以归于此类）。

数字签名：结合使用公钥与散列算法

数字签名是邮件、文件或其它数字编码信息的发件人将他们的身份与信息绑定在一起（即为信息提供签名）的方法。对信息进行数字签名的过程，需要将信息与由发件人掌握的秘密信息一起转换（使用私钥）为叫做签名的标记。数字签名用于公钥环境（任何人都可以拥有）中，它通过验证发件人确实是他或她所声明的那个人，并确认收到的邮件与发送的邮件完全相同。

散列算法处理数据的速度比公钥算法快得多。散列数据还缩短了要签名的数据的长度，因而加快了签名过程。

密钥交换：结合使用对称密钥与公钥

对称密钥算法非常适合于快速并安全地加密数据。但其缺点是，发件人和收件人必须在交换数据之前先交换机密密钥。结合使用加密数据的对称密钥算法与交换机密密钥的公钥算法可产生一种既快速又灵活的解决方案。

参考

文章来自：OpenSSL 与 SSL 数字证书概念贴

已回答：IIS6服务器中安装SSL证书

Sun, 08 May 2016 12:48:21 +0000

现在云服务器做的这么好，Windows服务器蛮少的了！而且，大多也是在Win里面装别的服务。

已回答：Nginx中安装配置Let's Encrypt免费证书

Sun, 08 May 2016 05:58:22 +0000

很不错的教程，感谢题主提供！

已回答：关于Comodo PositiveSSL在Firefox上不受信任的数字证书

Fri, 06 May 2016 14:13:10 +0000

合并证书就可以了！用代码编辑器手动合并敢行，把所有代码拼在一起就O了

已回答：使用openSSL生成自签名CA和自签名证书

Fri, 06 May 2016 14:10:30 +0000

自签名证书自己懂就可以了！要是给客户用就真坑爹。

已回答：我们公司有内部邮件服务器，应该买什么样的证书？

Thu, 28 Apr 2016 13:49:44 +0000

邮件服务器入门级其实就可以了！可以顺带买通配符版就可以了，这样除了企业邮件服务器可以用，其它子域名同样适用，一年就七八百，https://www.goovell.net/cart.php?a=confproduct&i=0

已回答：有没有不购买证书的SSL加密方案？

Tue, 26 Apr 2016 08:39:17 +0000

题主想要的是自签名CA，这种证书不是内置在浏览器中的根证书，需要用户点击信任或者导入证书才能继续访问页面，否则浏览器会提示该证书不受信任。就如上图所示。

解决方案很简单，像上图一样，点击“继续浏览此网站（不推荐）”，或者导入根证书，下述

首先得知道一些概念：http://www.sslzoo.com/68/使用openssl生成自签名ca和自签名证书

已回答：关于SSL中证书颁发机构（CA）的一些基本概念

Tue, 26 Apr 2016 08:27:04 +0000

可以让用户下载是根证书再导入到系统中

已回答：解决单IP多SSL证书在Windows XP下访问无效

Sat, 23 Apr 2016 14:24:58 +0000

有兴趣的同学，可以参考开源SSL数字证书Let's Encrypt做测试，待有条件可以购买收费SSL，回头补上关于Let's Encrypt免费证书的全系教程

已回答：阿里云ESC就一个ip怎么安装两个SSL证书

Sat, 23 Apr 2016 14:14:13 +0000

我想题主如果不是因为Windows XP的问题，就应该不用去担心这个问题，题主在架设阿里云的服务器时应该会默认内置了SNI（Server Name Indication），所以一台阿里云ESC是可以支持多个SSL证书。

如果希望解决Windows XP用户访问时出问题，那么可以参考本人写的简单教程：

解决单IP多SSL证书在Windows XP下访问无效

已回答：Question2Answer在Nginx中Rewrite和所有配置规则

Fri, 22 Apr 2016 05:26:21 +0000

    # 防止tpl inc cfg文件被下载，假如你可能不想让less,scss或者inc文件不被下载。
    location ~* \.(tpl|inc|cfg|ico|less|scss)$ {  
      deny all;
    }

注意这些代码是通用的，在其它系统中也可以这么配置

已回答：如何在服务器中生成CSR证书请求文件

Thu, 21 Apr 2016 15:07:05 +0000

介绍的很好，最好有后面详细安装及配置的教程！

已回答：SSL有什么用处，真的能防盗吗？

Thu, 21 Apr 2016 15:00:06 +0000

谈不上防盗，起码可以甄别是不是钓鱼网站，但凡需要支付类，或者涉及财务安全类的网站都应该标配SSL证书。国际统一标准都是由证书商认证并颁发证书给商户，商户经过SSL认证之后，信任度就很高。国外电子商务站标配。
比如国内京东、支付宝和各大银行的网页都配备Symantec或者Comodo的SSL数字证书，他们其实在保护你的安全。
此外一些如题主说的OA，和一些邮件服务器、办公系统、接口管理系统等都应当配备SSL数字证书，防止在传输过程中被病毒或者黑客截取数据。最典型的就是ISP运营商劫持，比如电信宽带的用户时常在浏览网站的时候弹出电信的促销广告，如果用户在浏览支付宝网站，则不会出现这样的广告。

有兴趣可以申请免费的SSL证书(Let's Encrypt Authority X1)体验，或者联系我们 http://www.goovell.net 购买入门级证书RapidSSL，便宜又实惠。毕竟免费不稳定！

已回答：CKEditor图片编辑时，移除掉宽、高、ALT、预览等高级属性

Thu, 21 Apr 2016 14:48:53 +0000

期待开源定制版编辑器！！！

已回答：请问本网站的模板是怎么做的，能分享吗

Wed, 20 Apr 2016 07:04:48 +0000

原作是来自 Donut Theme 本站主题是 shionphan 定制设计的！作者计划整理后再开源。