一次部署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，由於他們平時的工做與這一方面接觸較少，並且對於這種事情來講，它只是偶爾發生的，所以也不會在這個上面投入較多經歷。

　　信息、業務、職能等在對接的時候，每每會出現裂縫和誤差，這一方面會產生問題，另外一方面也造就了一個解決問題的價值空間，無論其是否合理，但它就在那裏。

　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　---以上是本人一點淺薄的想法，若有不對之處敬請指正---