From 907ae97bf63d7511d5d9b8a44c78ba1d90f408af Mon Sep 17 00:00:00 2001 From: Martin Alfke Date: Sun, 17 May 2026 15:24:37 +0200 Subject: [PATCH 1/4] Update several openvox-server files - remove canonical - rename from Puppet to OpenVox Signed-off-by: Martin Alfke --- docs/_openvox-server_8x/crl_refresh.markdown | 16 +++--- .../deprecated_features.markdown | 55 +++++++++---------- .../_openvox-server_8x/dev_debugging.markdown | 21 ++++--- .../dev_trace_func.markdown | 36 ++++++------ 4 files changed, 63 insertions(+), 65 deletions(-) diff --git a/docs/_openvox-server_8x/crl_refresh.markdown b/docs/_openvox-server_8x/crl_refresh.markdown index 13d2ae0fd..517d73216 100644 --- a/docs/_openvox-server_8x/crl_refresh.markdown +++ b/docs/_openvox-server_8x/crl_refresh.markdown @@ -1,19 +1,21 @@ --- layout: default -title: "Puppet Server: Automatic CRL refresh" -canonical: "/puppetserver/latest/crl_refresh.html" +title: "OpenVox Server: Automatic CRL refresh" --- -Starting in version 5.1.0, Puppet Server can automatically reload an updated CRL into the running SSL context, so that the revocation of an agent's certificate no longer requires a restart of the service to take effect. Prior versions required an explicit restart or reload of this service to reload the CRL, resulting in some small amount of downtime to effect the revocation of a certificate. Revocation is now transparent and requires no service downtime. +OpenVox Server can automatically reload an updated CRL into the running SSL context, so that the revocation of an agent's certificate no longer requires a restart of the service to take effect. +Revocation is now transparent and requires no service downtime. -If you are upgrading and have modified your ca.cfg, adding the following line manually may be required. See [Service Bootstraping](./configuration.html#service-bootstrapping) for information on how to update your Puppet Server's services bootstrap configuration. +If you are upgrading and have modified your ca.cfg, adding the following line manually may be required. +See [Service Bootstraping](./configuration.html#service-bootstrapping) for information on how to update your OpenVox Server's services bootstrap configuration. `puppetlabs.trapperkeeper.services.watcher.filesystem-watch-service/filesystem-watch-service` -### Implementation +## Implementation -Automatic CRL refresh leverages the the [trapperkeeper file system watcher](https://github.com/puppetlabs/trapperkeeper-filesystem-watcher) to watch for changes to the CRL file, and loads the updated CRL on change. +Automatic CRL refresh leverages the the [trapperkeeper file system watcher](https://github.com/openvoxproject/trapperkeeper-filesystem-watcher) to watch for changes to the CRL file, and loads the updated +CRL on change. ### Contributors -Thanks to Jeremy Barlow, who laid the groundwork for this feature in Puppet Server. +Thanks to Jeremy Barlow, who laid the groundwork for this feature in OpenVox Server. diff --git a/docs/_openvox-server_8x/deprecated_features.markdown b/docs/_openvox-server_8x/deprecated_features.markdown index df8c8c9aa..dac518c8a 100644 --- a/docs/_openvox-server_8x/deprecated_features.markdown +++ b/docs/_openvox-server_8x/deprecated_features.markdown @@ -1,17 +1,16 @@ --- layout: default -title: "Puppet Server: Deprecated Features" -canonical: "/puppetserver/latest/deprecated_features.html" +title: "OpenVox Server: Deprecated Features" --- -The following features / configuration settings are deprecated and will be removed in a future major release of Puppet Server. +The following features / configuration settings are deprecated and will be removed in a future major release of OpenVox Server. ## `certificate-status` settings ### Now If the `certificate-authority.certificate-status.authorization-required` setting is `false`, all requests that are successfully validated by SSL (if applicable for the port settings on the server) are permitted -to use the [Certificate Status](https://github.com/puppetlabs/puppet/blob/master/api/docs/http_certificate_status.md) HTTP API endpoints. This includes requests which do not provide an SSL client certificate. +to use the [Certificate Status](https://github.com/openvoxproject/penvox/blob/master/api/docs/http_certificate_status.md) HTTP API endpoints. This includes requests which do not provide an SSL client certificate. If the `certificate-authority.certificate-status.authorization-required` setting is `true` or not specified and the `puppet-admin.client-whitelist` setting has one or more entries, only the requests whose Common Name in the SSL client certificate subject matches one of the `client-whitelist` entries are permitted to use the certificate status HTTP API endpoints. @@ -21,7 +20,7 @@ For any other configuration, requests are only permitted to access the certifica ### In a Future Major Release -The `certificate-status` settings will be ignored completely by Puppet Server. Requests made to the `certificate-status` HTTP API will only be allowed per the `trapperkeeper-authorization` "auth.conf" +The `certificate-status` settings will be ignored completely by OpenVox Server. Requests made to the `certificate-status` HTTP API will only be allowed per the `trapperkeeper-authorization` "auth.conf" configuration. ### Detecting and Updating @@ -30,7 +29,7 @@ Look at the `certificate-status` settings in your configuration. If `authorizati the certificate status HTTP API instead of `trapperkeeper-authorization`. If `authorization-required` is set to `true` or is not specified and if the `client-whitelist` was empty, you could just remove the `certificate-authority` section from your configuration. The only behavior -that would change in Puppet Server from doing this would be that a warning message would no longer be written to the "puppetserver.log" file at startup. +that would change in OpenVox Server from doing this would be that a warning message would no longer be written to the "puppetserver.log" file at startup. If `authorization-required` is set to `false`, you would need to create a corresponding rule in the `trapperkeeper-authorization` file which would allow unauthenticated client access to the certificate status API. @@ -114,8 +113,8 @@ After adding the desired rules to the `trapperkeeper-authorization` "auth.conf" ### Context -In previous Puppet Server releases, there was no unified mechanism for controlling access to the various endpoints that Puppet Server hosts. Puppet Server used core Puppet "auth.conf" to authorize requests -handled by the master service and custom client whitelists for the CA and Admin endpoints. The custom client whitelists do not provide granular enough control to meet some use cases. +In previous OpenVox Server releases, there was no unified mechanism for controlling access to the various endpoints that OpenVox Server hosts. OpenVox Server used core OpenVox "auth.conf" to authorize requests +handled by the primary service and custom client whitelists for the CA and Admin endpoints. The custom client whitelists do not provide granular enough control to meet some use cases. `trapperkeeper-authorization` unifies authorization configuration across all of these endpoints into a single file and provides more granular control. @@ -134,7 +133,7 @@ For any other configuration, requests are only permitted to access the `puppet-a ### In a Future Major Release -The `puppet-admin` settings will be ignored completely by Puppet Server. Requests made to the `puppet-admin` HTTP API will only be allowed per the `trapperkeeper-authorization` "auth.conf" configuration. +The `puppet-admin` settings will be ignored completely by OpenVox Server. Requests made to the `puppet-admin` HTTP API will only be allowed per the `trapperkeeper-authorization` "auth.conf" configuration. ### Detecting and Updating @@ -142,7 +141,7 @@ Look at the `puppet-admin` settings in your configuration. If `authorization-req `puppet-admin` HTTP API instead of `trapperkeeper-authorization`. If `authorization-required` is set to `true` or is not specified and if the `client-whitelist` was empty, you could just remove the `puppet-admin` section from your configuration and restart your puppetserver -service in order for Puppet Server to start using the `trapperkeeper-authorization` "auth.conf" file. The only behavior that would change in Puppet Server from doing this would be that a warning message would +service in order for OpenVox Server to start using the `trapperkeeper-authorization` "auth.conf" file. The only behavior that would change in OpenVox Server from doing this would be that a warning message would no longer be written to the puppetserver.log file. If `authorization-required` is set to `false`, you would need to create corresponding rules in the `trapperkeeper-authorization` file which would allow unauthenticated client access to the "puppet-admin" API @@ -225,77 +224,77 @@ After adding the desired rules to the `trapperkeeper-authorization` "auth.conf" ### Context -In previous Puppet Server releases, there was no unified mechanism for controlling access to the various endpoints that Puppet Server hosts. Puppet Server used core Puppet "auth.conf" to authorize requests +In previous OpenVox Server releases, there was no unified mechanism for controlling access to the various endpoints that OpenVox Server hosts. OpenVox Server used core OpenVox "auth.conf" to authorize requests handled by the master service and custom client whitelists for the CA and Admin endpoints. The custom client whitelists do not provide granular enough control to meet some use cases. `trapperkeeper-authorization` unifies authorization configuration across all of these endpoints into a single file and provides more granular control. -## Puppet's "resource_types" API endpoint +## OpenVox's "resource_types" API endpoint ### Now -The `resource_type` and `resource_types` HTTP APIs were removed in Puppet Server 5.0. +The `resource_type` and `resource_types` HTTP APIs were removed in OpenVox Server 5.0. ### Previously -The [`resource_type` and `resource_types` Puppet HTTP API endpoints](https://puppet.com/docs/puppet/4.6/http_api/http_resource_type.html) return information about classes, defined types, and node definitions. +The [`resource_type` and `resource_types` OpenVox HTTP API endpoints](/openvox/latest/http_api/http_resource_type.html) return information about classes, defined types, and node definitions. -The [`environment_classes` HTTP API in Puppet Server](./puppet-api/v3/environment_classes.html) serves as a replacement for the Puppet resource type API for classes. +The [`environment_classes` HTTP API in OpenVox Server](./puppet-api/v3/environment_classes.html) serves as a replacement for the OpenVox resource type API for classes. ### Detecting and Updating If your application calls the `resource_type` or `resource_types` HTTP API endpoints for information about classes, point those calls to the `environment_classes` endpoint. The `environment_classes` endpoint has different features and returns different values than `resource_type`; see the [changes in the environment classes API](./puppet-api/v3/environment_classes.html) for details. -The `environment_classes` endpoint ignores Puppet's Ruby-based authorization methods and configuration in favor of Puppet Server's Trapperkeeper authorization. For more information, see the +The `environment_classes` endpoint ignores OpenVox's Ruby-based authorization methods and configuration in favor of OpenVox Server's Trapperkeeper authorization. For more information, see the ["Authorization" section](./puppet-api/v3/environment_classes.html) of the environment classes API documentation. ### Context Users often rely on the `resource_types` endpoint for lists of classes and associated parameters in an environment. For such requests, the `resource_types` endpoint is inefficient and can trigger problematic -events, such as [manifests being parsed during a catalog request](https://tickets.puppetlabs.com/browse/SERVER-1200). +events, such as manifests being parsed during a catalog request. -To fulfill these requests more efficiently and safely, Puppet Server 2.3.0 introduced the narrowly defined `environment_classes` endpoint. +To fulfill these requests more efficiently and safely, OpenVox Server 2.3.0 introduced the narrowly defined `environment_classes` endpoint. -## Puppet's node cache terminus +## OpenVox's node cache terminus ### Now -Puppet 5.0 (and by extension, Puppet Server 5.0) no longer writes node YAML files to its cache by default. +OpenVox 5.0 (and by extension, OpenVox Server 5.0) no longer writes node YAML files to its cache by default. ### Previously -Puppet wrote YAML to its node cache. +OpenVox wrote YAML to its node cache. ### Detecting and Updating -To retain the Puppet 4.x behavior, add the [`puppet.conf`](./configuration.html) setting `node_cache_terminus = write_only_yaml`. The `write_only_yaml` option is deprecated. +To retain the OpenVox 4.x behavior, add the [`puppet.conf`](./configuration.html) setting `node_cache_terminus = write_only_yaml`. The `write_only_yaml` option is deprecated. ### Context -This cache was used in workflows where external tooling needs a list of nodes. PuppetDB is the preferred source of node information. +This cache was used in workflows where external tooling needs a list of nodes. OpenVox-DB is the preferred source of node information. ## JRuby's "compat-version" setting ### Now -Puppet Server 5.0 removes the `jruby-puppet.compat-version` setting in [`puppetserver.conf`](./config_file_puppetserver.html), and exits the `puppetserver` service with an error if you start the service with +OpenVox Server 5.0 removes the `jruby-puppet.compat-version` setting in [`puppetserver.conf`](./config_file_puppetserver.html), and exits the `puppetserver` service with an error if you start the service with that setting. ### Previously -Puppet Server 2.7.x allowed you to set `compat-version` to `1.9` or `2.0` to choose a preferred Ruby interpreter version. +OpenVox Server 2.7.x allowed you to set `compat-version` to `1.9` or `2.0` to choose a preferred Ruby interpreter version. ### Detecting and Updating Launching the `puppetserver` service with this setting enabled will cause it to exit with an error message. The error includes information on [switching from JRuby 1.7.x to JRuby 9k](./configuration.html). -For Ruby language 2.x support in Puppet Server, configure Puppet Server to use JRuby 9k instead of JRuby 1.7.27. See the "Configuring the JRuby Version" section of +For Ruby language 2.x support in OpenVox Server, configure OpenVox Server to use JRuby 9k instead of JRuby 1.7.27. See the "Configuring the JRuby Version" section of [Puppet Server Configuration](./configuration.html) for details. ### Context -Puppet Server 5.0 updated JRuby v1.7 to v1.7.27, which in turn updated the `jruby-openssl` gem to v0.9.19 and `bouncycastle` libraries to v1.55. JRuby 1.7.27 breaks setting `jruby-puppet.compat-version` to +OpenVox Server 5.0 updated JRuby v1.7 to v1.7.27, which in turn updated the `jruby-openssl` gem to v0.9.19 and `bouncycastle` libraries to v1.55. JRuby 1.7.27 breaks setting `jruby-puppet.compat-version` to `2.0`. -Server 5.0 also added optional, experimental support for JRuby 9k, which includes Ruby 2.x language support. +OpenVox Server 5.0 also added optional, experimental support for JRuby 9k, which includes Ruby 2.x language support. diff --git a/docs/_openvox-server_8x/dev_debugging.markdown b/docs/_openvox-server_8x/dev_debugging.markdown index 4d3dfd7ba..61c463fcf 100644 --- a/docs/_openvox-server_8x/dev_debugging.markdown +++ b/docs/_openvox-server_8x/dev_debugging.markdown @@ -1,10 +1,9 @@ --- layout: default -title: "Puppet Server: Debugging" -canonical: "/puppetserver/latest/dev_debugging.html" +title: "OpenVox Server: Debugging" --- -Because Puppet Server executes both Clojure and Ruby code, approaches to debugging differ depending on which part of the application you're interested in. +Because OpenVox Server executes both Clojure and Ruby code, approaches to debugging differ depending on which part of the application you're interested in. ## Debugging Clojure Code @@ -20,10 +19,10 @@ debugging features that are available in Java; breakpoints, evaluating expressio ## Debugging Ruby Code -Debugging the Ruby code running in Puppet Server can be a bit trickier, because Java and Clojure debugging tools will only take you into the JRuby interpreter source code, not into the Ruby code that it is +Debugging the Ruby code running in OpenVox Server can be a bit trickier, because Java and Clojure debugging tools will only take you into the JRuby interpreter source code, not into the Ruby code that it is processing. So, if you wish to debug the Ruby code directly, you'll need to install gems and take advantage of their capabilities (not unlike how you would debug Ruby code in the MRI interpreter). -For more info on installing gems for Puppet Server, see [Puppet Server and Gems](./gems.html). +For more info on installing gems for OpenVox Server, see [OpenVox Server and Gems](./gems.html). ## Ruby REPL incompatible with Lein REPL @@ -41,7 +40,7 @@ sense. ### Installation There are many gems available that provide various ways of debugging Ruby code depending on what version of Ruby and which Ruby interpreter you're running. One of the most common gems is `ruby-debug`, and there -is a JRuby-compatible version available. To install it for use in Puppet Server, run: +is a JRuby-compatible version available. To install it for use in OpenVox Server, run: sudo puppetserver gem install ruby-debug @@ -51,7 +50,7 @@ Or, if you're running puppetserver from source: ### Usage -After installing the gem, you can trigger the debugger by adding a line like this to any of the Ruby code that is run in Puppet Server (including the Puppet Ruby code): +After installing the gem, you can trigger the debugger by adding a line like this to any of the Ruby code that is run in OpenVox Server (including the OpenVox Ruby code): require 'ruby-debug'; debugger @@ -86,11 +85,11 @@ adding it to this documentation! ## Limitations -We are aware that some favorite gems/tools/features for ruby debugging don't currently work with JRuby/Puppet Server. (For example, some things like color syntax highlighting in Pry.) It's important to us to -make sure that the Ruby developer experience is not degraded for developers working via Puppet Server rather than webrick, so, if you run into issues like this, please file an issue on our -[Bug Tracker](https://tickets.puppet.com/browse/SERVER), and we will see if it's possible to add support for things that we're missing. In many cases it might be a matter of simply submitting a patch to JRuby, +We are aware that some favorite gems/tools/features for ruby debugging don't currently work with JRuby/OpenVox Server. (For example, some things like color syntax highlighting in Pry.) +It's important to us to make sure that the Ruby developer experience is not degraded for developers working via OpenVox Server, so, if you run into issues like this, please file an issue on our +[Bug Tracker](https://github.com/openvoxproject), and we will see if it's possible to add support for things that we're missing. In many cases it might be a matter of simply submitting a patch to JRuby, or submitting a JRuby-compatibility patch for an existing gem, and we're interested in trying to help with those sorts of things whenever possible. # Tracing Code Events -Puppet Server can utilize JRuby's standard facilities for tracing events during code execution. For more information on these techniques, see the [Tracing Code Events](./dev_trace_func.html) page. +OpenVox Server can utilize JRuby's standard facilities for tracing events during code execution. For more information on these techniques, see the [Tracing Code Events](./dev_trace_func.html) page. diff --git a/docs/_openvox-server_8x/dev_trace_func.markdown b/docs/_openvox-server_8x/dev_trace_func.markdown index ea7bda6c1..79d4071a8 100644 --- a/docs/_openvox-server_8x/dev_trace_func.markdown +++ b/docs/_openvox-server_8x/dev_trace_func.markdown @@ -1,44 +1,42 @@ --- layout: default -title: "Puppet Server: Tracing Code Events" -canonical: "/puppetserver/latest/dev_trace_func.html" +title: "OpenVox Server: Tracing Code Events" --- -The JRuby runtime supports the Ruby [set_trace_func] -(http://ruby-doc.org/core-1.9.3/Kernel.html#method-i-set_trace_func) Kernel +The JRuby runtime supports the Ruby [set_trace_func](http://ruby-doc.org/core-1.9.3/Kernel.html#method-i-set_trace_func) Kernel method for tracing code events, e.g., lines of code being executed and calls -to C-language routines or Ruby methods. This can likewise be used in Puppet +to C-language routines or Ruby methods. This can likewise be used in OpenVox Server for tracing. In order to enable a more verbose level of tracing, e.g., to capture lower-level calls into C code, the `jruby.debug.fullTrace` Java property must be set to -"true". If you are running Puppet Server from source, this can be done by +"true". If you are running OpenVox Server from source, this can be done by adding the option to the `project.clj` file: -~~~ini +```ini :jvm-opts ["-Djruby.debug.fullTrace=true"] -~~~ +``` -If you are running Puppet Server from a package, this can be done by adding the +If you are running OpenVox Server from a package, this can be done by adding the option to the `puppetserver` file in `/etc/sysconfig` or `/etc/default`, depending upon your OS distribution: -~~~ini +```ini JAVA_ARGS="-Xms2g -Xmx2g -Djruby.debug.fullTrace=true" -~~~ +``` A call to the `set_trace_func` function can be done in one of the Ruby files in -the Puppet Server code. For the trace to be in effect for the full execution +the OpenVox Server code. For the trace to be in effect for the full execution of Ruby code, one common place to put this call would be at the top of the -`../src/ruby/puppetserver-lib/puppet/server/master.rb` file, the Puppet Server +`../src/ruby/puppetserver-lib/puppet/server/master.rb` file, the OpenVox Server master class. A basic implementation might look like this: -~~~ruby +```ruby set_trace_func proc { |event, file, line, id, binding, classname| printf "%8s %s:%-2d %10s %8s\n", event, file, line, id, classname } -~~~ +``` Note that `printf` will write each trace line to stdout. If you are running Puppet Server from a package install, stdout should be routed to the @@ -46,20 +44,20 @@ Puppet Server from a package install, stdout should be routed to the Lines of output from `set_trace_func` look like the following: -~~~ +```text c-call /usr/share/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/jopenssl19/openssl/ssl-internal.rb:30 initialize OpenSSL::X509::Store -~~~ +``` You could use this technique to locate any references made to specific class names from code and the active stack at the point of each reference. For example, to locate callers of any `OpenSSL` classes, you could add the following to the `set_trace_func` call: -~~~ruby +```ruby set_trace_func proc { |event, file, line, id, binding, classname| if classname.to_s =~ /OpenSSL/ printf "%8s %s:%-2d %10s %8s\n", event, file, line, id, classname puts caller end } -~~~ +``` From 9fb5ea34bbedee9e074dda412b8ff721e5709d2b Mon Sep 17 00:00:00 2001 From: Martin Alfke Date: Sun, 17 May 2026 15:31:04 +0200 Subject: [PATCH 2/4] Update docs/_openvox-server_8x/deprecated_features.markdown Co-authored-by: Corporate Gadfly Signed-off-by: Martin Alfke --- docs/_openvox-server_8x/deprecated_features.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/_openvox-server_8x/deprecated_features.markdown b/docs/_openvox-server_8x/deprecated_features.markdown index dac518c8a..73a84fdc5 100644 --- a/docs/_openvox-server_8x/deprecated_features.markdown +++ b/docs/_openvox-server_8x/deprecated_features.markdown @@ -10,7 +10,7 @@ The following features / configuration settings are deprecated and will be remov ### Now If the `certificate-authority.certificate-status.authorization-required` setting is `false`, all requests that are successfully validated by SSL (if applicable for the port settings on the server) are permitted -to use the [Certificate Status](https://github.com/openvoxproject/penvox/blob/master/api/docs/http_certificate_status.md) HTTP API endpoints. This includes requests which do not provide an SSL client certificate. +o use the [Certificate Status](https://github.com/openvoxproject/openvox/blob/master/api/docs/http_certificate_status.md) HTTP API endpoints. This includes requests which do not provide an SSL client certificate. If the `certificate-authority.certificate-status.authorization-required` setting is `true` or not specified and the `puppet-admin.client-whitelist` setting has one or more entries, only the requests whose Common Name in the SSL client certificate subject matches one of the `client-whitelist` entries are permitted to use the certificate status HTTP API endpoints. From e6a038847c8bab6a91990fe19a13103f98100203 Mon Sep 17 00:00:00 2001 From: Martin Alfke Date: Sun, 17 May 2026 15:31:36 +0200 Subject: [PATCH 3/4] Update docs/_openvox-server_8x/deprecated_features.markdown Co-authored-by: Corporate Gadfly Signed-off-by: Martin Alfke --- docs/_openvox-server_8x/deprecated_features.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/_openvox-server_8x/deprecated_features.markdown b/docs/_openvox-server_8x/deprecated_features.markdown index 73a84fdc5..2e9b85572 100644 --- a/docs/_openvox-server_8x/deprecated_features.markdown +++ b/docs/_openvox-server_8x/deprecated_features.markdown @@ -272,7 +272,7 @@ To retain the OpenVox 4.x behavior, add the [`puppet.conf`](./configuration.html ### Context -This cache was used in workflows where external tooling needs a list of nodes. OpenVox-DB is the preferred source of node information. +This cache was used in workflows where external tooling needs a list of nodes. OpenVoxDB is the preferred source of node information. ## JRuby's "compat-version" setting From 7461524b9021e9247041b4c9283ddd40028b4784 Mon Sep 17 00:00:00 2001 From: Corporate Gadfly Date: Sun, 17 May 2026 09:38:15 -0400 Subject: [PATCH 4/4] Apply suggestion from @corporate-gadfly Signed-off-by: Corporate Gadfly --- docs/_openvox-server_8x/deprecated_features.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/_openvox-server_8x/deprecated_features.markdown b/docs/_openvox-server_8x/deprecated_features.markdown index 2e9b85572..1c7da8d2c 100644 --- a/docs/_openvox-server_8x/deprecated_features.markdown +++ b/docs/_openvox-server_8x/deprecated_features.markdown @@ -10,7 +10,7 @@ The following features / configuration settings are deprecated and will be remov ### Now If the `certificate-authority.certificate-status.authorization-required` setting is `false`, all requests that are successfully validated by SSL (if applicable for the port settings on the server) are permitted -o use the [Certificate Status](https://github.com/openvoxproject/openvox/blob/master/api/docs/http_certificate_status.md) HTTP API endpoints. This includes requests which do not provide an SSL client certificate. +to use the [Certificate Status](https://github.com/openvoxproject/openvox/blob/master/api/docs/http_certificate_status.md) HTTP API endpoints. This includes requests which do not provide an SSL client certificate. If the `certificate-authority.certificate-status.authorization-required` setting is `true` or not specified and the `puppet-admin.client-whitelist` setting has one or more entries, only the requests whose Common Name in the SSL client certificate subject matches one of the `client-whitelist` entries are permitted to use the certificate status HTTP API endpoints.