blog.monophile.net

コンピュータのこととかのメモ。

山本 一彰 | Takaaki Yamamoto

山本一彰(Takaaki Yamamoto)

東京工業大学において計算機科学と応用数学を学び、 情報科学芸術大学院大学[IAMAS]においてメディア表現を専攻し修了。 2015年にコンビネータ論理を基に計算完備な計算手法 "論理珠算"を開発し、 それを含む体系である"算道"を構成した。 その成果により、2016年に 第19回 文化庁メディア芸術祭 アート部門 新人賞 (文部科学大臣賞) を受賞。 現在はSRE(サイト信頼性エンジニア)として生計をたててている。

技術

Configuration Management Terraform, Ansible, Cloud-Init
Cloud Platform GCP, AWS, Azure, OpenStack
Virtualization, Container QEMU+KVM, Proxmox, Xen, LXD/LXC, Docker, Kata, systemd-nspawn
OS, Distribution Debian GNU/Linux, Ubuntu, CentOS, FreeBSD, macOS, ...
Storage Ceph, GlusterFS, ZFS, Btrfs, ...
Router Linux+Netfilter, Quagga, FRR, VyOS, Cisco IOS, YAMAHA RTX, ...
Switch Dell FTOS, AlaxalA, NETGEAR, ...
SQL MySQL, MariaDB(Galera Cluster), PostgreSQL, BigQuery, ...
NoSQL Elasticsearch, InfluxDB, etcd, MongoDB, ...
WebApps WordPress, GitLab, Redmine, ...
Monitoring Grafana, Prometheus, Nagios, Munin, Zabbix
DNS CoreDNS, dnsmasq, Unbound, BIND9, ...
Misc Kubernetes/Istio, certbot, HAProxy, ...

自称はネットワークエンジニアだが、 Linuxのネットワークと仮想化技術が得意なため、 サーバエンジニアの雰囲気のほうが強いかもしれない。

習得中

Virtualization, Container, OS VirtIO GPU, okd, CDH, CoreOS, ...
Network mVPN, Calico, IoT(6LoWPAN, LoRaWAN), ...
NoSQL BigTable, HBase, OpenTSDB, Redis, ...
Misc Test Engineering, Android Apps, ...

大きな領域では、セキュリティを考慮した複数パブリッククラウドの相互運用に興味がある。

投稿

AWSをGCPのサービスアカウントで認証して利用する

概要

GCPのサービスアカウントのトークンを用いて認証し、AWSの機能を利用してみた。

背景

AWSをAWSの外から利用するには、IAM User とそれに付随する IAM Credential を発行して認証することが簡単かと思われる。 しかしながら、IAM Credentialは共通パスワードのようなものなので、 セキュリティ的にリスクが高く、なるべく用いることは避けたい。

今回、GCPのサービスアカウントを経由して認証することを試みた。 この方式であれば、GCP内のメタデータサーバからの一時的なトークンによる認証、 もしくは個人のGoogleアカウントによる認証を用いることができる。 したがって、共通パスワードのような性質のものを排除することができ、 セキュリティリスク (e.g. クレデンシャルの漏洩) や 運用のコスト (e.g. 鍵のローテーション) を低減することできる。

目標

今回は個人に紐づく Googleアカウント から Googleのサービスアカウント (以下、GSAとする) の一時トークンを生成し、AWSのトークンを取得し、 awsコマンドを実行する、ということを試みる。 (GCPのメタデータサーバを用いる場合でもほぼ同じフローで導入できる。)

Google サービスアカウント(GSA)の準備

GSA aws-user を作成する

GSAに対して iam.serviceAccountsTokenCreator のロールを Google アカウントに付与する

AWS Web Identity Federationの設定を行う

OIDC プロバイダ accounts.google.com の jwks 配信サーバのTLS証明書のfingerprintを取得する

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html

下記の内容は上記のAWSドキュメントに記載されている内容である。

↑のようにして account.google.com の jwks 配信サーバのURL↓を取得する。

https://www.googleapis.com/oauth2/v3/certs

エンドポイントは https://www.googleapis.com であることがわかったので、 このhttpsサーバで用いられている証明書のfingerprintを確認する。

↑を実行すると↓のような文字列が確認できるが、www.googleapis.com は中間認証局 GTS CA 1O1 とルート認証局 GlobalSign によって署名されていることがわかる。

depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = upload.video.google.com
verify return:1

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html

複数の証明書が表示される場合は、表示される最後 (コマンド出力の最後) の証明書を見つけます。

今回は中間認証局 GTS CA 1O1 の証明書が最後に出力されていることから、 中間認証局 GTS CA 1O1 の証明書のfingerprintをAWS側に登録する。

depth=0

-----BEGIN CERTIFICATE-----
MIIGVDCCBTygAwIBAgIRAMOFqvhu2qDOBQAAAACHvBYwDQYJKoZIhvcNAQELBQAw
QjELMAkGA1UEBhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczET
MBEGA1UEAxMKR1RTIENBIDFPMTAeFw0yMTA0MTMxMDE2MDdaFw0yMTA3MDYxMDE2
MDZaMHExCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQH
Ew1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgTExDMSAwHgYDVQQDExd1
cGxvYWQudmlkZW8uZ29vZ2xlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IA
BGMcGq3tTfwQRLn3HLmu9swf8XqLf3FfG0TbAGeXdssiOuN8nPkK5Ori+fYemhjq
EyEH2Xn27KZKMc7Tz06TDqCjggPfMIID2zAOBgNVHQ8BAf8EBAMCB4AwEwYDVR0l
BAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUNyC3kUnyEuo2
WGSsJ1FQ5Yf12FUwHwYDVR0jBBgwFoAUmNH4bhDrz5vsYJ8YkBug630J/SswaAYI
KwYBBQUHAQEEXDBaMCsGCCsGAQUFBzABhh9odHRwOi8vb2NzcC5wa2kuZ29vZy9n
dHMxbzFjb3JlMCsGCCsGAQUFBzAChh9odHRwOi8vcGtpLmdvb2cvZ3NyMi9HVFMx
TzEuY3J0MIIBmAYDVR0RBIIBjzCCAYuCF3VwbG9hZC52aWRlby5nb29nbGUuY29t
ghQqLmNsaWVudHMuZ29vZ2xlLmNvbYIRKi5kb2NzLmdvb2dsZS5jb22CEiouZHJp
dmUuZ29vZ2xlLmNvbYITKi5nZGF0YS55b3V0dWJlLmNvbYIQKi5nb29nbGVhcGlz
LmNvbYITKi5waG90b3MuZ29vZ2xlLmNvbYITKi51cGxvYWQuZ29vZ2xlLmNvbYIU
Ki51cGxvYWQueW91dHViZS5jb22CFyoueW91dHViZS0zcmQtcGFydHkuY29tghti
Zy1jYWxsLWRvbmF0aW9uLWFscGhhLmdvb2eCHGJnLWNhbGwtZG9uYXRpb24tY2Fu
YXJ5Lmdvb2eCGWJnLWNhbGwtZG9uYXRpb24tZGV2Lmdvb2eCFWJnLWNhbGwtZG9u
YXRpb24uZ29vZ4IRdXBsb2FkLmdvb2dsZS5jb22CEnVwbG9hZC55b3V0dWJlLmNv
bYIfdXBsb2Fkcy5zdGFnZS5nZGF0YS55b3V0dWJlLmNvbTAhBgNVHSAEGjAYMAgG
BmeBDAECAjAMBgorBgEEAdZ5AgUDMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwucGtpLmdvb2cvR1RTMU8xY29yZS5jcmwwggEGBgorBgEEAdZ5AgQCBIH3BIH0
APIAdwD2XJQv0XcwIhRUGAgwlFaO400TGTO/3wwvIAvMTvFk4wAAAXjK8hsOAAAE
AwBIMEYCIQCavqW8CdwK7hXvDYsaAorTCQqKYz26MfnyMXv8q2WfQQIhAOH2M4fa
VTz4yOUQ86RdmRIRaLCKTCvHcJ74ufdC264BAHcARJRlLrDuzq/EQAfYqP4owNrm
gr7YyzG1P9MzlrW2gagAAAF4yvIbSAAABAMASDBGAiEA5AuJL4jq01XnkwWUa4v+
eTkZDcsn9fRGRwPp/2+N+2ECIQDI8SEiaM1lwEAMvEjCudSVhhAsspRsZsf8wKOI
Geh68DANBgkqhkiG9w0BAQsFAAOCAQEAarNIFB1qGp3V96Y7oVADfwhPEGXCszY4
TkhJ9sNb2LWi1o0LzZMR9a/rfyfb8Q6eaP0+2ObY8xlQLNXrXJ+eOXnwTxqq99tT
9/7mEXXr72Fyaag8/uQTm3cNJGPX+XabQRt7r3VzgMtVowWdxcNFoCWTDQUXkloP
Bbap0YsrJy4wcAQqKUihjVVxez0oT5HejbhNamjUMYccQj3MO5akFW5/v8RNBKWM
nWAX5pxKf1qH8nwo6q/2lFKny879Lvv1Knru0P3XI9X+bnuTFxQuANVVf5AiEEJx
H8DdtkxrjS5u5vpSeciULGmfoGkS6weamvG75a/2Xi3kYYpOh68dAg==
-----END CERTIFICATE-----

depth=1

-----BEGIN CERTIFICATE-----
MIIESjCCAzKgAwIBAgINAeO0mqGNiqmBJWlQuDANBgkqhkiG9w0BAQsFADBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFs
U2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjAeFw0xNzA2MTUwMDAwNDJaFw0yMTEy
MTUwMDAwNDJaMEIxCzAJBgNVBAYTAlVTMR4wHAYDVQQKExVHb29nbGUgVHJ1c3Qg
U2VydmljZXMxEzARBgNVBAMTCkdUUyBDQSAxTzEwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDQGM9F1IvN05zkQO9+tN1pIRvJzzyOTHW5DzEZhD2ePCnv
UA0Qk28FgICfKqC9EksC4T2fWBYk/jCfC3R3VZMdS/dN4ZKCEPZRrAzDsiKUDzRr
mBBJ5wudgzndIMYcLe/RGGFl5yODIKgjEv/SJH/UL+dEaltN11BmsK+eQmMF++Ac
xGNhr59qM/9il71I2dN8FGfcddwuaej4bXhp0LcQBbjxMcI7JP0aM3T4I+DsaxmK
FsbjzaTNC9uzpFlgOIg7rR25xoynUxv8vNmkq7zdPGHXkxWY7oG9j+JkRyBABk7X
rJfoucBZEqFJJSPk7XA0LKW0Y3z5oz2D0c1tJKwHAgMBAAGjggEzMIIBLzAOBgNV
HQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFJjR+G4Q68+b7GCfGJAboOt9Cf0rMB8G
A1UdIwQYMBaAFJviB1dnHB7AagbeWbSaLd/cGYYuMDUGCCsGAQUFBwEBBCkwJzAl
BggrBgEFBQcwAYYZaHR0cDovL29jc3AucGtpLmdvb2cvZ3NyMjAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnBraS5nb29nL2dzcjIvZ3NyMi5jcmwwPwYDVR0g
BDgwNjA0BgZngQwBAgIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly9wa2kuZ29vZy9y
ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAGoA+Nnn78y6pRjd9XlQWNa7H
TgiZ/r3RNGkmUmYHPQq6Scti9PEajvwRT2iWTHQr02fesqOqBY2ETUwgZQ+lltoN
FvhsO9tvBCOIazpswWC9aJ9xju4tWDQH8NVU6YZZ/XteDSGU9YzJqPjY8q3MDxrz
mqepBCf5o8mw/wJ4a2G6xzUr6Fb6T8McDO22PLRL6u3M4Tzs3A2M1j6bykJYi8wW
IRdAvKLWZu/axBVbzYmqmwkm5zLSDW5nIAJbELCQCZwMH56t2Dvqofxs6BBcCFIZ
USpxu6x6td0V7SvJCCosirSmIatj/9dSSVDQibet8q/7UK4v4ZUN80atnZz1yg==
-----END CERTIFICATE-----

中間認証局の証明書を /tmp/depth_1.pem として保存する。

↑のopensslコマンドでfingerprint↓を得る。

SHA1 Fingerprint=DF:E2:07:0C:79:E7:FF:36:A9:25:FF:A3:27:FF:E3:DE:EC:F8:F9:C2

実際に利用する値はコロンを除いた小文字になるため、↑で加工した値 ↓ を利用する。

dfe2070c79e7ff36a925ffa327ffe3deecf8f9c2

OIDC プロバイダ accounts.google.com の作成

前項で得たfingerprintを用いて OIDC プロバイダ accounts.google.com を作成する。

サービスアカウントのUniqueIDをIdentity Proversのaudienceに追加する

AssumeRoleするためのIAM ロールを作成する

gsa-aws-user.json

GSAのトークンを用いてawsコマンドを実行できるようにする

https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-sourcing-external.html

.aws/config の credential_process という仕組みを用い、 GSAのトークンからAWSの認証情報を作成するための設定を行う。

gsa-oidc.sh を配置する

下記の gsa-oidc.sh を PATH が通っている場所に配置する。

実行権限を付与しておく。

aws-user という名前で gcloud の configuration を作成する

.aws/config で gsa-oidc.sh を用いて認証情報を得る設定をする

[profile gsa-oidc]
output = json

[profile gsa-aws-user]
credential_process = gsa-oidc.sh aws-user aws-user@{{ google_project_id }}.iam.gserviceaccount.com {{ aws_account_id }} gsa-aws-user

実行する

↑を実行すると↓のような出力を得られる。

これでAssumeRoleをGSAの認証情報を用いて行えることがわかった。

あとはロール aws-user に適切なポリシーを付与すれば、各種AWSの機能を使えるようになる。

補足

中間認証局 GTS CA 1O1 の証明書の情報を確認する。

openssl x509 -text <<_EOS_
-----BEGIN CERTIFICATE-----
MIIESjCCAzKgAwIBAgINAeO0mqGNiqmBJWlQuDANBgkqhkiG9w0BAQsFADBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFs
U2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjAeFw0xNzA2MTUwMDAwNDJaFw0yMTEy
MTUwMDAwNDJaMEIxCzAJBgNVBAYTAlVTMR4wHAYDVQQKExVHb29nbGUgVHJ1c3Qg
U2VydmljZXMxEzARBgNVBAMTCkdUUyBDQSAxTzEwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDQGM9F1IvN05zkQO9+tN1pIRvJzzyOTHW5DzEZhD2ePCnv
UA0Qk28FgICfKqC9EksC4T2fWBYk/jCfC3R3VZMdS/dN4ZKCEPZRrAzDsiKUDzRr
mBBJ5wudgzndIMYcLe/RGGFl5yODIKgjEv/SJH/UL+dEaltN11BmsK+eQmMF++Ac
xGNhr59qM/9il71I2dN8FGfcddwuaej4bXhp0LcQBbjxMcI7JP0aM3T4I+DsaxmK
FsbjzaTNC9uzpFlgOIg7rR25xoynUxv8vNmkq7zdPGHXkxWY7oG9j+JkRyBABk7X
rJfoucBZEqFJJSPk7XA0LKW0Y3z5oz2D0c1tJKwHAgMBAAGjggEzMIIBLzAOBgNV
HQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFJjR+G4Q68+b7GCfGJAboOt9Cf0rMB8G
A1UdIwQYMBaAFJviB1dnHB7AagbeWbSaLd/cGYYuMDUGCCsGAQUFBwEBBCkwJzAl
BggrBgEFBQcwAYYZaHR0cDovL29jc3AucGtpLmdvb2cvZ3NyMjAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnBraS5nb29nL2dzcjIvZ3NyMi5jcmwwPwYDVR0g
BDgwNjA0BgZngQwBAgIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly9wa2kuZ29vZy9y
ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAGoA+Nnn78y6pRjd9XlQWNa7H
TgiZ/r3RNGkmUmYHPQq6Scti9PEajvwRT2iWTHQr02fesqOqBY2ETUwgZQ+lltoN
FvhsO9tvBCOIazpswWC9aJ9xju4tWDQH8NVU6YZZ/XteDSGU9YzJqPjY8q3MDxrz
mqepBCf5o8mw/wJ4a2G6xzUr6Fb6T8McDO22PLRL6u3M4Tzs3A2M1j6bykJYi8wW
IRdAvKLWZu/axBVbzYmqmwkm5zLSDW5nIAJbELCQCZwMH56t2Dvqofxs6BBcCFIZ
USpxu6x6td0V7SvJCCosirSmIatj/9dSSVDQibet8q/7UK4v4ZUN80atnZz1yg==
-----END CERTIFICATE-----
_EOS_

↑を行うと↓のような出力を得られる。

  :
Validity
    Not Before: Jun 15 00:00:42 2017 GMT
    Not After : Dec 15 00:00:42 2021 GMT
  :

中間認証局の証明書が2021/12/15に失効するため、 中間認証局の証明書のfingerprintを更新する仕組みが必要になる。

参考URL

Docker Hubのレート制限を受けないように mirror.gcr.io を使う

概要

Docker Hub のレート制限 が2020/11/01から施行されるようになったらしい。

  • Free plan – anonymous users: 100 pulls per 6 hours
  • Free plan – authenticated users: 200 pulls per 6 hours
  • Pro plan – unlimited
  • Team plan – unlimited

レート制限はダウンロードする側のパブリックIPアドレスベースでかかるようなので、 同一のIPを使いまわしているオフィスなどでは致命的な状況になることが想像できる。 その制限を回避する方法の一つを紹介する。

回避方法

下記のような対応方法が考えられる。

  • Docker Hubの有料プランを契約し、各サーバもしくは手元の開発環境で認証情報を利用してダウンロードする。
  • 自前でコンテナイメージレジストリをホスティングし、そこを参照するように構成する。
  • ダウンロード元のパブリックIPを分散するために、プロキシを自前で構成する。
  • ミラーレポジトリ mirror.gcr.io を利用する。

それぞれにメリットとデメリットが存在するが、今回は追加の金銭的コストが発生しない 「ミラーレポジトリ mirror.gcr.io を利用する」 方法を紹介する。

この方法には他にもメリットがあり、 既存のアプリケーション周辺の設定(Dockerfile, CI/CD設定) を変更することなく、 Dockerを実行する環境(サーバ, 手元の開発環境)の設定だけを変えれば対応できるため、 比較的簡単に導入できると思っている。

ミラーリポジトリ mirror.gcr.io を利用するための設定

Linux(Ubuntu) の場合

/etc/docker/daemon.json に mirror.gcr.io を使うような設定を行い、 docker デーモンを再起動すればよい。

/etc/docker/daemon.json

上記のファイルを編集した上で、docker デーモンを再起動する。

Docker for Mac の場合

macOSの場合も基本的には上述のLinux(Ubuntu)と同じ。 macの画面の上部のツールバーに表示されているDocker(クジラ)のアイコンをクリックし、 PreferenceDocker Engine と辿り、 下図のように "registry-mirrors": ["https://mirror.gcr.io"] を追加し、 Apply & Restart を行えば良い。

Docker for Mac設定画面
Docker for Mac設定画面

確認方法

実際に mirror.gcr.io 経由でダウンロードが行われているかどうかは ↑のコマンドを打った状態で、別のターミナルで↓を打つ。

このとき、パケットが表示されれば mirror.gcr.io を利用していることを示している。

参考

systoolでカーネルモジュールのパラメータを確認する

概要

カーネルモジュールのパラーメータを確認したかったので、systoolを使ってみた。 sysfsの走査がめんどくさい場合によさそう。

install

カーネルモジュールのパラメータを確認する

loopモジュールの場合

sysfsでも同様のことを確認できる。

vhostモジュールの場合

vhostのmax_mem_regionsの値を変えるには、 /etc/modprobe.d/vhost.confを下記のように用意して、 カーネルモジュールのリロードを行えばよい。

/etc/modprobe.d/vhost.conf

options vhost max_mem_regions=512

余談だが、この値を変更しないと仮想マシンにメモリを64枚以上挿せなかった。

参考

QCOW2の中身を編集する

概要

QCOW2形式のイメージを編集する方法のメモ。 今回は例として、下記のCentOSイメージを利用した。

guestfishを使う

QCOW2のイメージを編集するにはguestfishを使えば良いので、↓でインストールする。

そして、編集したいQCOW2のイメージを指定してguestfishを立ち上げると、 guestfish用のシェルが起動するので、その中でコマンドを打つ。

手順は、パーティションを見つけて、マウントし、編集して、終了するだけ。

editコマンドで、環境変数EDITORで指定したエディタによってファイルを編集でき、 catコマンドで変更されたことが確認できた。

また、オプション-iをつけると、自動的にファイルシステムがマウントされるので、 下記のようにしてワンライナで編集することも可能。

参考

OpenSSLで証明書の順番を確認してみる

概要

普段使っているTLS証明書は大抵の場合で中間認証局によって発行されているので、 サーバに設定する証明書は証明書+中間証明書の組み合わせになっていると思うが、 くっつける順番がいつもわからなくなるので、正しく設定できているか不安になる。 そこで、確認する方法を調べてみた。

稼働しているWebサーバの場合

稼働しているWebサーバ (blog.monophile.net) の証明書を確認する場合は↓のようにすれば良い。 (サーバと言いつつも、このブログは CloudFront+S3で動いていて、 さらにAWS CertificateManagerを使っているので、証明書の確認をする必要はほぼない。)

↑を行うと↓が出力される。 ※ 後の説明のために行番号も付与している。

 1  subject=/CN=*.monophile.net
 2  issuer=/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
 3
 4  subject=/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
 5  issuer=/C=US/O=Amazon/CN=Amazon Root CA 1
 6
 7  subject=/C=US/O=Amazon/CN=Amazon Root CA 1
 8  issuer=/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
 9
10  subject=/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
11  issuer=/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
12

1行目のsubjectを2行目のissuerが証明していて、 4行目のsubjectを5行目のissuerが証明していて、 7行目のsubjectを8行目のissuerが証明していて、 10行目のsubjectを11行目のissuerが証明していることがわかる。

Let’s Encrypt の場合

Let’s Encryptで取得した証明書の場合は fullchain.pem を入力にすればよい。

subject=/CN=example.net
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
issuer=/O=Digital Signature Trust Co./CN=DST Root CA X3

参考