一次部署HTTPS的相关事件引起的思考

前言：　

　　上周五快要下班的时候，忽然收到通知客户但愿了解一下部署HTTPS的流程，这种事情谁听了都会有几分诧异的。由于这件事虽然和工做有必定的相关度，但平时不会走这个方向，实际上也较少接触。此外，客户手下应该不缺人，作运维和开发的确定比我更懂这个，但状况却和我想的不同。

正文：

　　客户有需求，就应该尽可能知足！所以，尽管以前对Apache、Tomcat的一些配置不熟，也未有过本身部署HTTPS的经验【固然失败的尝试仍是有的】，便趁着周末了解了一下相关的东西，在本地搭建了环境。实践代表，当你对一个东西不熟悉的话，你对难度的预期每每会高过实际不少，固然这里说的是一个你不太了解的东西。从个人角度来讲，作完了实验以后，看了相关资料后，总结下来步骤就那么几个【熟练的人能够在不到半小时搞定我花了两天时间所作的工做】，其实真是没什么好说的。可是这里又有点区别，就若有时候写代码，花半小时写出来的代码也许光调试就须要半天或一天。这种状况是有的，当你第一次作的时候，你须要弄清楚步骤和流程，须要让结果达到你的预期。咱们会说这样子效率过低了，学习能力太差了，但在一个陌生的环境里独自摸着石头过河能走多快呢？固然，这些其实都不是谈论的重点。

　　简单说一下CentOS上Apache和Tomcat部署HTTPS的几个要点：

　　a. 绝大多数SSL的实现使用的是openssl，所以在Apache和Tomcat安装好的状况下要肯定openssl已安装；

　　b. Apache在本地生成三个文件：*.key, *.csr和*.crt，内部用于加密的状况下证书就已经有了，对应命令：　　　

#openssl genrsa –out server.key 1024
#openssl req –new server.key –out server.csr
# openssl x509 -days 3650 -req -in server.csr -signkey server.key -out server.crt

c. 在配置文件/etc/httpd/conf.d/ssl.conf中导入几个整文件：　　

SSLCertificateFile /etc/pki/tls/mycert/server.crt
SSLCertificateKeyFile /etc/pki/tls/mycert/server.key

　　　进行CA认证的证书则为ca.crt, 代替server.crt

　　d. 强制将HTTP转换为HTTPS

　　　　在/etc/httpd/http.conf末尾或网站根目录下的.htaccess写入以下代码便可指定强制转换的路径：

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} somefolder
RewriteRule ^(.*)$ https://www.domain.com/somefolder/$1 [R,L]

***亲测在httpd.conf中加入以上代码可行***

e. 虚拟主机的HTTPS配置一样在ssl.conf中　　

NameVirtualHost *:443
<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/pki/tls/mycert/ca.crt
SSLCertificateKeyFile /etc/pki/tls/mycert/ca.key

<Directory /var/www/vhosts/yoursite.com/httpsdocs>
AllowOverride All
</Directory>
DocumentRoot /var/www/vhosts/yoursite.com/httpsdocs
ServerName yoursite.com
</VirtualHost>

　　f. 重启Apache服务：service httpd restart

　　g. Tomcat生成证书

　　　　$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA  -keystore /usr/local/tomcat/conf/keystore

　　　只在本地使用的话生成keystore文件便可，如须要生成csr等文件则　　　　

keytool -certreq -alias tomcat -file Server.csr -keystore tomcat.keystore
keytool -import -trustcacerts -alias tomcat -file Server.pem -keystore tomcat.keystore

h. 在../tomcat/conf/server.xml中找到注释掉的<connector port="8443"..>, 修改成下图所示即开启SSL

　　

　　i. 强制转换为HTTPS

　　　　在conf/web.xml中添加以下代码便可完成全局强制转换HTTPS

<login-config>
　　<auth-method>CLIENT-CERT</auth-method>
　　<realm-name>Client Cert Uers-only Area<realm-name>
</login-config>

<security-constraint>
　　<web-resource-collection>
　　　　<web-resource-name>SSL</web-resource-name>
　　　　　　　<url-pattern>/*</url-pattern>
　　　　</web-resource-collection>
　　<user-data-constraint>
　　　　<transport-guarantee>CONFIDENTIAL</transport-guarantee>
　　</user-data-constraint>
</security-constraint>

　　　j. 虚拟主机的设置在server.xml中，添加对应标签及内容便可

　　　　

　　　k. 重启Tomcat

　　如上即是Tomcat和Apache上部署HTTPS的简明步骤，操做上来讲除了获取CA证书，其他都在服务器上的配置文件中完成，能够看到操做并不复杂

　　固然，若是是第一次弄，或者须要根据业务进行调整及配置，那天然就没这么简单了

思考：

　　将HTTP改成HTTPS天然上信息安全方面的思考，照我以前的理解来看，运维人员显然应该对此比较熟悉，而客户那边作运维的人但是不少的，这又是本文一开始提到的这事谁听了都会有几分诧异的。事实上，状况和我理解的不同，客户的业务量很大，他们并不像许多公司货企业那样有一班负责网络、服务器等运维的人，他们的员工稍微有点不同。这些都不是重点，重点是他们将不少项目外包出去给开发商作，就是说本身提出要求，而后等着验收。因为本身并无接手项目，对一些相关的知识存在理解上的欠缺也就说得过去了，本身的工程师不知道怎么进行相关配置【又诧异了吧】

　　客户有部署HTTPS的需求，这种事本应该顺手就交给开发商作了，但开发商说这须要对代码进行较大改动，不肯意作这事。因而万能的某乙方工程师出场了，客户出了钱买服务，什么事都会想到找你。基本上就是以为本身被某乙方忽悠了，而后找另外一个乙方来咨询，好家伙，这下子由不懂变得懂了点，能够进行谈判了

　　以我肤浅的经验来看，这种事情代码层面就不须要作什么更改，弄好证书，改改配置文件就好了。我在这里并不似要吐槽客户或批判谁，只是提出本身的一点思考。

　　首先:

　　客户找上来，为其提供的某项服务与平时所作的有必定差距，但并不是绝不相干，只要有关系，服务方就逃不了

　　客户的需求在时间上有必定的紧迫性，所以，为了避免让客户着急，就得牺牲本身的休息时间，这一点开网店的同窗有时候劳累过分跟这个就有点像

　　客户以为他既然出了钱购买你的服务，你就应该尽量的帮他解决问题，最好是解决全部问题，在他看来，只要能有半毛钱关系就会拉上你【具体因客户而异】

　　客户在遇到问题时，有不少时候本身不知道该如何处理或者自身并无这方面的能力，此时不只是一个服务于被服务的关系，同时也是向你寻求帮助，若是你不帮这个忙，他可能就不知道该找谁了

　　客户的业务量很大，不少方面如运维都有刚需，但从成本方面或业务的相关性方面等考虑会进行必定的取舍，专一于本身的核心业务，而其余的则交给他们认为的可靠第三方

　　其次：

　　最初认为，开发商偷懒或怎样的，做为开发人员处理这种事天然是没问题的，有可能他们认为部署HTTPS或更改服务器配置须要花较多时间，而这些时间都是要计算在本身的成本中的。从他们的角度来说，这大概算是一项增值的或附加的服务，若是这是麻烦或者我为你多作些什么，可是却没有附加的报酬，那我确定是不乐意的。这是一种猜测，后来客户说，与开发人员沟经过后发现开发人员对服务器的配置不太了解，这，又是一件让人很诧异的事情了。依旧不针对任何人或任何事，由于不了解这两方之间的业务关系，加上开发人员主要任务是写代码，对他们而言在指定的环境下完成指定的功能即可，所谓术业有专攻也何尝不可能。

　　最后，本人与上文提到的开发商实质上都是提供服务的乙方，而咱们之间共同的客户则是甲方。甲方出钱，但愿乙方尽量多地为他服务，所以在不少事情上会比较多地依赖于乙方，自身没有太多解决问题的能力。另外一方面也体现出他能够专一于本身的业务，减小一些对于他来讲不是很必要的业务成本。乙方的生成依赖于甲方的业务，须要尽量知足对方的需求，尤为以信息安全方面的服务更是要在方方面面都有必定的解决问题的能力，有时候专一度没法提高，但综合业务能力会比较强。这里面还有一个引发我思考的问题，就像如今学校里专业划分愈来愈细同样，社会上的工做岗位也是这样，在乙方可能须要干不少事情，而在甲方如阿里、百度、腾讯等极可能即是一我的负责一整块业务，管好本身的业务就好了。精细化分工，可让咱们专一于本身的领域，在纵向层面走得更远，同时也让接触面变得更小了。所以当问题出如今两项业务的中间范围时，首先该由谁解决这个问题须要商榷，另外一方面，这其中必然会有本身不熟悉的东西在里面，而对通常人来讲，解决陌生问题的预期付出会比实际更高。未知和陌生自己就有一种不肯定性，而人的习惯是喜欢可预测和掌握的，对不肯定性的恐惧会带来对目标的高估。这也就能够解释客户那边主要的工做是运维，但这个可能本该属于运维的工做本身却胜任不了，一样的做为开发商也会以难度大为理由推脱由己方部署HTTPS，由于他们平时的工做与这一方面接触较少，并且对于这种事情来讲，它只是偶尔发生的，所以也不会在这个上面投入较多经历。

　　信息、业务、职能等在对接的时候，每每会出现裂缝和误差，这一方面会产生问题，另外一方面也造就了一个解决问题的价值空间，无论其是否合理，但它就在那里。

　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　---以上是本人一点浅薄的想法，若有不对之处敬请指正---