Becomin' Charles

世上许多重要的转折是在意想不到时发生的，这是否意味着人对事物发展进程无能为力？请写一篇文章，谈谈你对这个问题的认识和思考。这是今年高考，上海卷语文作文题目。

看到这个题目的时候，我正好在重温计算机系统的基础知识，重新学习了 Amdahl 定律。这个定律讲的是，在一个系统中，如果我们改善了系统的一个部分的性能，那么整个系统的性能改善，会被这个被改善部分在整个系统中重要性占比给削弱。

昨天，我在一台 CentOS 6.10 上面编译 PHP 7.4.7 和编译前几个版本有很大的区别，PHP 7.4 开始使用了一个叫 pkg-config 的东西，有点先进，但是在老旧的系统上，真是无比痛苦的一个体验。

今天我尝试一下在 CentOS 7.8 上面编译一下，之前没有干过，我就记录一下过程，虽然无聊得很，但是记录下来，可以给以后节省点时间。

话说，不作死就不会死。

上一篇文章讲解了怎么老旧的 MacBook Pro 重新安装 MacOS 操作系统，我安装成功了，但是跑了一会儿以后，我发现我犯了一个严重的错误，我还是把固态硬盘当作了启动盘来安装系统。

当年，我自己动手，拆掉了 MacBook Pro mid 2009 的光驱，使用光驱位硬盘盒给自己扩展了一块 SSD 固态硬盘，镁光 M4，现在 10 年过去了，我自己密集使用了两年，转送老爸又用了两年多，然后又放了好几年，这块硬盘的可靠性已经是 0 了，就在上篇文章写完，我装成功 MacOS 后，运行不到 30 分钟，我发现 System Preferences 这个 App，也就是系统设置，无法正常打开了。虽然不知道哪里坏了，我猜就是硬盘，另外我想启动个 SSH 服务，发现也连不上去…… 当然了，这不能怪硬盘，还是我自己没设置对，可是设置 App 又不能正常运行，一怒之下关机拉倒了，懒得琢磨了，又萌生了再安装一次 Linux 的想法，不折腾不作死，就不会死啊。

话说，不作死就不会死。

我的第一台 MacBook Pro，是一台 2009 Mid，真是有年头了，后来我换了电脑，就给了老爸，后来我又换了电脑，就把第二台给了老爸，老爸说第一台也没用了，还你吧，于是我现在多了一台闲置的 MBP 出来，还是 2009 Mid。

我之前就在家里跑了个树莓派 1 代，挺 Happy，想着，用 MBP 这逆天的性能，跑个 Linux，岂不是无敌了，于是开始了我作死之旅。

写这个话题，我是忐忑的，因为我讲不清楚，其实比我一开始以为得要复杂一些，不过，迫于压力，我还是得尝试去说清楚这个问题，如果看到不对地方，希望读者可以不吝赐教，谢谢～

之前写了一篇文章讲《什么是 POS 机》其实也没讲清楚，不过说了个大概。清分这个问题，首先涉及到银行卡收单这个业务，是否可以衍生到网络支付上面，我还没有想得很清楚。不管如何，我们可以从银行卡线下收单业务来看这个问题的性质。

简化情况下的一清和二清的区别

什么是一清

申请 POS 机的，在交易流程里叫特约商户，一般特约商户在收单机构注册开户，然后，安装 POS 机，持卡人刷卡后，通过 POS 机将交易上送到收单机构，再从收单机构通过清算机构发往发卡行，如上图左侧的蓝色线条，这个蓝色线条，叫交易的信息流。发卡行确认信息后，通知收单机构，然后反馈给 POS 机，持卡人就看到了交易成功。

这个时候，特约商户，也就是零售的卖家，其实还没有收到现金。但是因为交易已经被确认，所以，这次购买销售行为可以正常完成。一般清算机构，每天会进行一次日终清算，通过清算，资金会划拨给收单机构，然后收单机构再划拨给特约商户，所以 POS 机经常就是 T+1 到帐的，这我们在《什么是 POS 机》也提到了。

什么是二清

我们再来看看什么是二次清分，看上面图的右边，有一些特约商户，申请到 POS 机以后，再向收单机构申请增机，然后这家商户就有很多台 POS 机，然后将增设的 POS 机租给更小的商户，当完成清算后，钱都会被结算给同一个特约商户，这家商户再通过支付的信息，将资金结算给租用 POS 机的商户。完成一个二次的清分。特此说明一下，二次清分在当下是违规行为。

上面不难看出一个问题，就是 POS 机 理论上都是直接向收单机构去上送交易信息的，那么二次清分机构是怎么做到二清 POS 机 展示正确的商户信息，以及怎样在二次清分时候，做到正确分账呢？

POS 机的安装部署和线下拓展商户，都是一个繁重和细致的工作，也有很强的地域性，所以，收单机构，不一定可以自己经营所有的线下商户，就不得不依赖代理商，代理商很多都是 POS 机设备的生产厂商，注意，他们没有收单的资质，但是生产一台电子设备是合法的。这里，二清机构其实很多都是 POS 机设备的代理商，或者跟 POS 机代理商合作。

这里一个显著的风险点就是，二清机构，并不持有支付牌照，也不受监管，如果捐款跑路，就给租用 POS 机的商户带来很大的风险。

以上说得，都是比较简单的二次清分，比较形象，具体，容易理解。其实真正的二次清分，不是这么定义的。上面的案例，集中在二清清分机构，获得了下属机构的资金，然后二次划拨资金，对资金安全产生了很大的危害。

信息二清

于是，就产生了一种新的形态，二清机构说，我不把下属客户的资金拿到我自己的账上，不碰资金，是不是就行了？于是，产生了二清机构和持牌收单机构合作，在持牌收单机构的账户内，开设虚拟账户，将二清机构的待结算资金停留，通过二清机构的指令（清算依据），直接从收单机构的账户，结算给下属的商户。

这种情况，看起来，资金已经不是从二清机构的账户上结算给下属的商户账户了，但是，在当前，这仍然构成了二次清分，也是央行重点禁止的业务。这里比较重要的一个界定标准，不是资金从哪个账户流出，也不是资金受谁控制，关键在于，谁可以事实上决定的资金的流向，第二种模式，也被业内叫做是“信息二清”，现在的一个趋势是，“资金二清” 也好，“信息二清” 也好，都被称作二清，都是监管打击的对象。

虽然，不合法，但是市场上还是非常需要二清这个方案，这是为什么呢？抛开一开始就诈骗、套现抱有恶意动机的行为不看。合法经营的是否需要二清？

二清存在有其刚性需求

依据我个人的理解，信息中介型的企业，都潜在有二清的使用场景。我们常见的案例是电商平台。电商平台本质上是一种信息中介行为，这种平台往往相比于单个电商卖家，有更多的客户，所以，电商卖家更希望通过平台来获得客户，形成交易。

电商平台的建立，能提供一个虚拟的规模化的交易市场，上面入驻的商户，一般都依托平台的支付体系，所以往往就是消费者把钱先划转到了电商平台的账户上，再由平台结算给每个入驻的商户，这就构成了事实的二清。

我们再抽象点来看，一个信息中介，掌握着交易双方一方的资源，或者两方资源。这是中介赖以生存的核心优势，肯定不愿意将自己的资源直接输送给另一方，必然是愿意自己经营一个平台（市场），让双方在上面完成交易。这个平台不可能允许每个参与者自带一套支付体系，这样对买方极其不友好，而且，不掌握交易数据，对中介方来说，也不能建立长期有效的竞争壁垒。

所以，最后，这个商业模式都会导向二清这个行为。中介方有很强动机掌握交易的具体信息，完成资金的清算结算。所以，抛开违法的部分看，二清有其存在的必然需求。

国家现在打击二清，当然是整顿了市场，规避了系统性风险和信息安全，但是一种很有活力的商业模式，也受到了发展的制约。从长远看，是不能持久的，现在市场上就在提出各种各样的二清解决方案。本质上，需求还是刚性的，大家还在想各种办法来在监管的夹缝里求生存。

不过，终究不是长远的解决办法，还是希望监管政策层面，能推出比较明确的细则，区分对待，让正常做生意的人，有个出口。

POS 的英文是 Point of Sales，字面意思是销售点，百度百科也说是“销售点情报管理系统”，本质上来说，是一套系统，有很多的组成部分。

POS 系统

这套系统，大家见得比较多，主要用于零售点的收银，是零售业门店管理的重要组成部分。

这里面融合了库存，价格，收银，出纳等等功能。基本原理是这样的，门店的商品和信息被录入到系统中，然后需要一个条码读取器，可以扫描商品，统计订单金额，然后生成收银请求，配合银行卡读卡器，完成交易（无现金），也可以弹出一个抽屉，完成现金交易的收钱，找零等。

不过，咱们一般提到 POS 机，指的都是桌上那个小东西，就是 POS 刷卡机。因为这个东西能够从银行卡进行扣款转账，是一次销售行为中最重要的部分，所以刷卡机就往往被称作是 POS 机了。当然，众所周知的，也可以脱离开这个场景使用 :) 具体用途就不解释了。

POS 刷卡机，简称 POS 机，背后对应的业务，专业上叫银行卡线下收单业务。主要是银行类机构，以及第三方支付公司（又称非金融机构）经营的业务。对银行来说，不是主要的业务，但是对第三方支付公司来说，是主要经营的一种业务。

POS 机的持有者，专业上叫特约商户，一般来说，是一个零售型企业。他们为什么要安装 POS 机呢？主要是因为顾客是上帝，顾客更喜欢使用 POS 机进行支付。顾客在专业上叫持卡人，主要持有银行机构发行的储蓄卡，信用卡。银行机构，在这个场景里，叫发卡行。POS 机的作用就是从发卡行发行的卡账户上，将资金扣转并转移到特约商户的账户上。

如果，持卡人持有的卡，不是本行发行的卡，那么需要通过跨行结算组织，完成跨行资金结算，这个跨行结算组织，就是银联。

对于银行来说，去对接海量的线下零售型商户，显然是一个低效益并且也不可能完成的任务，所以，更多的 POS 线下收单业务，都由第三方支付公司经营。第三方支付公司，需要持有经营此项业务的牌照，也就是支付牌照。

对于第三方支付公司来说，经营 POS 线下收单业务，是其特许经营的业务，需要处理好与各种银行机构或者清算组织的业务，以及保障好交易的安全。拓展线下商户的任务，对其来说，是一个低效益的事情。所以，这里又出现了一个角色，就是代理商。

代理商的主要业务是，拓展线下商户，安装和部署 POS 机，维护客户的关系。代理商公司，不具备经营线下收单业务的资格，也即没有支付牌照。所以，其业务得以开展，主要还是依托支付公司的牌照。通过通信技术和计算机系统，完成与支付公司的对接，并在自己的信息系统上管理海量的特约商户客户。

因为涉及到跟清算组织的连接，所以，第三方支付公司的结算，也要符合清算组织的规则，所以，往往，POS 机都是 T+1 结算的。这主要受限于银联的业务规则。当然，这体验不好。于是，代理商公司为了优化自己客户的体验，就想出一个办法，自己设立一家特约商户，然后，生产很多 POS 机，然后把这个 POS 机分发给自己的客户商户，这样客户商户不需要跟支付公司签约，支付给每个商户的钱，都会支付给代理商公司，这个代理商公司再根据每个订单，把钱分给客户商户。这个过程就叫做“二清”，是二次清分的意思。

在二清的场景下，第三方支付公司会把所有的订单支付都结算给代理商公司，然后代理商公司再次把钱分给底下的商户。这里，如果代理商公司，垫付一笔资金，就可以先行将资金垫付给商户，然后等 T+1 的时候，支付公司自然会结算这笔钱。这就优化了客户的体验。

当然，这里存在巨大的安全隐患，如果代理商公司不给客户商户结算，自己拿着支付公司结算的款项跑路，这就带来了巨大的风险。所以，二清是不合规的。对于特约商户来说，如果安装使用了二清的 POS 机也是有巨大的风险的。

使用 POS 机进行收款，是需要支付手续费的。手续费的主要分成方是发卡行，银联，第三方支付公司，以及代理商。手续费的费率是不一样的，到了特约商户这里，可能各不相同。就是因为这里面，第三方支付公司，或者代理商有一定的费用融合在里面，尤其是代理商，其不是金融机构，不接受监管。费用的设置，主要是依赖市场竞争来调节。所以特约商户拿到的 POS 机费率各不相同。各个行业也有不同，一般消费类的场景，现在的行情是 0.6% 左右，如果特别低，可能存在猫腻。

以上知识，主要来自搜索、知乎，不确保准确无误。下面附上一幅图解释一次 POS 机刷卡的业务流程，原图来自网络，不清楚，进行了重绘。

一次完整的POS机刷卡流程

上图中，蓝色的线条代表信息流，红色的线条代表资金流。绿色的是参与方。收单行，也叫收单机构，可以是银行，也可以是第三方支付公司。商户在收单机构处开设有结算账户。如果收单机构是银行，则结算账户本身就是银行账户，但是也极可能是专用的。如果是第三方支付公司，则结算账户可能是某种虚拟账户，在第三方支付公司的托管系统中。从结算账户到商户的一般企业账户，可能还需要一次提现，在图中都被省略。

图中清算账户管理系统是个比较神秘的系统，我猜可能是银联这样的清算组织管理各方结算账户的系统。值得一提的是，这个图里说明，从收单行进行大额清算结束后，再把钱清算到商户的账户，使用的是央行小额系统完成的。对这一点，并没有进一步的信息以印证，大家就看个意思就行了。

在移动支付领域，经常会听到这个术语，I 类户，II 类户，III 类户，这个称法，据说最早开始于 2015 年，中国人民银行的发文（银发[392]号文），内容是《关于改进个人银行账户服务加强账户管理的通知》。

里面规定了各类各级银行，要对客户账户施行实名制管理，以及账户分类管理。通知里，规范了三类账上的名称，功能和限制。

此外，关于三种账户的发文还有《关于加强支付结算管理防范电信网络新型违法犯罪有关事项的通知》（银发 2016 [261] 号文），以及 《关于落实个人银行账户分类管理制度的通知》（银发 2016 [302] 号文）。进一步规范了三类账户的使用限制和限额。

新增了诸如 I 类户一个客户在一家银行只能开设一个，II 类户年累计限额 20 万，III 类户年累计限额 10 万，日累计限额 5000 元，等规定。

三类账户的限制是从小到大，使用的便捷程度则是从困难到简单。基本可以认为是为移动支付时代定制的规则。

II 类户的一个例子

下面通过一个小例子说明一下 II 类户的现实运用情况。微众银行是中国第一批的互联网银行，是由腾讯牵头成立的，于 2014 年 12 月 16 日成立。

在微众银行的手机 App 中，每个人可以申请一张虚拟银行卡。其实这张卡，就是上文提到的 II 类户，这个账户的开户过程，不需要用户亲自到银行柜面核验，但是开设过程中，需要绑定一个 I 类户才能进行身份验证。

微众银行的储蓄卡，上面有II类户标记

根据上面 II 类户的说明，这个账户可以用于理财投资，所以，微众银行 App 里面是可以使用微众银行卡，购买理财产品的。不过将资金转入到微众银行，是比较麻烦的，如果你尝试往里面转账，你会注意到，有两个不同的转账功能。一个是从绑定卡直接扣转，这个显然要符合 II 类户的转账限额，也就是 1 万元一次的限制。这边可能会有另一个限制，就是代扣的单次限额限制。

另一个转账进入的途径是大额转账，是从你的其他银行的 I 类户的手机银行，直接给微众的卡号转账汇款。但是，你发现，如果没有事先将出账卡登记绑定到微众银行 App 的话，转账也会失败的。这也是来源于 II 类户的限制。如果未进行事先与 I 类户绑定的操作，也会受到单次 1 万，累计 20 万的限制。

如何查询自己的卡是否 II 类户？

• 工行-中国工商银行app-我的账户-查询明细（1类卡没有提示，2类卡会标明是2类卡账户）
• 中行-中国银行app-账户管理（1类卡标明1类账户，2类卡会标明是2类卡账户）
• 建行-中国建设银行app-登陆后点击首页卡号下方，进去之后会有提示1类卡还是2类卡
• 农行-中国农业银行app–我的账户-借记卡-人名币可用余额-进去后卡号前方有提示1类卡还是2类卡。
• 交行-交通银行app-搜索“银行卡管理”，（1类卡标明1类账户，2类卡会标明是2类卡账户）
• 招行-招商银行app-我的-银行卡（1类卡没有提示，2类卡会标明是2类卡账户）
• 兴业-兴业银行app-我的-银行卡-选择银行卡后在账户类型可查看

在看一些印度支付相关的文档时候，发现各种英文缩写出现得自然而然，仿佛人尽皆知一般，可惜对我们来说，还是太过陌生，本文收集一批，便于查阅。

本文内容是研究印度网络支付行业的一些笔记，主要是便于自己记忆和理解，内容不一定准确，请自行甄别。

什么是数字钱包？

数字钱包（Digital Wallet）也被称为是电子钱包（e-Wallet），从概念上来说，就是一个字面意义的钱包，只不过是电子版的。不像普通钱包，存储的是“物理意义上的”的纸币和硬币，数字钱包使用数字表示货币。

对比中国的概念来看，更像是支付宝的余额，微信支付的钱包零钱。里面的数字就代表现金。

可以使用信用卡、贷记卡，网络银行，或者 UPI 往数字钱包里充钱，但是停留在数字钱包里的钱没有任何利息。这和国内的情况也是一样的，支付宝发明了余额宝，微信支付发明了零钱宝，来解决没有利息的问题。

电子钱包里面，内置了很多账单支付功能。对比支付宝，例如“生活缴费”功能，就是支付宝内置的账单支付功能。数字钱包里，存储的金额是有限的，在印度的限制是 20,000 卢比。

什么是普通银行？

这个概念其实很简单，放在这里主要是对比另外两个概念的。受到高度监管的金融机构，除了能储蓄以外，还可以给个人和企业提供信贷服务。对储蓄的现金支付固定或者浮动的利息。

银行可以发行 ATM卡、借记卡（Debit Card）、信用卡（Credit Card），支票（Cheque），可以开设网络银行（Internet Banking），移动银行（Mobile Banking），可以进行 UPI 交易。存钱最安全的地方，是一国经济的核心构成。

什么是支付银行？（Payments Bank）

是一种由 RBI（Reserve Bank of India）开发的一种新型银行模型。基本就是银行，但是不能进行信用和贷款服务，此外还有一些限制。依据 RBI 最新的条例，支付银行可以存储 Rs. 1 lakh 的现金（10万卢比）。可以依据银行的业绩表现来进行升级。

支付银行可以发行 ATM、借记卡，本票，但是不能发行信用卡。很快也会放开网络银行，移动银行和 UPI 交易业务。你可以往你的账户上放钱，也会收到利息。目前有八家机构可以开设支付银行（拥有牌照）：

• Paytm（马上）
• Airtel M Commerce Services（已经开设）
• Vodafone M-Pesa
• Reliance Industries（把 JioMoney 钱包，转化成支付银行）
• Aditya Birla Nuvo
• National Securities Depository
• Department of Posts
• FINO PayTech

「注」以上内容大部分翻译自：

Digital Wallet vs Normal Bank vs Payments Bank – Clearing The Confusion

当年，刚开始玩网站的时候， SSL 证书还是很难获得的，只有少数几个机构支持颁发免费的证书，所以我们只能自己签名一个证书，来部署 HTTPS，但是，自签名的证书不会被浏览器承认，12306 刚上线的时候像个骗子网站，就是因为它用了自签名的证书。

后来，有了救世主，就是 Let’s Encrypt，面向全网颁发免费证书，无条件的。截止目前，全网已经有 1.9 亿网站部署了 Let’s Encrypt 的证书。我以为，我这辈子再也用不到自签名证书了。哪知道，还是让我碰到了，用自签名证书更方便的场景。

场景

这里也顺便说说我的场景好了。第一次遇到非要自签名场景是公司里部署企业内网安全的时候。咱们访问一个网站的时候，一般是服务提供商，需要部署证书，我们作为个人用户，需要通过公信力机构，认定我们在访问的服务，使用的是合法获得的证书，且我们的通信是加密的。在公司，内网网站，还需要对访问者进行验证，不是谁都能看公司内网的，必须是公司的员工才行，怎么确认这一点呢？一般我们使用密码，更进一步，只有登记在册的设备才能访问公司的内网网站，那么就需要用到客户端证书。大家，平日里用的客户端证书的场景很少，一般只有访问网银的时候，才用客户端证书，也就是 UKey，原理是一样的。

颁发客户端证书，目前，全网免费的服务非常少，既要免费，又要可以信任的，就更难找了。所以，我们当年采用这一方案的时候，不得不使用自签名证书。

第二次就是最近，我是一个个人开发者，想要做一个 Telegram 机器人，这就需要跟服务器通信，比如，设置 Webhook 之类的，现在这类需要去服务端注册的回调，都要求强制 HTTPS 了，微信的公众号也是需要 HTTPS 的。这里，其实 Let’s Encrypt 是可以解决的，不过我想在本地电脑搭建一个开发环境，让服务器的回调发到我的本地，这样，我开发调试起来非常容易，那就不那么容易解决证书的问题。所以，我想到了，还是弄个自签名证书方便，反正只是在开发环境用一下。

EasyRSA

EasyRSA 是 OpenVPN 社区旗下的一个自项目，专门用来搭建一个 CA 的全部命令行套件。其本质是一套 shell 脚本，里面真正起作用的是 OpenSSL 的命令。如果，你非常熟悉的话，直接用 OpenSSL 也是可以的。

现在进入主题了，接下来本文介绍如何使用 EasyRSA 创建一个 SSL 证书。

下载安装 EasyRSA

因为是一款 shell 软件，本质上下载后解压就是安装完毕了：

1
2
3
4
5

# 去 GitHub 下载最新 Release 现在是 v3.0.6
curl -OL https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.6/EasyRSA-unix-v3.0.6.tgz
# 解压缩
tar xf EasyRSA-unix-v3.0.6.tgz
cd EasyRSA-v3.0.6

然后，我们可以看到一个 easyrsa 可执行文件在目录里，已经安装完毕了。

创建证书颁发机构 CA

接下来就要创建证书颁发机构了，这里有个小技巧，介绍一下，就是等下可能会在目录下生成很多文件，你可能会搞不清楚，生成了哪些，可以现在提前把整个目录变成本地 git 库，提交所有文件，然后一旦有新文件生成了，就很容易分辨。

1
2

# 第一个命令，初始化公钥基础设施（Public Key Infrastructure）
./easyrsa init-pki

公钥基础设施（PKI），是一个安全体系，也是咱们整个互联网的安全基础，我们接下来要讨论的一些概念，都是这个体系内的角色，所以，无论要扮演哪个角色，都需要先拥有一个 PKI。

图注：PKI 的简易版流程

初始化好 PKI 后，我们会发现，多了一个目录，叫 pki/ 里面有两个目录，一个是 private 显然，里面将要存储私钥了，另一个目录叫 reqs/ 看起来，要存储申请（request）了。

第一个，要扮演的角色是证书颁发机构（Certificate Authority）也就是我们说的 CA：

1
2

# 创建 CA 的时候，可以不使用选项，这里开启了一个 nopass 的选项，作用是，创建的 CA 不使用密码保护自己最重要的私钥，因为咱们是在玩开发环境嘛，如果是用于生产，还是需要密码保护的。
./easyrsa build-ca nopass

创建过程中，会问你要 Common Name，你可以输入一个英文句号 . 来表示留空，我输入了自己的名字 Charles，哈哈 :D

创建好 CA 后，我们在 pki/ 目录下，看到一个 ca.crt 这是 CA 的公钥，在 private/ 目录下，有 ca.key 这是 CA 的私钥，也是一个 CA 最要命的东西了。还有其他一大堆的文件，先不要管了。

创建申请表 CSR

刚才也简单介绍了 PKI 是怎么回事，也说到，在这个体系内，会有好多个角色，第一个角色，就是证书颁发机构 CA，然后，我们的目的是得到一张服务器证书，现在就要扮演另一个角色，就是证书申请人。

1
2
3
4

# 作为证书申请人，也是需要先初始化 PKI 的，当然，因为咱们全在同一台电脑上，就没必要这么做了，因为上一个步骤，已经有初始化好了一个 PKI 了
./easyrsa init-pki
# 接下来，要创建证书签名申请 CSR（Certificate Signing Request），咱们这里又用了一个 nopass 的参数，开发环境噢。Demo 只是一个名字而已，无所谓是什么。
./easyrsa gen-req DEMO nopass

这里应该比较容易理解吧，有一个证书颁发机构，申请人，先填写一个申请表，接下来拿去机构盖章（签名），于是就签发了一个证书出来。

这个脚本的执行过程中，会问及你的 Common Name，这个时候，如果证书是要用于网站的域名证书的时候，应该在这里填写上网站的域名。

导入申请

继续咱们的角色扮演游戏，咱们现在又要扮演回 CA 的角色了。申请人已经填写了申请表，接下来，提交了申请。作为 CA，我们收到了申请人的申请，需要将申请导入系统：

1
2

# 还记得上面初始化 PKI 的时候，我们说了一个 reqs/ 的目录吗？申请表在那个目录里
./easyrsa import-req ./pki/reqs/DEMO.req HelloDemo

上一个步骤，我们把 CSR 取名为 DEMO 了，所以，这次我们把第二个参数取名为 HelloDemo，为了跟刚才那个名字不一样，然后你就能看到比较好玩的，pki/ 目录下，除了 DEMO.req，又多了一个文件叫 HelloDemo.req，我有一个大胆的想法不知道当讲不当讲，哈哈哈，你猜对了，这两个文件一模一样，因为一般来说，证书申请的时候，CA 都不会是你自己的电脑，现在同一台服务器，扮演两个角色，就搞笑了，左手导入到右手，根本一回事嘛，所以，上面这步，在同一台电脑上是多余的。可以根本不做。只要你记得，你想签名的那份申请是叫 DEMO 就可以了。

签发证书

既然演戏，我们就演到底，咱们现在继续扮演 CA，需要给刚刚导入的 HelloDemo 签名了：

1

./easyrsa sign-req server HelloDemo

命令倒是简洁而且干脆啊…… 执行完毕后，证书就签发完毕了，在 pki/ 目录下，多了一个叫 issued/ 的子目录，里面存放了签发的证书，HelloDemo.crt，有效期默认是 1080 天。私钥就是前面生成 CSR 的时候，在 private/ 目录里的 DEMO.key。到此，我们需要的自签发网站证书就生成完毕了。

证书部署

生成好证书以后，我们就要把证书部署到本地的 Web 服务器上了。

Apache 证书部署

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

SSLEngine on

# Uncomment the next line if Apache should not accept SSLv3 connections, to learn more google for "POODLE SSLv3".
# SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:-SSLv3:+EXP:+eNULL

# Comment the next line (and uncomment the line above) if Apache should not accept SSLv3 connections, to learn more google for "POODLE SSLv3".
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

SSLProtocol         -all +TLSv1.2 +TLSv1.1 +TLSv1
SSLCipherSuite      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
SSLHonorCipherOrder on
SSLCompression      off

SSLCertificateFile    "/path/to/cert.crt"
SSLCertificateKeyFile "/path/to/cert.key"
SSLSessionTickets on

在 <VirtualHost/> 区段内，添加上述 SSL 有关的配置，关键是 14，15 行，证书文件和私钥的配置。因为，这个例子里面是顶级 CA 直接签发，所以，也不需要配置 Chain 了，否则真正的 SSL 证书还需要配置 SSLCertificateChainFile。因为一般颁发证书的，都不会是顶级 CA，所以，需要 Chain 来描述整个证书链，让浏览器可以确认安全。

Nginx 证书配置

在 nginx 服务器上，配置大概是这样的：

1
2
3
4
5
6
7
8
9
10
11

ssl on;
ssl_certificate     /path/to/cert.crt;
ssl_certificate_key /path/to/cert.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

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:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:DES-CBC3-SHA;

ssl_prefer_server_ciphers on;

上面这一段，配在 server 区段里。咱们的例子里，生成的证书对是 HelloDemo.crt 和 DEMO.key 一个是公钥，一个是私钥，我重命名为 cert.crt 和 cert.key，主要是为了好看，这里说明一下。

根证书导入

使用了私自签发的证书后，用浏览器访问本地的站点，会发现浏览器报不安全，要点好几次，才可以真的进入，还会有一个红色的警告。如果嫌麻烦的话，可以把跟证书，导入到系统的信任证书中。就是咱们在创建 CA 的时候，生成的 CA.crt ，在各种操作系统里，基本双击就可以激活导入程序了，询问的时候，都点“信任”就可以了。你自己生成的证书，也没什么可怕的了。

总结

以上这些，其实都可以使用 OpenSSL 里面自带的命令完成，不过，那个命令的参数非常多，也非常不友好，比较起来就好像是用 C 语言编程和用 Python 语言编程的区别。后者对用户更加友好，隐藏了更多的底层细节，生产力更加高。

本文介绍了 EasyRSA 的基本使用方法，以及穿插介绍了 PKI 的基本流程和几个关键角色。如果想要深入的了解，还是敬请阅读《HTTPS权威指南》by Ivan Ristic。

—全文完—

Update:

今天用了这个自签名证书，部署 Telegram 和 Potato 的机器人的 Webhook，发现，土豆是正常能用的，但是电报竟然一直说证书验证错误。这里贴一个电报官方给的生成自签名的方法：

1

openssl req -newkey rsa:2048 -sha256 -nodes -keyout YOURPRIVATE.key -x509 -days 365 -out YOURPUBLIC.pem -subj "/C=US/ST=New York/L=Brooklyn/O=Example Brooklyn Company/CN=YOURDOMAIN.EXAMPLE"

注意一下，它用的是 openssl 套件，调用了 req 命令，根据上面的介绍，这个命令本质上是生成签名请求用的，文档里说，也可以用于生成自签名证书，场景是生成 root 证书的时候。