いわさです。 AWS Nitro Enclaves を使って Amazon EC2 インスタンスで実行されているウェブサーバーで、ACM 証明書を利用出来るようにする ACM for Nitro Enclaves という機能があります。 これまで Nginx のみサポートされていましたが、今回 Apache でも利用出来るようになりました。 AWS Nitro Enclaves を使ったことがなかったのですが、Apache で ACM を利用するくらいであればチャチャッと試せるかなと思いやってみました。 やってみる 前提となる EC2 での AWS Nitro Enclaves の有効化は以下を参考に構築しています。 ちなみに Nitro Enclaves 自体は Windows インスタンスでも利用出来ますが、ACM for Nitro Enclaves は Linux インスタンスでの
こんにちは！コンサル部のaayushです。 初めてテラフォームを使う場合は、このブログでコマンドを確認することをお勧めします。 AWSでTerraformに入門 議題 AWSプロバイダを設定されます amazon certificate managerに公開証明書を要求する。 route 53 hosted zoneの詳細を取得する ルートにレコードセットを作成する ACM 証明書の検証 awsプロバイダが適切な認証情報で構成されている provider "aws" { region = profile = } は、amazon 証明書マネージャにパブリック証明書を要求します。 resource "aws_acm_certificate" "acm_certificate" { domain_name = subject_alternative_names = [] validation_
「Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる」の続き。 色々動きがあって猶予もできて助かった形だけど、来年9月29日以降の対応をどうするか考えないといけない状況なのは当然変わっていません。先にまとめると以下。 何もせずとも来年の1月11日までは猶予が伸びた 証明書を発行する側の場合、各クライアントで --preferred-chain "DST Root CA X3" のようにオプション設定することで、来年の9/29まで先延ばしが可能 独自ドメインに対して自動でSSL証明書を発行してくれるサービスを利用している場合はサービスが声明を出していないか調べ、出してない場合は問い合わせると良いでしょう 前回以降の動き go-acme/legoに--preferred-chainオプションのpull requestを取り込んでもらいました デフォルトRoot証
こちらの記事で書いたサーバーの Let's Encrypt の証明書の更新ですが、cron で自動実行されているので安心と思い込んでいたら、あと２０日で有効期限が切れるよ、というメールが先日やってきました。 慌てて、サーバーを確認すると。syslogに更新失敗の記録が載っていました。 Dec 19 06:19:10 ip-xxx-xxx-xxx-xxx systemd[1]: Starting Certbot... Dec 19 06:19:15 ip-xxx-xxx-xxx-xxx certbot[8506]: Attempting to renew cert (サーバーのドメイン名) from /etc/letsencrypt/renewal/サーバーのドメイン名.conf produced an unexpected error: Failed authorization proce
Strong SSL Security on Apache2 Published: 14-06-2015 | Last update: 27-04-2019 | Author: Remy van Elst | Text only version of this article ❗ This post is over five years old. It may no longer be up to date. Opinions may have changed. This tutorial shows you how to set up strong SSL security on the Apache2 webserver. We do this by updating OpenSSL to the latest version to mitigate attacks like Hear
あるいは私たちがPKIについて説明し続けなければいけない理由 Web屋のなくならない仕事の一つに「SSL証明書とPKIについて説明する」というのがある。 世の中のサイトはだいたいhttps://というアドレスでつながるように出来ていて、httpsでつながるということは何らかのSSL/TLS証明書が必要だということだ。（さもなければchromeがユーザーに不吉な警告を発することになる） 証明書が必要になる度、同じ質問が繰り返される。「なんか全部値段が違うけど、どの証明書（ブランド）がいいの？」と。そして私たちは毎回困ってしまう。 エンドユーザーの立場で言えば、証明書が有効でありさえすれば、無料のLet's Encryptでも21万円するDigiCertグローバル・サーバID EVでも、Webサイトの利便性は何も変わらない。私たちWeb制作業者の立場でも、代理店契約でもしない限り、証明書そのも
はじめに chrome58 から、SSL証明書の CN (Common Name) から SAN (509v3 extensions: X509v3 Subject Alternative Name) を評価するようになったため、従来のオレオレ証明書の作り方が通用しなくなった。 openssl 1.1.1以上であれば、-addextオプションでSANをコマンドラインで指定できるようになったらしいので、なるべく現環境に影響を及ぼさず簡単にオレオレ証明書を作成できないか検証してみた。 前提条件 openssl 1.1.1 以上(-addextオプションを使う) ubuntu 18.04.2 (筆者の環境) openssl 1.1.1 をビルドする ubuntu 18.04では、openssl 1.1.0g で-addextオプションが使えないので、致し方なくビルドする。 なぜかRUNPATHの
Let's Encrypt 最新情報 ・ワイルドカード証明書と ACME v2 へ対応が完了しました（2018年03月15日 更新） ※技術的な詳細については ACME v2 とワイルドカード証明書の技術情報 をご覧ください。 ※ワイルドカード証明書の取得には、ACME v2 プロトコルに対応したクライアントと DNS による認証が必要です。証明書の取得・更新の際に、DNS の「TXT レコード」にワンタイムトークンを登録する必要があります。 ※サブジェクトの代替名（SAN : Subject Alternative Name）を使用した 複数のドメイン名・サブドメイン名に対して有効な証明書 も引き続き取得可能です。 Let's Encrypt について Let's Encrypt は、認証局（CA）として「SSL/TLSサーバ証明書」を無料で発行するとともに、証明書の発行・インストール・
2/20 開発環境作成においてssl証明書が必要だったが、wikiに書かれていた方法が開発環境に本番の証明書を持ってきて使う、という危険極まりないものだったので自己証明書を使って代用することになった。"httpでいってしまえ” という案もあったが、開発時は楽でいいけど、HTTPSにしたら動かない問題とかありがちだったりするのでちゃんとhttpsで開発できる環境を整えた方がいいとのことから。 そのssl証明書の発行方法だが、幾つか手段があるみたいでopensslを使って発行する方法とssl-certで作成したsnekeoilを使う方法が見つかったので、それらの優位性などを比較してみる。 openssl コマンドはこちら $ openssl genrsa 2048 > server.key $ openssl req -new -key server.key > server.csr $ op
背景 ここ数年で暗号化されていないHTTPは減り、常時TLSが当たり前になってきました。 公開用のページはもちろん、開発段階のページでもTLSは必須です。 普段はAWS上で開発をしているので、AWS Certificate Managerを利用することが多いのですが、 ちょっとしたお遊びにELBやCloudFormationを使うのはオーバーキルです。 そこで EC2 にもインストールできて、無料で使える Let’s Encrypt を使って証明書を発行することを考えました。 Let’s Encrypt で発行できる証明書は期間が90日と短く、60日ごとの自動更新が推奨されています。 証明局とAPIとAPIクライアントの実装例は提供するから、あとの自動化部分は自前で頑張ってねという感じなので、自動化部分を頑張らないといけません。 今回は実行環境として AWS Labda、ACME(Auto
12.04.11 / こあくまベリサイン訪問記 / Author: aico ではフィッシングにひっかからないようにするにはどうしたらよいのでしょう？ …とその前に前回のおさらい！ 企業の実在性を認証しているOV、そのOVよりさらに厳格な審査を行うEV SSLを発行されているページには高い信頼性があります。 (DVは暗号化を行ってくれますが企業の実在性は認証しないのでかなり低い信頼度です。グループ内やユーザーの少ないサイト向け。) SSLが入っているからといって安心してはいけません。 フィッシングに引っかからないためにはそのページについているSSLサーバ証明書が どんなSSLなのかを確認しましょう！ ということで今回はドメイン名認証型(DV)、企業認証型(OV)、そしてEV SSLの３種類のSSLサーバ証明書を確認してみましょう！ 今回はSafari、IE、Firefox、Google C
Apache 2.2.12以降、SNI（Server Name Indication）に対応しているらしく、ひとつのWebサーバーで複数ドメインの SSL証明書を使い分けることが可能になっているようです。 注目の集まるSNI（Server Name Indication）導入の必要性とは SNIでサーバ上に複数のSSLサイトを設定する | shinobe.org 全然意識していませんでした。 ということで、Apacheで複数のドメインでHTTPSなサイトを扱うには、以下の方法があるようです。 SNIを使う SAN拡張を使用した複数のホスト名に対応した証明書を使う これを適用してみます。なお、このエントリで使用しているSSL証明書は、すべて自己署名証明書です。 いずれの場合も、VirtualHostとServerNameの組み合わせ（NamedVirtualHost）で実現することになります
ChromeおよびブラウザコミュニティによるSymantecの証明書の順次警告、無効化問題だそうで、該当する証明書(うちで該当するのはもちろん格安なDV RapidSSL)持ってるからさっさと更新せい、というメールが証明書屋さんから何度も来ました。TLSAの更新が必要なのでそれなりにめんどかったですが、本サイトも含めて2サイトの証明書を更新いたしました。皆さんどうしているのか見ようとしたところ… いきなり見つかった記事 デジタル証明書ニュース:ChromeがSymantec発行証明書についての行動計画を発表 によれば Chrome70では、現在のシマンテックのインフラストラクチャから発行されたTLS証明書を信頼しません。 Chrome70は、2018年9月13日にベータ版、2018年10月23日に安定版を予定しています。 となっており、あんぐりとなってしまいました。原文を当たると確かに「S
はじめまして、Kaizen Platform SRE の @tkuchiki です。 本記事では AWS 上で利用している SSL/TLS 証明書(以下、証明書)を一括管理するツールを作成したので紹介いたします。 TL;DR aws-cert-utils を作成して AWS 上で利用している証明書を一括管理できるようにした 証明書の一覧表示、証明書を利用している ALB / CLB / CloudFront の一覧表示も可能 aws-cert-utilsを利用し証明書を管理することで、更新・確認作業においてミスが発生しにくくなった 背景 今までの問題点 CLB / ALB / CloudFront の証明書更新時に aws cli iam でアップロードした証明書を Management Console から一つひとつ切り替えていた 更新対象が多いので作業に時間がかかる 確認作業も大変 そ
Googleは昨年、Symantecやその傘下の認証局が不適切にSSL証明書を発行していたとして、同社の発行した証明書すべてを無効化する計画を明らかにしていた（過去記事）。このスケジュールではChrome 66でSymantecによって発行された証明書が無効化されることになっているが、これに先駆けて、開発者やアーリーアダプタに向けたGoogle Chromeの実験的ビルド「Google Chrome Canary」でSymantecやその傘下であるRapidSSLなどが発行した証明書の無効化が行われたようだ。 bonkure曰く、 Googleさんは、Chromeにおける「Symantec発行の証明書の無効化」を宣言しておりましたが、最近リリースされましたChromeのCanaryのバージョンがめでたく66となり、Googleさんは本気だったことが証明されました。スラドも見事にその毒牙にか
> Q1 原理としては同じでしょうね。 中間者攻撃の要領でSSL通信に割り込むことで SSL通信の内容をチェックすることが可能になります。 > Q2 > 何故、オリジナル原本の「サーバ証明書」が使用出来ないのですか？ まずSSL通信の内容を見ることは通常はできません。 そのため内容を見るためには中間者攻撃のような方法が必要になります。 中間者攻撃を簡単に説明すると、通常は [サーバー:証明書Aで暗号化]→[ブラウザ:証明書Aで復号] のような暗号化通信をしているところに割り込んで、 [サーバー:証明書Aで暗号化]→[ESET:証明書Aで復号して、証明書Bで暗号化]→[ブラウザ:証明書Bで復号] のようにいったん暗号化を解除してからもう一度暗号化する手法のことです。 この再暗号化の時に、「サーバ証明書(A)」を使うことはできません。 それができるのは本来のサーバーだけだからです。 これが、「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
