Let’s Encrypt の証明書の自動更新が失敗しているサーバーがあって、原因を調べたら AAAA レコードに設定している IPv6 アドレスが間違っていたのが原因でした。

環境

  • Debian GNU/Linux 8.8 (jessie)
  • certbot 0.10.2-1~bpo8+1
  • さくらインターネットの VPS で IPv6 を使用 (過去に tun6rd を使っていた)

現象

2016-03-29 に現在のサーバーに移動した時に A レコードを書き換えただけではなく、追加で tun6rd の頃の IPv6 アドレスを AAAA レコードに設定してしまいました。 別の IPv6 アドレスを設定しているサーバーからの接続に時間がかかるという現象が発生していたものの、原因がわからず、ずっとそのままの状態でした。

StartCom の証明書が事実上使えなくなってしまったので、 2016-12-04 に Let’s Encrypt の証明書に変更しました。 初回の証明書の発行のときには問題なく発行できていました。 2017-02-03,2017-04-04 の自動更新も問題なく動いていました。

6月の自動更新で突然失敗するようになり、数日様子を見ていましたが、失敗し続けていたので、詳しく調査することにしました。

調査

色々悩んだ結果、 /var/log/letsencrypt/letsencrypt.log を眺めていたところ addressUsed に IPv6 のアドレスが出ているのに気づいて、もしかして、と思ってさらに調べることにしました。

"validationRecord": [
  {
    "url": "http://XXX.example.org/.well-known/acme-challenge/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
    "hostname": "XXX.example.org",
    "port": "80",
    "addressesResolved": [
      "XX.XXX.XXX.XX",
      "2001:e41:XXXX:XXXX::1"
    ],
    "addressUsed": "2001:e41:XXXX:XXXX::1",
    "addressesTried": []
  }
]

該当のサーバーから ping6 www.kame.net などは問題なく通り、該当サーバーへの ping6 も問題なく通ることなどを確認していたところ、IPv6 アドレスが違うことに気づきました。

修正

AAAA レコードを 2403:3a00:XXX:XXXX:XX:XXX:XXX:XX に修正して、急いでいるわけでもないので certbot の自動実行を待ってみたところ、ちゃんと更新されました。

関連情報

DVSNI challenge エラーの対処法urn:acme:error:connection の原因の例として A レコードのことは書いてあったのに AAAA レコードのことが書かれていなくて、可能性に気づくのが遅れたので、 AAAA レコードのことも書いてあると良いのではないかと思いました。

まとめ

Let’s Encrypt のサーバーの実装が変わったのか、IPv6 アドレスから IPv4 へのフォールバックをしなくなっていて、IPv6 アドレスの間違いに気づくことができ、接続が遅かった現象も解決しました。

主に IPv4 を使っているとなかなか気づかないので、 AAAA レコードを設定するときは、ちゃんと確認しておかないと、後でわかりにくいトラブルの原因になると実感しました。

Disqus Comments

Kazuhiro NISHIYAMA

Ruby のコミッターとかやってます。 フルスタックエンジニア(って何?)かもしれません。 About znzに主なアカウントをまとめました。

znz znz


Published