証明書を使用した暗号化
概要
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. Zabbixサーバーのセクションで説明されているとおり、トップレベルCA証明書、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インターフェースで、このプロキシの暗号化を設定します。
- 管理 > プロキシに移動します。
- プロキシを選択し、暗号化タブをクリックします。
以下の例では、発行者フィールドとサブジェクトフィールドに値が入力されています。 これらのフィールドを使用する理由と方法の詳細については、許可する証明書の発行者とサブジェクトの制限を参照してください。
アクティブプロキシの場合:

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

Zabbix エージェント
1. Zabbix サーバーのセクションで説明されているように、トップレベルCA証明書、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インターフェースで設定します。
- データ収集 > ホストに移動します。
- ホストを選択し、暗号化タブをクリックします。
以下の例では、発行者フィールドとサブジェクトフィールドに値が入力されています。 これらのフィールドを使用する理由と方法の詳細については、許可する証明書の発行者とサブジェクトの制限を参照してください。

Zabbix Webサービス
1. Zabbixサーバーのセクションで説明されているとおり、トップレベルCA証明書、Zabbix Webサービスの証明書/証明書チェーン、および秘密鍵を含むファイルを準備します。
次に、Zabbix Webサービス設定ファイルのTLSCAFile、TLSCertFile、TLSKeyFileパラメータを適切に編集します。
2. Zabbix Webサービス設定ファイルで、追加のTLSパラメータTLSAccept=certを編集します。
最終的なWebサービス設定ファイルの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 サーバー設定ファイルのWebServiceURLパラメータを編集して、TLSを設定したZabbix Webサービスに接続するようZabbixサーバーを設定します。
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 の値が同一であっても問題ありません。