証明書を使用した暗号化
概要
Zabbix は、公開の証明機関 (CA) または社内の証明機関 (CA) によって署名された、PEM 形式の RSA 証明書を使用できます。
証明書の検証は、事前に設定された CA 証明書に対して行われます。 必要に応じて、証明書失効リスト (CRL) を使用できます。
各 Zabbix コンポーネントに設定できる証明書は 1 つだけです。
内部 CA のセットアップと運用、証明書要求の生成と署名、証明書の失効については、OpenSSL PKI Tutorial v2.0 などのチュートリアルを参照してください。
証明書拡張は慎重に検討し、テストしてください。 詳細については、X.509 v3 証明書拡張の使用に関する制限 を参照してください。
証明書設定パラメータ
以下の設定パラメータは、Zabbixコンポーネントで証明書を設定するためにサポートされています。
| Parameter | Mandatory | Description |
|---|---|---|
| TLSCAFile | yes | ピア証明書の検証に使用する最上位CA証明書を含むファイルの完全なパス名。 複数のメンバーを持つ証明書チェーンを使用する場合は、下位レベルのCA証明書を先に、その後に上位レベルのCA証明書を配置してください。 複数のCAの証明書を1つのファイルに含めることができます。 |
| TLSCRLFile | no | 証明書失効リスト (CRL) を含むファイルの完全なパス名。 |
| TLSCertFile | yes | 証明書を含むファイルの完全なパス名。 複数のメンバーを持つ証明書チェーンを使用する場合は、サーバー、プロキシ、またはエージェントの証明書を先頭に置き、その後に下位レベルのCA証明書、最後に上位レベルのCA証明書を配置してください。 |
| TLSKeyFile | yes | 秘密鍵を含むファイルの完全なパス名。 このファイルは、適切なアクセス権を設定し、Zabbixユーザー のみが読み取れるようにしてください。 |
| TLSServerCertIssuer | no | 許可されるサーバー証明書の発行者。 |
| TLSServerCertSubject | no | 許可されるサーバー証明書のサブジェクト。 |
設定例
必要な証明書を設定したら、Zabbixコンポーネントが証明書ベースの暗号化を使用するように設定します。
以下に、設定手順の詳細を示します。
Zabbixサーバー
1. CA証明書ファイルを準備します。
ピア証明書を検証するには、Zabbixサーバーが最上位の自己署名ルートCA証明書を含むファイルにアクセスできる必要があります。
たとえば、2つの独立したルートCAの証明書が必要な場合は、これらを /home/zabbix/zabbix_ca_file.crt のファイルに配置します。
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root1 CA
...
Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root1 CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
...
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
...
-----BEGIN CERTIFICATE-----
MIID2jCCAsKgAwIBAgIBATANBgkqhkiG9w0BAQUFADB+MRMwEQYKCZImiZPyLGQB
....
9wEzdN8uTrqoyU78gi12npLj08LegRKjb5hFTVmO
-----END CERTIFICATE-----
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root2 CA
...
Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root2 CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
....
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
....
-----BEGIN CERTIFICATE-----
MIID3DCCAsSgAwIBAgIBATANBgkqhkiG9w0BAQUFADB/MRMwEQYKCZImiZPyLGQB
...
vdGNYoSfvu41GQAR5Vj5FnRJRzv5XQOZ3B6894GY1zY=
-----END CERTIFICATE-----
2. Zabbixサーバーの証明書/証明書チェーンを、たとえば /home/zabbix/zabbix_server.crt のファイルに配置します。
最初の証明書がZabbixサーバー証明書で、その後に中間CA証明書が続きます。
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Signing CA
...
Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Zabbix server
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
...
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Basic Constraints:
CA:FALSE
...
-----BEGIN CERTIFICATE-----
MIIECDCCAvCgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBgTETMBEGCgmSJomT8ixk
...
h02u1GHiy46GI+xfR3LsPwFKlkTaaLaL/6aaoQ==
-----END CERTIFICATE-----
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha1WithRSAEncryption
Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root1 CA
...
Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Signing CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
...
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
...
-----BEGIN CERTIFICATE-----
MIID4TCCAsmgAwIBAgIBAjANBgkqhkiG9w0BAQUFADB+MRMwEQYKCZImiZPyLGQB
...
dyCeWnvL7u5sd6ffo8iRny0QzbHKmQt/wUtcVIvWXdMIFJM0Hw==
-----END CERTIFICATE-----
上記で言及した属性のみをクライアント証明書とサーバー証明書の両方に使用してください。これにより、証明書の検証プロセスへの影響を避けられます。
たとえば、X509v3 Subject Alternative Name や Netscape Cert Type 拡張が使用されていると、OpenSSL が暗号化接続の確立に失敗する場合があります。
詳細については、X.509 v3証明書拡張の使用に関する制限 を参照してください。
3. Zabbixサーバーの秘密鍵を、たとえば /home/zabbix/zabbix_server.key のファイルに配置します。
-----BEGIN PRIVATE KEY-----
MIIEwAIBADANBgkqhkiG9w0BAQEFAASCBKowggSmAgEAAoIBAQC9tIXIJoVnNXDl
...
IJLkhbybBYEf47MLhffWa7XvZTY=
-----END PRIVATE KEY-----
4. Zabbixサーバー設定ファイル のTLS設定パラメータを編集します。
TLSCAFile=/home/zabbix/zabbix_ca_file.crt
TLSCertFile=/home/zabbix/zabbix_server.crt
TLSKeyFile=/home/zabbix/zabbix_server.key
Zabbixプロキシ
1. トップレベルのCA証明書、Zabbixプロキシの証明書/証明書チェーン、および秘密鍵を、Zabbixサーバーのセクションで説明されているとおりに準備します。
次に、Zabbixプロキシ設定ファイルの TLSCAFile、TLSCertFile、TLSKeyFile パラメータをそれぞれ編集します。
2. Zabbixプロキシ設定ファイルで追加のTLSパラメータを編集します。
- アクティブプロキシの場合:
TLSConnect=cert - パッシブプロキシの場合:
TLSAccept=cert
プロキシのセキュリティを向上させるために、TLSServerCertIssuer および TLSServerCertSubject パラメータを設定することもできます。
詳細は、許可される証明書の発行者とサブジェクトの制限を参照してください。
最終的なプロキシ設定ファイルのTLSパラメータは、次のようになります。
TLSConnect=cert
TLSAccept=cert
TLSCAFile=/home/zabbix/zabbix_ca_file.crt
TLSServerCertIssuer=CN=Signing CA,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSServerCertSubject=CN=Zabbix server,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSCertFile=/home/zabbix/zabbix_proxy.crt
TLSKeyFile=/home/zabbix/zabbix_proxy.key
3. Zabbix Webインターフェースでこのプロキシの暗号化を設定します。
- 次へ移動します: Administration > Proxies。
- プロキシを選択し、Encryption タブをクリックします。
以下の例では、Issuer と Subject フィールドに値が入力されています。
これらのフィールドを使用する理由と方法については、許可される証明書の発行者とサブジェクトの制限を参照してください。
アクティブプロキシの場合:

パッシブプロキシの場合:

Zabbix エージェント
1. トップレベル CA 証明書、Zabbix エージェントの証明書/証明書チェーン、および秘密鍵を、Zabbix サーバー セクションの説明に従って用意します。
次に、Zabbix エージェント設定ファイル の TLSCAFile、TLSCertFile、TLSKeyFile パラメータをそれぞれ編集します。
2. Zabbix エージェント設定ファイル で追加の TLS パラメータを編集します。
- アクティブ エージェントの場合:
TLSConnect=cert - パッシブ エージェントの場合:
TLSAccept=cert
エージェントのセキュリティを向上させるには、TLSServerCertIssuer および TLSServerCertSubject パラメータを設定できます。
詳細は、許可される証明書の発行者とサブジェクトの制限 を参照してください。
最終的なエージェント設定ファイルの TLS パラメータは、次のようになります。
この例では、ホストはプロキシによって監視されているため、証明書の Subject として指定されています。
TLSConnect=cert
TLSAccept=cert
TLSCAFile=/home/zabbix/zabbix_ca_file.crt
TLSServerCertIssuer=CN=Signing CA,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSServerCertSubject=CN=Zabbix proxy,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSCertFile=/home/zabbix/zabbix_agentd.crt
TLSKeyFile=/home/zabbix/zabbix_agentd.key
3. このエージェントによって監視されるホストの Zabbix Webインターフェースで暗号化を設定します。
- 次へ移動します: Data collection > Hosts。
- ホストを選択し、Encryption タブをクリックします。
以下の例では、Issuer と Subject フィールドが入力されています。
これらのフィールドを使用する理由と方法については、許可される証明書の発行者とサブジェクトの制限 を参照してください。

Zabbix web service
1. トップレベルの CA 証明書、Zabbix web service の証明書/証明書チェーン、および秘密鍵を含むファイルを、Zabbix server セクションの説明に従って準備します。
その後、Zabbix web service 設定ファイル の TLSCAFile、TLSCertFile、TLSKeyFile パラメータをそれぞれ編集します。
2. Zabbix web service 設定ファイル で、追加の TLS パラメータ TLSAccept=cert を編集します。
最終的な web service 設定ファイル内の TLS パラメータは、次のようになります。
TLSAccept=cert
TLSCAFile=/home/zabbix/zabbix_ca_file.crt
TLSCertFile=/home/zabbix/zabbix_web_service.crt
TLSKeyFile=/home/zabbix/zabbix_web_service.key
3. Zabbix server 設定ファイル の WebServiceURL パラメータを編集し、TLS が設定された Zabbix web service に接続するよう Zabbix server を設定します。
WebServiceURL=https://example.com:443/report
許可する証明書の発行者とサブジェクトの制限
2つの Zabbix コンポーネント(たとえば、サーバーとエージェント)が TLS 接続を確立すると、互いの証明書を検証します。
相手側の証明書が信頼された CA によって署名されており(TLSCAFile に事前設定された最上位証明書を使用)、有効で、期限切れではなく、その他のチェックにも合格した場合、コンポーネント間の通信を続行できます。
この最も単純なケースでは、証明書の発行者とサブジェクトは検証されません。
ただし、これにはリスクがあります。つまり、有効な証明書を持つ誰でも他人になりすませる可能性があります(たとえば、ホスト証明書をサーバーになりすますために使用できる)。
これは、証明書が専用の社内 CA によって署名され、なりすましのリスクが低い小規模な環境では許容できるかもしれませんが、より大規模な環境やセキュリティ要件の高い環境では十分ではない場合があります。
最上位 CA が Zabbix で受け入れるべきではない証明書を発行する場合、またはなりすましのリスクを減らしたい場合は、発行者とサブジェクトを指定して許可する証明書を制限できます。
たとえば、Zabbix プロキシの設定ファイルでは、次のように指定できます。
TLSServerCertIssuer=CN=Signing CA,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSServerCertSubject=CN=Zabbix server,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
これらの設定を行うと、アクティブプロキシは、証明書の発行者またはサブジェクトが異なる Zabbix サーバーとは通信しません。
同様に、パッシブプロキシはそのようなサーバーからの要求を受け入れません。
Issuer と Subject 文字列の照合ルール
Issuer と Subject 文字列の照合ルールは次のとおりです。
IssuerとSubjectの文字列は個別にチェックされます。 どちらも省略可能です。- 指定されていない文字列は、任意の文字列が受け入れられることを意味します。
- 文字列は そのまま 比較され、完全一致する必要があります。
- UTF-8 文字がサポートされています。
ただし、ワイルドカード (
*) や正規表現はサポートされていません。 - 次の RFC 4514 の要件が実装されています。エスケープが必要な文字は、('
\' バックスラッシュ、U+005C) を使用してエスケープします。- 文字列のどこでも: '
"' (U+0022)、 '+' (U+002B)、 ',' (U+002C)、 ';' (U+003B)、 '<' (U+003C)、 '>' (U+003E)、 '\\' (U+005C); - 文字列の先頭: スペース (' ', U+0020) または番号記号 ('
#', U+0023); - 文字列の末尾: スペース (' ', U+0020)。
- 文字列のどこでも: '
- Null 文字 (U+0000) はサポートされていません。 Null 文字が見つかった場合、照合は失敗します。
- RFC 4517 および RFC 4518 の標準はサポートされていません。
たとえば、Issuer と Subject の組織 (O) 文字列に末尾のスペースが含まれ、Subject の組織単位 (OU) 文字列に二重引用符が含まれている場合、これらの文字はエスケープする必要があります。
TLSServerCertIssuer=CN=Signing CA,OU=Development head,O=\ Example SIA\ ,DC=example,DC=com
TLSServerCertSubject=CN=Zabbix server,OU=Development group \"5\",O=\ Example SIA\ ,DC=example,DC=com
フィールドの順序と書式
Zabbix は RFC 4514 の推奨に従っており、これらのフィールドは「逆順」で記述します。つまり、最下位レベルのフィールド (CN) から始め、中間レベルのフィールド (OU, O) を経て、最上位レベルのフィールド (DC) で終わります。
TLSServerCertIssuer=CN=Signing CA,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSServerCertSubject=CN=Zabbix proxy,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
一方、OpenSSL はデフォルトでは Issuer と Subject の文字列を上位レベルから下位レベルの順で表示します。
次の例では、Issuer と Subject フィールドは最上位レベル (DC) から始まり、最下位レベル (CN) のフィールドで終わります。
また、スペースやフィールド区切りの書式も使用するオプションによって異なるため、Zabbix が必要とする形式とは一致しません。
$ openssl x509 -noout -in /home/zabbix/zabbix_proxy.crt -issuer -subject
issuer= /DC=com/DC=zabbix/O=Zabbix SIA/OU=Development group/CN=Signing CA
subject= /DC=com/DC=zabbix/O=Zabbix SIA/OU=Development group/CN=Zabbix proxy
$ openssl x509 -noout -text -in /home/zabbix/zabbix_proxy.crt
Certificate:
...
Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Signing CA
...
Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Zabbix proxy
Issuer と Subject の文字列を Zabbix 用に正しく整形するには、OpenSSL を次のオプション付きで実行します。
$ openssl x509 -noout -issuer -subject \
-nameopt esc_2253,esc_ctrl,utf8,dump_nostr,dump_unknown,dump_der,sep_comma_plus,dn_rev,sname\
-in /home/zabbix/zabbix_proxy.crt
これにより、出力は逆順でカンマ区切りになり、Zabbix の設定ファイルおよび Webインターフェースで使用できる形式になります。
issuer=CN=Signing CA,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
subject=CN=Zabbix proxy,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
X.509 v3 証明書拡張の使用に関する制限
Zabbix で X.509 v3 証明書を実装する場合、特定の拡張は完全にはサポートされないか、動作が一貫しない可能性があります。
Subject Alternative Name 拡張
Zabbix は、IP アドレスやメールアドレスなどの代替 DNS 名を指定するために使用される Subject Alternative Name 拡張をサポートしていません。
Zabbix が検証できるのは、証明書の Subject フィールドの値のみです (許可される証明書の発行者と Subject の制限 を参照してください)。
証明書に subjectAltName フィールドが含まれている場合、証明書検証の結果は、Zabbix コンポーネントのビルドに使用された特定の暗号ツールキットによって異なる場合があります。
そのため、Zabbix はこれらの組み合わせに基づいて証明書を受け入れる場合もあれば、拒否する場合もあります。
Extended Key Usage 拡張
Zabbix は Extended Key Usage 拡張をサポートしています。
ただし、これを使用する場合は、通常、clientAuth(TLS WWW クライアント認証用)と serverAuth(TLS WWW サーバー認証用)の両方の属性を指定する必要があります。
例:
- パッシブチェックでは、Zabbix エージェントが TLS サーバーとして動作するため、エージェントの証明書に serverAuth 属性を含める必要があります。
- アクティブチェックでは、エージェントが TLS クライアントとして動作するため、エージェントの証明書に clientAuth 属性を含める必要があります。
GnuTLS はキー使用法違反に対して警告を出す場合がありますが、通常はこれらの警告があっても通信を継続できます。
Name Constraints 拡張
Name Constraints 拡張のサポートは、暗号ツールキットによって異なります。
選択したツールキットがこの拡張をサポートしていることを確認してください。
この拡張では、使用しているツールキットによっては、このセクションが critical としてマークされている場合に、Zabbix が CA 証明書を読み込めなくなることがあります。
証明書失効リスト (CRL)
証明書が侵害された場合、認証局 (CA) はその証明書を証明書失効リスト (CRL) に含めることで失効させることができます。
CRL は設定ファイルを通じて管理され、サーバー、プロキシ、およびエージェントの設定ファイルで TLSCRLFile パラメーターを使用して指定できます。
例:
TLSCRLFile=/home/zabbix/zabbix_crl_file.crt
この場合、zabbix_crl_file.crt には複数の CA の CRL を含めることができ、次のようになります:
-----BEGIN X509 CRL-----
MIIB/DCB5QIBATANBgkqhkiG9w0BAQUFADCBgTETMBEGCgmSJomT8ixkARkWA2Nv
...
treZeUPjb7LSmZ3K2hpbZN7SoOZcAoHQ3GWd9npuctg=
-----END X509 CRL-----
-----BEGIN X509 CRL-----
MIIB+TCB4gIBATANBgkqhkiG9w0BAQUFADB/MRMwEQYKCZImiZPyLGQBGRYDY29t
...
CAEebS2CND3ShBedZ8YSil59O6JvaDP61lR5lNs=
-----END X509 CRL-----
CRL ファイルは Zabbix の起動時にのみ読み込まれます。
CRL を更新するには、Zabbix を再起動してください。
Zabbix コンポーネントが OpenSSL でコンパイルされており、CRL を使用する場合は、証明書チェーン内の各最上位 CA および中間 CA に対応する CRL が TLSCRLFile に含まれていることを確認してください(空の CRL でも構いません)。
証明書の問題のトラブルシューティング
CRL とともに使用される OpenSSL で、証明書チェーン内の一部の CA の CRL が TLSCRLFile に含まれていない場合
TLS サーバーログで OpenSSL ピアの場合:
failed to accept an incoming connection: from 127.0.0.1: TLS handshake with 127.0.0.1 returned error code 1: \
file s3_srvr.c line 3251: error:14089086: SSL routines:ssl3_get_client_certificate:certificate verify failed: \
TLS write fatal alert "unknown CA"
TLS サーバーログで GnuTLS ピアの場合:
failed to accept an incoming connection: from 127.0.0.1: TLS handshake with 127.0.0.1 returned error code 1: \
file rsa_pk1.c line 103: error:0407006A: rsa routines:RSA_padding_check_PKCS1_type_1:\
block type is not 01 file rsa_eay.c line 705: error:04067072: rsa routines:RSA_EAY_PUBLIC_DECRYPT:paddin
CRLの有効期限切れ、またはサーバー稼働中に期限切れになる場合
[OpenSSL]{.underline}、サーバーログ内:
- 期限切れ前:
<!-- -->
プロキシ "proxy-openssl-1.0.1e" に接続できません: TCP は成功しましたが、[[127.0.0.1]:20004] への TLS を確立できません:\
SSL_connect() returned SSL_ERROR_SSL: file s3_clnt.c line 1253: error:14090086:\
SSL routines:ssl3_get_server_certificate:certificate verify failed:\
TLS write fatal alert "certificate revoked"
- 期限切れ後:
<!-- -->
プロキシ "proxy-openssl-1.0.1e" に接続できません: TCP は成功しましたが、[[127.0.0.1]:20004] への TLS を確立できません:\
SSL_connect() returned SSL_ERROR_SSL: file s3_clnt.c line 1253: error:14090086:\
SSL routines:ssl3_get_server_certificate:certificate verify failed:\
TLS write fatal alert "certificate expired"
ここでのポイントは、有効な CRL がある場合、失効した証明書は "certificate revoked" として報告されることです。CRL の有効期限が切れると、エラーメッセージは "certificate expired" に変わりますが、これはかなり紛らわしいです。
[GnuTLS]{.underline}、サーバーログ内:
- 期限切れ前後で同じ:
<!-- -->
プロキシ "proxy-openssl-1.0.1e" に接続できません: TCP は成功しましたが、[[127.0.0.1]:20004] への TLS を確立できません:\
invalid peer certificate: The certificate is NOT trusted. The certificate chain is revoked.
自己署名証明書、未知の CA
[OpenSSL]{.underline} のログ:
error:'self signed certificate: SSL_connect() set result code to SSL_ERROR_SSL: file ../ssl/statem/statem_clnt.c\
line 1924: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:\
TLS write fatal alert "unknown CA"'
これは、サーバー証明書が CA によって署名されているにもかかわらず、誤って Issuer と Subject の文字列が同じになっていた場合に確認されました。Issuer と Subject は最上位の CA 証明書では同じでもかまいませんが、サーバー証明書では同じにできません。(同様に、プロキシおよびエージェントの証明書にも当てはまります。)
証明書に同じ Issuer と Subject のエントリが含まれているかどうかを確認するには、次を実行します:
openssl x509 -in <yourcertificate.crt> -noout -text
ルート(最上位)証明書では、Issuer と Subject の値が同一であっても問題ありません。