Let's Encryptでこれまで長く使用されてきたIdentrust社発行のDST Root X3ルート証明書が、日本時間2021年9月30日23時1分15秒に期限切れになりました。十分時間を取って事前に移行計画や影響範囲、救える環境、救えない環境などアナウンスをしてきましたが、やはり、期限切れ以降、様々なサービスや製品で接続できないといった声が上がってきました。 特にOpenSSLに関しては、OpenSSL 1.0.2以前に影響があると9月13日に事前の注意喚起がOpenSSL公式ブログであったにもかかわらず、製品やサービスの奥底で使われていて気づかなかったのか、様々なOSや製品で古いものが組み込みで使われていたために影響が広かったように思います。 OpenSSLからの注意喚起の概要 2021年9月30日にLet's EncryptのDST Root X3ルート証明書の期限が切れるに
I'm unable to connect to a remote URL from my Amazon Elastic Compute Cloud (Amazon EC2) instance that has a Let's Encrypt certificate. Or, I'm receiving an error that my Let's Encrypt certificate expired. How do I fix this? Short description Some EC2 instances are experiencing expired certificate errors due to an expired Let's Encrypt cross-signed DST Root CA X3. Instances running the following op
これは、Let's Encryptを支えるこの二人のルートCAと OpenSSLの物語である。 DST Root CA X3 (2000-2021) ISRG Root X1 (2015-2035) 〜2021年1月〜 ISRG Root X1「いままで一緒にやってきたDST Root CA X3さんの寿命が間近・・・このままだと僕を信頼してくれていないベテランの（具体的にいうと2016年くらいまでの）古いクライアントたちは Let's Encryptさんを信用してくれなくなっちゃう・・・どうしよう」 DST Root CA X3「どれ、わしが死ぬ前に(有効期限が切れる前に)お前が信頼に値する旨を一筆書いて残せばいいじゃろう。サラサラ」 Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3 Validity Not Bef
The Morning After: Should you upgrade to an iPhone 16?
無料でウェブサーバー向けのSSL/TLS証明書を発行している認証局Let's Encryptが、「全世界に存在するAndroidデバイスの3分の1で、Let's Encryptの証明書が使えなくなる」と警告しました。 Standing on Our Own Two Feet - Let's Encrypt - Free SSL/TLS Certificates https://letsencrypt.org/2020/11/06/own-two-feet.html Let's Encrypt warns about a third of Android devices will from next year stumble over sites that use its certs • The Register https://www.theregister.com/2020/11/06/
Let's Encryptがルート証明書の切り替えに向け、古いバージョンのAndroidへの対策をサイトオーナーとユーザーに呼びかけている(Let's Encryptのブログ記事、 The Registerの記事)。 5年前にLet's Encryptが立ち上げられた際にはIdenTrustのクロス署名を得たルート証明書「DST Root X3」を使用することで、メジャーなソフトウェアプラットフォームすべてで信頼される証明書をすぐに発行することが可能だったという。しかし、DST Root X3は2021年9月1日に失効する(ただし、実際に証明書を見ると有効期限は日本時間2021/9/30 23:01:15となっている)。他のCAからクロス署名を得た証明書を使い続けることはリスクが高いため、Let's Encryptでは既に独自のルート証明書「ISRG Root X1」を発行している。このル
Update, July 10, 2023 See our new blog post for details on the September 2024 expiration of the newer ISRG Root X1 cross-sign from IdenTrust. Update, December 21, 2020 Thanks to community feedback and our wonderful partners at IdenTrust, we will be able to continue to offer service without interruption to people using older Android devices. We flagged the content of this blog post that is no longe
![Standing on Our Own Two Feet [Updated]](https://cdn-ak-scissors.b.st-hatena.com/image/square/f770c99675b3592736a34f17cb4f2101c311492e/height=288;version=1;width=512/https%3A%2F%2Fv17.ery.cc%3A443%2Fhttps%2Fletsencrypt.org%2Fimages%2FLetsEncrypt-SocialShare.png)
HTTPS（Hypertext Transfer Protocol Secure）は、HTTP通信をより安全（セキュア）に行うためのURIスキームである。「HTTPS」はプロトコルではなく、SSL/TLSプロトコルなどによって提供されるセキュアな接続の上でのHTTP通信をさす。 HTTP通信において認証や暗号化を行うために、ネットスケープコミュニケーションズによって開発された。当初、World Wide Web上での個人情報の送信や電子決済など、セキュリティが重要となる通信で使用されるようになった。その後、公衆無線LANの普及による中間者攻撃のリスクの増加[1]、PRISMによる大規模な盗聴、ネット検閲への対抗などを要因として、あらゆるHTTP通信をHTTPSに置き換える動きが活発になっている[2][3][4][5]。 HTTPSは、メッセージを平文のままで送受信する標準のHTTPと異なり
1 TLS 1.3 2 TLS TLS 1.2 TLS 1.3 TLS 1.3 3 TLS 4 TLS 5 TLS 1.2 TLS1.2 TLS_RSA_WITH_AES_128_CBC_SHA 6 TLS 7 TLS 1.1 8 TLS 1.2 9 TLS 1.2 10 Pervasive monitoring Forward secrecy RSA RSA Diffie Hellman DHE (Diffie Hellman Ephemeral) ECDHE (Elliptic Curve Diffie Hellman Ephemeral) 11 CRIME TLS HTTP 12 2 (MitM) (RFC5746) DoS RSA (d ) RSA (e = 2^2^4+1 = 65537) TCP/IP 13 14 RC4 RC 4 (RFC 7465) CBC CBC SSL
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 一体何の話なんです? SSL/TLSというのは、ご存じの通り、4種類の機能 Kx(鍵交換),Au(認証),Enc(暗号),Mac(ハッシュ/AEAD) を組み合わせたハイブリッド暗号技術です。 ここに、DHやECDHという鍵交換の方式が使われていることもご存じとは思いますが、ほとんどの場合それは、DHEやECDHEといったEphemeral(一時キー)版を指します。 しかし…。おそらく超マイナーながら、EphemeralでないDH,ECDH、通称static-DH,static-ECDHを使う方式もプロトコル上はあるのです。
以下順を追って説明します。 HelloRequest 相手にClientHelloを送信するよう促すメッセージです。送信しなくても構いません。 ClientHello ServerHello ClientHelloとServerHelloは、TLSのひとつめの肝です。後ほど説明します。 ServerCertificate サーバ証明書を送信します。中間CA証明書なども、ここで送ります。 ServerKeyExchange 鍵交換メッセージその１です。鍵交換はTLSのふたつめの肝で、これも後ほど説明します。 CertificateRequest クライアント証明書を送信するように促すメッセージです。クライアント証明書が必要な場合に送信します。何そのクライアント証明書って？と思った方は読み飛ばして構いません。 ServerHelloDone サーバからの送信終了を示すエンドマークです。 Cli
これは、http2 Advent Calendar 2016の13日目の記事です。 今日は、TLS 1.3 の第三番目のハンドシェイクである PSK (Pre Shared Key)について説明します。 みなさんは、Pre Shared Key という言葉から何をイメージしますか？ 多くの方は、通信路の暗号化に使う鍵をあらかじめ共有することだと思うのではないでしょうか？ TLS 1.2 での Pre Shared Key は、RFC4279で定められています。なんとなんと、共有している鍵の主目的は、通信路の暗号化ではなく、通信相手の認証です。ここを間違っていると、全然話が理解できないので、間違っていた人は認識を新たにして下さい。 TLS 1.3 での PSK は、セッションの再開(resumption)と統合されました。ややこしいのですが、TLS 1.3 で PSK という場合、次の2つの
TLS 1.3は現在策定中ですが、 前方秘匿性 の問題から RSAのみ を用いた鍵委共有が禁止になる見込みです。(詳細は後述します) HTTPSとは 次に、HTTPSです。 HTTPS - Wikipedia HTTPS（Hypertext Transfer Protocol Secure）は、HTTPによる通信を安全に（セキュアに）行うためのプロトコルおよびURIスキームである。 厳密に言えば、HTTPS自体はプロトコルではなく、SSL/TLSプロトコルによって提供される セキュアな接続の上でHTTP通信を行うこと をHTTPSと呼んでいる。 とのことです。 HTTPの説明を割愛するとすれば、「SSL/TLSでセキュアにHTTPをやる」というだけの説明で済んでしまいます。 最近では個人情報等の観点から全てのサイトをHTTPSにするような動きが見られますが、元々HTTPSが使われやすかった
前方秘匿性（forward secrecy）とは、以下のような性質を指します。 公開鍵暗号の秘密鍵のように、比較的長期に渡って使われる鍵が漏えいしたときでも、それまで通信していた暗号文が解読されないという性質 鍵が漏れることも想定せよ――クラウド時代における「楕円曲線暗号」の必然性 - @IT 鍵が攻撃者や諜報機関など第三者の知るところとなった場合でも、それまで通信していた暗号文が解読されないようにしないといけない、という考え方とともに、最近 HTTPS を利用するウェブサイトにおいても導入が求められるようになってきた概念です。 前方秘匿性を満たすウェブサイトの設定方法については、TLSの暗号化方式をECDH_RSAあるいはECDHE_RSAに設定すれば良い、と述べている文献が多いです。 ですが、ほとんどのウェブサーバにおいて、それは誤りです。 なぜか。 通信を暗号化する鍵（セッション鍵）
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TIS Engineer Advent Calendar 2015 4日目はExcelから予定を変更して証明書のお話です。 はじめに SSLサーバ証明書を用いたHTTPS通信は一般的になってきましたが、社員向けWebサービスなどにおいては自己署名証明書（通称：オレオレ証明書）が使われている例も少ないながら見受けられます。 これらのサーバの中には「暗号化できているから良いじゃないか」と、有料のSSL証明書を買ってもらえない例もあるかもしれません。 この記事ではこういった場合の説得に使える「オレオレ証明書は何故まずいのか」について、まずい例
証明機関は階層構造を取ることができます。 ツリー構造的に管理ができ、整理がしやすいためです。フォルダと同じ原理です。 3 階層や 4 階層のパターンが多いですが、2 階層のパターンは商用ではあまり見られません。 なぜでしょうか？ それは運用とセキュリティの観点からです。 実際にCAを構築する際の設計をしてみましょう。 階層構造の理由顧客への証明書の発行は速やかに実施されるべきです。そのため、発行手続きもある程度簡素化しオンラインで発行ができるものがよいでしょう。 しかしオンラインであるがゆえに、脆弱性を突かれ、証明書の利用が適正に行われない可能性もあります。その際にはその証明書を発行した CA を無効化する必要があります。 このとき、2 階層だった場合、「証明書を発行した上位CAの証明書＝ルート証明書を無効化」することになりますが、それを実行した場合、当然発行した全ての証明書が無効になりま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
