You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
SSLサーバー証明書は2年物を買うべきではない 今日の今日、今の今知ったことですが、たくさんの人に知られるべきだと思ってまとめます。サーバー証明書を購入する時、たいてい「1年」「2年」が選べると思います。更新作業は面倒なので、2年を選びたくなる方がいらっしゃると思いますが、この「2年」に大きな落とし穴があります。端的に言えば「1年」を購入するべきです。 その理由は、AppleのSafariにあります。 その理由 下記の記事を見てください。 ssl.sakura.ad.jp AppleがSafariブラウザにおいて、2020年9月よりSSL証明書の最大有効期間を398日に短縮すると発表しました。突然発表された本対応の経緯やその影響、私たちがこれから取るべき対策についてご紹介します。 Appleの発表は2020/3/3です。もう一か月も経過するのに結構誰も知らないのではないかと思います。最近の
この記事は さくらインターネット Advent Calendar 2019 4日目の記事です。 さくらインターネット研究所に所属している大久保です。お久しぶりです。 自分、研究は全くやってなくて、 ひたすら弊社のIaaSである「さくらのクラウド」の運用、開発、コーディング、お客様サポート、構築、ラックマウント、配線、障害対応、その他あらゆる全てをやっています。よろしくおねがいします 😇 せっかくAdvent Calendar空いてたので、最近作ってるサービスの紹介をさせていただこうと思います。 HTTPSの終端って大変だし面倒じゃないですか。 今回のネタは、お客様からご要望いただいて1年前から開発スタートしたサービスなんですね。当時、L4のロードバランサは提供していましたが、要件として、 インターネット向け大規模コンテンツ配信に使える高性能なもので、 DDoS対策ができて、 SSLの終端
2019年9月にリリース予定の「Google Chrome 77」で、ちょっとした……いや、かなり大きな変更が実施されます。それは、このコラムでも何度かフィッシング対策として紹介してきた「EV SSLサーバ証明書(以下、EV SSL)」の扱い。なんと、本物のサイトと偽サイトを区別する「URLバーの組織名表示」を無効にするというのです。 Upcoming Change to Chrome's Identity Indicators - Google グループ 「いったいなぜ安全の証明を無効化するのか?」と思われるかもしれません。その背景には、致し方のない事情がありました。 EV SSLで「何ができていた」のか EV SSLは、WebブラウザとWebサーバの通信を暗号化し、改ざんを防止するためのSSLサーバ証明書の一種として登場し、金融機関のWebサイトで導入が進みました。 SSLサーバ証明書
Google App EngineでマネージドSSLが全ユーザーに無料提供、HTTPSの導入が簡単に。証明書の更新もGoogleにおまかせで心配無用 - Publickey というニュースを目にしたのが先週の火曜日・9月19日。 www.publickey1.jp 「GAE 、どんどん便利で最高になっていってるなぁ......」と思わず遠い目をした僕は、おそらく古参GAEユーザーと言っても差し支えはなさそう。記録(このブログ)によると、2009年に GAE を触り始めていた。GAE をメインで扱う Web 起業にエンジニアとして働いていたこともある(2012 - 2013)。なので、昔の不便......いや、荒削りな頃の GAE はイヤというほど触り倒していた。 それもあって、今回の報はとても嬉しかったし、ただでさえ「またそろそろ GAE でおもしろいことやりたいなぁ...」と思っていたと
SNIとは元々SSL通信は1つのIPアドレスに対して、1つの証明書が前提になっていました。というのもSSLでは暗号化されているため、1つのIPアドレスに対して複数の証明書を持っていた場合、リクエストが来たときにどの証明書を使えばいいか判断できないからです。 しかしこれだとどう考えてもつらいことが分かります。昨今の流れとして常時SSL通信が当たり前の世界になりつつあります。すべてのドメインに対して全てのIPアドレスを用意するのは特にIPv4では現実的ではありません。 そもそもHTTPではVirtual Hostを使って、1つのIPアドレスで複数のドメインのサイトを扱うことがとても一般的です。 そこで有用なのがSNIです。SNIは最初の通信時に今から通信したいサーバーネームをサーバーに平文で渡すことで、通信したいSSL証明書を指定できます。 SNIを使うことでHTTPのVirtual Host
インフラストラクチャー部長の星 (@kani_b) です。 2017年1月5日をもって、クックパッド における全ページで HTTPS が使われるようになりました。 完全 HTTPS 化をするにあたり、その理由や具体的な進め方について紹介します。 以前 SRE Tech Talks #2 にて一部発表した内容も含みますので、ご興味のある方はあわせてスライドもご覧ください。 完全 HTTPS 化に踏み切った理由 以前のクックパッドは、ログインや登録情報の参照など、いわゆる個人情報や認証情報を扱う箇所のみに HTTPS が使われていました。 このように「必要な箇所にのみ HTTPS を使う」構成は、ある程度歴史のある Web サービスにおいてよく使われている構成です。 この状態から、完全 HTTPS 化に踏み切った理由を説明します。 サービスをよりセキュアにするため HTTPS の利用を考えるに
「常時SSL化」とは、Webサイトのすべてのページをhttpsにすることだ。しかし、Web制作を請け負ったとき、クライアントにきちんと説明して、常時SSL化を進言できるだろうか。そのためにはWeb制作者がまず、常時SSL化のメリットを理解しなければならない。 「SSLは、セキュリティ向上のために入力フォームに導入するもの」というのが一般的なイメージだが、今はそうではなく、全ページをSSLにするメリットがあるのだ。また、SSLサーバー証明書には複数の種類があり、どれでもいいというわけではない。常時SSL化のメリットとSSLサーバー証明書の選び方を紹介しよう。 常時SSL化は待ったなし大多数のホスティングサービスでは、9割のユーザーがhttpのみを使っている。つまり、これまでは大多数のユーザーにとってSSLは無関係なものと思われていた。しかし、これからはすべてのWeb担当者にとって、SSLが関
(初めに言い訳しておくと、証明書界隈については詳しくないです。某誤訳量産サイトが適当な記事を書いていたので、なにか書かねばと思って書いているという程度のまとめ記事です。間違いなどあればご指摘ください) 何が起こるのか Ryan Sleeviさん(Googleの人)がBlink-devのメーリングリストに投稿したこれにまとまっています:https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ 経緯についてはいったん飛ばして、どのようなアクションが提案されているのか見ます。 To restore confidence and security of our users, we propose the following steps: A reduction in the accepted
こんにちは。並河(@namikawa)です。 随分と寒くなってきたんで、そろそろ銀座界隈のオススメのラーメン屋の紹介でもしようと思・・・うわなにをするやめくぁwせdrftgyふじこlp; ・・・はい。今日は、ちょっと前にやった nginx + ngx_mruby でSSL証明書の動的読み込みを実現して、作業がとっても楽になったワンって話をしようと思います。 前提の話 弊社では、転職ナビという400近く存在する多くのドメインを持つサイトがあり、そのSSL処理をフロントの nginx で行なっています。 過去、そのバーチャルホストの設定がドメインごとにベタ書きされていた経緯があり、その辺の共通化・書き直しを少しずつやっていて、正規表現や環境変数を駆使することで、随分と設定は共通化できたりするのですが、どうにもならなかったのがSSL証明書の設定である、 ssl_certificate ssl_c
0. 短いまとめ 長い間、TLSのクライアント・サーバ間で使用するTLSバージョンを合意する際に、 不完全なサーバ実装によって version intolerance が発生することが問題になっていました。 TLS1.3ではこの version intolerance の影響を最小化するため、新しい version negotiation の仕組みを取り入れました。 Googleは、GREASE(Generate Random Extensions And Sustain Extensibility)という仕様をChromeに実装し、TLSサーバのバグで通らない拡張やフィールド値で問題が発生しないか試験を始めました。 パケットキャプチャが好きな人は、Chromeが 0x[0-f]a0x[0-f]a の見慣れない値をCipherSuiteやTLS拡張に使っているのを見つけても驚かないよう気を
今頃ではありますが、このブログをLet's Encryptの証明書を使って、https化してみました。 Let's Encryptとか、ACMEプロトコルってなに? Let's Encryptは、無料で証明書を発行してくれるCA(Certificate Authority:認証局)です。日本で有名なCAといえば、GlobalSignやシマンテック(旧ベリサイン)でしょうか。 CAが発行する証明書の種類として、以下の3つがあります。 DV (Domain Validation) ドメインの所有を確認して発行 OV (Organization Validation) 組織の実在の確認をして発行 EV (Extended Validation) より厳密な実在確認をして発行 Let's Encryptが発行できる証明書は、DVの証明書のみです。これは、証明書を発行したい人が、本当にそのドメインの
インフラエンジニアの方向けに、SSL/TLSとは何か、また証明書入手のポイント、HTTPS設定のポイントについて、最新の動向を踏まえて紹介します。また、最後の方で勉強会主催者のリクエストでおまけがあります(^^;Read less
現在SSL証明書の署名アルゴリズムがSHA–1からSHA–2へと変更になる過渡期となっています。今後はSSL証明書の新規取得や更新を行う際にはSHA–2の証明書を取得することになると思いますが、いつも通りの慣れた作業と思っていると、思わぬところでハマるかも知れません。 今回は実際に更新作業をした経験を踏まえて取得/更新作業の注意点について簡単にまとめてみました。 そもそもなぜSHA–2に移行する必要があるのか? 署名アルゴリズムがSHA–1の証明書は非推奨となり、ゆくゆくは廃止となる流れとなっています。基本的にSHA–1の証明書は2017年1月1日以降使えなくなると考えてよいでしょう。そして2016年12月31日までにSHA–2に移行する必要があります。 詳細はここで説明すると長くなりますので、次のようなSSL証明書の発行元のサイトの解説を参照してください。 SHA–1証明書の受付終了とS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く