一般的なLet’s Encryptエラーの修正方法

1年 ago
桜, 春樹
2 minutes

日本語のネイティブで次の文章を言い換えてください、オプションは1つだけ必要です：
序論

ドメイン名やHTTPSサポートの設定時には多くの一般的なエラーが発生する可能性があります。ドメインネームシステム（DNS）はトラブルシューティングが困難であり、エラーを明確にDNSのせいとするのは難しいです。それらはスタックの別の部分によって引き起こされた可能性もあるためです。

悪名高き「システム管理者の俳句」は、次のようになります：

It's not DNS
There's no way it's DNS
It was DNS

サーバーのSSL/HTTPSサポートを設定しようとする際に、DNSの問題に遭遇する最も一般的なタイミングは、Let’s Encryptなどを使用する場合です。このチュートリアルでは、DNS、HTTPS、または特にLet’s Encryptに関わるときに遭遇するいくつかの一般的なエラーについて確認します。これらの推奨事項は、Silicon Cloud DNSまたは他のプロバイダーを使用している場合にも適用されます。

DNSレコード

DNSは、IPアドレスを使用する必要がある代わりに、your_domain.comのようなドメイン名を使用してWebサーバーにトラフィックを割り当て、誘導するシステムです。すべてのドメインレジストラ（Silicon Cloudを含む）は、DNSレコードを管理するための独自のインターフェースを提供しますが、全体的に似た構文とルールを使用しています。

DNSレコードの種類の完全な概要については、「DNS用語、コンポーネント、および概念の紹介」を参照してください。

最も一般的なDNSレコードはAレコードであり、ドメイン名とサーバーアドレスの主要なリンクです。このチュートリアルでは、サーバーのIPアドレスに正式なドメイン名を割り当てるために、主にAレコードに関心を持つ必要があります。

もしもあなたがSilicon CloudのDNSを使用している場合、設定されたAレコードは以下のようになります。

Required A records

DNSレコードの更新または移行

DNSの更新には少し時間がかかる場合があります。通常は30分未満で効果が現れるはずですが、変更後すぐにDNSをテストすることができないため、エラーが誤った情報を示すこともあります。また、DNSの変更がほとんどまたはすべてのグローバルなネームサーバーに広まるまで、ドメインでのLetsEncryptの設定はできません。

DNSの変更が、DNSルックアップに使用されるほとんどまたはすべてのグローバルネームサーバーに伝播されたかどうかをテストするには、whatsmydns.netのようなウェブサイトも使用できます。もしローカルでDNSが解決しない場合、それがほとんどの場所で機能するかどうかを確認できます。あなたのISPはこれらのサーバーよりも更新が遅い場合もありますが、ほとんどの場合は数分で済みます。

あなたがDNSの変更が一部のサーバーに伝わったが他のサーバーにはまだ伝わっていない短い時間枠内でテストしている場合、リモートサーバーやローカルのウェブブラウザーから異なる結果を受け取る可能性があります。それはさらに混乱を招くことでしょう。これは、あなたのリモートサーバーやドロップレットのDNSがISPの更新よりも早く行われる場合に起こります。これらのエラーを排除するために、nslookupコマンドを使用して特定のドメイン名がどのIPアドレスに解決されるかをテストすることもできます。

  1. nslookup digitalocean.com

 

Output

… Name: digitalocean.com Addresses: 2606:4700::6810:b50f 2606:4700::6810:b60f 104.16.181.15 104.16.182.15

この方法を使えば、あなたのローカルの結果がグローバルのDNSリゾルバと一致するかどうかを確認できます。

DNSの設定を長いTTL（Time-To-Live）値で行うと、更新が遅くなる可能性もあります。ほとんどのドメイン名登録業者がデフォルトのTTL値を3600秒（1時間）に設定しています。これは通常、Aレコードのすぐ隣に表示されます。長いTTL値はリクエストのキャッシュを効率的に行うのに役立ちますが、DNSの変更が伝播するのに時間がかかる場合があります。DNSの変更を行う予定がある場合やテストする場合は、一時的にTTLを低く設定することをおすすめします。

ブラウザのエラーやHTTPSの設定問題

時々、HTTPSとDNSを適切に設定したと思っても、あなたやユーザーがウェブサイトを使用しようとする際に、ブラウザでエラーが表示されることがあります。

HTTPエラーコードに関する一般的なガイドについては、『一般的なHTTPエラーコードのトラブルシューティング方法』を参照してください。これらのほとんどは直接的なHTTPSエラーを示すものではありませんが、不適切な設定から発生する可能性があります。例えば、Nginxリバースプロキシを使用してサーバー上で実行される別のアプリケーションへのHTTPSゲートウェイを提供している場合、ゲートウェイの設定が誤っていると502エラーが発生する可能性があります。

もう一つのエラーは、期限切れの証明書です。商用のHTTPS証明書とは異なり、Let’s Encryptの証明書は3ヶ月間しか有効ではありません。証明書の期限が切れる前に更新しないと、誰でもウェブサイトにアクセスする際にエラーが発生します。

通常、これはERR_CERT_DATE_INVALIDエラーが発生します。Chromeでは、以下のように見えるかもしれません。

An expired certificate browser warning

最初にLet’s Encryptを設定する際には、証明書の自動更新のためのバックグラウンドプロセスが設定されるはずです。また、Let’s Encryptは通常、証明書の有効期限が切れる直前にメールを送信することもあります。

ただし、このプロセスが誤って設定されたり、トリガーが失敗した場合は、常に「renew」引数を使用してcertbotを再実行することで、手動で証明書を更新することができます。

  1. sudo certbot renew –nginx -d example.com -d www.example.com

 

証明書を更新した後にウェブサーバーを再起動する必要があるかもしれません。もしウェブサーバーの設定に他の変更を加えていない場合、証明書が更新された後にsystemctl restart nginxを実行することで自動化して安全に再起動できます（例：スケジュールされたcronに追加するなど）。

混合コンテンツ (こんごうコンテンツ)

HTTPからHTTPSへの複雑なスタックの移行を行っている場合、一部の画像や他のサイトの資産が表示されない場合があります。ブラウザの開発者コンソールを開くと、「混合コンテンツ」としてこれらのエラーが表示されます。

Mixed content browser errors

これは、HTTPS経由で提供されているウェブサイトにはHTTPコンテンツが含まれないというデフォルトのウェブポリシーのためです。これは、1つのサイトが2つの異なるウェブサーバーからコンテンツを読み込む場合や、ウェブアプリケーションがNginxゲートウェイの背後から提供されているが、SSL転送が正しく機能していない場合に発生することがあります。

もしNginxを使用していて、ウェブサーバーの背後で実行されている別のアプリケーションにトラフィックを転送していて、混合コンテンツの警告が発生している場合には、場所ブロックにいくつかの追加のSSL転送設定を追加してみることができます。

あなたのウェブサイトの場所は、”/etc/nginx/sites-available/your-website” です。
…
    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto https;
    }

それを超えて、提供しているすべてのサイトがHTTPSで設定されていることを確認してください。混在コンテンツエラーに関しては、MDNドキュメントを参照することもできます。

Let’sEncryptのCertbotスクリプトのエラー実行

Let’sEncryptのcertbotスクリプトを実行する際に、エラーに遭遇することもあります。時には、これらのエラーには具体的な出力が表示されるため、直接対処できます。ただし、他の場合はより明確ではないかもしれません。スクリプトが「タイムアウト」している場合は、おそらくファイアウォールの問題です。

  1. certbot –nginx -d example.com -d www.example.com

 

Output

Press Enter to Continue Waiting for verification… Cleaning up challenges Failed authorization procedure. example.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://example.com/.well-known/acme-challenge/EWbLNaAWwRZGM1UCqSvbIIxFFaoH09wPUEwVuYucCb0: 93 Timeout during connect (likely firewall problem)

通常、タイムアウトは応答を全く得られない接続によって引き起こされますが、ファイアウォールが意図的にすべてのトラフィックをドロップしているため、これの確認ができません。Certbotを実行する前に、ファイアウォールがポート80または443をブロックしていないか確認してください。一部のドキュメンテーションでは、ポート80または443のいずれかだけを開放すれば良いと示唆されることもありますが、エラーを排除するために両方を開放してみることをお勧めします。Nginxを使ってUFWを使用している場合、Nginxのフル設定を有効にすることでこれを実行できます。

  1. sudo ufw allow ‘Nginx Full’

 

ファイアウォールの設定を変更した後、certbotを再実行してみてください。もしエラーを除外するために何度も連続してcertbotを再実行した場合、このような「検証の失敗制限」メッセージが表示されるかもしれません。

Output

too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/

この場合、アカウントの制限が解除されるまで最大1時間お待ちいただく必要があります。バリデーションの制限やその他のCertbotエラーについての詳細は、Certbotのドキュメンテーションを参照してください。

もしあなたがDNS、タイムアウト、または接続の問題以外でcertbotのエラーが発生した場合、それはおそらくcertbotによって最初に設定されたサーバーのPython環境の問題です。

これらはほとんどの場合、Certbotを削除し、最初から再インストールすることで解決できます。これを行うには、Ubuntu 22.04上でLet’s Encryptを使ったNginxのセキュリティ設定の手順1に従ってください。これにより、既存のHTTPSの設定は影響を受けず、メンテナンスと更新に使用されるツールのみが変更されます。

HTTPSが機能しなくて、何もエラーが表示されない。

もしCertbotとDNSが正常に動作していることを確認したにもかかわらず、サイトがHTTPからHTTPSへ切り替わっていないようであれば、通常はウェブサーバーの設定に問題があります。Certbotは最初に実行されたときに自動的にウェブサーバーの設定ファイルを更新しようとします。それがCertbotコマンドで通常nginxを指定する理由であり、証明書を取得した後にどのようなウェブサーバーの設定を更新するかを知るためです。しかし、既存のウェブサーバーの設定が非常に複雑な場合、CertbotはHTTPSを反映するためにそれを更新することができず、独自の変更を行う必要があります。

最初に、Ubuntu 20.04でNginxをLet’s Encryptでセキュアにする方法のステップ２にあるように、Webサーバーの設定ファイルにserver_nameブロックが含まれているか確認してください。これがないと、certbotはどの設定ファイルを更新すべきかわからなくなります。それでも問題が解決しない場合、certbotをスタンドアロンモードで実行して証明書の取得のみを行い、その後、Webサーバーを手動でHTTPSを使用するように設定する必要があるかもしれません。

ベースラインのNginx HTTPS設定には、443ポートでのsslリスンと、SSL証明書とキーへのパスが含まれます。

/etc/nginx/sites-available/sampleを日本語で書き直してください。一つのオプションだけで構いません。

/etc/nginx/sites-available/sample：

…
    listen 443 ssl;
    # RSA certificate
    ssl_certificate /etc/letsencrypt/live/your_domain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your_domain/privkey.pem;

    # Redirect non-https traffic to https
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }
…

Nginxの設定を行う際には、Webサーバーを再起動する前にnginx -tコマンドで変更内容を検証できることを忘れないでください。変更を完了したら、systemctl restart nginxコマンドで新しい設定でNginxを再起動できます。

  1. sudo systemctl restart nginx

 

結論

Let’s Encryptの目標は、誰にでも無料でどこでもHTTPSを提供することです。これが自動的に動作すると非常に便利ですが、そうでない場合は混乱することがあります。特にSSLやDNSの設定経験が少ない場合は尚更です。このチュートリアルでは、Let’s Encryptのいくつかの一般的なエラーシナリオとトラブルシューティング手順についてご確認いただきます。

次に、SSL証明書の認証機関についてさらに詳しくお読みいただけます。

コメントを残す 0

Your email address will not be published. Required fields are marked *