見出し画像
Photo by yk317ss

おやっ？Let's encryptが動かなくなった...と言うそこのアナタへ（certbot-autoのサポート終了）

Ｎ　ＩＴＫ

暑さ、ジメジメが増えてきた７月、皆様も体調など崩されていないでしょうか。

今日はサーバでSSL証明書を発行する Let's encrypt と言うサービスで起きたトラブルとその復旧方法をまとめてみようと思います。

「CentOS6」、「certbot-auto」、「Let's encrypt」と言う単語が気にかかり、同じようなトラブルに悩まれている方の参考になれば幸いです。

どんなトラブルが起きたの？

7～8年前に構築したWebサイト用のサーバでは、CentOS6.9 に Let's encrypt 用のクライアントとして certbot-auto をインストールして使用していました。

cronによる自動実行でいままで正常なSSL証明書を発行してくれていたのですが、2023/6 あたりから上手く動かなくなりました。

certbot-autoを手動実行すると下記のようなエラーメッセージが表示されます。

# certbot-auto renew
～～～
To use Certbot on this operating system, packages from the SCL repository need to be installed.
Enable the SCL repository and try running Certbot again.

どうやら certbot-auto を新しく入れなおすなどしないと、OS が古すぎるので動作しない環境になってしまったようです。(･´ω`･)ｺﾏｯﾀﾅｧ

どんな対応をしたの？（解決方法の答え）

Let's encrypt が使える別のACMEクライアント（下記バナー参照）の中で、シンプルな「acme.sh」で新しい証明書に更新する事ができました。
※acme.sh をインストールすると、自動的に cron に発行済みSSL証明書の更新処理が入る点も頭の片隅に入れておいてください。

acme.sh のインストール方法は下記バナー先の GitHub ページにある「１．How to Install」を参照してみてください。
２番以降にはSSL証明書のパターン別発行方法が掲載されています。

ただ、１点情報共有として、私の環境の問題か不明ですが、webroot モードや DNS モードでの Verifying でエラーになり、Apache モードだけ上手くいきました。

# acme.sh --issue --apache -d ～～～.com -d www.～～～.com

新しく発行されたSSL証明書を apache の設定に書き加えてあげれば更新完了です。

# vi/etc/httpd/conf.d/ssl.conf
SSLCertificateFile ～/～.com.cer
SSLCertificateKeyFile ～/～.com.key
SSLCertificateChainFile ～/fullchain.cer
SSLCACertificateFile ～/ca.cer

上記の上手く言った答えの対応以外に、上手く言かなった苦労話の対応内容もメモしておきますので、お時間に余裕があればご覧ください。

どんな対応をしたの？（上手くいかなかった苦労話）

  1. certbot-auto自体のバージョンアップを試す！
    ▼▼▼
    もうサポート終了していて出来ない…次！

  2. Web情報（2020～2021年頃）から、yum で後継システムの certbot（似たような名前）をインストールしているページがあったので試してみる！
    ▼▼▼
    古い yum リポジトリを別のもの（vault.centos.org）にしたり、古いPython環境をアップグレード（⇒Python3）したりもするが、最終的に cryptography パッケージがないので Rust で再構築したいが、新しい Rust を提供してくれる yum リポジトリが存在しないでつみました……次！

  3. Let's encrypt の主催者？の一つ、EFF が推奨している snap で certbot のインストールを試す！
    ▼▼▼
    もう yum のリポジトリで snap を提供していない…どこかに残っていないかと別のリポジトリ（archives.fedoraproject.org）なども見るが見つからない………次！

  4. SSL証明書を販売している業者から仕入れる方法を検討してみる。
    ▼▼▼
    今回のことでサーバリニューアルは確定なので、それまでの延命処理的な対応としては有りだが、問題のサイトはそれほど大規模ではなく、WordPressのホスティングサーバへの引っ越しをやっつけでやろうと思えば 1.5 日（10時間）ぐらいでいけそう……別途購入手続きやサーバへの設定の手間とトントンなので、他に方法がなければWordPressホスティングサービスへの強制引っ越しを最終手段と考えました。

以上になります。
皆様の参考になれば幸いです。


この記事が気に入ったらサポートをしてみませんか？