Q&A
AWS上の構成は、EC2直アクセスでALB等ロードバランサはかませてない形ですか？
この度Let's Encryptで証明書を取得し、サイトをSSL化したいと考えております。
環境は
OS : Amazon linux
Webサーバ : apache2.4 (AWS EC2でインスタンス生成時にデフォルトで導入されていたapache)
です。
現在こちらの記事の手順に従い、
https://qiita.com/sayama0402/items/011644191dfdbde9c646
cronを使った証明書更新の自動化の目前まで作業を進めましたが、この時点でサイトにhttps://ドメイン名でアクセスすると、画面上
'このサイトにアクセスできませんhoge.comからの応答時間が長すぎます。'
となってしまい設定がうまく反映されておりません。
上掲の記事の内容以外で私が試したことといえば、/etc/httpd/conf.d/ssl.confの中のバーチャルホストの記述内のServerNameを自サイトに書き換えたくらいです。
また、
/etc/httpd/logs/ssl_error_log /etc/httpd/logs/error_log
等には、アクセス後に確認しても特にエラーの記述は見られません。
ドキュメントルートにtest.phpのようなものを作成しても、やはりhttps://ドメイン名/test.phpにアクセスすると、応答時間が長すぎる旨のエラーが表示されてしまうので、アプリケーション側の問題ではなさそうです。
/etc/letsencrypt/live/ドメイン名/
の配下に必要なpemファイル等が存在していることも確認しています。
現状、http://ドメイン名では通常通りアクセスができる状態です。
どなたか上記のような現象に心当たりがございましたらお教えいただければと思います。
よろしくお願いいたします。
追記)
アクセス時のHTTPヘッダの中身です。
尚Responseの方はタイムアウト終了後空白でした。
追追記)
[ec2-user@myaws conf.d]$ cat ssl.conf Listen 443 https SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog SSLSessionCache shmcb:/run/httpd/sslcache(512000) SSLSessionCacheTimeout 300 SSLRandomSeed startup file:/dev/urandom 256 SSLRandomSeed connect builtin #SSLRandomSeed startup file:/dev/random 512 #SSLRandomSeed connect file:/dev/random 512 #SSLRandomSeed connect file:/dev/urandom 512 SSLCryptoDevice builtin #SSLCryptoDevice ubsec <VirtualHost _default_:443> DocumentRoot "/var/www/html" ServerName myaws:443 ErrorLog logs/ssl_error_log TransferLog logs/ssl_access_log LogLevel warn SSLEngine on SSLProtocol all -SSLv3 SSLProxyProtocol all -SSLv3 SSLHonorCipherOrder on SSLCertificateFile /etc/letsencrypt/live/mysite.com/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/mysite.com/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/mysite.com/chain.pem <FilesMatch ".(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory "/var/www/cgi-bin"> SSLOptions +StdEnvVars </Directory> BrowserMatch "MSIE [2-5]"nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" ServerAlias mysite.com #SSLCertificateFile /etc/letsencrypt/live/mysite.com/fullchain.pem #SSLCertificateKeyFile /etc/letsencrypt/live/mysite.com/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf </VirtualHost>
そうですね、かませてない構成です。
特定のPCやネットワークに関係なく、つまり手持ちのスマホのモバイル回線(not Wifi)でも同様の事象が発生しますか？
今PCからでなくスマートフォンの4G回線からアクセスしてみましたが、同様の現象が発生していました。
サイトアクセス時のエラーメッセージを省略無く記述してください。
多分、time out だろうと思いますが、status の記述も必須です。
こちらに画像の添付ができなかったので、質問を編集する形で画像を追加しました。
デベロッパーツールからHTTPレスポンスのステータスコードの確認ができませんでした。
実際に設定したhttpdのconfファイルを質問に追記してください。
httpd.confを追記しました。
遅くなってすみません。編集できたと思っていたら10000文字オーバーに引っかかっていました。
なのでファイル内記述上部のコメント部分を一部添削して掲載しました。
httpd.confにはListen 443に関する設定は含まれていないようです。
IncludeOptional conf.d/*.conf
にListen 443に関する設定一式があるとおもいますので、それに差し替えてもらえますでしょうか。
すみませんでした。conf.d/ssl.confと差し替えました。
またコメント部分は添削(一部残骸のように残ってしまいましたが)しました。ご確認お願いいたします。
いえ、ありがとうございます。
Listen 443のまま、SSLに関する設定をコメントアウトした場合、httpでのアクセスは可能でしょうか？
回答が遅くなってしまい申し訳ありません。
日中EC2インスタンスにログインできないもので、しかも特に今日は帰宅も遅くこの時間になってしまいました。
指示通りssl.confの中身の Listen 443 https の記述を残し、他を全てコメントアウトしてみました。
するとApacheの再起動の際に
" Cannot define multiple Listeners on the same IP:port "
のメッセージが帰ってきて再起動に失敗しました。
回答3件
0
先ほどAWS側の設定をもう一度よく確認してみたところ、過去に学習用で作ったロードバランサとターゲットグループが有効化されたままになっておりました。
ロードバランサとターゲットグループを削除してみたところ、当然ながらhttp接続ができなくなりました。
よく確認をせず、ウソを言ってしまい申し訳ありません。
よく設定を見直してからSSL化の手段を考えるなり、質問をするべきでした。
回答してくださった皆さま、お忙しい中時間を割いて頂き本当にありがとうございました。
te2ji様が仰るように、正式に対応していないAmazonLinuxではなくCentOSに乗り換え、まずはCertbotを使ったSSL化と自動更新処理に成功してからサービスの移行を考えたいと思います。
尚、Certbotについてもっと綿密に調べ、扱うのが難しいようであれば代替を考えます。今回私が開発しているサービスは自分用のものであるため、(既にマスト機能だけ実装しリリースして自己使用しながらボチボチと開発しているものです)今回の皆さまのアドバイスを踏まえ学習用として色々と転がしてみます。
長くなりましたが以上です。
投稿2019/02/25 14:42
総合スコア13
0
ベストアンサー
前提として、AmazonLinux で Certbot の利用はオウンリスクです
Certbot は AmazonLinux に正式に対応しておらず、ユーザが手探りで導入した経緯を記事として各所に上げています。
ただし、その方法は当然時間経過とともに更新する必要があり、そのスキルを持っている人だけが、リスクを承知の上で使用すべきものです。
現在までの追記状況からみて、インフラへの基礎知識が足りていません。
素直に CentOS 等の Certbot が対応している OS へ切り替えることをオススメします。
以下本件に関しての回答
一般論として、__応答時間が長すぎる旨のエラー__は Firewall 等のパケット破棄を行う機構が通信経路上にあることにより発生します。
通信 log を確認することで、アクセスがサーバまで到着しているか切り分けられるので。まずはそこからはじめ、途中機器の log を遡るのが一般的な切り分け方法です。
本件では、Firewall の log が確認できないと思うので、一旦すべてのパケット通過を許す設定とし、切り分けを行うと良いです。
投稿2019/02/24 14:36
退会済みユーザー
総合スコア0
確かにCentOS前提の情報の方が多かったり、pem生成の際にdebugオプションをつけなければならなかったりと、おかしいなとは感じていましたが、そういうことでしたか。そもそもAmazonLinuxが正式に対応してないんですね。
やはりAmazonとしては何としてもACMを使わせたいという根性の表れなのでしょうかね。
もしこのままAmazonLinuxで解決が図れなければCentOSでトライしてみたいと思います。
アドバイスありがとうござました！
あまり意識していないと思いますが、Certbot は3ヶ月に一度動かすことが必須です。その際 VerUP等の要因で依存関係の解消や代替方法の準備が自身でできなければ、簡単に死ねます。正式稼働前に検討したほうが良いです。
回答が遅くなってしまい申し訳ありません。
日中EC2インスタンスにログインできないもので、しかも特に今日は帰宅も遅くこの時間になってしまいました。
ありがとうございます。
無料という面が大変魅力なのですが、その分労苦も伴い、十分の知識も必要ということですね。
CentOSの件も含め検討させていただきます。
現象から考えて、本件は Certbot が要因では無い気がしますが、SSL 証明書は Web サービスのキモです。
安定したサポート OS を選択されることが安定したサービス提供につながるので、ぜひ慎重に選んでください。
根本的には私の知識不足です。
ありがとうございました。
0
EC2のセキュリティグループで、0.0.0.0からの443が許可されていないとかそういうことでは？
投稿2019/02/24 10:05
総合スコア5405
ありがとうございます。インバウンドでHTTPS443を許可済みです。
証明書の設定後、Apache再起動しました？
sudo service httpd restart しました。
ServerNameを自ホスト名に変えたと書かれていますが、certbot系コマンド実行時のドメイン等もちゃんと自分のドメインで実行してますよね？
証明書の作成時のコマンドは
certbot-auto certonly --webroot -w /var/www/html -d 自ドメイン名 --email 自メールアドレス -n --agree-tos --debug
にて実行しました。
ssl.confは、
#ServerName www.example.com:443
の部分を、
serverName test.com:443
に変更いたしました
あなたの回答
tips
プレビュー
