diff options
Diffstat (limited to 'doc')
25 files changed, 614 insertions, 0 deletions
diff --git a/doc/01-About.md b/doc/01-About.md new file mode 100644 index 0000000..38fa06a --- /dev/null +++ b/doc/01-About.md @@ -0,0 +1,22 @@ +# Icinga Certificate Monitoring + +The certificate monitoring module for Icinga keeps track of certificates as they are deployed in a network environment. +It does this by scanning networks for TLS services and collects whatever certificates it finds along the way. +The certificates are verified using its own trust store. + +The module’s web frontend can be used to view scan results, allowing you to drill down into detailed information +about any discovered certificate of your landscape: + + + + + +At a glance you see which CAs have issued your certificates and key counters of your environment: + + + +## Documentation + +* [Installation](02-Installation.md) +* [Configuration](03-Configuration.md) +* [Monitoring](10-Monitoring.md) diff --git a/doc/02-Installation.md b/doc/02-Installation.md new file mode 100644 index 0000000..af2eaf3 --- /dev/null +++ b/doc/02-Installation.md @@ -0,0 +1,73 @@ +<!-- {% if index %} --> +# Installing Icinga Certificate Monitoring + +The recommended way to install Icinga Certificate Monitoring +and its dependencies is to use prebuilt packages for +all supported platforms from our official release repository. +Please note that [Icinga Web](https://icinga.com/docs/icinga-web) is required +and if it is not already set up, it is best to do this first. + +The following steps will guide you through installing and setting up Icinga Certificate Monitoring. +<!-- {% else %} --> +<!-- {% if not icingaDocs %} --> + +## Installing the Package + +If the [repository](https://packages.icinga.com) is not configured yet, please add it first. +Then use your distribution's package manager to install the `icinga-x509` package +or install [from source](02-Installation.md.d/From-Source.md). +<!-- {% endif %} --> + +## Setting up the Database + +### Setting up a MySQL or MariaDB Database + +The module needs a MySQL/MariaDB database with the schema that's provided in the `/usr/share/icingaweb2/modules/x509/schema/mysql.schema.sql` file. +<!-- {% if not icingaDocs %} --> + +**Note:** If you haven't installed this module from packages, then please adapt the schema path to the correct installation path. + +<!-- {% endif %} --> + +You can use the following sample command for creating the MySQL/MariaDB database. Please change the password: + +``` +CREATE DATABASE x509; +GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, DROP, ALTER, CREATE VIEW, INDEX, EXECUTE ON x509.* TO x509@localhost IDENTIFIED BY 'secret'; +``` + +After, you can import the schema using the following command: + +``` +mysql -p -u root x509 < /usr/share/icingaweb2/modules/x509/schema/mysql.schema.sql +``` + +### Setting up a PostgreSQL Database + +The module needs a PostgreSQL database with the schema that's provided in the `/usr/share/icingaweb2/modules/x509/schema/pgsql.schema.sql` file. +<!-- {% if not icingaDocs %} --> + +**Note:** If you haven't installed this module from packages, then please adapt the schema path to the correct installation path. + +<!-- {% endif %} --> + +You can use the following sample command for creating the PostgreSQL database. Please change the password: + +```sql +CREATE USER x509 WITH PASSWORD 'secret'; +CREATE DATABASE x509 + WITH OWNER x509 + ENCODING 'UTF8' + LC_COLLATE = 'en_US.UTF-8' + LC_CTYPE = 'en_US.UTF-8'; +``` + +After, you can import the schema using the following command: + +``` +psql -U x509 x509 -a -f /usr/share/icingaweb2/modules/x509/schema/pgsql.schema.sql +``` + +This concludes the installation. You should now be able to import CA certificates and set up scan jobs. +Please read the [Configuration](03-Configuration.md) section for details. +<!-- {% endif %} --><!-- {# end else if index #} --> diff --git a/doc/02-Installation.md.d/From-Source.md b/doc/02-Installation.md.d/From-Source.md new file mode 100644 index 0000000..31f3d2b --- /dev/null +++ b/doc/02-Installation.md.d/From-Source.md @@ -0,0 +1,16 @@ +# Installing Icinga Certificate Monitoring from Source + +Please see the Icinga Web documentation on +[how to install modules](https://icinga.com/docs/icinga-web-2/latest/doc/08-Modules/#installation) from source. +Make sure you use `x509` as the module name. The following requirements must also be met. + +## Requirements + +* PHP (≥7.2) +* MySQL or PostgreSQL PDO PHP libraries +* The following PHP modules must be installed: `gmp`, `pcntl`, `openssl` +* [Icinga Web](https://github.com/Icinga/icingaweb2) (≥2.9) +* [Icinga PHP Library (ipl)](https://github.com/Icinga/icinga-php-library) (≥0.13.0) +* [Icinga PHP Thirdparty](https://github.com/Icinga/icinga-php-thirdparty) (≥0.12.0) + +<!-- {% include "02-Installation.md" %} --> diff --git a/doc/03-Configuration.md b/doc/03-Configuration.md new file mode 100644 index 0000000..4ecde77 --- /dev/null +++ b/doc/03-Configuration.md @@ -0,0 +1,77 @@ +# <a id="Configuration"></a>Configuration + +## Importing CA certificates + +The module tries to verify certificates using its own trust store. By default, this trust store is empty, and it +is up to the Icinga Web 2 admin to import CA certificates into it. + +Using the `icingacli x509 import` command CA certificates can be imported. The certificate chain file that is specified +with the `--file` option should contain a PEM-encoded list of X.509 certificates which should be added to the trust +store: + +``` +icingacli x509 import --file /etc/ssl/certs/ca-certificates.crt +``` + +## Configure Jobs + +Scan jobs have a name which uniquely identifies them, e.g. `lan`. These names are used by the CLI command to start +scanning for specific jobs. + +Each scan job can have one or more IP address ranges and one or more port ranges. The module scans each port in +a job's port ranges for all the individual IP addresses in the IP ranges. IP address ranges have to be specified using +the CIDR format. Multiple IP address ranges can be separated with commas, e.g.: + +`192.0.2.0/24,10.0.10.0/24` + +Port ranges are separated with dashes (`-`). If you only want to scan a single port you don't need to specify the second +port: + +`443,5665-5669` + +Additionally, each job may also exclude specific **hosts** and **IP** addresses from scan. These hosts won't be scanned +when you run the [scan](04-Scanning.md#scan-command) or [jobs](04-Scanning.md#scheduling-jobs) command. Excluding an entire network and specifying IP addresses in CIDR +format will not work. You must specify concrete **IP**s and **host CN**s separated with commas, e.g: + +`192.0.2.2,192.0.2.5,icinga.com` + +### Job Schedules + +Schedules are [`cron`](https://crontab.guru) and rule based configs used to run jobs periodically at the given interval. +Every job is allowed to have multiple schedules that can be run independently of each other. Each job schedule provides +different options that you can use to control the scheduling behavior of the [jobs command](04-Scanning.md#scheduling-jobs). + +#### Examples + +A schedule that runs weekly on **Friday** and scans all targets that have not yet been scanned, or +whose last scan is older than `1 week`. + + + +## Server Name Indication + +In case you are serving multiple virtual hosts under a single IP you can configure those in +`Configuration -> Modules -> x509 -> SNI`. + +Each entry defines an IP with multiple hostnames associated with it. These are then utilized when jobs run. + +Modules may also provide sources for SNI. At this time the module monitoring is the only one with known support. + +## Icinga Certificate Monitoring Daemon + +The default `systemd` service of this module, shipped with package installations, uses the [jobs command](04-Scanning.md#scheduling-jobs) +and runs all your configured jobs and schedules. + +<!-- {% if not icingaDocs %} --> + +> **Note** +> +> If you haven't installed this module from packages, you have to configure this as a `systemd` service yourself by just +> copying the example service definition from `/usr/share/icingaweb2/modules/x509/config/systemd/icinga-x509.service` +> to `/etc/systemd/system/icinga-x509.service`. +<!-- {% endif %} --> + +You can run the following command to enable and start the daemon. +``` +systemctl enable --now icinga-x509.service +``` diff --git a/doc/04-Scanning.md b/doc/04-Scanning.md new file mode 100644 index 0000000..608d18a --- /dev/null +++ b/doc/04-Scanning.md @@ -0,0 +1,85 @@ +# <a id="Scanning"></a>Scanning + +The Icinga Certificate Monitoring provides CLI commands to scan **hosts** and **IPs** in various ways. +These commands are listed below and can be used individually. It is necessary for all commands to know which IP address +ranges and ports to scan. These can be configured as described [here](03-Configuration.md#configure-jobs). + +## Scan Command + +The scan command, scans targets to find their X.509 certificates and track changes to them. +A **target** is an **IP-port** combination that is generated from the job configuration, taking into account configured +[**SNI**](03-Configuration.md#server-name-indication) maps, so that targets with multiple certificates are also properly +scanned. + +By default, successive calls to the scan command perform partial scans, checking both targets not yet scanned and +targets whose scan is older than 24 hours, to ensure that all targets are rescanned over time and new certificates +are collected. This behavior can be customized through the command [options](#usage-1). + +> **Note** +> +> When rescanning due targets, they will be rescanned regardless of whether the target previously provided a certificate +> or not, to collect new certificates, track changed certificates, and remove decommissioned certificates. + +### Usage + +This scan command can be used like any other Icinga Web cli operations like this: `icingacli x509 scan [OPTIONS]` + +**Options:** + +``` +--job=<name> Scan targets that belong to the specified job. (Required) +--since-last-scan=<time> Scan targets whose last scan is older than the spcified date/time, which can also be an + English textual datetime description like "2 days". Defaults to "-24 hours". +--rescan Rescn only targets that have been scanned before. +--full (Re)scan all known and unknown targets. This will override the "rescan" and "since-last-scan" options. +--parallel=<number> Allow parallel scanning of targets up to the specified number. Defaults to 256. + May cause **too many open files** error if set to a number higher than the configured one (ulimit). +``` + +#### Example + +Scan all targets that have not yet been scanned, or whose last scan is older than a certain date/time: +``` +# icingacli x509 scan --job <name> --since-last-scan '3 days' +``` + +Scan only **unknown** targets: +``` +# icingacli x509 scan --job <name> --since-last-scan=null +``` + +Scan only known targets: +``` +# icingacli x509 scan --job <name> --rescan +``` + +Scan only known targets whose last scan is older than certain a given date/time: +``` +# icingacli x509 scan --job <name> --rescan --since-last-scan '5 days' +``` + +Scan all known and unknown targets: +``` +# icingacli x509 scan --job <name> --full +``` + +## Scheduling Jobs + +The jobs command is similar to the [scan command](#scan-command), but it additionally allows you to schedule your jobs +in a more convenient way. This is used by the default `systemd` service of this module as well. By default, this command +will run all your configured jobs based on their frequency. This behaviour can be customized through the command options +too. Since you can have multiple schedules for a single job, all job schedules can also be scheduled individually. + +### Usage + +This scan command can be used like any other Icinga Web cli operations like this: `icingacli x509 jobs run [OPTIONS` + +**Options:** + +``` +--job=<name> Run all configured schedules only of the specified job. +--schedule=<name> Run only the given schedule of the specified job. + Providing a schedule name without a job will fail immediately. +--parallel=<number> Allow parallel scanning of targets up to the specified number. Defaults to 256. + May cause **too many open files** error if set to a number higher than the configured one (ulimit). +``` diff --git a/doc/10-Monitoring.md b/doc/10-Monitoring.md new file mode 100644 index 0000000..d729bb9 --- /dev/null +++ b/doc/10-Monitoring.md @@ -0,0 +1,212 @@ +# <a id="Monitoring"></a>Monitoring + +## Host Check Command + +The module provides a CLI command to check a host's certificate. It does so by +fetching all the necessary information from this module's own database. + +### Usage + +General: `icingacli x509 check host [options]` + +Options: + +``` +--ip A hosts IP address +--host A hosts name +--port The port to check in particular +--warning Less remaining time results in state WARNING [25%] +--critical Less remaining time results in state CRITICAL [10%] +--allow-self-signed Ignore if a certificate or its issuer has been self-signed +``` + +### Threshold Definition + +Thresholds can either be defined relative (in percent) or absolute (time interval). +Time intervals consist of a digit and an accompanying unit (e.g. "3M" are three +months). Supported units are: + + Identifier | Description +------------|------------ +y, Y | Year +M | Month +d, D | Day +h, H | Hour +m | Minute +s, S | Second + +**Example:** + +``` +$ icingacli x509 check host --host example.org --warning 1y +WARNING - *.example.org expires in 219 days|'*.example.org'=18985010s;25574400;10281600;0;102470399 +``` + +### Performance Data + +The command outputs a performance data value for each certificate that is +served by the host. The value measured is the amount of seconds remaining +until the certificate expires. + + + +The value of `max` is the total amount of seconds the certificate is valid. +`warning` and `critical` are the seconds remaining after which the respective +state is reported. + +## Icinga 2 Integration + +First off, this chapter relies on the fact that you're using the Director +already and that you're familiar with some of the terms and functionalities +used there. + +If you don't want to use the Director, know that Icinga 2 already provides +an appropriate template for the host check command in its template library: +https://icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#x509 + +### Director Import Sources + +The module provides two different import sources: + +#### Hosts (X509) + +Focuses on the hosts the module found when scanning the networks. Use this +for the most straightforward way of integrating the results into your +environment. It's also the utilized source in the example further below. + +Columns provided by this source: + +Name | Description +----------------|-------------------------------------------------------------- +host_name_or_ip | Default key column. This is primarily `host_name`, though if this is not unique it falls back to `host_ip` for individual results +host_ip | A host's IP address by which it is known to this module. May be IPv4 or IPv6 +host_name | A host's name as detected by SNI or a reverse DNS lookup during the scan process +host_ports | Separated by comma. All ports where certificates were found +host_address | Set to `host_ip` if it is IPv4 else `null` +host_address6 | Set to `host_ip` if it is IPv6 else `null` + +#### Services (X509) + +While the hosts import source does not provide any details about the found +certificates this one does. This also means that this source may generate +multiple results for a single host since it focuses on the found certificates. + +Use this source if you want to import service objects directly and relate them +to already existing hosts by their utilized certificates. The Director's many +utilities provided in this regard will again come in handy here. + +Columns provided by this source: + +Name | Description +----------------------|-------------------------------------------------------- +host_name_ip_and_port | Default key column. This is a combination of `host_name`, `host_ip` and `host_port` in the format `name/ip:port` +host_ip | A host's IP address by which it is known to this module. May be IPv4 or IPv6 +host_name | A host's name as detected by SNI or a reverse DNS lookup during the scan process +host_port | A host's port where a certificate has been found +host_address | Set to `host_ip` if it is IPv4 else `null` +host_address6 | Set to `host_ip` if it is IPv6 else `null` +cert_subject | A certificate's common name +cert_issuer | The issuer's common name +cert_self_signed | Whether the certificate is self-signed (`y` or `n`) +cert_trusted | Whether the certificate is trusted (`y` or `n`) +cert_valid_from | The certificate's start time of validity (UNIX timestamp) +cert_valid_to | The certificate's end time of validity (UNIX timestamp) +cert_fingerprint | The certificate's fingerprint (hex-encoded) +cert_dn | The certificate's distinguished name +cert_subject_alt_name | The certificate's alternative subject names (Comma separated pairs of `type:name`) + +### Service Checks With the Hosts Import Source + +This example covers the setup of service checks by using a particular host +template and suggests then two options utilizing service apply rules. + +#### Preparations + +Assuming the check command definition `icingacli-x509` has already been imported +you need to define a few data fields now: + +Field name | Data type +---------------------------------|---------- +certified_ports | Array +icingacli_x509_ip | String +icingacli_x509_host | String +icingacli_x509_port | String +icingacli_x509_warning | String +icingacli_x509_critical | String +icingacli_x509_allow_self_signed | Boolean + +Then please create a new host template with a name of your choosing. We've chosen +`x509-host`. We're also importing our base template `base-host` here which defines +all the default properties of our hosts. + + + +This host template also requires three data fields which are shown below. + + + +A service template is also needed. We chose the name `x509-host-check` and +`icingacli-x509` as check command. + + + +The service template now requires all data fields which correspond to the +check command's parameters. + + + +#### Import Source Setup + +Create a new import source of type `Hosts (X509)`. + + +Configure a property modifier for column `host_ports` of type `Split` and use +the comma `,` as delimiter. + + +The preview should now produce a similar result to this: + + +#### Sync Rule Setup + +Create a new sync rule for objects of type `Host`. Depending on your environment +you may choose either `Merge` or `Replace` as update policy. Choose `Merge` to +continue with this example. + +Which properties this rule defines is also very dependent on what you want to +achieve. We now assume that you already have host objects whose object names +match exactly those the import source provides. (Hence you should choose +`Merge` as update policy) + + + +#### Service Check Setup + +There are two choices now. The first checks a host's certificates as a single +service. The second creates for each individual certificate (port) a service. + +##### Single Service + +This is done by defining a new service as part of the host template created +earlier. There add a service and choose the service template also created +previously. + + + +Once you've triggered the import and synchronisation as well as deployed +the resulting changes you should see this in Icinga Web 2: + + + +##### Multiple Services + +This utilizes a service apply rule. Trigger the import and synchronisation +first, otherwise you can't choose a custom variable for the *apply for* rule. + +Once the synchronisation is finished, set up the service apply rule like this: + + + +After deploying the resulting changes you should see this in Icinga Web 2: + + diff --git a/doc/11-Housekeeping.md b/doc/11-Housekeeping.md new file mode 100644 index 0000000..174a9ef --- /dev/null +++ b/doc/11-Housekeeping.md @@ -0,0 +1,38 @@ +# <a id="Datbase Housekeeping"></a>Database Housekeeping + +Your database may grow over time and contain some outdated information. Icinga Certificate Monitoring provides you +the ability to clean up these outdated info in an easy way. + +## Certificates and Targets + +The default `cleanup` action removes targets whose last scan is older than a certain date/time and certificates that +are no longer used. + +By default, any targets whose last scan is older than `1 month` are removed. The last scan information is always updated +when scanning a target, regardless of whether a successful connection is made or not. Therefore, targets that have been +decommissioned or are no longer part of a job configuration are removed after the specified period. Any certificates +that are no longer used are also removed. This can either be because the associated target has been removed or because +it is presenting a new certificate chain. + +The `cleanup` command will also remove additionally all jobs activities created before the given date/time. +Jobs activities are usually just some stats about the job runs performed by the scheduler or/and manually +executed using the [scan](04-Scanning.md#scan-command) and/or [jobs](04-Scanning.md#scheduling-jobs) command. + +### Usage + +This command can be used like any other Icinga Web cli operations like this: `icingacli x509 cleanup [OPTIONS]` + +**Options:** + +``` +--since-last-scan=<datetime> Clean up targets whose last scan is older than the specified date/time, + which can also be an English textual datetime description like "2 days". + Defaults to "1 month". +``` + +#### Example + +Remove any targets that have not been scanned for at least two months and any certificates that are no longer used. +``` +icingacli x509 cleanup --since-last-scan="2 months" +``` diff --git a/doc/80-Upgrading.md b/doc/80-Upgrading.md new file mode 100644 index 0000000..a66ddc4 --- /dev/null +++ b/doc/80-Upgrading.md @@ -0,0 +1,91 @@ +# Upgrading Icinga Certificate Monitoring + +Upgrading Icinga Certificate Monitoring is straightforward. +Usually the only manual steps involved are schema updates for the database. + +## Upgrading to version 1.3.0 + +Icinga Certificate Monitoring version `1.3.0` requires a schema update for the database. We have dropped the use of **INI** +files to store jobs and are using the database instead. So you need to migrate your job configs to the database. + +If you're already using Icinga Web 2 version `>= 2.12`, then you don't need to import the sql upgrade scripts manually. +Icinga Web provides you the ability to perform such migrations in a simple way. You may be familiar with such an automation +if you're an Icinga Director user. + +> **Note** +> +> Please note that it doesn't matter if you import the database upgrade script manually or via the new automation, +> you will have to migrate your [Jobs config](#migrate-jobs) from INI to the database manually afterwards. + +Before migrating your jobs from **INI** to the database, you need to first apply the migration script. This will create +the tables needed to store the jobs and schedules in the database. + +You may use the following command to apply the database schema upgrade file: +<!-- {% if not icingaDocs %} --> + +**Note:** If you haven't installed this module from packages, then please adapt the schema path to the correct installation path. + +<!-- {% endif %} --> +```sql +# mysql -u root -p x509 < /usr/share/icingaweb2/modules/x509/schema/mysql-upgrades/1.3.0.sql +``` + +### Migrate Jobs + +Afterwards, you can safely migrate your jobs with the following command. Keep in mind that you need to specify an +Icinga Web username that will be used as the author of these jobs in the database. + +``` +# icingacli x509 migrate jobs --author "icingaadmin" +``` + +## Upgrading to version 1.2.0 + +Icinga Certificate Monitoring version 1.2.0 requires a schema update for the database. We have changed all `timestamp` +columns in the database to biguint to store all timestamps in milliseconds. The sort column `expires` has been dropped +as well, but you can sort the certificates by `valid_to` instead. + +You may use the following command to apply the database schema upgrade file: +<!-- {% if not icingaDocs %} --> + +**Note:** If you haven't installed this module from packages, then please adapt the schema path to the correct installation path. + +<!-- {% endif %} --> +```sql +# mysql -u root -p x509 < /usr/share/icingaweb2/modules/x509/schema/mysql-upgrades/1.2.0.sql +``` + +## Upgrading to version 1.1.0 + +Icinga Certificate Monitoring version 1.1.0 fixes issues that affect the database schema. +To have these issues really fixed in your environment, the schema must be upgraded. +Please find the upgrade script in **/usr/share/icingaweb2/modules/x509/schema/mysql-upgrades**. + +You may use the following command to apply the database schema upgrade file: +<!-- {% if not icingaDocs %} --> + +**Note:** If you haven't installed this module from packages, then please adapt the schema path to the correct installation path. + +<!-- {% endif %} --> + +``` +# mysql -u root -p x509 < /usr/share/icingaweb2/modules/x509/schema/mysql-upgrades/1.1.0.sql +``` + +## Upgrading to version 1.0.0 + +Icinga Certificate Monitoring version 1.0.0 requires a schema update for the database. +The schema has been adjusted so that it is no longer necessary to adjust server settings +if you're using a version of MySQL < 5.7 or MariaDB < 10.2. +Please find the upgrade script in **/user/share/icingaweb2/modules/x509/schema/mysql-upgrades**. + +You may use the following command to apply the database schema upgrade file: +<!-- {% if not icingaDocs %} --> + +**Note:** If you haven't installed this module from packages, then please adapt the schema path to the correct installation path. + +<!-- {% endif %} --> + +``` +# mysql -u root -p x509 < /usr/share/icingaweb2/modules/x509/schema/mysql-upgrades/1.0.0.sql +``` diff --git a/doc/res/check-host-perf-data.png b/doc/res/check-host-perf-data.png Binary files differnew file mode 100644 index 0000000..958a226 --- /dev/null +++ b/doc/res/check-host-perf-data.png diff --git a/doc/res/host-check-multiple-services.png b/doc/res/host-check-multiple-services.png Binary files differnew file mode 100644 index 0000000..a153e2e --- /dev/null +++ b/doc/res/host-check-multiple-services.png diff --git a/doc/res/host-check-single-service.png b/doc/res/host-check-single-service.png Binary files differnew file mode 100644 index 0000000..1f4bdec --- /dev/null +++ b/doc/res/host-check-single-service.png diff --git a/doc/res/host-template-fields.png b/doc/res/host-template-fields.png Binary files differnew file mode 100644 index 0000000..a6aa438 --- /dev/null +++ b/doc/res/host-template-fields.png diff --git a/doc/res/hosts-import-result.png b/doc/res/hosts-import-result.png Binary files differnew file mode 100644 index 0000000..c19b1f2 --- /dev/null +++ b/doc/res/hosts-import-result.png diff --git a/doc/res/hosts-import-source.png b/doc/res/hosts-import-source.png Binary files differnew file mode 100644 index 0000000..fe525c7 --- /dev/null +++ b/doc/res/hosts-import-source.png diff --git a/doc/res/multiple-services-result.png b/doc/res/multiple-services-result.png Binary files differnew file mode 100644 index 0000000..8bec4b9 --- /dev/null +++ b/doc/res/multiple-services-result.png diff --git a/doc/res/new-host-template.png b/doc/res/new-host-template.png Binary files differnew file mode 100644 index 0000000..2ff9074 --- /dev/null +++ b/doc/res/new-host-template.png diff --git a/doc/res/new-service-template.png b/doc/res/new-service-template.png Binary files differnew file mode 100644 index 0000000..fec3d22 --- /dev/null +++ b/doc/res/new-service-template.png diff --git a/doc/res/ports-property-modifier.png b/doc/res/ports-property-modifier.png Binary files differnew file mode 100644 index 0000000..7bb3ecc --- /dev/null +++ b/doc/res/ports-property-modifier.png diff --git a/doc/res/service-template-fields.png b/doc/res/service-template-fields.png Binary files differnew file mode 100644 index 0000000..17c1cbd --- /dev/null +++ b/doc/res/service-template-fields.png diff --git a/doc/res/single-service-result.png b/doc/res/single-service-result.png Binary files differnew file mode 100644 index 0000000..418f495 --- /dev/null +++ b/doc/res/single-service-result.png diff --git a/doc/res/sync-rule-properties.png b/doc/res/sync-rule-properties.png Binary files differnew file mode 100644 index 0000000..1b54553 --- /dev/null +++ b/doc/res/sync-rule-properties.png diff --git a/doc/res/weekly-schedules.png b/doc/res/weekly-schedules.png Binary files differnew file mode 100644 index 0000000..a7b9508 --- /dev/null +++ b/doc/res/weekly-schedules.png diff --git a/doc/res/x509-certificates.png b/doc/res/x509-certificates.png Binary files differnew file mode 100644 index 0000000..2a67029 --- /dev/null +++ b/doc/res/x509-certificates.png diff --git a/doc/res/x509-dashboard.png b/doc/res/x509-dashboard.png Binary files differnew file mode 100644 index 0000000..4d5eaf1 --- /dev/null +++ b/doc/res/x509-dashboard.png diff --git a/doc/res/x509-usage.png b/doc/res/x509-usage.png Binary files differnew file mode 100644 index 0000000..cb80267 --- /dev/null +++ b/doc/res/x509-usage.png |
