certbot renew で Connection refused になってしまったので調べてみた。

Let's Encryptで証明書更新をしたのですが、Connection refused となってしまったので、原因を調べてみました。以下がエラーになったときのログです。ドメイン、IPは伏せています。


# certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/web.example.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for web.example.com

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Domain: web.example.com
  Type:   connection
  Detail: xxx.xxx.xxx.xxx: Fetching https://web.example.com/.well-known/acme-challenge/9109eVHrvSxOWX3e1EM94RDM42AGDBEk6pamz0Rm6qE: Connection refused

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Failed to renew certificate web.example.com with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/web.example.com/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

certbotが https://web.example.com/.well-known 配下に一時ファイルを作成していて、それをLet's Encryptの認証局がダウンロードするようなのだけど、それができないらしい。certbot renew をして別画面を立ち上げて .well-known フォルダが作成されるかを確認したところ、フォルダは作成されているのはわかりました。ということは、外部からは .well-known フォルダがわかっていないらしい。

/var/log/letsencrypt/letsencrypt.log が出ているので、そちらを見てみたらポート80とポート443とではIPアドレスの名前解決方法が違うようです。ポート80ではIPv4を使い、ポート443ではIPv6を使っていることがわかりました。以下が、letsencrypt.log の抜粋です。


{
  "url": "http://web.example.com/.well-known/acme-challenge/9109eVHrvSxOWX3e1EM94RDM42AGDBEk6pamz0Rm6qE",
  "hostname": "web.example.com",
  "port": "80",
  "addressesResolved": [
    "xxx.xxx.xxx.xxx",
    "2406:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1291"
   ],
   "addressUsed": "xxx.xxx.xxx.xxx"
},
{
  "url": "https://web.example.com/.well-known/acme-challenge/9109eVHrvSxOWX3e1EM94RDM42AGDBEk6pamz0Rm6qE",
  "hostname": "web.example.com",
  "port": "443",
  "addressesResolved": [
    "xxx.xxx.xxx.xxx",
    "2406:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1291"
  ],
  "addressUsed": "2406:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1291"
}

DNSの名前解決でIPv6を登録したのですが、どうやらそれが原因だったようです。なので、DNSのIPv6の名前解決を削除して改めて certbot renew をしてみました。


# certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/web.example.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for web.example.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded: 
  /etc/letsencrypt/live/web.example.com/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

成功しました!

どうやらIPv6の名前解決に原因があったようでした。

無線LANのセキュリティ規格(WEPからWPA3まで)

無線LANのセキュリティ規格である、WEP、WPA、WPA2、WPA3についてまとめてみました。

歴史を振り返ってみると無線LANの暗号方式として最初に登場したのはWEPです。ですが、WEPには致命的な脆弱性が見つかってしまい代替となる暗号方式が必要になりました。

その当時はIEEEが無線LANのセキュリティ規格であるIEEE802.11iの標準化を進めていたのですが、標準化の完了を待っていられる状況でもなく、Wi-FiアライアンスがIEEE802.11iのドラフト版をもとにWPAを策定しました。Wi-Fiアライアンスは無線LAN製品の普及促進を図る業界団体です。

その後、IEEE802.11iが標準化されるとWi-FiアライアンスはWPA2を策定しました。ですのでWPAとWPA2の中身はほとんど変わりません。

WEPはもともとは暗号方式を表す言葉だったのですが、WPAやWPA2と比べられるため規格名としても使われるようになったようです。もしWEPに脆弱性が見つからなければ(WPAという規格は存在しなくなり)WEPやIEEE802.11i準拠という呼び名になっていたかもしれません。

長らくはWPAやWPA2が使われていたのですが、今の最新規格は2018年に登場したWPA3です。WPA2の登場から実に14年ぶりのことでした。

ではそれぞれの規格が、どういう暗号方式で、それはどのような暗号アルゴリズムを使っていて、認証方式はどうなっているのか?を見てみます。

図の中にある認証方式(パーソナルとエンタープライズ)については後述するので、まずは暗号方式と暗号アルゴリズムについて説明します。

WEPは暗号アルゴリズムにRC4を使っています。先ほど書いたようにもともとWEPは暗号方式を表す言葉だったのが規格名としても使われるようになりました。認証方式はパーソナルのみです。

WPAの標準の暗号方式はTKIPです。TKIPでは暗号アルゴリズムにRC4を使います。WPAではオプションで暗号アルゴリズムにAESを選ぶこともできます。AESは暗号アルゴリズムであって暗号方式ではないのですが、AESが信頼性の高い暗号アルゴリズムであったために本来の方式であるCCMPという呼び名は省略されて(暗号アルゴリズムと方式を合わせて)AESと言われることが多いようです。

WPA2では標準の暗号アルゴリズムとしてAESを使います。つまりWPA2の標準の暗号方式はCCMPとなります。WPA2ではオプションとしてTKIPも選ぶことができます。ですが暗号強度が劣るTKIPに変更する必要はないでしょう。

WPA、WPA2とも認証方式はパーソナル、エンタープライズのどちらでも選択が可能です。

WPA3はWPA2と同様に暗号方式はCCMPですが、暗号アルゴリズムにAESより強い暗号強度を持つCNSAを使うことができます。CNSAは認証方式がエンタープライズのときに選択が可能です。AESは128ビットの暗号強度ですがCNSAは192ビットの暗号強度になります。

ここから認証方式についてです。

パーソナルはPSK(Pre-Shared Key)による認証方式です。端末と無線LANアクセスポイントとで共通のパスフレーズを設定します。端末から送られてきたパスフレーズがアクセスポイントが持つパスフレーズと一致すれば認証OKとなります。

WPA2ではパスフレーズを総当たりや辞書攻撃により推測されてしまう危険性があったのですが、WPA3ではSAEという新しい手続きを導入することでこれらの攻撃に対して強くなっています。

エンタープライズはIEEE802.1Xによる認証方式です。IEEE802.1Xでは、クライアント(サプリカント)、認証装置(オーセンティケーター)、認証サーバー(RADIUSなど)という構成をとります。以下は無線LANでの場合です。

端末と無線LANアクセスポイント間ではEAPOL(EAP over LAN)というプロトコルを使い認証を行います。EAPはPPPの認証機能を拡張したプロトコルです。

また認証の種類には以下のようなものがあります。クライアント、サーバーの両方を認証するか、クライアントのみの認証かで違ってきます。

今は最新のセキュリティ規格であるWPA3を使うのが望ましいでしょう。