怎么把http请求变成https

如果你的应用使用SSL证书，则需要决定如何在负载均衡器上使用它们。

单服务器的简单配置通常是考虑客户端SSL连接如何被接收请求的服务器解码。由于负载均衡器处在客户端和更多服务器之间，SSL连接解码就成了需要关注的焦点。

2、有两种主要的策略

第一种是我们选择的模式，在haproxy这里设定SSL，这样我们可以继续使用七层负载均衡。SSL连接终止在负载均衡器haproxy ----->解码SSL连接并发送非加密连接到后端应用tomcat，这意味着负载均衡器负责解码SSL连接，这与SSL穿透相反，它是直接向代理服务器发送SSL连接的。

第二种使用SSL穿透，SSL连接在每个tomcat服务器终止，将CPU负载都分散到tomcat服务器。然而，这样做会让你失去增加或修改HTTP报头的能力，因为连接只是简单地从负载均衡器路由到tomcat服务器，这意味着应用服务器会失去获取 X-Forwarded- 报头的能力，这个报头包含了客户端IP地址、端口和使用的协议。

有两种策略的组合做法，那就是第三种，SSL连接在负载均衡器处终止，按需求调整，然后作为新的SSL连接代理到后台服务器。这可能会提供最大的安全性和发送客户端信息的能力。这样做的代价是更多的CPU能耗和稍复杂一点的配置。

那么安卓需要怎么配置才能支持https请求呢？

app网络采用的是retrofit20版本

命名文件并且导入到Android studio项目的value/raw目录下，命名为your_cercer

注意点：浏览器一把锁的图标是绿色的，说明是有第三方机构服务器认证的，这类的https请求在客户端不需要配置也可以访问，但配置了也不会出错。所以文章标题给出的是解决 自签名 的证书问题

HttpsTrustManager类：关键https配置

1、服务端的配置。 采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

2、传送证书。 这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

3、客户端解析证书。 这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

4、传送加密信息。 这部分传送的是用 证书 加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

5、服务段解密信息。 服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

6、传输加密后的信息。 这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。

7、客户端解密信息。 客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

1找到jdk安装目录，运行控制台，切换到该目录；

2使用keytool为tomcat生成证书;

keytool -genkey -v -alias tomcat -keyalg RSA -keystore tomcatkeystore -validity 36500

3为客户端生成证书;

keytool -genkey -v -alias huawei -keyalg RSA -storetype PKCS12 -keystore huaweitestp12 -validity 36500

4将huaweitestp12导入到tomcat的信任证书链中

keytool-export -alias huawei -keystore huaweitestp12 -storetype PKCS12 -rfc -filehuaweitestcer

keytool-import -alias huawei -v -file huaweitestcer -keystore tomcatkeystore

5从tomcat的证书链里导出跟证书

keytool-export -v -alias tomcat -file CAcer-keystore tomcatkeystore

6将华为的outgoingCertpem导入tomcat的信任证书链

keytool -import -v -file outgoingCertpem -alias huawei -keystore tomcatkeystore

7将华为的capem导入tomcat的信任证书链

keytool -import -v -file capem -alias huawei_ca -keystore tomcatkeystore

8配置tomcat

双向认证：

<Connector port="28443"

protocol="orgapachecoyotehttp11Http11NioProtocol"

scheme="https" secure="true"

keystoreFile="conf/keys/tomcatkeystore" keystorePass="123$%^"

truststoreFile="conf/keys/tomcatkeystore" truststorePass="123$%^"

clientAuth="true" sslProtocol="TLS"

maxThreads="150" SSLEnabled="true">

单向认证：

<Connector port="28443"

protocol="orgapachecoyotehttp11Http11NioProtocol"

scheme="https" secure="true"

keystoreFile="conf/keys/tomcatkeystore" keystorePass="123$%^"

clientAuth="false" sslProtocol="TLS"

maxThreads="150" SSLEnabled="true">

9配置完后，可以在本地验证配置是否成功。

在服务器上进行格式转换成pem格式

openssl x509 -inform der -in CAcer -out capem

通过以下命令模拟与应用服务器建链

单向认证模拟建链：

openssl s_client -connect ip:port -tls1 -CAfile capem

双向认证模拟建链：

openssl s_client -connect ip:port -cert huaweitestpem -CAfile CApem -tls1

10将生成的huaweitestp12和CAcer证书发给华为接口人。

根据您描述的这种情况，一个单域名SSL证书是解决不了问题的。需要申请一个通配符SSL证书。

1、打开iis管理器，之后右键点击要安装SSL证书的站点。并对属性进行选择，选择“目录安全性”标签，点击“服务器证书”;

2、进入web服务器证书导向，点击“下一步”，选择“处理挂起的请求并安装证书”;

3、选择证书文件;

4、输入SSL访问端口 443 ;

5、查看证书摘要，如果证书信息无误，点击下一步;

6、完成web证书向导，点击完成;检查所安装的证书;

7、查看证书信息是否有误，如无误则重启IIS查看证书作用，如果服务器上的防火墙是开启的， 那么需要打开服务器上的防火墙443端口;

通过上面步骤Windows2003+IIS6上安装SSL证书也就完成。若您收到的证书文件不是cer格式的证书，而是crt格式的证书，那么可能需要安装中级证书和根证书。

1、浏览器发起往服务器的 443 端口发起请求，请求携带了浏览器支持的加密算法和哈希算法。

2、服务器收到请求，选择浏览器支持的加密算法和哈希算法。

3、服务器下将数字证书返回给浏览器，这里的数字证书可以是向某个可靠机构申请的，也可以是自制的。 （注释：证书包括以下这些内容：1 证书序列号。2 证书过期时间。3 站点组织名。4 站点DNS主机名。5 站点公钥。6 证书颁发者名。7 证书签名。因为证书就是要给大家用的，所以不需要加密传输）

4、浏览器进入数字证书认证环节，这一部分是浏览器内置的 TSL 完成的：

41 首先浏览器会从内置的证书列表中索引，找到服务器下发证书对应的机构，如果没有找到，此时就会提示用户该证书是不是由权威机构颁发，是不可信任的。如果查到了对应的机构，则取出该机构颁发的公钥。

42 用机构的证书公钥解密得到证书的内容和证书签名，内容包括网站的网址、网站的公钥、证书的有效期等。浏览器会先验证证书签名的合法性（验证过程类似上面 Bob 和 Susan 的通信）。签名通过后，浏览器验证证书记录的网址是否和当前网址是一致的，不一致会提示用户。如果网址一致会检查证书有效期，证书过期了也会提示用户。这些都通过认证时，浏览器就可以安全使用证书中的网站公钥了。

43 浏览器生成一个随机数 R，并使用网站公钥对 R 进行加密。

5、浏览器将加密的 R 传送给服务器。

6、服务器用自己的私钥解密得到 R。

7、服务器以 R 为密钥使用了对称加密算法加密网页内容并传输给浏览器。

8、浏览器以 R 为密钥使用之前约定好的解密算法获取网页内容。

注释：

第3步中，证书的内容包含的证书的签名是什么？签名是指利用上一层证书的私钥，加密一些元信息（证书所有者的信息，包括基本信息，公钥，证书生效域名等）。这样，当收到签名证书时，只需要根据CA提供的公钥对签名解密，验证元信息是否一致，就可以判断当前证书是否合法。一句话来说就是，每个证书会对下一层的证书合法性做担保 。

第4步中，怎么认证数字证书？

客户端怎么确认你的证书是合法的呢。首先你的证书会在https握手过程中被传递到浏览器，浏览器从你的证书中找到了颁发者，从颁发者的证书（如果你电脑上有的话）又找到了CA的证书（CA证书会在操作系统安装时就安装好，所以每个人电脑上都有根证书），使用CA证书中带的公钥来对颁发者证书做验签，一旦匹配，说明你电脑上的颁发者证书不是伪造的，同理，再用颁发者证书中的公钥去验证你的证书，以此证明你的证书不是伪造的。这样整个链状的验证，从而确保你的证书一定是直接或间接从CA签发的，这样浏览器地址栏会显示一个绿色的盾牌，表示你的网站能通过证书验证

如果你的电脑上没有颁发者证书（断链）或者你自己本身就是自签名证书（自己做CA，但是要记得，人家电脑上并没有装你的自签名根证书），那么浏览器会报警提示不能验证证书，问你是否还需要继续。

过几天有时间整理下防止抓包的文档。

HTTPS实际是SSL over HTTP, 该协议通过SSL在发送方把原始数据进行加密，在接收方解

密，因此，所传送的数据不容易被网络黑客截获和破解。本文介绍HTTPS的三种实现方法

。

方法一 静态超链接

这是目前网站中使用得较多的方法，也最简单。在要求使用SSL进行传输的Web网页链接

中直接标明使用HTTPS协议，以下是指向需要使用SSL的网页的超链接：

<a href=“https://192168100100/ok/securePagejsp”>SSL例子</a>

需要说明的是，在网页里的超链接如果使用相对路径的话，其默认启用协议与引用该超

链接的网页或资源的传输协议相同，例如在某超链接“https://192168100100/ok/l

oginjps”的网页中包含如下两个超链接：

<a href=“/bessl/examjsp”>SSL链接</a>

<a href=“http://192168100100/notssl/indexjsp”>非SSL链接

那么，第一个链接使用与“https://192168100100/ok/loginjsp”相同的传输协议

HTTPS，第二个链接使用本身所标识的协议HTTP。

使用静态超链接的好处是容易实现，不需要额外开发。然而，它却不容易维护管理; 因

为在一个完全使用HTTP协议访问的Web应用里，每个资源都存放在该应用特定根目录下的

各个子目录里，资源的链接路径都使用相对路径，这样做是为了方便应用的迁移并且易

于管理。但假如该应用的某些资源要用到HTTPS协议，引用的链接就必须使用完整的路径

，所以当应用迁移或需要更改URL中所涉及的任何部分如：域名、目录、文件名等，维护

者都需要对每个超链接修改，工作量之大可想而知。再者，如果客户在浏览器地址栏里

手工输入HTTPS协议的资源，那么所有敏感机密数据在传输中就得不到保护，很容易被黑

客截获和篡改！

方法二 资源访问限制

为了保护Web应用中的敏感数据，防止资源的非法访问和保证传输的安全性，Java Serv

let 22规范定义了安全约束（Security-Constraint）元件，它用于指定一个或多个We

b资源集的安全约束条件；用户数据约束（User-Data-Constraint）元件是安全约束元件

的子类，它用于指定在客户端和容器之间传输的数据是如何被保护的。用户数据约束元

件还包括了传输保证（Transport-Guarantee）元件，它规定了客户机和服务器之间的通

信必须是以下三种模式之一：None、Integral、Confidential。None表示被指定的Web资

源不需要任何传输保证；Integral表示客户机与服务器之间传送的数据在传送过程中不

会被篡改; Confidential表示数据在传送过程中被加密。大多数情况下，Integral或Co

nfidential是使用SSL实现。

这里以BEA的WebLogic Server 61为例介绍其实现方法，WebLogic是一个性能卓越的J2

EE服务器，它可以对所管理的Web资源，包括EJB、JSP、Servlet应用程序设置访问控制

条款。假设某个应用建立在Weblogic Server里的/mywebAPP目录下，其中一部分Servle

ts、JSPs要求使用SSL传输，那么可将它们都放在/mywebAPP/sslsource/目录里，然后编

辑/secureAPP/Web-INF/webxml文件，通过对webxml的设置可达到对Web用户实现访问

控制。

当Web用户试图通过HTTP访问/sslsource目录下的资源时，Weblogic Server就会查找we

bxml里的访问约束定义，返回提示信息：Need SSL connection to access this reso

urce。资源访问限制与静态超链接结合使用，不仅继承了静态超链接方法的简单易用性

，而且有效保护了敏感资源数据。然而，这样就会存在一个问题： 假如Web客户使用HT

TP协议访问需要使用SSL的网络资源时看到弹出的提示信息: Need SSL connection to

access this resource，大部分人可能都不知道应该用HTTPS去访问该网页，造成的后果

是用户会放弃访问该网页，这是Web应用服务提供商不愿意看到的事情。

方法三 链接重定向

综观目前商业网站资源数据的交互访问，要求严格加密传输的数据只占其中一小部分，

也就是说在一个具体Web应用中需要使用SSL的服务程序只占整体的一小部分。那么，我

们可以从应用开发方面考虑解决方法，对需要使用HTTPS协议的那部分JSPs、Servlets或

EJBs进行处理，使程序本身在接收到访问请求时首先判断该请求使用的协议是否符合本

程序的要求，即来访请求是否使用HTTPS协议，如果不是就将其访问协议重定向为HTTPS

，这样就避免了客户使用HTTP协议访问要求使用HTTPS协议的Web资源时，看到错误提示

信息无所适从的情况，这些处理对Web客户来说是透明的。

实现思想是：首先创建一个类，该类方法可以实现自动引导Web客户的访问请求使用HTT

PS协议，每个要求使用SSL进行传输的Servlets或JSPs在程序开始时调用它进行协议重定

向，最后才进行数据应用处理。

J2EE提供了两种链接重定向机制。第一种机制是RequestDispatcher接口里的forward()

方法。使用MVC(Model-View-Controller)机制的Web应用通常都使用这个方法从Servlet

转移请求到JSP。但这种转向只能是同种协议间的转向，并不能重定向到不同的协议。第

二种机制是使用HTTPServletReponse接口里的sendRedirect()方法，它能使用任何协议

重定向到任何URL，例如：

BeSslResponsesendRedirect(“https://192168100100/order”);

此外，我们还需使用到Java Servlet API中的两个方法：ServletRequest接口中的getS

cheme()，它用于获取访问请求使用的传输协议；HTTPUtils类中的getRequestUrl()，它

用于获取访问请求的URL，要注意的是该方法在Servlet 23中已被移到HTTPServletReq

uest接口。

以下是实现协议重定向的基本步骤：

1 获取访问的请求所使用的协议；

2 如果请求协议符合被访问的Servlet所要求的协议，就说明已经使用HTTPS协议了，不

需做任何处理；

3 如果不符合，使用Servlet所要求的协议(HTTPS)重定向到相同的URL。

例如，某Web用户使用HTTP协议访问要求使用HTTPS协议的资源BeSslServlet，敲入“UR

L：http://192168100100/BeSslServlet”，在执行BeSslServlet时首先使用Proces

sSslServlet．processSsl（）重定向到https://192168100100/BeSslServlet，然后

BeSslServlet与客户浏览器之间就通过HTTPS协议进行数据传输。

以上介绍的仅是最简单的例子，是为了对这种重定向的方法有个初步的认识。假如想真

正在Web应用中实现，还必须考虑如下几个问题：

● 在Web应用中常常会用到GET或Post方法，访问请求的URL中就会带上一些查询字串，

这些字串是使用getRequesUrl()时获取不到的，而且在重定向之后会丢失，所以必须在

重定向之前将它们加入到新的URL里。我们可以使用requestgetQueryString()来获取G

ET的查询字串，对于Post的Request参数，可以把它们转换成查询串再进行处理。

● 某些Web应用请求中会使用对象作为其属性，必须在重定向之前将这些属性保存在该

Session中，以便重定向后使用。

● 大多数浏览器会把对同一个主机的不同端口的访问当作对不同的主机进行访问，分用

不同的Session，为了使重定向后保留使用原来的Session，必须对应用服务器的Cookie

域名进行相应的设置。

以上问题均可在程序设计中解决。

通过程序自身实现协议重定向，就可以把要求严格保护的那部分资源与其他普通数据从

逻辑上分开处理，使得要求使用SSL的资源和不需要使用SSL的资源各取所需，避免浪费

网站的系统资源。