前言：
上周五快要下班的时候，突然收到通知客户希望了解一下部署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，因为他们平时的工作与这一方面接触较少，而且对于这种事情来说，它只是偶尔发生的，因此也不会在这个上面投入较多经历。
信息、业务、职能等在对接的时候，往往会出现裂缝和偏差，这一方面会产生问题，另一方面也造就了一个解决问题的价值空间，不管其是否合理，但它就在那里。
---以上是本人一点浅薄的想法，如有不对之处敬请指正---