インフラエンジニア勉強雑記

インフラ技術に関して勉強したメモを残したものです。誤っている内容があればコメントもしくはメッセージでお知らせいただけると助かります。

SSL/TLSについて③ 証明書とは

 

1.用語説明

用語の説明を行います。

  • ルート認証局:自分自身で自身が正しい証明機関だと証明できる認証局です。通常は中間認証局のように上位の証明機関(ルート証明機関など)から正しい認証局だと証明してもらう必要がありますが、ルート認証局は不要となります。例としてVerisignやEntrustなどがあります。
  • 中間認証局:上位の認証局に信頼できる認証局と証明された認証局です。外部公開用のサーバはこの中間認証局から証明書を発行してもらうことになります。
  • CSR(Certificate Signing Request):証明書の発行を依頼するために依頼元の組織で発行するための証明書です。

2.証明書とは

2.1.証明書の概要

正しくは電子証明書といいます。証明書は信頼できる機関(認証局)が発行することで、サイトやクライアントが安全であることを証明します。

以下のような証明書があります。

  • サーバ証明書:アクセス先のサーバが信頼できるサイトであることを証明するための証明書。HTTPSなどで公開しているWebサーバで使用されることが多いかもしれません。
  • ユーザ証明書:対象のユーザもしくはデバイスが信頼できるものであることを伝えるための証明書。無線や有線でNWに接続する際の802.1X認証や銀行での認証で使用されることが多いかと思います。

ではどのように証明書が発行されるのかを説明します。サーバ証明書を例として説明します。

f:id:light-spoqz:20190203153144j:plain

①証明書発行依頼組織がサーバ(OpenSSLがインストールされているLinux,アプライアンス製品など)でCSRの発行を行います。秘密鍵CSRが生成されます。

②発行したCSRを中間認証局に送信します。

③中間認証局秘密鍵で本内容から証明書を生成します。

④中間認証局は生成した証明書を依頼組織に対して返送します。

上記が簡単ですが、流れとなります。ルート認証局から証明書送信とありますが、ルート認証局が中間認証局が信頼できると事前に証明しているため、このフローは不要です。

本手順はインターネット上に公開する場合のサービスとなっております。インターネット上に公開する場合は不特定多数の人が閲覧するため、ルート証明書保有しているクライアントでないとエラー画面が表示されてしまいます。自己証明書であれば先程の手順のように外部認証機関から証明書の発行は不要となります。

2.2.署名とは

上記でCSRに署名を行うことで証明書が作成されると記載しましたが、具体的な動きを説明します。まず以下はCSRの内容です。

Certificate Request:
   Data:
      Version: 0 (0x0)
      Subject: C=JP, ST=Tokyo, L=Default City, O=test inc, OU=IT test, CN=test.com
      Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
         Public-Key: (2048 bit)
         Modulus:
            00:d3:cf:af:cf:32:7f:3c:29:c4:cf:45:be:c8:1e:
            16:e4:66:98:6c:02:9f:75:c9:07:d4:01:95:61:af:
            6c:c9:d1:2d:ea:94:b4:5e:e3:0c:6a:3c:a9:27:25:
            5d:7e:90:e6:dd:69:3c:fe:d3:21:55:b4:b9:bd:34:
            3f:25:9f:d5:b9:5c:b6:d9:6e:94:90:a2:9e:46:01:
            64:86:59:0d:9c:90:ab:02:e9:b1:cb:26:58:4b:19:
            db:ef:6c:52:5d:a6:f4:dc:2d:b9:39:7e:97:53:f6:
            97:71:b6:26:b8:9f:d4:f9:94:13:ab:6d:ac:42:2e:
            9c:03:d5:94:70:0a:ae:2d:a4:44:56:75:80:ea:c3:
            5a:df:42:d6:b9:2e:a5:45:e2:cf:3f:2b:c8:f3:2d:
            e3:ed:9c:58:fe:74:dc:a5:0b:7a:b3:40:8b:8b:65:
            f9:39:3f:6f:6b:b3:4b:41:d0:a7:ce:89:8c:56:52:
            f0:b9:67:0d:39:b3:76:65:ba:f4:9a:35:e3:6d:23:
            dd:78:52:22:17:f6:86:00:b6:58:a8:da:1c:b4:84:
            f6:02:b8:de:ac:01:11:8a:f1:86:23:7b:50:1a:95:
            da:15:53:ce:98:4c:fd:41:0d:dd:e4:e8:79:ed:30:
            11:7f:bd:0b:1b:b9:c5:83:70:56:8a:9a:01:df:73:
            89:59
         Exponent: 65537 (0x10001)
      Attributes:
      Requested Extensions:
         X509v3 Basic Constraints:
            CA:FALSE
         X509v3 Key Usage:
            Digital Signature, Non Repudiation, Key Encipherment
         X509v3 Subject Alternative Name:
            DNS:test.com, DNS:*.test.com
   Signature Algorithm: sha256WithRSAEncryption
      10:cf:11:1b:a7:d2:f6:a9:e8:76:2c:73:4e:13:4c:1b:a1:e1:
      b9:d7:16:19:2a:93:c6:fa:fa:ad:d9:6f:1d:8e:e8:50:64:13:
      5d:c9:c7:17:0f:fc:5d:16:4f:90:27:bc:9f:d7:13:e6:5f:d3:
      c5:48:1b:ca:c0:b2:d0:e4:ea:e4:23:aa:84:36:50:b6:2a:24:
      7e:c9:4d:58:9c:e8:2b:98:72:de:e5:3a:7b:67:e7:8b:85:fc:
      9e:8d:74:e4:36:79:ee:c8:56:37:ad:9c:1f:0f:aa:7a:88:26:
      d0:8c:67:ea:27:19:fa:e7:dc:42:f9:12:e0:24:ef:bf:27:60:
      54:0e:b3:37:68:c5:54:c4:45:9d:30:63:3b:d0:14:05:a4:4f:
      da:e2:20:8f:8a:94:97:6d:4e:c3:07:c4:03:0d:28:96:d2:69:
      39:a5:18:6d:12:dc:5f:2d:b0:fd:a0:17:81:71:f3:94:8b:46:
      db:6d:68:20:94:e0:14:99:92:01:3f:ab:1d:98:8c:b2:a5:fa:
      a1:21:4e:be:28:a2:68:62:eb:fe:37:49:ad:d9:c9:c5:b0:22:
      05:88:fb:3f:6e:b5:c0:57:3c:39:15:61:42:ec:52:a7:18:81:
      84:29:2f:46:19:52:f3:42:0c:ce:19:de:55:fb:a5:b5:79:0f:
      41:f1:c7:2f
 

 以下は証明書の内容です。赤文字部分が署名です。

Certificate:
   Data:
      Version: 3 (0x2)
      Serial Number: 2 (0x2)
   Signature Algorithm: sha256WithRSAEncryption
      Issuer: C=JP, ST=Tokyo, L=Default City, O=test inc, CN=test.co.jp
      Validity
         Not Before: Feb 6 15:03:05 2019 GMT
         Not After : Feb 3 15:03:05 2029 GMT
      Subject: C=JP, ST=Tokyo, O=test inc, OU=IT test, CN=test.com
      Subject Public Key Info:
          Public Key Algorithm: rsaEncryption
             Public-Key: (2048 bit)
             Modulus:
                 00:d3:cf:af:cf:32:7f:3c:29:c4:cf:45:be:c8:1e:
                 16:e4:66:98:6c:02:9f:75:c9:07:d4:01:95:61:af:
                 6c:c9:d1:2d:ea:94:b4:5e:e3:0c:6a:3c:a9:27:25:
                 5d:7e:90:e6:dd:69:3c:fe:d3:21:55:b4:b9:bd:34:
                 3f:25:9f:d5:b9:5c:b6:d9:6e:94:90:a2:9e:46:01:
                 64:86:59:0d:9c:90:ab:02:e9:b1:cb:26:58:4b:19:
                 db:ef:6c:52:5d:a6:f4:dc:2d:b9:39:7e:97:53:f6:
                 97:71:b6:26:b8:9f:d4:f9:94:13:ab:6d:ac:42:2e:
                 9c:03:d5:94:70:0a:ae:2d:a4:44:56:75:80:ea:c3:
                 5a:df:42:d6:b9:2e:a5:45:e2:cf:3f:2b:c8:f3:2d:
                 e3:ed:9c:58:fe:74:dc:a5:0b:7a:b3:40:8b:8b:65:
                 f9:39:3f:6f:6b:b3:4b:41:d0:a7:ce:89:8c:56:52:
                 f0:b9:67:0d:39:b3:76:65:ba:f4:9a:35:e3:6d:23:
                 dd:78:52:22:17:f6:86:00:b6:58:a8:da:1c:b4:84:
                 f6:02:b8:de:ac:01:11:8a:f1:86:23:7b:50:1a:95:
                 da:15:53:ce:98:4c:fd:41:0d:dd:e4:e8:79:ed:30:
                 11:7f:bd:0b:1b:b9:c5:83:70:56:8a:9a:01:df:73:
                 89:59
            Exponent: 65537 (0x10001)
      X509v3 extensions:
         X509v3 Subject Alternative Name:
            DNS:test.com, DNS:*.test.com
   Signature Algorithm: sha256WithRSAEncryption
      30:e9:69:10:01:46:c9:be:0a:97:2d:1d:6c:48:28:29:f9:55:
      54:75:80:ce:60:b2:bc:63:b1:97:ff:08:91:7a:e5:f7:98:97:
      13:01:db:14:61:f2:58:c4:0c:c4:63:ec:94:26:49:9b:07:c7:
      36:1e:df:99:ab:cd:df:91:e7:10:a0:c9:fa:e0:57:3d:c9:c4:
      50:e7:4d:36:4c:22:9c:e4:88:a8:03:ee:fb:ae:3a:cb:f1:55:
      96:62:12:37:3e:90:33:75:22:bb:c4:85:9d:b8:c4:4c:c2:6b:
      f2:4d:33:13:9a:4b:86:f6:d6:ab:49:4a:c8:d4:fc:19:f4:23:
      a1:ec:e9:85:3f:3d:20:23:4d:8f:55:23:24:ad:b4:4d:8d:44:
      66:8e:e6:46:b7:ca:94:55:e0:99:a5:6e:59:30:17:e9:4c:f4:
      74:4d:9f:b7:8b:83:0b:91:72:b3:13:6b:58:bb:1a:eb:a4:c8:
      69:4d:93:d1:04:2a:12:dc:2e:86:fb:4e:f0:38:fe:00:aa:6a:
      e6:cb:a7:61:57:a5:28:4e:f1:f0:53:c9:ce:96:58:35:f1:b1:
      75:2c:3d:e9:a7:b9:1f:ba:1a:42:16:cb:10:a5:3a:6a:06:24:
      44:f0:4e:db:c4:39:90:db:8d:61:cb:2c:9b:0b:40:17:ac:2f:
      78:02:e2:62
-----BEGIN CERTIFICATE-----
MIIDTzCCAjegAwIBAgIBAjANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJKUDEO
MAwGA1UECAwFVG9reW8xFTATBgNVBAcMDERlZmF1bHQgQ2l0eTERMA8GA1UECgwI
dGVzdCBpbmMxEzARBgNVBAMMCnRlc3QuY28uanAwHhcNMTkwMjA2MTUwMzA1WhcN
MjkwMjAzMTUwMzA1WjBVMQswCQYDVQQGEwJKUDEOMAwGA1UECAwFVG9reW8xETAP
BgNVBAoMCHRlc3QgaW5jMRAwDgYDVQQLDAdJVCB0ZXN0MREwDwYDVQQDDAh0ZXN0
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANPPr88yfzwpxM9F
vsgeFuRmmGwCn3XJB9QBlWGvbMnRLeqUtF7jDGo8qSclXX6Q5t1pPP7TIVW0ub00
PyWf1blcttlulJCinkYBZIZZDZyQqwLpscsmWEsZ2+9sUl2m9NwtuTl+l1P2l3G2
Jrif1PmUE6ttrEIunAPVlHAKri2kRFZ1gOrDWt9C1rkupUXizz8ryPMt4+2cWP50
3KULerNAi4tl+Tk/b2uzS0HQp86JjFZS8LlnDTmzdmW69Jo1420j3XhSIhf2hgC2
WKjaHLSE9gK43qwBEYrxhiN7UBqV2hVTzphM/UEN3eToee0wEX+9Cxu5xYNwVoqa
Ad9ziVkCAwEAAaMjMCEwHwYDVR0RBBgwFoIIdGVzdC5jb22CCioudGVzdC5jb20w
DQYJKoZIhvcNAQELBQADggEBADDpaRABRsm+CpctHWxIKCn5VVR1gM5gsrxjsZf/
CJF65feYlxMB2xRh8ljEDMRj7JQmSZsHxzYe35mrzd+R5xCgyfrgVz3JxFDnTTZM
IpzkiKgD7vuuOsvxVZZiEjc+kDN1IrvEhZ24xEzCa/JNMxOaS4b21qtJSsjU/Bn0
I6Hs6YU/PSAjTY9VIySttE2NRGaO5ka3ypRV4JmlblkwF+lM9HRNn7eLgwuRcrMT
a1i7GuukyGlNk9EEKhLcLob7TvA4/gCqaubLp2FXpShO8fBTyc6WWDXxsXUsPemn
uR+6GkIWyxClOmoGJETwTtvEOZDbjWHLLJsLQBesL3gC4mI=
-----END CERTIFICATE-----

CSRを受け取った認証局はオクテット文字列を生成して、自身の秘密鍵で暗号化して証明書に付与します。(赤文字の部分です。)

この署名がどのように検証されるかを説明します。

①クライアントは証明書をもらって署名部分を既に所有している公開鍵(ルート証明書内に保有)で復号化します。

②署名部分のハッシュ値を計算します。

③2つの値を比較して同じだったら正当な証明書であるとクライアントは判断します。

CSRにも署名があります。本内容はCSRを受け取った認証局秘密鍵がちゃんとあるCSRであるかを確認しています。この内容はDERエンコードされたcertificationRequestInfoコンポーネントの値(オクテット文字列)をCSRと対になる秘密鍵で暗号化した値です。認証局ハッシュ値と公開鍵で復号化した内容を比較し、同一であった場合正しいと判断されます。証明書作成時には破棄されます。

2.3.証明書の情報

以下は本ブログをブラウザで開いたときにGoogle Chrome上のURL部分となります。鍵マークをクリックすると証明書によって暗号化されていることがわかります。

f:id:light-spoqz:20190207201829j:plain

「証明書(有効)」をクリックすると詳細を確認が可能です。以下の画面を見ると「COMODO RSA DOmain Validation Secure Server CA」という中間認証局がhatenablog.comに対して証明書を発行していることがわかります。

f:id:light-spoqz:20190207202213j:plain

「証明のパス」タブをクリックすると中間認証局の他に「COMODO SECURE™」というルート証明書も確認できます。

f:id:light-spoqz:20190207202419j:plain

「詳細」タブをクリックすると詳細な情報を確認することが可能です。証明書を発行したあとに確認することは以下が主になります。

①有効期間の終了

短すぎると運用に支障をきたします。認証局が発行する際に指定する期限となるため、自己認証局で発行する際に注意する点となります。

f:id:light-spoqz:20190207204230j:plain

サブジェクト

CSRを作成する際に記載した内容が記載されてます。自身の申請内容があっていることを確認します。

f:id:light-spoqz:20190207204226j:plain

サブジェクト代替名

SAN(Subject Alternative Name)とは証明書の拡張領域を指します。SSLサーバ証明書内の「SAN」領域にFQDNを設定できるようになり、1枚の証明書で複数のウェブサイトの暗号化通信を実現することが可能になります。

この領域は元々重要ではなかったのですが、Google Chrome はバージョン58からSSLの検証を行う際にCN(Common Name)ではなくSANを使用することになった頃から、この領域がほぼ必須となりました。

f:id:light-spoqz:20190207204233j:plain

 

 

3.自己認証局とは

自己認証局とは外部の証明機関を使用しないで、自組織内に認証局を作成して証明書を発行した場合を指します。この場合、イントラネット内でのクライアントがイントラネット内サーバに対してHTTPS通信やFTPSなどの通信を行う場合に行います。

メリットとしては証明書を購入するためのコストが浮くことです。デメリットとしてはクライアント端末側にルート証明書のインポートが必要となってしまうことかと思います。

f:id:light-spoqz:20190203155054j:plain

①対象のサーバでCSRの発行を行います。

②発行したCSRを中間認証局に送信します。

③中間認証局で本内容から証明書を生成します。

④中間認証局は生成した証明書を依頼組織に対して返送します。

 

 基本的なフローは同一です。ただし、ルート認証局が存在しないという点が大きいです。

4.ルート認証局と自己認証局の違い

しなぜ組織は自己証明書にて認証をわないのでしょうか。コストもあまりかからないで発行できる証明書がベストでは無いのでしょうか。

その説明のためにはルート証明書を理解する必要があります。クライアント端末(WindowsMac)にはルート証明書というものがインストールされています。

クライアントはルート証明書を元にアクセス先のサーバ証明書を検証し、自身の持っているルート証明書と比較することで信頼できると判断してます。

その場合、自己認証局が署名したサーバ証明書は正しいとクライアントは判断するのでしょうか。その場合、信頼できないサイトとして表示されます。

もし、全世界のクライアントにエラーなくページを表示させたい場合はルート証明書を全世界に配布する必要があります。逆に言えば世界中のクライアントが信頼している認証局がルート認証局となります。インターネット公開向けの証明書はきちんと外部の認証局に発行を依頼しましょう。

ルート証明書Windows OSだとWindows Updateなどで適宜配信されます。

インストールされているルート証明書は以下の手順で確認できます。(IEによる例となります。)

IEのツールをクリックします。

f:id:light-spoqz:20190203155938j:plain

 

②インタネットオプションをクリックします。

f:id:light-spoqz:20190203160131j:plain

 

③コンテンツをクリックし、証明書をクリックします。

f:id:light-spoqz:20190203160144j:plain

 

④信頼されたルート証明機関をクリックすると信頼されたルート認証局が表示されます。

f:id:light-spoqz:20190203160152j:plain

 

 

5.まとめ

  • 認証局は上位の認証機関から信頼できる認証機関から認証を受けることにより、信頼できるものとされる。
  • 証明書には外部の認証局から発行された証明書と自身を認証局として発行した自己証明書の二種類がある。
  • 自己認証局により証明書を発行した場合はクライアントにルート証明書を発行することが必要である。

 6.おまけ

6.1.世界のルート認証局のシェア

SSLèªè¨¼å±ã·ã§ã¢æ¨ç§» 2015å¹´4æ1æ¥ã2018å¹´3æ22æ¥ - è³æ: Q-Successæä¾

SSL/TLSについて① SSL/TLS通信の概要 - インフラエンジニア勉強雑記

SSL/TLSについて② SSLの通信フロー - インフラエンジニア勉強雑記

SSL/TLSについて③ 証明書とは - インフラエンジニア勉強雑記

SSL/TLSについて④ 証明書の発行方法、ルート証明書のインポート方法 - インフラエンジニア勉強雑記

SSL/TLSについて⑤ SSLの終端機器 - インフラエンジニア勉強雑記

SSL/TLSについて⑥ SSLハンドシェイク - インフラエンジニア勉強雑記