ZeroSSL ならIPアドレスのサーバ証明書が取得できる - ASnoKaze blog
IPアドレスのサーバ証明書が欲しい場合があります。そうすれば、ドメインを取得せずともサーバとHTTPS通信ができるようになります。 その他にも例えばDNS over HTTPSではIPアドレスでアクセス出来るように、有効な証明書がセットされていたりします。 https://1.1.1.1 https://8.8.8.8 しかし、Let's Encryptでは、IPアドレスのサーバ証明書は取得できません ~$ sudo certbot certonly --nginx -d 160.16.124.39 Requested name 160.16.124.39 is an IP address. The Let's Encrypt certificateauthority will not issue certificates for a bare IP address.ZeroSSLでは出来
NginxのHTTP/3を試す (2020年6月) - ASnoKaze blog
NginxのHTTP/3対応版が公開されました。実際に動かしていきます。(なお、現在サポートしているのはHTTP/3 draft 27版です) www.nginx.com 基本的には 「README」 の通りやるだけです。 HTTP/3の詳細についてはガッツリ解説を書いたので、ご参考にしていただければ asnokaze.hatenablog.com 準備 (ちなみに環境は Ubuntu18.04 Bionicです) パッケージのインストールと、依存するboringsslのビルドをしておきます https://boringssl.googlesource.com/boringssl/+/HEAD/BUILDING.md $ sudo apt install mercurial ninja-build $ git clone https://boringssl.googlesource.com
2020-05-02 Dynamic Rendering を試してみる - odan-worklog
#dynamic-rendering Dynamic Rendering とは https://developers.google.com/search/docs/guides/dynamic-rendering?hl=ja UserAgent がクローラーな場合に html をレンダリングしてからレスポンスを返すことにより、JS を実行しないクローラーに対して正しいコンテンツを読み込ませる技術 SSR との比較 Dynamic Rendering はヘッドレスブラウザなどを用いてレンダリングすることが多い 最終的には SSR にするのが良いらしい https://www.suzukikenichi.com/blog/dynamic-rendering-is-a-temporary-workaround/ SSR 実装難しくない？ 選択肢 prerender.io https://prer
Nginx+NLBでHTTP/3環境をAWSに作ってみた | Developers.IO
つい最近(2019/10)CloudFlareがQUIC対応のQuicheをNginxで利用出来るパッチを公開したりHTTP-over-QUICがHTTP/3に改名したりで、HTTP/3がかなりアツくなってきています。 このビッグウェーブに乗るべく、CloudFlareのQuicheパッチを適用したNginxを用意して、NLB越しでQUICを喋ってみたいと思います。 もこ@札幌オフィスです。 つい最近、(2019/10)CloudFlareがQUIC対応のQuicheをNginxで利用出来るパッチを公開したりHTTP-over-QUICがHTTP/3に改名したりで、HTTP/3がかなりアツくなってきています。 このビッグウェーブに乗るべく、CloudFlareのQuicheパッチを適用したNginxを用意して、NLB越しでHTTP/3を喋ってみたいと思います。 NLBを利用してHTTP/3
Route 53 + CloudFront + S3でZoneApexへのHTTP/HTTPSリクエストをリダイレクトする | DevelopersIO
こんにちは、佐伯です。 静的サイトを既存のApache or NginxからCloudFront + S3に移行を行う場合、既存サイトがZoneApex(例:example.com)へのリクエストをwww.example.comにリダイレクトしており、引継ぎたいケースがあります。 HTTPのみであれば以下エントリのようにS3の静的ウェブサイトホスティングのリダイレクトルールを使用することで、リダイレクトすることができます。 Route 53でZone ApexドメインをS3を使ってリダイレクトする 今回はHTTPSもサポートした構成となります。 やってみた 構成図 リダイレクト用のCloudFrontとS3バケットを作成して、静的サイトのFQDNへリダイレクトします。なお、今回の手順ではリダイレクト先は既に存在している前提となっており、リダイレクト先のリソース作成手順などは省いています。
Nginxを利用してCloudFront対応のWordPressを環境を最適化してみた | DevelopersIO
はじめに AWSチームのすずきです。 先日紹介させて頂いた、CloudFront、ELB、EC2を利用したWordPress環境。 ELBやEC2のパブリックIPアドレスを知り得た第三者により WordPressの実行環境が直接攻撃される事があった場合、DDoSなどの被害を受けやすいリスクがありました。 今回、この対策としてNginxをリバースプロキシとして導入し、 CloudFrontを経由と、正しい認証情報を持つ管理者のリクエストのみWordPress環境に中継、 他の不正なアクセスは遮断する方法を紹介させていただきます。 構成図 環境 OSは、Amazon Linux2のAMI (amzn2-ami-hvm-2.0.20190508-x86_64-gp2) を利用しました。 CloudFront、ELB、EC2の各リソースは、以下の環境を一部変更して利用します。 CloudFront
NginxでSSLの評価をA+にする手順
昨日 HTTPS 化した シャンプー評価サイト のSSL評価をA+にしました。 参考にしたのは下の記事 HTTPS on Nginx: From Zero to A+ (Part 2) - Configuration, Ciphersuites, and Performance - Julian Simioni この記事のNginx証明書設定をPOSTDさんが翻訳しているので、近いうちに詳しい訳は日本語で読めるかも。ここでは適当にかいつまんだ手順を書いておく。一部時間のかかるコマンドもあるけど、基本的に決まった設定書くだけなので時間はかかりません。（もちろんどういう意味なのか知っておくに越したことはない） SSLの評価計測について SSLサーバーのテストはQualys SSL Reportで確認します。 Nginxデフォルトの設定で計測したらCだった。 SSLv3 を無効にする SSLv3
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
SPDY対応するために考えてること - ASnoKaze blog
概要 若者の間でも、SPDYに対応するためのノウハウが共有されていないことは有名である。 そこで、中規模サイトでSSL化、SPDY対応という観点で個人的に考えていることを書き出してみる。 HTTP2は暗号化の議論や、アップグレード、ヘッダ圧縮など細部が違うため別途考慮する必要があるが、今回の話も概ね適応できるだろう。 今回主に考える構成としては、以下の様に前段にリバースプロキシを置く構成である。 幾つかSPDY対応しているソフトウェアがあるが、現状NGINXが無難だと考えているので、NGINX前提で話を進める。 （SPDY対応のロードバランサ製品の導入も出来るだろうが、今回は考慮しない） SSL化とSPDY対応 SDPYではSSL化が必須である。これは、SSLハンドシェイク時にHTTPSとSPDYのどちらで通信を行うかネゴシエーションしているためである（TLS上でのプロトコルネゴシエーショ
Groupon: 単一のRailsアプリから複数のNode.jsアプリへの移行 - ワザノバ | wazanova.jp
https://engineering.groupon.com/2013/misc/i-tier-dismantling-the-monoliths/ Grouponのビジネス自体はかつての盛り上がりはないですが、シンプルなRailsアプリが、事業の成長 & グローバル化に従って、アーキテクチャを変えていった過程をエンジニアブログで紹介してるので、参考になればと。 1) まとめ Grouponは、Railsのシングルコードベースを独立した20個のNode.jsアプリにアーキテクチャを変更した。 ページの読み込み時間が概ね50%改善。これはテクノロジーの効果とコードの書き直しでwebページが軽くなったのとの相乗効果。 同じトラッフィクに対してハードウェアが削減できた。 チーム間の依存関係が少なくなったので、新機能リリースのペースが早くなった 同じ機能を複数の国にそれぞれ導入するような冗長さが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Making HTTPS Fast(er) - nginx.conf