開発・運用の現場から、IIJのエンジニアが技術的な情報や取り組みについて執筆する公式ブログを運営しています。 こんにちは。IIJ Engineers Blog編集部です。 IIJの社内掲示板では、エンジニアのちょっとした技術ネタが好評となって多くのコメントが付いたり、お役立ち情報が掲載されています。 今回は、すでにお気づきの方もいるかもしれませんが、いつの間にか HTTPS 証明書の Common Name の検証が禁止 になっていた件について紹介します。 HTTPS 証明書の検証手続きは、RFC2818 で「Subject Alternative Name があればそれで、なければ Common Name を見よ」となっていました。 If a subjectAltName extension of type dNSName is present, that MUST be used as
これは、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
『プロフェッショナルSSL/TLS』特別版PDF（原著改訂第2版のTLS 1.3解説章を収録）のお知らせ 2021年2月08日 お待たせしました。事実上のTLS 1.3対応版となる『プロフェッショナルSSL/TLS 特別版PDF』の提供を、ラムダノート直販サイト登録ユーザの方向けに開始しました。 今回は、「原著改訂第2版に収録されるTLS 1.3を解説した新章」を付録として追加した特別版PDFを新たに「マイ本棚」からダウンロードしていただけます。 対象：ラムダノートの直販サイトにてユーザ登録済みで、『プロフェッショナルSSL/TLS』を購入された方 取得先：購入時のユーザアカウントでラムダノートの直販サイトにログインしていただくと、「マイ本棚」の「購入済みの電子書籍」に下記のように特別版PDFが表示されます もちろん、これから直販サイトで『プロフェッショナルSSL/TLS』を購入いただき、
はじめに 皆さんは ZeroSSL を知っていますか？個人でウェブサイトを運営している皆さんであれば、多くの方は Let's Encrypt を利用されていると思います。 https://letsencrypt.org/ja/ もちろん僕も使っています。僕の様なエンジニアの方であれば SSL の仕組みもおおよそ理解もしているし、コマンドラインの実行方法も知っておられるのでウェブサイトの SSL 証明書を取得する事もそれほど難しい事ではないでしょう。 しかしそれほど詳しくない方が certbot の様なコマンドを使って SSL 証明書を発行するのは割と難しい事です。そこでご紹介したいのが ZeroSSL です。 https://zerossl.com/ ZeroSSL とは ZeroSSL もまだあまり名前が知られていないせいか、Google 検索で「ZeroSSL」を検索すると「ZeroS
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では出来
概要 今回はテストのため、開発環境に自己認証局を構築し、自己認証局による自己署名証明書を発行しました。手順をまとめます。 自己署名証明書は、自分を認証局（CA）として立て、自分で自分の正当性を証明するいわゆる「オレオレ証明書」となります。自己署名証明書の利用で、通信は暗号化されますが、組織の実在性確認はできません。あくまでもテスト向けであり、サービス向けには信頼できる第三者認証局が発行した証明書を利用します。 AWS では、ACM（AWS Certificate Manager）で証明書を発行する構成が多いですが、Load Balancer ではSSL終端せず、バックエンドのEC2やコンテナでSSL終端もあり得ます。このような構成では、ACMではなく、外部認証局 or 自己認証局で発行した証明書をバックエンド側で配置することもあります。 自己認証局の作り方 先ず、自己認証局用の秘密鍵と証明
追記: その後の動きについて書きました → Let's Encryptの証明書切替周りその後 このサイトはLet's Encryptで証明書発行しているのでタイトルの件が気になったのだが、どうもあまり話題になっていない。恥ずかしながらSSL周り詳しいわけじゃないので、誤っているかも知れない。識者の意見を求む。 Let's Encryptが使われているサイトがAndroid7.1以前のバージョンで今年の9月29日以降見られなくなる可能性がある 延命策は用意されそうだが、それも来年の9月29日まで Let's Encryptのルート証明書切り替え計画に起因している Let's Encryptのルート証明書の変更 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしている。現在は、IdenTrustのルート証明書(DST
御社の常時SSL (TLS) への対応はお済みですか。というわけで本稿ではRFCで標準化されているプロトコルのうち、SSL (TLS) に対応済みのものを列挙していきたいと思います。 用語の定義 本稿では、以下の用語を使います。 Implicit TLS （暗黙のTLS） TCPコネクション開始と同時にTLSセッションがいきなり始まる方式です。httpsなどはこれです。平文通信用と暗号通信用に別々のポートを割り当てる必要がありますが、そのぶん低レイテンシーを実現できます。 Explicit TLS （明示的TLS） TCPコネクションが確立すると、最初は平文で通信が始まり、そこからTLSへ移行する方式です。STARTTLSとか、そんな感じのコマンドが用意されているのがこれです。特徴としては、平文通信と暗号通信を同じポートでカバーできます。平文で始まって暗号へ切り替わるという手順を踏む分、レ
#!/usr/bin/env bash # https://superuser.com/questions/109213/how-do-i-list-the-ssl-tls-cipher-suites-a-particular-website-offers # OpenSSL requires the port number. SERVER=192.168.33.10:443 DELAY=0 ciphers=$(openssl-1.1.0f ciphers 'ALL:eNULL' | sed -e 's/:/ /g') echo Obtaining cipher list from $(openssl version). for cipher in ${ciphers[@]} do echo -n Testing $cipher... result=$(echo -n | openssl-
はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書（１）』と『#5 X.509 証明書（２）』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名（前提知識） この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと
SSLサーバー証明書は2年物を買うべきではない 今日の今日、今の今知ったことですが、たくさんの人に知られるべきだと思ってまとめます。サーバー証明書を購入する時、たいてい「１年」「２年」が選べると思います。更新作業は面倒なので、２年を選びたくなる方がいらっしゃると思いますが、この「２年」に大きな落とし穴があります。端的に言えば「１年」を購入するべきです。 その理由は、AppleのSafariにあります。 その理由 下記の記事を見てください。 ssl.sakura.ad.jp AppleがSafariブラウザにおいて、2020年9月よりSSL証明書の最大有効期間を398日に短縮すると発表しました。突然発表された本対応の経緯やその影響、私たちがこれから取るべき対策についてご紹介します。 Appleの発表は2020/3/3です。もう一か月も経過するのに結構誰も知らないのではないかと思います。最近の
こんにちわ、TenForward こと加藤です。 この記事は ファーストサーバ Advent Calendar 2016 7 日目の記事となります。 レンタルサーバに限らず、各種サーバでセキュリティのために SSL/TLS を使用する場合は、安全に暗号通信が行われる必要があるので、安全な設定をする必要があります。 SSL/TLS には色々なバージョンがありますが、プロトコル自体に含まれる脆弱性のため、最近では SSLv2 や SSLv3 は無効にする必要があります。 しかし、脆弱なバージョンを使わないだけでは、SSL/TLS を使った通信が安全になるわけではありません。どのような技術を使って暗号通信を行うのかが重要です。 SSL/TLS 関連の設定は、暗号関連技術の危殆化などにより、定期的に見直す必要があります。弊社においてもこれまで何度か見直しを行っています。最近も「暗号スイート」を中心
使用すべきでない暗号化スイートを調べました。 暗号化スイートを確認してみて、使用すべきでないものが有効になっていたら設定の変更をおすすめします。 暗号化スイートを確認する 以下のコマンドで任意の暗号化スイートで使用される暗号化方式の一覧が見れます。 openssl ciphers -V 'CipherSuites_NAME' 実行例 # openssl ciphers -V 'ALL' 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x28 - ECDHE-RSA-AES
平常時にどんなパケットがやりとりされるかを知っておくと、トラブルが起こったときに何がおかしいのかを発見しやすくなる。そこで、Wiresharkの使い方に慣れながら、通常のパソコンでやりとりされるパケットを見ていこう。 インターネットの通信に使うHTTPS通信を取り上げる。HTTPS通信は、TLSによって暗号化されるが、データ通信を始める前の通信はパケットキャプチャーで解析できる。 3つの画面領域で情報を表示 HTTPS通信は、主にWebサーバーとの通信に使う。HTTPSは、HTTP通信をTLSという技術を使って、安全にやりとりするようにしたプロトコル。現在のWeb通信では、従来のHTTPに代わって主流になっている。 まず、HTTPSは仕様上どのようなやりとりをすることになっているかをおさらいしておく。 TLSは、使用するバージョンによってやりとりする流れ（シーケンス）に違いがある。現在、一
透過型プロキシとは透過型プロキシ (Transparent Proxy) とは、ブラウザにプロキシの設定をしていない状態でもプロキシサーバ経由による Web アクセスをさせる方法です。透過プロキシとも言います。 フリーウェアの Squid でも実現できますし、商用プロキシの BlueCoat や i-filter 等でも機能を持っています。 仕組みとしては、インターネットへの通信経路上に透過プロキシの設定をしたプロキシサーバを配置するのみです。 以下に、通常のプロキシと透過型プロキシの通信の比較を示します。 「インターネットへの通信経路上」といっても、デフォルトルートの経路上に配置してしまうと、smtp や pop, imap 等の他のプロトコルがインターネット通信できなくなってしまいます (http 等の一部のプロトコルのみ、透過型プロキシサーバで取り次がれますので)。 なので、透過型プ
以前から気になっていた「次世代 Web カンファレンス 2019」を、ようやく聴きに行くことができました。 たくさんのトークがありましたが、ここではHTTPS (hashtag: #nwc_https)をメモしておきます。なお、このセッションが間違いなく一番アツく、一番面白かったです! 当日の動画 https://www.youtube.com/watch?v=_8dCa8wj8QY togetter https://togetter.com/li/1268794 以下、当日参加した、もしくは動画を見たという前提でのメモなので、見てない人はぜひ見ましょう。 PKI 「低レイヤから行きましょう」ということで、はじめはPKI絡み。Symantecのdistrustと、日本のGPKIの話でした。 トーク中に何度か出てきましたが、認証局(厳密にはCAとRAを分けて書くべきですが、どうせみんな一緒な
以下順を追って説明します。 HelloRequest 相手にClientHelloを送信するよう促すメッセージです。送信しなくても構いません。 ClientHello ServerHello ClientHelloとServerHelloは、TLSのひとつめの肝です。後ほど説明します。 ServerCertificate サーバ証明書を送信します。中間CA証明書なども、ここで送ります。 ServerKeyExchange 鍵交換メッセージその１です。鍵交換はTLSのふたつめの肝で、これも後ほど説明します。 CertificateRequest クライアント証明書を送信するように促すメッセージです。クライアント証明書が必要な場合に送信します。何そのクライアント証明書って？と思った方は読み飛ばして構いません。 ServerHelloDone サーバからの送信終了を示すエンドマークです。 Cli
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
