.jpg)
一、如何创建一个自签名的SSL证书
创建自签名证书的步骤
注意:以下步骤仅用于配置内部使用或测试需要的SSL证书。
第1步:生成私钥使用openssl工具生成一个RSA私钥
$opensslgenrsa-des3-outserver.key2048
说明:生成rsa私钥,des3算法,2048位强度,server.key是秘钥文件名。
注意:生成私钥,需要提供一个至少4位的密码。
第2步:生成CSR(证书签名请求)生成私钥之后,便可以创建csr文件了。
此时可以有两种选择。理想情况下,可以将证书发送给证书颁发机构(CA),CA验证过请求者的身份之后,会出具签名证书(很贵)。另外,如果只是内部或者测试需求,也可以使用OpenSSL实现自签名,具体操作如下:
$opensslreq-new-keyserver.key-outserver.csr
说明:需要依次输入国家,地区,城市,组织,组织单位,Common Name和Email。其中Common Name,可以写自己的名字或者域名,如果要支持https,Common Name应该与域名保持一致,否则会引起浏览器警告。
CountryName(2lettercode)[AU]:CN
StateorProvinceName(fullname)[Some-State]:Beijing
LocalityName(eg,city)[]:Beijing
OrganizationName(eg,company)[InternetWidgitsPtyLtd]:joyios
OrganizationalUnitName(eg,section)[]:infotechnology
CommonName(e.g.serverFQDNorYOURname)[]:demo.joyios.com
EmailAddress[]:liufan@joyios.com
第3步:删除私钥中的密码在第1步创建私钥的过程中,由于必须要指定一个密码。而这个密码会带来一个副作用,那就是在每次Apache启动Web服务器时,都会要求输入密码,这显然非常不方便。要删除私钥中的密码,操作如下:
cpserver.keyserver.key.org
opensslrsa-inserver.key.org-outserver.key
第4步:生成自签名证书如果你不想花钱让CA签名,或者只是测试SSL的具体实现。那么,现在便可以着手生成一个自签名的证书了。
$opensslx509-req-days365-inserver.csr-signkeyserver.key-outserver.crt
说明:crt上有证书持有人的信息,持有人的公钥,以及签署者的签名等信息。当用户安装了证书之后,便意味着信任了这份证书,同时拥有了其中的公钥。证书上会说明用途,例如服务器认证,客户端认证,或者签署其他证书。当系统收到一份新的证书的时候,证书会说明,是由谁签署的。如果这个签署者确实可以签署其他证书,并且收到证书上的签名和签署者的公钥可以对上的时候,系统就自动信任新的证书。
第5步:安装私钥和证书将私钥和证书文件复制到Apache的配置目录下即可,在Mac 10.10系统中,复制到/etc/apache2/目录中即可。
需要注意的是,在使用自签名证书时,浏览器会提示证书不受信任,如果你是对外网站使用,建议还是去CA机构申请可信的SSL证书,现在证书也很便宜,沃通CA超快SSL Pre才488元/年。
二、数字签名的实现为什么要使用私钥对数字摘要加密这种方式
公钥体制是数字签名的基础,数字签名就是使用数字证书的私钥对数据的摘要加密,以保证数据的完整性、真实性和不可抵赖。
数字签名(又称公钥数字签名)是只有信息的发送者才能产生的别人无法伪造的一段数字串,这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。
它是一种类似写在纸上的普通的物理签名,但是在使用了公钥加密领域的技术来实现的,用于鉴别数字信息的方法。一套数字签名通常定义两种互补的运算,一个用于签名,另一个用于验证。数字签名是非对称密钥加密技术与数字摘要技术的应用。
特点
每个人都有一对“钥匙”(数字身份),其中一个只有她/他本人知道(密钥),另一个公开的(公钥)。签名的时候用密钥,验证签名的时候用公钥。
又因为任何人都可以落款声称她/他就是你,因此公钥必须向接受者信任的人(身份认证机构)来注册。注册后身份认证机构给你发一数字证书。对文件签名后,你把此数字证书连同文件及签名一起发给接受者,接受者向身份认证机构求证是否真地是用你的密钥签发的文件。
三、四、公钥和私钥,加密和数字签名
本文涉及到支付宝SDK的内容,均摘自支付宝开放平台。
因为支付宝SDK使用RSA来加密和生成数字签名,所以本文中涉及到的概念也都是针对于RSA的。
一对儿密钥生成后,会有公钥和私钥之分,我们需要把私钥保存下来,而把公钥发布出去。一对儿公钥和私钥,不能由其中一个导出另一个。
比如使用支付宝SDK的时候,我们商户端会生成一对儿密钥A和B,A是私钥,B是公钥,支付宝也会生成一对儿密钥C和D,C是私钥,D是公钥。我们商户端需要把商户端私钥A保存下来,而把商户端公钥B发布出去给支付宝,支付宝需要把支付宝私钥C保存下来,而把支付宝公钥D发布出去给我们商户端。
加密是指我们使用一对儿密钥中的一个来对数据加密,而使用另一个来对数据解密的技术,需要注意的是公钥和私钥都可以用来加密,也都可以用来解密,并不是规定死了只能用公钥加密私钥解密,但是加解密必须是一对儿密钥之间的互相加解密,否则不能成功。
加密的目的是为了保证数据的不可读性,防止数据在传输过程中被截获。
知道了加密这个概念,我们先看一下支付宝的加密过程,再引出数字签名这个概念。接着第1小节的例子,当我们商户端和支付宝互相发布了公钥之后,我们商户端手里就有商户端私钥和支付宝公钥两个密钥,支付宝手里也有商户端公钥和支付宝私钥两个密钥。现在假设我们商户端要给支付宝传输订单信息,那么为了保证传输订单信息时数据的安全性,结合我们商户端手里所拥有的密钥,可以有两套加密方案
貌似这两套加密方案都能达到对订单信息加密的效果,而且如果采用方案二,我们商户端甚至只需要存储支付宝公钥这一个密钥,都不用去申请一对儿商户端的公私钥来维护,支付宝也不用保存我们一堆商户那么多的商户端公钥了,这不是更简单吗,那为什么支付宝开放平台让我们采用的是方案一而不是方案二呢?下面来回答一下。
支付宝开放平台说明:当我们采用RSA(1024位密钥)来加密的时候,支付宝分配给所有商户的支付宝公钥都是一样的,即支付宝针对那么多的商户只负责维护一对儿支付宝公私钥,这就意味着支付宝公钥随便什么人拿到后都是一样的;而当我们采用RSA2(2048位密钥)来加密的时候,支付宝会分配给每个商户单独的一个支付宝公钥,即支付宝为每一个的商户单独的维护一对独立的支付宝公私钥,当然一个商户下的多个App的支付宝公钥是一样的。RSA是早就支持的,RSA2是最近才支持的。
知道了上面这段话,现在假设我们采用的是方案二,并且采用RSA加密(很多老业务并没有使用RSA2加密),业务逻辑将会是下面这样。
这就出问题了, RSA加密下,支付宝公钥是公开发布的,而且所有的商户用的都是同一个支付宝公钥(上面声明了RSA2加密下,支付宝才针对每个商户维护了一对儿公私钥),攻击者很容易就能获取到,而 notify_url也很容易被截获,那攻击者拿到这两个东西就可以做和商户一样的操作来发起支付请求,这样就会一直给小明充钱了。
所以支付宝就需要确认支付请求确实是商户发给他们的,而不是攻击者发给他们的。这就用到了数字签名,我们会通过方案一的实现流程来引出数字签名的具体概念。如果我们采用的是方案一,我们商户端保存的就是商户端私钥和支付宝公钥,而支付宝保存的就是需要存着商户端公钥和支付宝私钥的,业务逻辑将会是下面这样。
这样就可以保证交易的安全性了,我们也可以看出使用支付宝SDK保证交易的安全性注重的其实不是订单信息是否加密,而是如何确保商户端和支付宝能够互相确认身份,订单信息是明文的,但是后面拼接了数字签名。
数字签名其实就是明文数据加密之后得到的一个密文,只不过它是用私钥加密生成的而已,我们一般会把数字签名拼接在明文数据后面一起传递给接收方,接收方收到后用公钥解密数字签名,从而验证发送方的身份、以及明文数据是否被篡改。数字签名的生成过程其实就是一个加密过程,数字签名的验签过程就是一个解密过程。
数字签名的目的有两个:一、发送方和接收方互相验证身份;二、验证数据是否被篡改。
从上面第一部分我们知道为了确保商户和支付宝交易的安全性,约定采用的是给订单信息加数字签名传输的方式。支付宝也为我们提供了一键生成RSA密钥的工具,可以帮助我们很快的生成一对商户端公私钥。以下会对支付宝SDK的支付流程做个大概的解释,并点出实际开发中我们使用支付宝SDK时应该注意的地方。
由我们商户端自己生成的RSA私钥(必须与商户端公钥是一对),生成后要保存在服务端,绝对不能保存在客户端,也绝对不能从服务端传输给客户端。
用来对订单信息加签,加签过程一定要在服务端完成,绝对不能在客户端做加,客户端只负责用加签后的订单信息调起支付宝来支付。
由我们商户端自己生成的RSA公钥(必须与商户端私钥是一对),生成后需要填写在支付宝开放平台。
用来给支付宝服务端验签经过我们加签后的订单信息,以确保订单信息确实是我们商户端发给支付宝的,并且确保订单信息在传输过程中未被篡改。
这个和我们就没关系了,支付宝私钥是他们自己生成的,也是他们自己保存的。
用来对支付结果进行加签。
支付宝公钥和支付宝私钥是一对,也是支付宝生成的,当我们把商户端公钥填写在支付宝开放平台后,平台就会给我们生成一个支付宝公钥,我们可以复制下来保存在服务端,同样不要保存在客户端,并且不要传输给客户端。
用来让服务端对支付宝服务端返给我们的同步或异步支付结果进行验签,以确保支付结果确实是由支付宝服务端返给我们服务端的,而且没有被篡改,对支付结果的验签工作也一定要在服务端完成。
上面已经说过了:订单信息的加签和支付结果的验签是一定要在服务端做的,绝对不能在客户端做。
下面是在客户端对订单信息加签的过程,仅仅是为了模拟服务端来表明订单信息是如何通过加签最终转变为orderString的,千万不要觉得订单信息的加签过程也可以放在客户端完成。
假设我们服务端收到了来自支付宝服务端的支付结果,即:支付结果+数字签名。
那么我们服务端就会对支付结果进行验签,怎么个验法呢?
本文来自用户投稿,不代表币大大立场,如若转载,请注明出处:https://czxurui.com/jys/158975.html


发表回复
评论列表(0条)