none
DNS ゾーン (独自ドメインの設定について) RRS feed

  • 質問

  • 初心者ですが、どうかよろしくお願いいたします。

    KUSANAGI for Microsoft Azure をDNS名ラベルで設定した後、

    独自ドメイン名を使用したいという事で、DNS ゾーンで設定した後、ドメイン取得先のサイトでネームサーバーの設定もしたのですが、

    独自ドメイン先がIt works!とデフォルトのようなままでwordpressの画面が出ません。

    一番最初にやった時は上手くいったのですが、過去の話なので、信用できませんが、何が原因か教えてもらうことはできますでしょうか。

    どうかよろしくお願いいたします。

    2017年11月10日 7:57

回答

  • Misha R様ありがとうございます。

    返事が遅れてすみません。

    サーバー証明書はLet's Encryptをそのまま使っています。デフォルトのまま使っています。それでインストールした後に

    An unexpected error occurred:
    There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for: azure.com

    Please see the logfiles in /var/log/letsencrypt for more details.
    Cannot get Let\'s Encrypt SSL Certificate files.

    の一文が登場するのですが、これが原因なのでしょうか。今の所、対応をまだしていないので未確認なのですが、ご意見があれば

    よろしくお願いいたします。

    Let¥'sの¥はバックスラッシュです。

    追記

    午後8時前現在で

    FQDN(×××.com) is already setになりましたが、サイトが独自ドメインに移行はまだしてないようです。

    午後10時30前ですが、独自ドメインで接続が確認できました。Misha R様

    大変ありがとうございます。感謝しております。


    • 回答としてマーク kkopan 2017年11月11日 13:29
    • 編集済み kkopan 2017年11月11日 13:35 更新の為
    2017年11月11日 9:22

すべての返信

  • 一番最初にやった時は上手くいったのですが、

    最初にKUSANAGI for Microsoft Azureを構築した際、下記の初期設定(プロビジョニング)コマンド

    # kusanagi provision [options] 【任意のプロファイル名】

    において、

    Enter hostname(fqdn) for your website. ex) kusanagi.tokyo

    のプロンプト表示の際、FQDNを設定されたかと思います。

    https://kusanagi.tokyo/document/kusanagi-provision/

    ご質問の現象から推測するに、このFQDNがそのままKUSANAGIに登録されており、KUSANAGI(WordPress)自身は新しい独自ドメインを知らないため、ホスト名(FQDN)解決ができず、httpd(Apache)の示すドキュメントルートへアクセスしているのではないか、と思われます。

    ("It works!"と表示される、とのことなので、おそらくApacheを選択されているかと思います)

    この場合、KUSANAGIへ改めてFQDNを再登録する必要があります。

     

    SSHコンソールからログインし、

    sudo kusanagi setting --fqdn <独自ドメイン>

    を打って、その独自ドメインでWordPressのページが表示されるか、お試しください。


    • 編集済み Misha R 2017年11月11日 2:26 外部リンク修正
    2017年11月11日 2:25
  • Misha R様 回答ありがとうございます。

    kusanagi setting --fqdn host.XXX.XXXについては検索して試した事があるのですが、

    あなたは/etc/pkiの証明書を選択しているので、サーバ設定を変更しませんでした。

    完了しました。

    との答えが返って来て、途中で変更を止めた事があります。これを修正した方がよろしいでしょうか?

    2度の質問をしてすみません。

    2017年11月11日 4:18
  • あなたは/etc/pkiの証明書を選択しているので、サーバ設定を変更しませんでした。

    完了しました。

    独自のSSLサーバー証明書をお使いでしょうか。

    そしてssl.conf、あるいはhttpd.confを、それに合わせて変更していることはないでしょうか。

     

    サーバー証明書に関しては、KUSANAGILet's Encryptがパッケージ化されており、sudo kusanagi setting --fqdn コマンドは、これと連動しているようです。

     

    最初に補足しておくべきでしたが、上記コマンドが正常終了すると、

    再度'kusanagi ssl <Eメールアドレス>'を実行してください。
    完了しました。

    というメッセージが表示されます。

    この後、

    sudo kusanagi ssl --email <最初にLet's Encryptへ登録したメールアドレス>

    を打って、Let's Encrypt証明書の更新をする流れになるのがデフォルトです。

     

    私自身はサーバー証明書の差し替えを試していないので、以下推測に過ぎませんが(そして独自証明書使用時の解決策は未知ですが)、もし、最初のKUSANAGIプロビジョニングの後、サーバー証明書を差し替えられているようでしたら、最初に作成されたLet's Encryptの証明書に戻してみては如何かと思うのですが、

    これを修正した方がよろしいでしょうか?

    と書かれている「これ」というのが上記、独自証明書の差し替えをしたか、の件に当たるのでしょうか。 

    現在までに頂いているお話からは、詳細の状況や設定内容が不明のため、もし認識が異なっていれば、その旨ご指摘いただくとともに、より具体的な設定(変更)内容をお知らせいただけると助かります。

    2017年11月11日 5:41
  • Misha R様ありがとうございます。

    返事が遅れてすみません。

    サーバー証明書はLet's Encryptをそのまま使っています。デフォルトのまま使っています。それでインストールした後に

    An unexpected error occurred:
    There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for: azure.com

    Please see the logfiles in /var/log/letsencrypt for more details.
    Cannot get Let\'s Encrypt SSL Certificate files.

    の一文が登場するのですが、これが原因なのでしょうか。今の所、対応をまだしていないので未確認なのですが、ご意見があれば

    よろしくお願いいたします。

    Let¥'sの¥はバックスラッシュです。

    追記

    午後8時前現在で

    FQDN(×××.com) is already setになりましたが、サイトが独自ドメインに移行はまだしてないようです。

    午後10時30前ですが、独自ドメインで接続が確認できました。Misha R様

    大変ありがとうございます。感謝しております。


    • 回答としてマーク kkopan 2017年11月11日 13:29
    • 編集済み kkopan 2017年11月11日 13:35 更新の為
    2017年11月11日 9:22
  • An unexpected error occurred:
    There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for: azure.com

    Please see the logfiles in /var/log/letsencrypt for more details.
    Cannot get Let\'s Encrypt SSL Certificate files.

    これは、

    Let’s Encryptcloudapp.azure.comで使おうとするときのハマりどころ - ククログ(2016-06-16)

    ここで書かれている問題と同じかと思います。


    ただ、

    それでインストールした後に

    というのが、いつインストールしたときのことか、最初にKUSANAGIをプロビジョニングしたときのことなのか、などが説明の内容からは不明ですし、「それでどうするか」についても、

    FQDN(×××.com) is already setになりましたが、サイトが独自ドメインに移行はまだしてないようです。

    この件と何かしら関係があるのか、またこのメッセージが何によって表示されたものかも不明のため、お答えのしようがないのですが、すでに何らかの試行錯誤により、何かをご自身で解決されたのでしょうか。

    あるいは、kusanagi setting --fqdn コマンドを叩いていたら何らかのタイミングで成功した、ということでしょうか。

    少なくとも、まだ独自ドメインで叩くと"It works!"が表示されている、ということなのでしょうね。

     

     

    とりあえず、ですが、

    sudo httpd -S

    と叩いて、VirtualHostに、独自ドメイン名が存在するかどうかをご確認ください。

    正しく反映されていれば、

    VirtualHost configuration:

    *:80                   is a NameVirtualHost

    *:443                  is a NameVirtualHost

    それぞれに、独自ドメイン名が

    port 80 namevhost xxx.com

    port 443 namevhost xxx.com

    として表示されているはずです。

    2017年11月11日 14:00
  • あれ、行き違いですね。

    午後10時30前ですが、独自ドメインで接続が確認できました。

    接続成功して何よりです。

     

    ところで、何が原因で、それをどのようにして成功したのか、記載しておいていただけるとありがたいです。

    2017年11月11日 14:08
  • Misha R様 ありがとうございます。ただいま確認しました。

    自分の場合はLet’s Encryptの設定で  メール欄を記入せずにenterキーを押し、

    次にkusanagi setting --fqdn <独自ドメイン名>のコマンド入力をして、

    サーバー設定が出来ませんとの答えが返って来ても 2度入力するとFQDN(×××.com) is already set

    ととなりました。自分の時は再デプロイしていますが、あくまで推測ですけれど、

    Let’s Encryptの設定がおかしかったのではないかと思います。

    このような説明でよろしいでしょうか。

    2017年11月11日 22:25
  •  なんとなく流れが見えてきた気がします。

    今回の本題である、

    独自ドメイン先がIt works!とデフォルトのようなままでwordpressの画面が出ません。

    この大元の原因は、

    kusanagi setting --fqdn host.XXX.XXXについては検索して試した事があるのですが、
    あなたは/etc/pkiの証明書を選択しているので、サーバ設定を変更しませんでした。
    完了しました。
    との答えが返って来て、途中で変更を止めた事があります。
    この kusanagi setting --fqdn host.XXX.XXX を中断したために、変更しようとした独自ドメインが反映されなかったためでしょう。

    そこで改めて、kusanagi setting --fqdn host.XXX.XXX を実行したところ、
    あなたは/etc/pkiの証明書を選択しているので、サーバ設定を変更しませんでした。
    完了しました。

    これが表示された原因は、

    自分の場合はLet’s Encryptの設定で メール欄を記入せずにenterキーを押し、

    これです。
    これをすると、Let's Encrypt証明書の発行はされず、KUSANAGIのVirtualHost用ssl.confに設定されるSSL/TSLサーバー証明書は、httpd初期値の、
            SSLCertificateFile /etc/pki/tls/certs/localhost.crt
            SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
    になります。
    改めてkusanagi setting --fqdn を実行したときに表示された「/etc/pkiの証明書」とは、これを指しています。
    ただしこの場合、ブラウザーからhttpsで接続したときに証明書エラーが発生するだけで、FQDN自体はすでに切り替わっていたはずです。
    もしhttp接続でも"It works!"が表示されていたとすれば、ブラウザー側のキャッシュの問題等、何かしら別の理由だろうと思います。

    そこでもう一度、kusanagi setting --fqdn host.XXX.XXX を実行したところ、今度は、

    FQDN(host.XXX.XXX ) は既に使われています
    完了しました。

     が表示されたのは、
    「あなたは/etc/pkiの証明書を選択しているので、サーバ設定を変更しませんでした。」
    となったときの実行で、すでにFQDNは切り替わっているので、そのままメッセージどおりの状態だからです。
    ※ちなみに、なぜこのときに選択言語:英語の

    FQDN(×××.com) is already set

    この表示になっているのかが不明ですが、別環境での実行か何かでしょうか


    そして、

    それでインストールした後に

    An unexpected error occurred:
    There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for: azure.com
    Please see the logfiles in /var/log/letsencrypt for more details.
    Cannot get Let\'s Encrypt SSL Certificate files.

    の一文が登場するのですが、これが原因なのでしょうか。

    これは先述のとおり、Let's Encryptをazure.comで(再)発行しようとして、失敗したことが考えられるのですが、単にLet's Encryptの証明書が発行されないだけなので、今回のFQDNが切り替わらない原因ではないはずです。

    ちなみに、Let's Encryptに関しては、KUSANAGIのプロビジョニング時、

    In order to use Let's Encrypt services, you must agree to Let's Encrypt's Term of Services.
    If you agree to this TOS, type your email address; if not, hit enter twice.
    TOS of Let's Encrypt : https://letsencrypt.org/repository/
    のとおり、発行は省略可能になっていますし、また、証明書がない場合の影響は、単にhttps接続でサーバー証明書なしの警告が出るだけですので、これがFQDN切り替えを失敗させる原因とはならないはずです。

    実際にサーバー証明書なしで(それと故意に誤った証明書を発行して)、http/httpsアクセス双方を試してみましたが、FQDN切り替え自体には影響せず、 kusanagi setting --fqdn によって切り替えたFQDNで正しくWordPress画面が表示されました。

    そのようなわけで、今回トラブルの原因はLet's Encrypt設定の問題ではなく、おしなべて kusanagi setting --fqdn の実行が、何かしら不完全だったことが考えられます。
    (それが何かは、すでに明確ではないようですが)

    今回の構成で、もし同じようなFQDN切り替えの失敗が発生した場合は、先述のとおり、
    sudo httpd -S
    で、切り替えたFQDN(httpdのNameVirtualHost)が正しく表示されているかの確認をお勧めいたします。


    • 編集済み Misha R 2017年11月12日 3:20 誤字訂正
    2017年11月12日 3:16
  • Misha R様 ありがとうございます。

    FQDN(×××.com) is already setが英語に変わっている理由ですが、何回かデプロイしている為に、

    表示が変わったのかと思います。それとsudo httpd -Sについてですが、以下の返答があったのでお伝えします。

    丁寧な解説ありがとうございました。

    [Sun Nov 12 13:57:29.229855 2017] [so:warn] [pid 68752] AH01574: module headers_module is already loaded, skipping
    VirtualHost configuration:
    *:80                   is a NameVirtualHost
             default server example.com (/etc/httpd/conf.d/_http.conf:2)
             port 80 namevhost example.com (/etc/httpd/conf.d/_http.conf:2)
             port 80 namevhost www.XXX.com (/etc/httpd/conf.d/kusanagi_html_http.conf:5)
    *:443                  is a NameVirtualHost
             default server example.com (/etc/httpd/conf.d/_ssl.conf:14)
             port 443 namevhost example.com (/etc/httpd/conf.d/_ssl.conf:14)
             port 443 namevhost www.XXX.com (/etc/httpd/conf.d/kusanagi_html_ssl.conf:11)
    ServerRoot: "/etc/httpd"
    Main DocumentRoot: "/var/www/html"
    Main ErrorLog: "/var/log/httpd/error.log"
    Mutex authdigest-opaque: using_defaults
    Mutex proxy-balancer-shm: using_defaults
    Mutex rewrite-map: using_defaults
    Mutex ssl-stapling-refresh: using_defaults
    Mutex authdigest-client: using_defaults
    Mutex lua-ivm-shm: using_defaults
    Mutex ssl-stapling: using_defaults
    Mutex proxy: using_defaults
    Mutex authn-socache: using_defaults
    Mutex ssl-cache: using_defaults
    Mutex default: dir="/var/run/" mechanism=default
    PidFile: "/var/run/httpd.pid"
    Define: DUMP_VHOSTS
    Define: DUMP_RUN_CFG
    Define: hsts=0
    User: name="httpd" id=1000
    Group: name="www" id=1000

    2017年11月12日 5:06