Let’s Encryptの短期証明書はかなり厳しいのでARI対応クライアントを使った方がよい
Let’s Encryptの短期証明書は、90日証明書の延長くらいの感覚で入るとかなり厳しいです。 サブドメインを含む複数の証明書を短い間隔で発行・更新する構成では、証明書発行まわりのレート制限に引っかかりやすくなります。短期証明書では更新回数が増えるので、その影響がかなり表面化しやすくなります。 まずステージング環境で試した方がよい 開発やテストでは、本番ではなくステージング環境を使った方がよいです。本番と同じ種類の挙動をかなり緩い制限で試せるので、証明書の切り方や更新方法を確認する段階では先にこちらを使う方が安全です。 環境 ACME directory URL 短期証明書はレート制限に当たりやすい 短期証明書は有効期限が160時間しかなく、Let’s Encryptは3日ごとの更新を勧めています。90日証明書より更新回数が大きく増えるので、レート制限に当たりやすくなります。 特に厳し
badssl.com
badssl.com 🎛Dashboard Dashboard 🎫Certificate expired wrong.host self-signed untrusted-root revoked pinning-test no-common-name no-subject incomplete-chain sha256 sha384 sha512 1000-sans 10000-sans ecc256 ecc384 rsa2048 rsa4096 rsa8192 extended-validation 🎟Client Certificate Certificate Downloads client client-cert-missing 🖼Mixed Content mixed-script very mixed mixed-favicon mixed-form ✏️HTTP h
HTTPS 証明書クロニクル | blog.jxck.io
Intro Web サービスをデプロイする際に、CA から証明書を取得し HTTPS で暗号化するのが一般的となった。 かつては "SSL 証明書" として、メールでやり取りし有料で購入するのが常識だったが、自動/無料で取得することが増えた。かつては 5~10 年あった有効期限もどんどん短くなり、今では 6 日の証明書も発行されている。 このように、証明書を取り巻く変遷は目覚ましく、それは Web を取り巻く環境の劇的な変化を色濃く反映した結果と言える。 http:// が https:// になった裏で何が起こり、これからどうなっていくのか。まとめていく。 (極力ソースを付記するが、既に消えて WebArchive にも残っていないものも多く、筆者の記憶に頼る情報も多い。) 黎明期 (90 年代後半~2010 年頃) 90 年代の終わり頃、当時は TLS の前身にあたる SSL のデプロ
ドメインに発行されたすべての証明書を検索できる「CertRadar」
公開鍵証明書は信頼された第三者機関である認証局(CA)から発行され、ウェブサイトの正当性を証明するために使用されています。しかし悪意のある攻撃者が正規のドメイン名に対して不正に証明書を取得することでフィッシングサイトや中間者攻撃に利用するケースも存在し、過去の事例では2011年デジノター事件などが知られています。こうしたリスクを軽減するためにドメインに発行されたすべての証明書を検索できるツールが必要となります。CertRadarはドメインに対して発行されたすべての証明書を手軽に検索することができ、さらにドメインのリスクを洗い出すことのできるオンラインツールです。 SSL/TLS Security Tools - CertRadar https://certradar.net/ ◆CertRadarについて CertRadarはソーシャルニュースサイトのHacker Newsで公開されました
Let's Encrypt、IPアドレス証明書が一般提供開始 - RFC 8738準拠の6日間証明書 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 2026年1月15日、Let's EncryptがIPアドレス証明書の一般提供を開始したっていうリリースを見たので、どのRFCに準拠しているのか？などを整理したので、せっかくだからQiitaを書いたのです。今まではドメイン名でしか発行できなかったTLS証明書が、IPアドレス（IPv4/IPv6）に対しても自動発行可能になるのって結構応用が効きますよね。 この機能は、RFC 8738で標準化されたACMEプロトコルの拡張仕様に準拠しており、IoTデバイス、内部API、DNS非依存環境などでの利用が想定されています。 それでは解説
GitHub Copilotコーディングエージェントでコンテナイメージをビルドするときに「self-signed certificate in certificate chain」が出て失敗した - Qiita
GitHub Copilotコーディングエージェントでコンテナイメージをビルドするときに「self-signed certificate in certificate chain」が出て失敗したDocker証明書container自己署名証明書GitHubCopilot 結論 問題 GitHub Copilotコーディングエージェントでコンテナイメージをビルドするときに「self-signed certificate in certificate chain」というエラーが出て通信に失敗しました。 原因 GitHub Copilotコーディングエージェントは、コードなどの機密情報をインターネット上に漏洩させることのないよう、ファイアウォールによって通信を制限しています。GitHub CopilotコーディングエージェントはGitHub ActionsのRunner上で動作しており、自己署名
Node-v0.10.34がはまったクロスルート証明書とOpenSSLの落とし穴 - ぼちぼち日記
既に12月22日ですが、このエントリーは、Node.js Advent Calendar 2014の13日目のエントリーです。 いや私が書くの遅れたわけじゃないですけど…(言い訳)、ちょうどタイムリーなネタがあるので、先日リリースされたNode-v0.10.34で発生した（現在も継続している）問題について携わった経緯を自分の目線で書いてみます。 追記：日本時間の12/24にNode-v0.10.35がリリースされました。 http://blog.nodejs.org/2014/12/23/node-v0-10-35-stable/ 本記事の不具合も修正されています。 1. Node-v0.10.34リリース直後にissue発生 先週12/17にNode v0.10.34 (Stable)がリリースされました。10月中旬にPOODLE騒ぎでOpenSSLに対応した Node-v0.10.33
Node.js のルート証明書 - @kyanny's blog
Node.js は独自のルート証明書ストアを持っており OS の証明書ストアを参照しないので自己署名証明書を使うサーバーとの通信でトラブルになることがある、などと知られているが、「Node.js は独自のルート証明書ストアを持っており OS の証明書ストアを参照しない」の根拠はどこに書いてあるのか。 おそらく Maintaining the root certificates が、この件に関する決定的な文書（source of truth）とみていいだろう。 Node.js contains a compiled-in set of root certificates used as trust anchors for TLS certificate validation. The certificates come from Mozilla, specifically NSS's cer
Unable to Connect to SSL Services Due to 'PKIX Path Building Failed' Error | Atlassian knowledge base | Atlassian Support
Unable to Connect to SSL Services Due to 'PKIX Path Building Failed' Error Platform Notice: Data Center Only - This article only applies to Atlassian apps on the Data Center platform. Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Sup
SSL/TLSライブラリの正しい使い方（もしくは、コモンネームの検証について）
スマホアプリの市場拡大に伴い、直接SSL/TLSライブラリを使用するプログラムを書く機会も増えてきている今日この頃かと思います。 SSL/TLSライブラリを使う際には、接続確立時にサーバの認証を正しく行う必要があります。具体的には、クライアントプログラムで以下の２種類の検証を行うことになります。 SSL/TLSライブラリがサーバの証明書の検証に成功したこと サーバの証明書に含まれるコモンネーム注1が接続しようとしたサーバと同一であること 前者については、OpenSSLの場合はSSL_CTX_set_verifyの引数にSSL_VERIFY_PEERを指定するなどして、ライブラリ側で処理を行わせることが可能です（証明書の検証に失敗した場合はSSL_connectがエラーを返します）。 一方、後者についてはSSL/TLSライブラリによって差があり、検証機能を有効にするために特別な呼出が必要だっ
『プロフェッショナルSSL/TLS』（現『プロフェッショナルTLS&PKI 改題第2版』）の読み方（私論） - golden-luckyの日記
［2024/04/29 追記］ 本書は2023年12月に改訂改題され、『プロフェッショナルTLS&PKI 改題第2版』となっています。改訂により次のようなブラッシュアップが施されていますが、書籍の大きな流れ自体は本記事の旧版と変わっていませんので、引き続き参考にしていただければと思います。 TLS 1.3ベースの解説になった 一方で、TLS 1.2以前について知っているべきことも厳選して残されている ウェブでTLSとPKIを安全に使うための課題と対策についての解説が拡充され、整理された 書籍後半の設定や運用に関する詳細説明がOpenSSLベースに一本化され、整理された 新たに明らかになった脆弱性やインシデントの解説が追加された ［ここまで2024/04/29 追記］ 本記事は、ラムダノートで発売している『プロフェッショナルSSL/TLS』を買っていただいた方向けに「読んで」とお願いするため
The ZAP Homepage
Zed Attack Proxy (ZAP) by The world’s most widely used web app scanner. Free and open source. A community based GitHub Top 1000 project that anyone can contribute to. Intro Video Quick Start Guide Download Now Intro to ZAP If you are new to security testing, then ZAP has you very much in mind. Check out our ZAP Quick Start Guide to learn more! Automate with ZAP ZAP provides range of options for se
Haproxyを用いて443ポートで複数サービスをホストする - Qiita
はじめに グローバルIPが1つしかないプライベートなサーバーで443ポートはかなり貴重です。 元々SSH,OpenVPN,HTTPSといった各サービスの標準ポートを使えば何ら問題はないんですが、80,443しか通さない強固なプロキシや◯盾等のけしからんネットワークを掻い潜るためには、どうしても443ポートを使用してHTTPSに偽装する必要が生じます。 それらのサービスを同時にホストするためのプロキシとしてSSLHがありますが、プロトコル判定ルールがソースレベルで定義されているため、定義にないプロトコルを追加することは少々難しいです。 拙記事 SSLHでSoftether(SSTP)とApacheを共存 https://qiita.com/Shachihoko/items/64a519b930b26ee4e81e そこで今回はDPIっぽい挙動ができる汎用プロキシである Haproxy を用い
OpenSSLがGUIだったら
► 2014 (94) 8月 (3) 9月 (22) 10月 (22) 11月 (25) 12月 (22) ► 2015 (280) 1月 (18) 2月 (20) 3月 (32) 4月 (13) 5月 (28) 6月 (34) 7月 (23) 8月 (30) 9月 (24) 10月 (13) 11月 (20) 12月 (25) ► 2016 (362) 1月 (27) 2月 (17) 3月 (29) 4月 (28) 5月 (33) 6月 (18) 7月 (24) 8月 (29) 9月 (38) 10月 (36) 11月 (37) 12月 (46) ► 2017 (578) 1月 (41) 2月 (53) 3月 (51) 4月 (44) 5月 (52) 6月 (46) 7月 (50) 8月 (51) 9月 (51) 10月 (49) 11月 (47) 12月 (43) ► 2018 (47
HTTPS 証明書の Common Name の検証がしれっと禁止されていた件について | IIJ Engineers Blog
開発・運用の現場から、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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://help.zscaler.com/ja/zia/about-ssl-inspection
GitHub CoPilot self-signed certificate error in Intellij
GitHub - escline/InstallCert: Java program to retrieve server certificate that can be added to local keystore
Upcoming Let’s Encrypt certificate chain change and impact for Cloudflare customers
X.509証明書の失効