お問い合せ先: ケープコッド株式会社 所在地 〒359-0001 埼玉県所沢市下富1043-109 TEL 04-2942-5899 FAX 04-2942-5899 E-mail sales@onlinessl.jp
Let’s Encrypt はフリーで自動化されたオープンな認証局です。 2021 年の年次レポートを読む ブログ記事より 2024/07/23 Intent to End OCSP Service Moving to a more privacy-respecting and efficient method of checking certificate revocation. もっと読む 2024/06/24 More Memory Safety for Let’s Encrypt: Deploying ntpd-rs NTP is critical to how TLS works, and now it’s memory safe at Let’s Encrypt. もっと読む 2024/05/30 Let’s Encrypt Continues Partnership with
smtp_tls_CAfile接続先の証明書を検証するためのルート証明書です。 ルート証明書の期限が切れていたりすると正しい設定でもエラーが出力されるので内容を確認しましょう。もし、古いようであれば最新のものに更新しましょう。 ルート証明書確認方法# openssl x509 -text -noout -in /etc/pki/tls/cert.pem Certificate: Data: Version: 3 (0x2) Serial Number: 6828503384748696800 (0x5ec3b7a6437fa4e0) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=ACCVRAIZ1, OU=PKIACCV, O=ACCV, C=ES Validity Not Before: May 5 09:37:37 2011
TLSサポート付きでPostfixをビルドする TLSサポートを付けてPostfixをビルドするには、まず必要な定義の書かれた make(1) ファイルを生成する必要があります。これはPostfixトップレベルディレクトリで "make makefiles" コマンドに次に示す短い引数を付けて呼び出すことで生成されます。 注意: Gnu TLSを使わないでください。Postfixは 1) maillogファイルにエラーを 報告して、2) 適切な平文サービスを提供できず、Postfixデーモンプロセスは終了ステータスコード2で終了させられてしまいます。 OpenSSL インクルードファイル (ssl.h のような) が /usr/include/openssl ディレクトリにあり、OpenSSL ライブラリ (libssl.so や libcrypto.so のような) が /usr/lib
Apacheを使ってReverseProxyしていて、フロント(クライアント)からのアクセスをhttpsで、バックエンドをhttpでやっているようなケースでの問題。mod_proxyのドキュメント通りに、おおむね以下のような設定を書いているハズ。 <VirtualHost *:443> (...snip...) ProxyPass /bugzilla http://192.168.1.3/bugzilla ProxyPassReverse /bugzilla http://192.168.1.3/bugzilla (...snip...) </VirtualHost> ProxyPassReverseは、バックエンドがLocationヘッダでリダイレクトしようとするような場合に、pathをReverseProxyっぽく(クライアントの都合のいいように)書き換えるオプション。このとき、Loc
(1) Apacheのリバースプロキシをhttps化する手順について 本記事はApacheのリバースプロキシでhttpに加えてhttpsでもできるようにするための手順です。 (1-0) STEP0:前提事項の確認 前提としては、Webサイトやドメインの設定が一通り済んでおり「httpでのリバースプロキシ設定」の済んでいる前提で進めるため、もしまだ完了していない場合は先にそれらのステップを実施頂けたらと思います。 (前提事項) ①HTML、JSP/Servlet等でホームページを作成済み (例:「http://[ホスト名]:[ポート番号]/[アプリ名]/[画面名].jsp」のURL形式で自身のサイトにアクセスできる) ②ウェルカムページの設定が完了している (例:「http://[ホスト名]:[ポート番号]/[アプリ名]/」のURL形式で自身のサイトにアクセスできる) ③ドメインを取得してD
nginxでリバースプロキシするとバックエンド側への通信がHTTP/1.0になる件 2019年10月2日 2019年10月2日 未分類 Nginx経由でPHP製のWebアプリにつないだ際、なぜかWebアプリを稼働させているバックエンドのApacheのプロセスが無数に増えてしまい、RAMを食いつぶしてしまう問題に遭遇しました。 Apacheへ直つなぎした場合はそういった問題が起きないため、Apacheとnginxのアクセスログを見比べてみたところ、Apacheへ通信した際はHTTP/1.1が使われていたのに対し、nginx経由でアクセスした際は何故かApacheとの通信が”HTTP/1.0″になってしまっていました。 色々調べたところ、どうやらNginxでリバースプロキシを行う場合、何も指定しない場合、バックエンドのサーバーとはデフォルトでHTTP/1.0で通信してしまうとのこと。 HTTP
OpenSSLに重大度「CRITICAL(致命的)」の脆弱(ぜいじゃく)性が発見されました。脆弱性への対応は迅速に行われており、日本時間の2022年11月1日22時~2022年11月2日4時の間に修正版の「OpenSSL 3.0.7」が公開予定です。OpenSSLに重大度「CRITICAL」の脆弱性が発見されたのは、2014年に報告されて世界中を騒がせた「Heartbleed」に続いて史上2回目。修正版のリリース後には、速やかにアップデートを適用する必要があります。【2022年11月2日追記】その後の分析の結果、OpenSSL 3.0.7で修正された脆弱性の重大度は「HIGH(CRITICALの1段階下)」に修正されました。 Forthcoming OpenSSL Releases https://mta.openssl.org/pipermail/openssl-announce/202
本記事で紹介している証明書は2018年10月にリリースされる GoogleChromeで不正な証明書と判定されてしまう予定です。 証明書更新する際は注意してください。 Webアプリを作っていて、ログインする機能や、ユーザの情報を入れてもらうような機能を作る場合、通信はhttpではなくhttpsで暗号化すべきかと存じます。サーバ証明書を設定する機会は新しいアプリを作るとき、または、証明書の更新時(1年に1回)しかないため、毎回設定の手順を忘れて0から作り直しています。そのため、今回は次の証明書設定時に困らないよう、Nginxにサーバ証明書を設定する手順を以下に残しておきたいと存じます。 導入するサーバ証明書 国内最安値と有名なSSLBOXのラピッド証明書を選択します。 (企業として公開するものではないため、EVや企業認証ではなくドメイン認証の証明書を利用します) 無料で発行できるものもありま
更新または乗り換えのお客様 証明書の更新方法は以下の方法があります。 ・既存の「証明書」「秘密鍵」のファイル名を引き続き使用する。 ・「証明書」「秘密鍵」のファイル名を新たにし、confファイルで新ファイル名を記載する。 いずれの方法を取っていただいても問題ございませんが、前者の場合ファイルを上書きしてしまいますと、復旧できませんのでご注意ください。 また、新証明書が反映するのは、以下手順の最後のnginx再起動後となります。 契約者、技術担当者宛に送信しております「サーバ証明書発行のお知らせ」メール本文から「◆証明書」のデータ (-----BEGIN CERTIFICATE----- から -----END CERTIFICATE-----まで)をコピーしてサーバに保存します。GSパネルにログインし、「サーバ証明書」タブにある「証明書一覧」メニューから取得をすることもできます。 保存先の
更新または乗り換えのお客様 証明書の更新方法は以下の方法があります。 ・既存の「証明書」「秘密鍵」のファイル名を引き続き使用する。 ・「証明書」「秘密鍵」のファイル名を新たにし、confファイルで新ファイル名を記載する。 いずれの方法を取っていただいても問題ございませんが、前者の場合ファイルを上書きしてしまいますと、復旧できませんのでご注意ください。 また、新証明書が反映するのは、以下手順の最後のnginx再起動後となります。 契約者、技術担当者宛に送信しております「サーバ証明書発行のお知らせ」メール本文から「◆証明書」のデータ (-----BEGIN CERTIFICATE----- から -----END CERTIFICATE-----まで)をコピーしてサーバに保存します。 保存先の例 /etc/nginx/ssl.toritonssl.com.crt 更新のお客様 引き続き同じファ
以前導入した Let's Encrypt の証明書の有効期限が切れてしまい、ついでに色々問題が発生したので、対処した方法のメモを記録しておくことにしました。 今回発生した現象はこちら。(抜粋です。) Traceback (most recent call last): File "/opt/eff.org/certbot/venv/bin/letsencrypt", line 11, in <module> sys.exit(main()) File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/main.py", line 755, in main return config.func(config, plugins) File "/opt/eff.org/certbot/venv/local/l
nginx で https と ssh をリッスンする nginx には $ssl_preread_protocol というStream設定が用意されている。これを使うとTLSプロトコルごとに、プロキシ先を変えることができる ただし443 はストリームが使うので、リッスン先をいい感じに帰る必要がある。 全体の接続 全体の接続は、次のようになる。 nginx stream は sshd / https に直接接続しない。 sshd のリッスンポートに直接接続すると、プロトコル不一致が起きて接続できないので、server{ .. } を経由してる。 https に直接接続できるといえばできるが、プロキシプロトコルを設定しやすくするため、server{ .. } を経由してある nginx の設定は次の通り stream 設定を作る。 ssl_preread_protocol で TLSはweb
グローバルで既に広く普及しているDigiCertルート証明書を活用し、パブリック TLS/SSLサーバ証明書を以下の階層構造で発行いたします。 「署名アルゴリズム」の概要は以下の通りです。 Mixed SHA-2:SHA-256 with RSA and SHA-1 root ※2023/3/8にTLS/SSL証明書の発行が終了します Full SHA-2(標準):SHA-256 with RSA and SHA-256 root ※2022/3/9からCertCentralで標準的に発行されているチェーンです Mixed ECC: ECDSA with SHA-384 and RSA root ※2023/3/8にTLS/SSL証明書の発行が終了します Full ECC: ECDSA with SHA-384 and ECC root
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く