refirio.org

SSL証明書についての勉強メモ 【図解】よく分かるデジタル(SSL/TLS)証明書の仕組み 〜https通信フロー、CSR、自己署名(オレオレ)証明書、ルート証明書、中間証明書の必要性や扱いについて〜 | SEの道標 https://milestone-of-se.nesuke.com/sv-advanced/digicert/digital-certification-summary/ 【図解】初心者にもわかりやすい『公開鍵・秘密鍵』の仕組み　〜近で具体的な利用例やメリット〜 | SEの道標 https://milestone-of-se.nesuke.com/sv-advanced/digicert/public-private-key/ 中間証明書の必要性、証明機関(認証局)の階層化の理由 | SEの道標 https://milestone-of-se.nesuke.com/sv-advanced/digicert/ca-hierarchy/ CSRとは？ | SSL入門ガイド | CSP SSL https://cspssl.jp/guide/csr.php OpenSSLでキーペアやCSRを作成する手順 - Qiita https://qiita.com/dribble13/items/52372ffbd218d2b019f8 秘密鍵から公開鍵作る - Qiita https://qiita.com/koudaiii/items/45f9f5929afb0039ffdb OpenSSLコマンドの備忘録 - Qiita https://qiita.com/takech9203/items/5206f8e2572e95209bbc RSA鍵、証明書のファイルフォーマットについて - Qiita https://qiita.com/kunichiko/items/12cbccaadcbf41c72735 Open-SSLで作ったCSRファイルの電子署名を解析してみた - Qiita https://qiita.com/izuki_y/items/15f755d150d251c0533b CSRとは何ですか | Symantec https://knowledge.symantec.com/jp/support/ssl-certificates-support/index?vproductcat=V_C_S&vdoma... （短いビット長の）RSA暗号を解いてみる - clock-up-blog http://blog.clock-up.jp/entry/2016/12/15/crack-rsa-key オレオレ証明書を使い続ける上場企業をまとめてみた - megamouthの葬列 https://www.megamouth.info/entry/2020/01/16/224511 図解 X.509 証明書 - Qiita https://qiita.com/TakahikoKawasaki/items/4c35ac38c52978805c69 SSHの公開鍵暗号には「RSA」「DSA」「ECDSA」「EdDSA」のどれを使えばよいのか？ - GIGAZINE https://gigazine.net/news/20200828-ssh-encryption-algorithm/ 暗号の歴史と現代暗号の基礎理論（RSA, 楕円曲線）-前半- - ABEJA Tech Blog https://tech-blog.abeja.asia/entry/cryptographic-fundamental-theory-202304-1 暗号の歴史と現代暗号の基礎理論（RSA, 楕円曲線）-後半- - ABEJA Tech Blog https://tech-blog.abeja.asia/entry/cryptographic-fundamental-theory-202304-2 プログラマのための公開鍵による暗号化と署名の話 https://zenn.dev/herumi/articles/pke-signature-for-programmer ■SSLとTLS SSLは「Secure Socket Layer」の略で、インターネット上でやりとりされるデータの「盗聴」「改ざん」「なりすまし」を防止するための通信方式 SSLの設計を根本から見直して新しく作成されたものがTLSで「Transport Layer Security」の略 よって現在使われているのはTLSだが、馴染みのあるSSLという名前で呼ばれ続けている ■暗号化とハッシュ化 ハッシュ化は、復号化を前提としていない 暗号化は、復号化を前提としている ハッシュ化とは？暗号化との違いや利用シーンを詳しく解説！｜ITトレンド https://it-trend.jp/encryption/article/64-0065 ■公開鍵暗号方式と共通鍵暗号方式 共通鍵暗号方式は、暗号化するための鍵とそれを復号するための鍵に同じものを使用する方式 公開鍵暗号方式は、暗号化（復号）するときに「公開鍵」「秘密鍵」という別々の鍵を用いる方式。共通鍵暗号方式よりも複雑で処理コストも高い SSLでも共通鍵暗号方式で暗号化と復号化を行うが、共通鍵を安全にやりとりしてからとなる 共通鍵を安全にやりとりするために公開鍵暗号方式を使用する PKIとは？｜GMOグローバルサイン【公式】 https://jp.globalsign.com/ssl-pki-info/pki/aboutpki.html ■公開鍵暗号方式の仕組み 公開鍵で暗号化されたものを、秘密鍵によって復号化できる暗号化方式 クライアントは、ルート証明書（公開鍵が含まれており、ブラウザに組み込まれている）を持っている Webサーバには、サーバ証明書（公開鍵が含まれている）と秘密鍵が組み込まれている（SSL導入の際に組み込む） サーバ証明書は、中間認証局によって中間証明書を使って発行される その中間証明書は、ルート認証局によってルート証明書を使って発行される ルート証明書は、はじめからブラウザに組み込まれている この前提で、以下の流れで暗号化通信が行われる 1. クライアントからWebサーバに、接続要求を行う 2. Webサーバからクライアントに、サーバ証明書を送る 3. クライアントは、ルート証明書でサーバ証明書の妥当性を検証する 4. クライアントは、共通鍵を生成する 5. クライアントは、サーバ証明書内の公開鍵で共通鍵を暗号化する 6. クライアントからWebサーバに、暗号化した共通鍵を送付する 7. Webサーバは、暗号化された共通鍵を秘密鍵で複合する 8. クライアントとWebサーバの両方が共通鍵を持ったことになるので、以降は共通鍵で暗号化通信を行う より簡易に書くと 1. クライアントは、Webサーバからサーバ証明書を受け取る 2. クライアントは共通鍵を生成し、サーバ証明書内の公開鍵で暗号化する 3. Webサーバは、クライアントから暗号化された共通鍵を受け取る 4. Webサーバは、暗号化された共通鍵を秘密鍵で複合する という流れになる 公開鍵だけで複合できない根拠は「SSL証明書の安全性と有効期限」を参照 SSL/TLS暗号化通信の仕組み｜GMOグローバルサイン【公式】 https://jp.globalsign.com/ssl-pki-info/ssl_practices/ssl_encryption.html 【図解】SSL/TLSとは何か？仕組みや導入方法をわかりやすく解説します | カゴヤのサーバー研究室 https://www.kagoya.jp/howto/rentalserver/ssl/ SSLって何？意味や仕組みをわかりやすく解説！ | さくらのSSL https://ssl.sakura.ad.jp/column/ssl/ ■証明書の関係 秘密鍵 … 流出してはいけない鍵ファイル 公開鍵 … 流出しても問題無い鍵ファイル CSR … 証明書を発行するための署名要求（Certificate Signing Request）。つまり認証局に対し、SSLサーバ証明書への署名を申請する内容 CSRには、公開鍵、発行者情報やコモンネーム（FQDN）、電子署名（もとのCSRをハッシュ化し、さらに秘密鍵で暗号化したもの）が含まれる 秘密鍵があれば、CSRは何度でも生成できる 証明書 … 認証局から発行されるSSL証明書 CSRをもとに発行される 中間証明書 … 認証局から発行されるSSL証明書 証明書に階層構造を持たせることにより、認証局が攻撃されたときの影響を抑えている CSRについて教えてください。 https://jp.globalsign.com/support/faq/65.html ■秘密鍵と変換 秘密鍵には以下のように複数の種類があり、それぞれ変換することができる id_rsa ... Linux上で「ssh-keygen -t rsa」などによるSSH鍵作成をした際の秘密鍵。RSAは、桁数が大きい合成数の素因数分解問題が困難であることを安全性の根拠とした暗号化方式 pem ... 「Privacy Enhanced Mail」の略で、電子メール暗号化技術。OpenSSH形式の秘密鍵。AWSで作成されるキーペアもこの形式 ppk ... 「Putty Private Key」の略で、PuTTY形式の秘密鍵。WinSCPやTera Termなどで使用される id_rsa⇒pem⇔ppk 相互変換 | Punio Kid Works https://web.archive.org/web/20191229185925/http://www.puniokid.com/tips/linux/69/ SSH秘密鍵 id_rsa -> putty形式&OpenSSH形式に変換 - Qiita https://qiita.com/dskst/items/391fc55018fbf3cf795e ■概要 今さら聞けない SSL 証明書とは、DV、OV、EV や常時 SSL について｜レンタルサーバーナレッジ https://knowledge.cpi.ad.jp/security-info/244/ 証明書には以下の種類がある ・DV（ドメイン認証） … ドメイン名が正しいかどうかを認証する ・OV（実在証明型） … ドメイン名に加え、運営組織名（会社名）も証明する ・EV（実在証明拡張型） … ドメイン名と運営組織名（会社名）に加え、住所や法人番号も証明する 運営組織名や住所などを実際に確認する場合、ブラウザの鍵アイコンをクリックして 「この接続は保護されています → 証明書は有効です」 で表示されるウインドウの 「詳細」 タブ内の 「証明書のフィールド → 件名」 で確認できる（2022年12月時点のChromeで確認した手順） SSL証明書のEV・OV・DVの違いとブラウザでの見え方について - Rainbow Engine https://rainbow-engine.com/sslcert-ev-ov-dv-diff/ 以下は実際の商品（証明書）案内の例 SSL認証タイプ別機能・サービス内容一覧｜GMOグローバルサイン【公式】 https://jp.globalsign.com/ssl/guide/functions.html SSLサーバ証明書お申し込みガイド｜GMOグローバルサイン【公式】 https://jp.globalsign.com/ssl-shop/new-order/ CSRを作成する際にディスティングイッシュネーム（サイトやサイト運営団体に関わる情報）を入力する 証明書の種類によって、これらがどこまで証明書に反映されるかの差がある ディスティングイッシュネームとは何ですか | GMOグローバルサイン サポート https://jp.globalsign.com/support/cert-management/distinguish-name.html ■OV（実在証明型）による組織名表示の具体例 企業認証SSL byGMO｜GMOグローバルサイン【公式】 https://jp.globalsign.com/ssl/bizssl.html CSR作成時に以下を入力したとする （EVでなければLocality Nameは反映されないし、OVでなければさらにOrganization Nameも反映されないはず DVの場合は最低限の情報だけ入力して進めれば良さそうではある 要検証） グローバルサインで「クイック認証SSL byGMO」の購入直前まで進めてみると、 「CSR解析結果」の項目に「O」は表示される。ただし「審査される証明書の内容」では表示されない 「クイック認証SSL byGMO」ドメイン認証なので、作成される証明書の内容からは省かれる また と説明も表示される つまり組織名を証明書に反映されたければ、企業認証SSLにする必要がある グローバルサインで「企業認証SSL byGMO」の購入直前まで進めてみると、「O」が「審査される証明書の内容」にも表示された また と説明も表示される このまま進めていくと、「申請組織情報」の入力画面が表示され、 「第三者データベース情報」の入力欄が表示される 情報は「DUNSナンバー」か「帝国データバンクコード」を選択して入力するようになっている （あわせて、サイトシール用に「番地、地名（英語）」「ビル名（英語）」の入力欄も表示される） この申請内容をもとにグローバルサイン側で確認が取れれば、証明書が即日発行されるのだと思われる 確認が取れない場合、組織に対して電話確認などが行なわれるのだと思われる ■組織単位名の表示 証明書の OU（組織単位名）は非推奨へ、来年からは利用禁止に｜BLOG｜ サイバートラスト https://www.cybertrust.co.jp/blog/ssl/regulations/ou-usage-prohibit.html OU（組織単位名）は禁止されるとのこと （ここには部署名などを入力することが多いようだが、個人的には普段から空欄でCSRを作成している） 恐らく「2022年9月1日以降に発行する証明書には、OUは反映されない」というだけで、 証明書発行の作業内容などには特に影響しないはず ■OV（実在証明型）を導入する際の具体的な流れ ここでは「作業者」が「クライアント」からの依頼を受け、「クライアント」のWebサイトにOV（実在証明型）を導入するものとする 前提として、申し込みは作業者アカウントからではなく、 下記「新規お申し込み」ページ最下部の「<アカウントをお持ちでないお客様> 今すぐ証明書をご購入」から行う必要がある これにより、（クライアント用の）新たなアカウント作成と証明書のお申し込みを同時に行うことになる 企業認証SSL byGMO 新規お申し込み https://jp.globalsign.com/ssl-shop/new-order/bizssl.html [企業認証SSL byGMO] 証明書新規お申し込み フォームサンプル https://jp.globalsign.com/introduce/ssl/formsample/bizssl.php?sta=new&sv=cert そのうえで、申し込みにあたって作業者が行うべきことは以下となる ・クライアントから「組織情報」の内容を引き上げる 住所や電話番号は、クライアントのホームページに掲載されているような情報でいい ・クライアントから「契約者情報」の内容も引き上げる 氏名は情報処理部署のようなものがあれば、そこの担当者名でいい 電話番号やメールアドレスも、その部署のもので問題無い もし専用の電話番号が無ければ、「組織情報」と同じにする。ただしこの場合、「組織情報」に記載の電話番号で担当者名が会話できる必要がある パスワードは「契約者情報」のメールアドレスには通知されず、必要なら作業者からクライアントに共有することになる ・「支払い担当者情報」は作業者の情報を入力する この情報は、SSL証明書の内容には一切影響しない パスワードは作業者がGSパネルにログインする際に使用する。原則、クライアントと同じ情報を参照できる ・「技術担当者情報」は作業者の情報を入力する この情報は、SSL証明書の内容には一切影響しない ・購入した証明書は、「契約者情報」で指定したメールアドレスと、「技術担当者情報」で指定したメールアドレスに送られる 証明書更新の案内も、「契約者情報」で指定したメールアドレスと、「技術担当者情報」で指定したメールアドレスに送られる ・電話審査の連絡は第三者データベースに記載の代表電話番号へ、「契約者情報」に入力した方宛に行なわれる 代表電話番号から「契約者情報」に入力されている人へ取次ぎできない場合、代表電話番号で電話を取った人が「契約者情報」に記載の電話番号を伝える必要がある よってクライアントには、上記の電話があることをあらかじめ伝えておく必要がある ・「支払い担当者情報」と「技術担当者情報」を作業者にしておけば、来年以降のSSL証明書更新も作業者で作業できる ただし、電話での審査は更新の都度行われるので、「前年と同様、電話での審査の連絡がきます。担当者名の変更などは無いでしょうか？」な内容を、あらかじめクライアントに伝えておく必要がある 初回発行の手間がかかるのはもちろん、毎年クライアントに電話確認が行くなど、なかなか手間がかかることになる OVだからと言って暗号化の強度が向上するわけでは無いので、本当に必要かどうかはよく考えて導入したい ■メールアドレスの入力 CSRのメールアドレスは、証明書に反映されるものと反映されないものがあるみたい 自分で作るときは、基本的に入力しておけば良さそうではある 【疑問質問】 CSRには何を入力すれば良いのか？ | 大手正規SSL証明書が定価よりMAX66％OFFから 【 SSLコンシェル 】 https://www.ssl-concier.com/news/topics/230 OpenSSLでCSR作成 | サイフにやさしいSSL証明書 https://www.slogical.co.jp/ssl/faq/csr_openssl/ ディスティングイッシュネームとは何ですか | GMOグローバルサイン サポート https://jp.globalsign.com/support/cert-management/distinguish-name.html ■ブランドによる金額の差 どのブランドが発行しても、証明書の暗号化強度は同じ ただ「あの有名なセキュリティ会社が発行した証明書だからいいものなのだろう」という知名度と信頼度によって金額が上げられていることが多い （例えばシマンテックやセコムなど） あとは 「サポートを充実させています」「サイトシール（サイト上で紹介できる証明書みたいなもの）を提供します」「1つの証明書で複数のサブドメインに対応できます（ワイルドカード）」 など、サポートや機能によっても金額が異なる SSL証明書のブランドによる違い | さくらのSSL https://ssl.sakura.ad.jp/column/ssl-brand-compare/ SSLサーバ証明書の認証局（ブランド）の種類と違い | ServerKurabe https://serverkurabe.com/ssl-brand/ ■大まかな流れ 1. 秘密鍵を作成する 2. 秘密鍵をもとにCSRを作成する 3. CSRをもとに証明書を発行する（SSL証明書を購入する） 4. 発行された証明書を、秘密鍵とセットでサーバに組み込む 証明書を発行する際、その内容が妥当かどうかはルート証明書の公開鍵が使われる ルート証明書の秘密鍵が流出するとすべてのSSL証明書の再発行が必要になって影響が大きいので、中間証明書を間に挟む ルート証明書は通常ブラウザに組み込まれているが、中間証明書は組み込まれていない よって証明書とともに、中間証明書もサーバに組み込む必要がある ルート証明書の秘密鍵は、攻撃による流出を避けるためオフラインで管理される ■SSL用に鍵を作成する これで秘密鍵とCSRを作成できた SSL証明書を購入する際は、このうちCSRの情報を登録する 購入が完了すると、証明書と中間証明書を入手できる 今回はそれぞれ refirio.net.20170417.crt と refirio.net.20170417.ca として保存するものとする 一例だが、以下のようにしてApacheに組み込む 証明書関連の設定以外や設定箇所は、あくまでも一例 完了したらブラウザからアクセスし、証明書の有効期限を確認する 以降では、このSSL用のファイルについて詳細を確認する ■SSHでの認証用に鍵を作成する場合（参考までに。SSL証明書には不要） 認証用に id_rsa （秘密鍵）と id_rsa.pub （公開鍵）が作成される 同じ場所に authorized_keys が配置されていることがあるが、これは認証済みの id_rsa.pub が記録されるファイル アクセス元で id_rsa.pub を作成した場合、その内容を authorized_keys に追記しておけばアクセス元に id_rsa.pub は不要 （アクセス元が一つなら、authorized_keys と id_rsa.pub の内容は同一になる） id_rsa はアクセス元のどこに置いても大丈夫だが、セキュリティ上パーミッションを0600にしておかないと使えない これで秘密鍵 /home/refirio/.ssh/id_rsa をダウンロードして、接続時に鍵ファイルとして指定すれば、 SSHで refirio ユーザとして鍵認証で接続できる Linuxコマンド【 ssh-keygen 】認証用の鍵を生成 - Linux入門 - Webkaru https://webkaru.net/linux/ssh-keygen-command/ ssh公開鍵認証を実装する - Qiita https://qiita.com/HamaTech/items/21bb9761f326c4d4aa65 ■セキュリティビット数について 鍵を作成する際に2048という数を指定しているが、これがセキュリティビット数 脆弱性の知られていない共通鍵暗号を破るには、攻撃者はパターンを総当たりに試す必要がある この試行回数を基準として、2のべき乗として尺度にしたものがセキュリティービット数 例えば64ビットの場合、2の64乗（1844京6744兆737億955万1616）パターンの鍵を持つことになる なお公開鍵暗号はその性質から、秘密鍵のビット数で表現できる数値のすべてが鍵になるわけでは無い 暗号スイートの暗号強度と、公開鍵のビット数の設定、及びRSAとECDHEでサーバ負荷の比較 - Apache 2.4系でHTTP/2対応サーバを構築してみるテスト。 https://http2.try-and-test.net/ecdhe.html なお、2の2048乗を計算すると以下になる 無量大数が10の68乗なので、もはや名前がつかない巨大な数になる 32317006071311007300714876688669951960444102669715 48403213034542752465513886789089319720141152291346 36887179609218980194941195591504909210950881523864 48283120630877367300996091750197750389652106796057 63838406756827679221864261975616183809433847617047 05816458520363050428875758915410658086075523991239 30385521914333389668342420684974786564569494856176 03532632205807780565933102619270846031415025859286 41771167259436037184618573575983511523016459044036 97613233287231227125684710820209725157101726931323 46967854258065669793504599726835299863821552516638 94373355436021354332296046453184786049521481935558 53611059596230656 ■SSL証明書の安全性と有効期限 RSAは、桁数が大きい合成数の素因数分解問題が困難であることを安全性の根拠とした暗号化方式 例えば二つの素数の積「19 × 37 = 703」を求めることは容易だが、素数の積から二つの素数「703 = 19 × 37」を求めるには総当たりで計算するしか無い 桁数が少なければ計算は難しくないが、桁数が多くなると計算に時間がかかる とは言え時間をかければ計算できるので、SSL証明書には通常1年の有効期限が設けられている コンピュータの性能向上の影響で、SSL証明書の有効期限は徐々に短く設定されるようになっている またSSL証明書の署名に不備があったなどで大量の証明書を失効せざるを得ない場合、 有効期限は短ければ短いほど影響範囲は少なくて済む 有効期限は今後も短くなっていく可能性がある 証明書の差し替え作業を機械的にできるようにするか、自動更新できるようにするなどの検討が必要 何度も短縮し過ぎ？！SSL証明書の有効期間がどんどん短くなる理由とは？ | さくらのSSL https://ssl.sakura.ad.jp/column/shortened-ssl/ ■量子コンピュータについて 上記のように、共通鍵暗号を破るにはパターンを総当たりに試す必要がある 現在のコンピュータではこの総当りを現実的な時間で行えないため、これが安全性の根拠となっている ただし現在は量子コンピュータが研究されていて、これが実用化されると現在のSSL通信は解読されてしまう可能性がある SSL通信も量子コンピュータの前では無意味に？　今から備えるべき「耐量子コンピュータ暗号」とは - ITmedia NEWS https://www.itmedia.co.jp/news/articles/1911/15/news072.html 量子コンピュータによる暗号解読を防ぐためには、規格が定まり、導入可能になったらすぐに導入すること とされている 秘密鍵、CSR、証明書、中間証明書、公開鍵の内容は、 それぞれ一例だが以下のようなものになっている ■秘密鍵 ■CSR ■証明書 ■中間証明書 ■公開鍵（SSH通信用に作成した公開鍵の内容を参考までに。SSL証明書には不要） 秘密鍵、CSR、証明書、中間証明書、公開鍵の内容は、 opensslコマンドを使うことで解析できる ■秘密鍵 ■CSR ■証明書 ■中間証明書 ■CSRと秘密鍵の比較 ※CSRの「Modulus」と鍵の「modulus」の内容が一致すれば正しいペア ■公開鍵（参考までに。今回は不要） ■「-noout」について 省略すると、ファイルの内容も一緒にそのまま出力されるみたい 公開鍵に含まれる「素数の積」と 秘密鍵に含まれる2つの「素数」の積が一致することは、 以下の手順で確認できる ■素数の積 コロン、スペース、改行を削除する 16進数を10進数にする これが素数の積 ■素数1 コロン、スペース、改行を削除する 16進数を10進数にする これが素数1 ■素数2 コロン、スペース、改行を削除する 16進数を10進数にする これが素数2 ■計算 「素数1」と「素数2」の積が「素数の積」と一致することが確認できる 計算の桁数が非常に多いため、簡易な計算ツールだと対応できないので注意 以下の計算ツールを使うなどで対応できる 高精度な高等関数が使えるフリー計算 https://keisan.casio.jp/calculator RSA公開鍵から素数の積を取り出す方法 - hnwの日記 http://d.hatena.ne.jp/hnw/20140517 2進数、8進数、10進数、16進数相互変換ツール https://hogehoge.tk/tool/number.html 以下は有効期限を確認している例 opensslでの解析については、このファイル内の「ファイルの解析」や「外部サーバからコマンドで証明書情報を確認」も参照 SSL証明書の内容をopensslで確認する - Qiita https://qiita.com/masachika/items/e4936feb4087b7ddbe8b また、以下でSSLの品質を評価できる SSL Server Test (Powered by Qualys SSL Labs) https://www.ssllabs.com/ssltest/ 以下のようにすると、評価結果に直接リンクできる SSL Server Test: refirio.net (Powered by Qualys SSL Labs) https://www.ssllabs.com/ssltest/analyze.html?d=refirio.net 以下は活用事例 レガシーとなった TLS 1.0/1.1 廃止までの道のり - クックパッド開発者ブログ https://techlife.cookpad.com/entry/2021/08/19/100000 【AWS】ELBセキュリティポリシー変更してTLS 1.0/1.1 無効化｜SAYJOY blog https://sayjoyblog.com/elb-securitypolicy/ 証明書と中間証明書は外部に公開されている 以下のようにコマンドで内容を確認できる opensslコマンドで証明書情報を確認したい。 │ サポート │ GMOグローバルサイン【公式】 https://jp.globalsign.com/support/faq/07.html 証明書と中間証明書は外部に公開されている ブラウザのアドレスバーの鍵アイコンをクリックし、「証明書」を選択するとダイアログが表示される 「詳細」タブの「シリアル番号」を確認する ■バージョン ■シリアル番号 ■署名アルゴリズム ■署名ハッシュアルゴリズム ■発行者 ■有効期間の開始 ■有効期間の終了 ■サブジェクト ■公開キー ※実際には改行は無い 先頭の「30 82 01 0a 02 82 01 01」と末尾の「02 03 01 00 01」を除いたものが、公開鍵の内容（素数の積）と一致する ■公開キーのパラメーター ■機関情報アクセス ■証明書ポリシー ■基本制限 ■CRL配布ポイント ■サブジェクト代替名 ■拡張キー使用法 ■サブジェクトキー識別子 ■機関キー識別子 ■SCT一覧 ■キー使用法 ■拇印 本当に意図した証明書がサーバ上に反映されているか確認する方法 まずは、サーバ上に反映したはずの証明書の内容をテキストファイルに入力し、拡張子を「.cer」にして保存する そのファイルをダブルクリックで開くと、証明書の内容を確認できる（Windows10で、ダイアログが開くのを確認できた） 「詳細」タブの「シリアル番号」を確認する 次に、サーバ上に適用済みの証明書を確認する ブラウザのアドレスバーの鍵アイコンをクリックし、「証明書」を選択するとダイアログが表示される 「詳細」タブの「シリアル番号」を確認する それぞれの「シリアル番号」が一致していることを確認する 必要に応じて、その他の項目も比較確認する 証明書のシリアル番号の確認方法 https://knowledge.digicert.com/ja/jp/solution/SO25504.html 現在はSNIにより設定が可能になっている Etcetera.txt の同項目を参照 pemのみの場合と、公開鍵秘密鍵の2つを作る場合 について整理中 makeで証明書を作成しているのは、同階層にMakefileがあるからか Makefile内で「openssl」といった文字列を確認できる Make と Makefile の説明 https://www.unixuser.org/~euske/doc/makefile/ openssl genrsa はブラウザでHTTPS通信を行う時に使うSSL用の秘密鍵と公開鍵を発行するコマンド、 ssh-keygen はリモートマシンを操作する時に使うSSH用の秘密鍵と公開鍵を発行するコマンド らしい pemは証明書情報をbase64でテキスト化したものらしい Linux - openssl genrsa と ssh-keygenについて｜teratail https://teratail.com/questions/14469 どの命令で何が作られるのか、改めて整理しておきたい 以下は参考メモ ■SSH 以下で認証用の鍵を作成している ■Web 以下で証明書を作成している（オレオレ証明書） 内部で以下が実行される？ 以下で作成しているメモもある ■FTP 以下で証明書を作成している 内部で以下が実行される？ ■MAIL 以下で証明書を作成している 内部で以下が実行される？