症状
-
ubuntu16のサーバで定期的にcurlを使って協力会社からデータを取得していたが、10月に入りデータが取得できなくなった(CentOS7,AmazonLinuxの場合は後述)
-
以下のエラーが出る
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
- PCのブラウザで該当の web API を開くと普通にデータは取得できるのでAPI側の問題ではなさそう
原因
協力会社のAPIがLet's encryptの証明書を使っていて、そのルート証明書 DST_Root_CA_X3 の期限が9月30日で切れたのが原因らしい
普通ならこれの期限が切れても新しいルート証明書である ISRG_Root_X1 を信用していればそれでいいことになるのだが、opensshのバージョンが古い(1.0.2)とそうならずDST_Root_CA_X3の期限が切れたせいで有効な証明書であるISRG_Root_X1まで信用しなくなってしまうという問題があるらしくて、それが真の原因だったみたいです
ワルブリックスさんの記事がわかりやすくて、ようやく事態を飲み込めましたが、それまでは新しい証明書がca-certificatesに入ってないだけの問題だと勘違いしていたのでハマってしまいました
なんでルート証明書がこんなややこしいことになっているかはこちらがわかりやすかったです
対策 (ubuntu16)
今回の私の件の場合ワルブリックスさんの記事の「対策」のところに書いてある２番目の
- クライアント側で DST Root CA X3 を信頼済みCA一覧から削除する
というのがやるべき対策になる
具体的には以下の通り
- 以下のコマンドでTUI(テキストユーザーインターフェイス）のca-certificates設定画面を出す
sudo dpkg-reconfigure ca-certificates
- 「はい」を選択すると、信用してる証明書一覧が出てくるのでDST_Root_CA_X3でスペースを押し、アスタリスクを外す
- 「了解」を選択
事情によってTUIが使えない場合は/etc/ca-certificates.confを編集してDST Root CA X3を!マークでコメントアウトしてからsudo update-ca-certificatesでもいいみたいです
対策 (CentOS7, AmazonLinux)
CentOS7も古いAmazonLinuxもopensslのバージョンが1.0.2なので同様の問題がある
CentOS7のcurlはopensslを使ってないようなので問題が出ないが、wgetは同様の問題が発生する
こちらはちゃんとリポジトリが対応してくれてるので、yumでca-certificatesを更新すれば完了
sudo yum update ca-certificates