From 95e515d58529950574291c351d1cdb8ba6604737 Mon Sep 17 00:00:00 2001 From: William Yang Date: Mon, 27 May 2024 17:19:05 +0200 Subject: [PATCH] docs: add emqx_auth_ext_schema.hocon --- rel/i18n/emqx_auth_ext_schema.hocon | 46 +++++++++++++++++++++++++++++ rel/i18n/emqx_schema.hocon | 42 -------------------------- 2 files changed, 46 insertions(+), 42 deletions(-) create mode 100644 rel/i18n/emqx_auth_ext_schema.hocon diff --git a/rel/i18n/emqx_auth_ext_schema.hocon b/rel/i18n/emqx_auth_ext_schema.hocon new file mode 100644 index 000000000..3589a3436 --- /dev/null +++ b/rel/i18n/emqx_auth_ext_schema.hocon @@ -0,0 +1,46 @@ +emqx_auth_ext_schema { + +common_ssl_opts_schema_partial_chain.desc: +"""Enable or disable peer verification with partial_chain. +When local verifies a peer certificate during the x509 path validation +process, it constructs a certificate chain that starts with the peer +certificate and ends with a trust anchor. +By default, if it is set to `false`, the trust anchor is the +Root CA, and the certificate chain must be complete. +However, if the setting is set to `true` or `cacert_from_cacertfile`, +the last certificate in `cacertfile` will be used as the trust anchor +certificate (intermediate CA). This creates a partial chain +in the path validation. +Alternatively, if it is configured with `two_cacerts_from_cacertfile`, +one of the last two certificates in `cacertfile` will be used as the +trust anchor certificate, forming a partial chain. This option is +particularly useful for intermediate CA certificate rotation. +However, please note that it incurs some additional overhead, so it +should only be used for certificate rotation purposes.""" + +common_ssl_opts_schema_partial_chain.label: +"""Partial chain""" + +common_ssl_opts_verify_peer_ext_key_usage.desc: +"""Verify extended key usage in peer's certificate +For additional peer certificate validation, the value defined here must present in the +'Extended Key Usage' of peer certificate defined in +[rfc5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12). + +Allowed values are +- `clientAuth` +- `serverAuth` +- `codeSigning` +- `emailProtection` +- `timeStamping` +- `ocspSigning` +- raw OID, for example: "OID:1.3.6.1.5.5.7.3.2" means `id-pk 2` which is equivalent to `clientAuth` + +Comma-separated string is also supported for validating more than one key usages. + +For example, `"serverAuth,OID:1.3.6.1.5.5.7.3.2"`""" + +common_ssl_opts_verify_peer_ext_key_usage.label: +"""Verify KeyUsage in cert""" + +} diff --git a/rel/i18n/emqx_schema.hocon b/rel/i18n/emqx_schema.hocon index c6ec68d63..156d9dce9 100644 --- a/rel/i18n/emqx_schema.hocon +++ b/rel/i18n/emqx_schema.hocon @@ -684,48 +684,6 @@ common_ssl_opts_schema_verify.desc: common_ssl_opts_schema_verify.label: """Verify peer""" -common_ssl_opts_schema_partial_chain.desc: -"""Enable or disable peer verification with partial_chain. -When local verifies a peer certificate during the x509 path validation -process, it constructs a certificate chain that starts with the peer -certificate and ends with a trust anchor. -By default, if it is set to `false`, the trust anchor is the -Root CA, and the certificate chain must be complete. -However, if the setting is set to `true` or `cacert_from_cacertfile`, -the last certificate in `cacertfile` will be used as the trust anchor -certificate (intermediate CA). This creates a partial chain -in the path validation. -Alternatively, if it is configured with `two_cacerts_from_cacertfile`, -one of the last two certificates in `cacertfile` will be used as the -trust anchor certificate, forming a partial chain. This option is -particularly useful for intermediate CA certificate rotation. -However, please note that it incurs some additional overhead, so it -should only be used for certificate rotation purposes.""" - -common_ssl_opts_schema_partial_chain.label: -"""Partial chain""" - -common_ssl_opts_verify_peer_ext_key_usage.desc: -"""Verify extended key usage in peer's certificate -For additional peer certificate validation, the value defined here must present in the -'Extended Key Usage' of peer certificate defined in -[rfc5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12). - -Allowed values are -- `clientAuth` -- `serverAuth` -- `codeSigning` -- `emailProtection` -- `timeStamping` -- `ocspSigning` -- raw OID, for example: "OID:1.3.6.1.5.5.7.3.2" means `id-pk 2` which is equivalent to `clientAuth` - -Comma-separated string is also supported for validating more than one key usages. - -For example, `"serverAuth,OID:1.3.6.1.5.5.7.3.2"`""" - -common_ssl_opts_verify_peer_ext_key_usage.label: -"""Verify KeyUsage in cert""" fields_listeners_ssl.desc: """SSL listeners."""