HTTPS与SSL(二)

CA

Ca介绍

电子商务认证授权机构（CA, Certificate Authority），也称为电子商务认证中心，是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

　　CA中心为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。CA机构的数字签名使得攻击者不能伪造和篡改证书。在SET交易中，CA不仅对持卡人、商户发放证书，还要对获款的银行、网关发放证书。

CA是证书的签发机构,它是PKI(Public Key Infrastructure，公钥基础设施)的核心。CA是负责签发证书、认证证书、管理已颁发证书的机关。它要制定政策和具体步骤来验证、识别用户身份，并对用户证书进行签名，以确保证书持有者的身份和公钥的拥有权。

CA 也拥有一个证书（内含公钥）和私钥。网上的公众用户通过验证 CA 的签字从而信任 CA ，任何人都可以得到 CA 的证书（含公钥），用以验证它所签发的证书。

　　如果用户想得到一份属于自己的证书，他应先向 CA 提出申请。在 CA 判明申请者的身份后，便为他分配一个公钥，并且 CA 将该公钥与申请者的身份信息绑在一起，并为之签字后，便形成证书发给申请者。

如果一个用户想鉴别另一个证书的真伪，他就用 CA 的公钥对那个证书上的签字进行验证，一旦验证通过，该证书就被认为是有效的。

CA认证证书

证书实际是由证书签证机关（CA）签发的对用户的公钥的认证。

　　证书的内容包括：电子签证机关的信息、公钥用户信息、公钥、权威机构的签字和有效期等等。目前，证书的格式和验证方法普遍遵循X.509国际标准。 

　　如何在电子文档上实现签名的目的呢？我们可以使用数字签名。RSA公钥体制可实现对数字信息的数字签名，方法如下：

　　信息发送者用其私钥对从所传报文中提取出的特征数据（或称数字指纹）进行RSA算法操作，以保证发信人无法抵赖曾发过该信息（即不可抵赖性），同时也确保信息报文在传递过程中未被篡改（即完整性）。当信息接收者收到报文后，就可以用发送者的公钥对数字签名进行验证。

　　在数字签名中有重要作用的数字指纹是通过一类特殊的散列函数(HASH函数) 生成的。对这些HASH函数的特殊要求是：

　　1．接受的输入报文数据没有长度限制；

　　2．对任何输入报文数据生成固定长度的摘要(数字指纹)输出；

　　3．从报文能方便地算出摘要；

　　4．难以对指定的摘要生成一个报文，而由该报文可以算出该指定的摘要；

5．难以生成两个不同的报文具有相同的摘要。

CA认证验证

　　接收方在收到信息后用如下的步骤验证您的签名：

　　1．使用自己的私钥将信息转为明文；

　　2．使用发信方的公钥从数字签名部分得到原摘要；

　　3．收方对您所发送的源信息进行hash运算，也产生一个摘要；

　　4．收方比较两个摘要，如果两者相同，则可以证明信息签名者的身份。

　　如果两摘要内容不符，会说明:

可能对摘要进行签名所用的私钥不是签名者的私钥，这就表明信息的签名者不可信；也可能收到的信息根本就不是签名者发送的信息，信息在传输过程中已经遭到破坏或篡改。

CA认证数字证书

数字证书为实现双方安全通信提供了电子认证。在因特网、公司内部网或外部网中，使用数字证书实现身份识别和电子信息加密。数字证书中含有密钥对（公钥和私钥）所有者的识别信息，通过验证识别信息的真伪实现对证书持有者身份的认证。

 

CA认证使用数字证书

数字证书在用户公钥后附加了用户信息及CA的签名。公钥是密钥的一部分，另一部分是私钥。公钥公之于众，谁都可以使用。私钥只有自己知道。由公钥加密的信息只能由与之相对应的私钥解密。为确保只有某个人才能阅读自己的信件，发送者要用收件人的公钥加密信件；收件人便可用自己的私钥解密信件。同样，为证实发件人的身份，发送者要用自己的私钥对信件进行签名；收件人可使用发送者的公钥对签名进行验证，以确认发送者的身份。

 

图1.1 发送数据处理过程

 

 

图1.2接收数据处理过程

 

在线交易中您可使用数字证书验证对方身份。用数字证书加密信息，可以确保只有接收者才能解密、阅读原文，信息在传递过程中的保密性和完整性。有了数字证书网上安全才得以实现，电子邮件、在线交易和信用卡购物的安全才能得到保证。

密钥、密钥对、公钥、证书、私钥、jks、keystore、truststore、cer、pfx的区别

密钥:  公钥+私钥的统称。

密钥对：公钥(证书)和私钥成对存在。

通信双方各持有自己的私钥和对方的公钥。自己的私钥需密切保护，而公钥是公开给对方的。在windows下，单独存在的公钥一般是后缀为.cer的文件

公钥的两个用途：

1。验证对方身份：防止其他人假冒对方发送数据给你。

2。解密。

 

私钥的两个用途：

1。表明自己身份：除非第三方有你私钥，否则无法假冒你发送数据数据给对方。

2。加密。

 

jks(java key store)：

java用的存储密钥的容器。可以同时容纳n个公钥或私钥，后缀一般是.jks或者.keystore或.truststore等，千奇百怪。不管什么后缀，它就是一个容器，各个公司或机构叫法不同而已。比如把只包含"受信任的公钥"的容器存成.truststore文件等。

用jdkin目录下的keytool.exe对其进行查看，导入，导出，删除，修改密码等各种操作。

可以对jks容器加入密码，输入正确才可以操作此容器中密钥。

还有一个密码的概念与上者不同，是jks中存储着的私钥的密码，通常是绝密的。

pfx：

和jks功能相同但文件格式不同，pfx是浏览器用的。

可以用一些工具程序把pfx转化成jks格式供java程序使用(如银行只提供了pfx)。 

常见的几种https系统的访问

经https协议的数据经过加密传输，防止第三方监听，冒充和篡改。

1.不需要用户做任何操作，比如https://www.verisign.com/

这是因为此公钥是合法的(公钥是可信任的机构颁发，和实际域名吻合，而且没有到期)。用IE访问时空白处点右键可以查看公钥信息。

2.https的页面会弹出公钥确认提示

公钥不合法(不是可信任的机构颁发，和实际域名不吻合，已到期)，但用户点“是”即表示忽略危险，继续访问。

3.需要往浏览器倒入一个文件才可访问的

一般是银行在线交易等特别需要安全的场合，站方(银行)需要验证访客身份(如要确认必须是已注册的网银商户)，需要在浏览器中导入含有访客私钥的pfx文件。

如果java程序访问此地址时在jre默认的信任库中找不到对方证书的颁发机构，则会抛出安全方面的异常。所以要将站方公钥存进一个jks，并在环境变量中设定，表明信任此库中的公钥，才可以正常访问。在浏览器中查看站方公钥时，把公钥导出(一般是cer后缀)，然后用keytool.exe手工将此cer导入一个jks

TOMCAT配置单项认证

在命令提示符窗口，进入Tomcat目录，执行以下命令：
keytool -genkey -alias tomcat -keyalg RSA -keypass changeit -storepass changeit -keystore server.keystore -validity 3600
通过以上步骤生成server.keystore证书文件

将servlet.xml的SSL注释打开

<!-- Define a SSL HTTP/1.1 Connector on port 8443 --> 
<Connector protocol="org.apache.coyote.http11.Http11Protocol" 
port="8443" maxHttpHeaderSize="8192" 
maxThreads="150" minSpareThreads="25" maxSpareThreads="75" 
enableLookups="false" disableUploadTimeout="true" 
acceptCount="100" scheme="https" secure="true" 
clientAuth="false" sslProtocol="TLS" 
keystoreFile="server.keystore" 
keystorePass="changeit"/> 
到这一步访问基本配置完成.

一般Tomcat默认的SSL端口号是8443，但是对于SSL标准端口号是443，这样在访问网页的时候，直接使用https而不需要输入端口号就可以访问，如https://loalhost/webserver
想要修改端口号，需要修改Tomcat的server.xml文件：

1) non-SSL HTTP/1.1 Connector定义的地方，一般如下：
<Connector port="80" maxHttpHeaderSize="8192"
maxThreads="500" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" />
将其中的redirectPort端口号改为：443

2)SSL HTTP/1.1 Connector定义的地方，修改端口号为：443，如下：
<Connector port="443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25"
maxSpareThreads="75"
enableLookups="false" 
disableUploadTimeout="true"
acceptCount="100" scheme="https"
secure="true"
clientAuth="false" sslProtocol="TLS" 
keystoreFile="conf/tomcat.keystore" 
keystorePass="123456" />

3)AJP 1.3 Connector定义的地方(apache就是通过AJP协议与tomcat进行通信的)，修改redirectPort为443，如下：
<Connector port="8009" 
enableLookups="false" redirectPort="443" protocol="AJP/1.3" />
重新启动Tomcat就可以了。到这一步可以形成访问方式 https://ip/item

使用java内置keytool配置tomcat双向SSL认证

在Tomcat 6中配置SSL双向认证是相当容易的，本文将介绍如何使用JDK的keytool来为Tomcat配置双向SSL认证。

系统需求：

JDK 5.0
Tomcat 6.0.16

第一步：为服务器生成证书

使用keytool为Tomcat生成证书，假定目标机器的域名是“localhost”，keystore文件存放在“C:/tomcat.keystore”，口令为“password”，使用如下命令生成：

1. keytool -genkey -v -alias tomcat -keyalg RSA -keystore c:/tomcat.keystore -dname
2. "CN=localhost,OU=,O=,L=,ST=,C=" -storepass password -keypass password

复制代码

如果Tomcat所在服务器的域名不是“localhost”，应改为对应的域名，如“www.sina.com.cn”，否则浏览器会弹出警告窗口，提示用户证书与所在域不匹配。在本地做开发测试时，应填入“localhost”
；证书如果没有指定有效期，默认为90天

第二步：为客户端生成证书

下一步是为浏览器生成证书，以便让服务器来验证它。为了能将证书顺利导入至IE和Firefox，证书格式应该是PKCS12，因此，使用如下命令生成：

1. keytool -genkey -v -alias mykey -keyalg RSA -storetype PKCS12 -keystore  C:/my.p12
2. -dname "CN=localhost,OU=,O=,L=,ST=,C=" -storepass password -keypass password

复制代码

对应的证书库存放在“C:/my.p12”，客户端的CN可以是任意值。稍候，我们将把这个“my.p12”证书库导入到IE和Firefox中。

第三步：让服务器信任客户端证书

由于是双向SSL认证，服务器必须要信任客户端证书，因此，必须把客户端证书添加为服务器的信任认证。由于不能直接将PKCS12格式的证书库导入，我们必须先把客户端证书导出为一个单独的CER文件，使用如下命令：

1. keytool -export -alias mykey -keystore c:/my.p12 -storetype PKCS12 -storepass password -rfc -file C:/my.cer

复制代码

通过以上命令，客户端证书就被我们导出到“C:/my.cer”文件了。下一步，是将该文件导入到服务器的证书库，添加为一个信任证书：

1. keytool -import -v -file C:/my.cer -keystore C:/tomcat.keystore -storepass password

复制代码

通过list命令查看服务器的证书库，我们可以看到两个输入，一个是服务器证书，一个是受信任的客户端证书：

1. keytool -list c:/tomcat.keystore -storepass password

复制代码

第四步：配置Tomcat服务器

打开Tomcat根目录下的/conf/server.xml，找到如下配置段，修改如下：

1. <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
2. maxThreads="150" scheme="https" secure="true"
3. clientAuth="true" sslProtocol="TLS"
4. keystoreFile="C:/tomcat.keystore" keystorePass="password"
5. truststoreFile="C:/tomcat.keystore" truststorePass="password"
6. />

复制代码

其中，clientAuth指定是否需要验证客户端证书，如果该设置为“false”，则为单向SSL验证，SSL配置可到此结束。如果clientAuth设置为“true”，表示强制双向SSL验证，必须验证客户端证书。如果clientAuth设置为“want”，则表示可以验证客户端证书，但如果客户端没有有效证书，也不强制验证。

第五步：导入客户端证书
如果设置了clientAuth="true"，则需要强制验证客户端证书。双击“C:/my.p12”即可将证书导入至IE：
导入证书后，即可启动Tomcat，用IE进行访问。如果需要用FireFox访问，则需将证书导入至FireFox：

配置Flex使用安全通道

1.在services-config.xml中创建节点      

<channel-definition id="my-secure-amf" class="mx.messaging.channels.SecureAMFChannel">

<endpointurl="https://{server.name}:{server.port}/{context.root}/messagebroker/amfsecure"class="flex.messaging.endpoints.SecureAMFEndpoint" />

<properties>

    <add-no-cache-headers>false</add-no-cache-headers>

</properties>

</channel-definition>

2.修改自定义通道的url和class，如：

<channel-definition id="resource-streaming-amf"

 class="mx.messaging.channels.SecureStreamingAMFChannel">

<endpoint  url=https://{server.name}:{server.port}/{context.root}/messagebroker/resourcestreamingamf

class="flex.messaging.endpoints.SecureStreamingAMFEndpoint" />

3.修改proxy-config.xml中的default-channels，如：

    <default-channels>

        <channel ref="my-secure-amf"/>

</default-channels>

4.修改remoting-config.xml中的default-channels,如：

<default-channels>

        <channel ref="my-secure-amf" />

</default-channels>

5.在as中使用_remoteObject.endpoint的地方修改value：

https://{server.name}:{server.port}/项目名称/messagebroker/amfsecure