cURL無法訪問TLS網站故障解決_ZenDei技術網路在線

大多數人都厭煩使用老舊的系統，無論軟體還是硬體。但有的時候又不得不困守其中，堅持延續著系統的壽命，或者還需要點幾柱香，祈求神佛的護佑。 Linux是一個模塊化極好的操作系統，得益於此，當其中有組件落伍之時，大多數情況下，還能通過下載源碼，手工編譯來升級組件，從而保證系統的可用性。在這個過程中，cU ...

大多數人都厭煩使用老舊的系統，無論軟體還是硬體。但有的時候又不得不困守其中，堅持延續著系統的壽命，或者還需要點幾柱香，祈求神佛的護佑。
Linux是一個模塊化極好的操作系統，得益於此，當其中有組件落伍之時，大多數情況下，還能通過下載源碼，手工編譯來升級組件，從而保證系統的可用性。
在這個過程中，cURL工具是必不可少的，特別很多常用的開發平臺，都使用了libcurl庫作為下載的基礎工具。比如PHP/PYTHON/RUST/NPM等。當cURL出現故障的時候，直接就導致很多開發工具的升級或者安裝依賴包無法繼續。

今天碰到一個故障，一臺有些年頭的伺服器在升級一個安全組件的時候報了一個錯誤：

cURL error 35: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

字面意思上看，是ssl3在握手的時候出現了錯誤。
但實際上，如果換用一臺正常的設備訪問同樣的網站，再加上-v參數，能看到網站實際是用了TLS的加密方式：

$ curl -v https://sh.rustup.rs
* Rebuilt URL to: https://sh.rustup.rs/
*   Trying 13.225.103.123...
* TCP_NODELAY set
* Connected to sh.rustup.rs (13.225.103.123) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
    ...(略)

cURL在https的處理方面，主要依賴openssl的處理，所以實際上單純重新編譯cURL是不起作用的，必須把openssl也下載新版本重新編譯。

首先在目標伺服器上卸載掉原有的curl和openssl，並且安裝基本的編譯系統:

$ sudo apt-get purge curl libcurl3 libcurl3-gnutls libcurl4-openssl-dev openssl libssl-dev
$ sudo apt-get autoremove -y

$ sudo apt-get install build-essential libtool make

libtool make 正常情況下其實已經包含在build-essential，但仍然有個別發行版本需要單獨安裝，不過不用擔心，已經安裝過的組件反正是會自動跳過的，耽誤不了什麼時間。
在這個過程中應當慶幸apt工具並沒有依賴cURL，不然那才是一場災難 :)
不過接下來就只能換到一臺正常的電腦上工作了，因為openssl和cURL源碼的下載必須通過可用的下載工具，而通常如果openssl的版本過低，即便不用cURL，常用的wget一般也是無法工作的。
在openssl源碼的選擇上是個小坑。如果是一臺新的伺服器，當然會希望使用最新的版本，很少會有什麼相容性問題。
但在一臺老的伺服器上，操作系統版本也比較低，使用最新的版本就不一定好了。經常會碰到各種各樣的問題。這個過程很可能需要自己來嘗試，找一個儘量新，但運行沒有問題的版本。
當前在openssl官網提供下載的有三個穩定版本：1.0.2t/1.1.0l/1.1.1d，三個版本都已經支持tls，我經過測試選擇了1.1.0l，在這台伺服器能正常工作。
下載的源碼文件可以通過scp的方式拷貝到目標伺服器：

$ scp openssl-1.1.0l.tar.gz [email protected]:~/

隨後登陸到目標伺服器上：

$ tar xvf openssl-1.1.0l.tar.gz
$ cd openssl-1.1.0l
$ ./config
$ make
$ sudo make install
$ sudo echo "/usr/local/ssl/lib" >> /etc/ld.so.conf

安裝之後的測試可以通過openssl內置的s_client:

$ openssl s_client -tls1_2 -connect  sh.rustup.rs:443
CONNECTED(00000005)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = sh.rustup.rs
verify return:1
---
Certificate chain
 0 s:CN = sh.rustup.rs
   i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
 1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
   i:C = US, O = Amazon, CN = Amazon Root CA 1
 2 s:C = US, O = Amazon, CN = Amazon Root CA 1
   i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
 3 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
   i:C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIQCYiHqMAcId0Jd6fEfXdC8jANBgkqhkiG9w0BAQsFADBG
MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRUwEwYDVQQLEwxTZXJ2ZXIg
Q0EgMUIxDzANBgNVBAMTBkFtYXpvbjAeFw0xOTA1MjkwMDAwMDBaFw0yMDA2Mjkx
MjAwMDBaMBcxFTATBgNVBAMTDHNoLnJ1c3R1cC5yczCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAN7D4NF6MP8rKvehZtNeSH19cqW5DFD+o8S3rywcyWvo
jkDrdbgxrVhCBf6DY9IlVantRrSJr3N+vmd64y13riRhZC/Q4dqL7S6lyqEtOoj+
   ...(略)

能拿到伺服器發出的公鑰表示編譯的openssl版本可以正常的工作和支持tls加密。
然後可以繼續下麵編譯cURL，否則編譯完白費時間，仍然不能用。

cURL通常使用最新版就可以，極少碰到不相容的情況。仍然在工作電腦下載，完成後scp拷貝到目標伺服器，過程略。
然後登錄到目標伺服器上：

$ tar xvf curl-7.66.0.tar.gz
$ cd curl-7.66.0
# 下麵一行顯示的指名了ssl安裝的路徑，採用預設編譯的話，openssl1.1.0l是安裝在這個目錄
# openssl1.1.1d是安裝在/usr/local，請根據自己的版本確認一下安裝路徑
# 如果確認當前只有安裝的這一個版本openssl,只需要--with-ssl參數，不附加目錄參數也是可以的
# 但通常系統中因為其它依賴openssl的軟體存在，經常有其他版本的libssl,沒有被徹底刪除，
# 這時候必須制定一個準確路徑
$ ./configure --with-ssl=/usr/local/ssl
$ make
$ sudo make install

此時的cURL已經支持TLS加密的伺服器了，但使用仍會報錯：

curl: (60) SSL certificate problem: unable to get local issuer certificate

這是因為沒有安裝ssl加密的根證書。
根證書可以在https://curl.haxx.se/ca/cacert.pem下載，建議仍在工作機下載，之後拷貝到目標伺服器。
根證書放到openssl的配置目錄，一般是：/usr/local/ssl/certs/或者/etc/ssl/certs/。

之後可以正常使用了。