Distrusting Comodo


Update: The certificate has finally been revoked, after I have brought it up a month ago. Comodo’s Technical Support Team Lead gave me a reason why it all goes to hell is because my order is attached with an e-mail address, so I have to send the request via that e-mail. It is perfectly fine except that neither Comodo support staff nor GoGetSSL knows this should be done within this way, as Comodo’s support staff are redirecting me to go back to GoGetSSL to solve the problem at the first place.


This is not an article about Comodo being distrusted by main-stream browsers, but just me.

In short, Comodo failed to act as a trusted Certificate Authority. I recently bought a certificate from their reseller GoGetSSL and the transmit of the private key was initially not safe because I did it on a Chinese software which has zero encrypt on the messages and have files copied on their server. So we ( me and my client ) decided to re-issue the certificate and asked GoGetSSL to revoke the old one. Things start out smoothly as GoGetSSL ask for specific certification to revoke, and said that Comodo will do it in 12 hours.

Well, 12 hours past, but nothing happened on the old certificate. CRL and OCSP still validates it ( according to https://certificate.revocationcheck.com/ ). So I request it again, and GoGetSSL’s customer service try to revoke it again, some days had past, nothing happened.

Then, I tried to get in touch with Comodo by their Official website’s ticket system, I clarified the issue and want to know if they have anything to say about it, or even will it actually be GoGetSSL’s fault in this. But nope, all they replied was this:

Thank you for contacting Comodo, we will be happy to assist you.  Please contact the party in which the certificate was purchased from in regards to any revocation of your certificate.  If you have any further questions or concerns feel free to contact us again.

Which basically said nothing.

A few days ago, I published an article saying why am I deciding to move my own website’s certificate to GlobalSign because I felt Comodo is being to feel like it is “Too big to fail”. And now, if a trusted certificate authority, could not even complete the most basic part of a certification, which is validate and revoke, it’s out my friend.

Going back to GlobalSign

幾年前, xoxo 在 V2EX 上賣非法渠道的 AlphaSSL 通配符,成為了本博客的第一張證書。

因為那次的事件, GlobalSign 的信用在我心目中直線下降,以至於我以為“野卡”這個詞就是針對 GlobalSign 才出現的。

近期 CA 界好不熱鬧,繼 WoSign 事件之後 Symantec 又開始跟 Google 幹架, Comodo 趁機坐上了證書市場份額的第一把椅子。發生了這麼多事情,對我來說也是時候要重新審視自己博客證書用的 Comodo 了。

經過很多個星期對當下 CA 以及 SSL 界的文檔研究,發現各大 CA 在歷史上都有過不輕的安全事故, Let’s Encrypt 以及 COMODO 包攬釣魚域名證書發行量前二, Let’s Encrypt 作為一個目標是全免費全自動化的證書發行工具,還可以說他們的願景並不是審核網站內容,但 COMODO 是不是有點說不過去…

然後看看 Symantec ,他們收購了 Verisign 之後穩坐份額第一很久了,這次 Google 幹架估計把他們的信用也嗆的厲害… RapidSSL , Thawte , GeoTrust 全都是他家的,於是這些品牌直接以同一理由出局,希望 Symantec 能夠在這場跟 Google 的戰役中打贏吧,確實覺得 Google 有點橫行霸道,但好像又無可厚非。( Symantec 最近在國內大範圍推廣合作 DV 證書之餘,也準備正式推出一個免費發行 DV 證書的網站了)

於是,在深刮多家 CA 歷史及其 CPS 之後,最終決定回到 GlobalSign 的懷抱。其實因為 GlobalSign 是日本企業所以我一開始真的是很懷疑他們的技術實力,但目前看來無論是 Certificate Transparency 還是 OCSP 服務器的響應表現等,都是 CA 中做的最好的一家,市場份額也是全球第三,有一定用戶基數的同時又不會像 Comodo 那樣開始有點 “Too Big To Fail” 的感覺。最後,博客是因為想要 Wildcard 證書才買的 GlobalSign ,如果是 DV 證書的話 Let’s Encrypt 足矣。

Making life easier,Let’s Encrypt with 4096 Bits

我們都知道, Let’s Encrypt 的默認RSA密鑰長度是 2048Bits ,在創建網站證書的時候沒有修改這個配置的話,可能就是後悔終生(不)幸好,在90天的有效期過後,我們能夠輕鬆通過一行命令解決這個問題。

certbot renew --rsa-key-size 4096

Just run this bad boy, and you’re good to go.

 

DNSSEC,我們走!(Hexonet篇)

最近買了好幾個新域名,分別是 .gd, .io 後綴的。一直以來都看見 Hexonet 支持 DNSSEC ,但怎麼就是沒在面板上看見任何選項呢?

今天查了一下,終於知道如何操作。得手動在 API 中輸入命令…

參考資料:

https://wiki.hexonet.net/wiki/DNSSEC

http://bp.la/hexonet-cloudflare-dnssec/

首先,打開 Hexonet 的 API 執行頁面,(https://cp.hexonet.net/cp2/index.php/tools/apiaccess)

然後按照以下格式輸入命令:

command = ModifyDomain
domain = example.com
secDNS-urgent = 1
secDNS-ds0 = [KEYTAG] [ALGORITHM] [DIGEST-TYPE] [DIGEST]

這裡面唯一一個坑就是 Digest Type 吧, CloudFlare 提供的是 SHA256 ,然而這不存在…查了一下官方資料, 2 代表 SHA256 ,嗯。

Quick Memo:如何解決Percona源與MariaDB-libs衝突的問題

從Percona的Repo處安裝他們的數據庫軟件通常都會導致很多問題…

在CentOS上最常見的案例是跟系統自己的MariaDB-libs衝突(即便是全新安裝的系統),這個時候需要做的事情很簡單,就是單獨卸載掉MariaDB-libs(系統並不需要原帶的數據庫文件去啟動Percona Server)。

yum remove mariadb-libs

簡簡單單解決問題。

(注意:使用yum remove理應能夠做到不牽扯依賴包而只單一卸載該軟件包,如果發現其他依赖包被yum管理器一同要求卸載,應立即停止操作)

編譯新的TCP擁塞控制算法-BBR

最近Google新出的玩物,大家都很開心的在玩,這邊在回國之後也坐下來玩了一下。

本文章基於本人在Linode運行的服務器,系統為CentOS 7。

這裡有一個問題就是大家都以為Linode上了4.9.0內核,理所當然內置BBR了,但Linode官方其實沒有編譯進去,我們還是得自己編譯內核。

本文大部分參考了 https://blog.linuxeye.com/452.html ,Please check them out。

    1. 安裝ELRepo源

cat > /etc/yum.repos.d/elrepo.repo << EOF
[elrepo-kernel]
name=ELRepo.org Community Enterprise Linux Kernel Repository - el7
baseurl=http://elrepo.org/linux/kernel/el7/\$basearch/
http://mirrors.coreix.net/elrepo/kernel/el7/\$basearch/
http://jur-linux.org/download/elrepo/kernel/el7/\$basearch/
http://repos.lax-noc.com/elrepo/kernel/el7/\$basearch/
http://mirror.ventraip.net.au/elrepo/kernel/el7/\$basearch/
enabled=1
gpgcheck=0
EOF

    1. 平行安裝帶有BBR的4.9內核以及GRUB2

注意:GRUB2只是給KVM用的,Xen用戶請照常使用 /boot/grub/menu.lst 來引導啟動。

yum -y install kernel-ml grub2

    1. 檢查內核是否安裝成功

[root@localhost ~]# ls -l /boot/vmlinuz*
-rwxr-xr-x 1 root root 6037696 Dec 29 12:47 /boot/vmlinuz-0-rescue-72863e389b584a4dab36fae7f3bffda2
-rwxr-xr-x 1 root root 6037696 Dec 11 21:37 /boot/vmlinuz-4.9.0-1.el7.elrepo.x86_64

    1. 設置內核(Linode-KVM篇):

[root@localhost ~]# mkdir /boot/grub
[root@localhost ~]# grub2-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.9.0-1.el7.elrepo.x86_64
Found initrd image: /boot/initramfs-4.9.0-1.el7.elrepo.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-72863e389b584a4dab36fae7f3bffda2
Found initrd image: /boot/initramfs-0-rescue-72863e389b584a4dab36fae7f3bffda2.img
done

之後在Linode的面板配置文件中選擇使用 GRUB 2 啟動即可。

    1. 設置內核(非Linode-KVM篇):

[root@localhost ~]# awk -F\' '$1=="menuentry " {print $2}' /etc/grub2.cfg
CentOS Linux (4.9.0-1.el7.elrepo.x86_64) 7 (Core)
CentOS Linux (3.10.0-327.36.3.el7.x86_64) 7 (Core)
CentOS Linux (0-rescue-153a217486fe4be8a8dbd28db67ed581) 7 (Core)
[root@localhost ~]# grub2-set-default 0

  1. 設置內核(Linode-Xen篇):

編輯 /boot/grub/menu.lst :

timeout 5
title CentOS (4.9.0-1.el7.elrepo.x86_64)
root (hd0)
kernel /boot/vmlinuz-4.9.0-1.el7.elrepo.x86_64 root=/dev/xvda
initrd /boot/initramfs-4.9.0-1.el7.elrepo.x86_64.img

然後在Linode的面板配置文件中選擇 pv-grub-x86_64 啟動方式。

注意:以上更換內核方式均需重啟。

最後,配置使用BBR:

cat >>/etc/sysctl.conf << EOF
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF

sysctl -p

查看BBR是否生效:

[root@localhost ~]# sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = bbr cubic reno
[root@localhost ~]# lsmod | grep bbr
tcp_bbr 16384 16

增加 HTTP/2 支持

曾經的我天真的以為只要在 Nginx 配置文件中寫上 ssl http2 就是在用 HTTP/2 了…

經過 Maxsum 的提醒,我錯了…我錯在低估了 CentOS 的軟件版本落後程度。

Maxsum 在跟我說 ALPN 時,我還在圖樣的想著 ALPN 是什麼,而去問 Google 。很明顯,如果系統上的 OpenSSL 版本太舊,或者說使用了 Nginx 官方提前編譯好的安裝包,基本都是不支持 ALPN (HTTP/2 所需特性)的 1.0.1e 版本。

於是,幹活吧。

從官網上拖下最新的 OpenSSL 1.1.0c 壓縮包,重新編譯一次 Nginx 。

Welcome to HTTP/2 now.

好久不見,初次見面。

你好,歡迎來到白翼的服務器運維博客,但又已經不是你熟知的那個博客。

曾經的內容,今後會在某個二級域名上線,至於是哪個二級域名,我也不想公開,就讓那些內容成為古老的寶藏,等待探險人的發現吧。

好了,我們迴歸本質,談談技術。

這次為何重啟博客,有幾個理由:

  1. Typecho太久沒有人維護。
  2. 我想要重新寫點乾貨。
  3. 老博客的主題厭倦了。

還有就是,對於我這種懶癌晚期患者來說,能夠動手做這麼大改裝,一定是服務器環境也煥然一新了。

That’s right,歡迎體驗這個由 PHP 7.1 + Percona 5.7 + Nginx 1.11 驅動的服務器,部署了 Let’s Encrypt (Certbot),而且,每一個部署細節都用 Shell 腳本寫了下來,再也無需手動輸入命令肝到天亮。

Check them out:
https://github.com/richardevs/Self-written-bash-script


這次的服務器環境配置可以說是我第一次挑戰全部靠自己,之前因為網站數量過多,一直都依賴著 Virtualmin 的幫助,而 Virtualmin 的臃腫安裝步驟也實在很吃資源,於是,每一點的不滿都成為推動人類進步的動力(?)

總結一下這次遇到的困難,其實比起以前,這次可以說是很暢通無阻了:

  1. PHP 7.1 存在部分函數變更,比如 Typecho 用的 utf8_decode() 刪除了。
  2. 靠自己,就有Bug。php-xml, php-gd, php-mcrypt 等都沒有裝,導致初期測試時很多網站空白輸出。沒錯,我只裝了 php 和 php-mysqlnd 。
  3. 這次把服務器的安全性提升了一個檔次,所有 80 端口的請求都會被 301 至 HTTPS 。雖然大部分網站都能夠自動根據 HSTS 引導文件訪問 HTTPS ,然而部分上古世紀的代碼沒能做到,這個時候就需要 Content-Security-Policy : upgrade-insecure-requests 出場了。

最後,再次歡迎你到來/回來。