acra-addzone (deprecated since 0.94.0) #
acra-addzone is a command-line utility that generates new Zone keys for AcraBlocks/AcraStructs. Zones are deprecated since 0.94.0, but if you are looking for a flexible approach of differentiating clients, check the differentiating ClientID dynamically via SQL page.
Command line flags #
Configuration files #
-
--config_file=<filename>Path to YAML configuration file.
-
--dump_configDump configuration to
configs/acra-addzone.yaml. -
--generate_markdown_args_tableGenerate markdown file with text description of all flags. Output file is
configs/markdown_acra-addzone.md. Works in a pair with--dump_config.
Logging #
-
-vLog to stderr all
INFO,WARNINGandERRORlogs.
Storage destination #
Filesystem #
-
--keys_output_dir=<path>Path to keystore directory.
Default is
.acrakeys.
Redis #
-
--redis_db_keys=<number>Redis database number to use. Default is
0. -
--redis_host_port=<host:port>Address of Redis database to use as keystore. If not specified, Redis is not used.
-
--redis_password=<password>Password to Redis database.
-
--redis_tls_client_auth=<mode>Set authentication mode that will be used for TLS connection with Redis.
-1— not specified, common--tls_cavalue will be used.1— request client certificate, but don’t require it;2— expect to receive at least one certificate to continue the handshake;3— don’t require client certificate, but validate it if client actually sent it;4— (default) request and validate client certificate.
These values correspond to crypto.tls.ClientAuthType.
-
--redis_tls_client_ca=<filename>Path to additional CA certificate for Redis' certificate validation. Empty by default. If not specified, acra-addzone uses value from
--tls_caflag. -
--redis_tls_client_cert=<filename>Path to TLS certificate presented to Redis. Empty by default. If not specified, acra-addzone uses value from
--tls_certflag. -
--redis_tls_client_key=<filename>Path to private key of the TLS certificate presented to Redis. Empty by default. If not specified, acra-addzone uses value from
--tls_keyflag. -
--redis_tls_client_sni=<SNI>Expected Server Name (SNI) of the Redis instance. Will be used
--redis_host_portvalue if is empty. Empty by default. -
--redis_tls_crl_client_cache_size=<count>How many CRLs to cache in memory in connections to Redis. Use
0to disable caching. Maximum is1000000. Default is16. Cache uses LRU policy. If not specified, acra-addzone uses value from--tls_crl_cache_sizeflag. -
--redis_tls_crl_client_cache_time=<seconds>How long to keep CRLs cached, in seconds for connections to Redis. Use
0to disable caching. Maximum is300seconds. Default is0. If not specified, acra-addzone uses value from--tls_crl_cache_timeflag. -
--redis_tls_crl_client_check_only_leaf_certificate={true|false}This flag controls behavior of validator in cases when Redis' certificate chain contains at least one intermediate certificate.
true— validate only leaf certificatefalse— (default) validate leaf certificate and all intermediate certificates
This option may be enabled in cases when intermediate CAs are trusted and there is no need to verify them all the time. Also, even if this flag is
falsebut there is no CRL’s URL configured and there is no CRL’s URL in intermediate CA certificates, these intermediate CAs won’t be validated since we don’t know which CRLs could be used for validation. If not specified, acra-addzone uses value from--tls_crl_check_only_leaf_certificateflag. -
--redis_tls_crl_client_from_cert=<policy>How to treat CRL’s URL described in a certificate from Redis server
use— try URL(s) from certificate after the one from configuration (if set)trust— try first URL from certificate, if it does not contain checked certificate, stop further checksprefer— (default) try URL(s) from certificate before the one from configuration (if set)ignore— completely ignore CRL’s URL(s) specified in certificate
“URL from configuration” above means the one configured with
--redis_tls_crl_client_urlflags. See Configuring & maintaining > TLS > CRL. If not specified, acra-addzone uses value from--tls_crl_from_certflag. -
--redis_tls_crl_client_url=<url>CRL’s URL for outcoming TLS connections to Redis. Empty by default. If not specified, acra-addzone uses value from
--tls_crl_urlflag. -
--redis_tls_enable=<true|false>Turns on/off TLS for connection with Redis to
--redis_host_portendpoint.true— turns onfalse— (default) turns off.
-
--redis_tls_ocsp_client_check_only_leaf_certificate={true|false}This flag controls behavior of validator in cases when Redis' certificate chain contains at least one intermediate certificate.
true— validate only leaf certificatefalse— (default) validate leaf certificate and all intermediate certificates
This option may be enabled in cases when intermediate CAs are trusted and there is no need to verify them all the time. Also, even if this flag is
falsebut there is no OCSP’s URL configured and there is no OCSP’s URL in intermediate CA certificates, these intermediate CAs won’t be validated since we don’t know whom to ask about them. If not specified, acra-addzone uses value from--tls_ocsp_check_only_leaf_certificateflag. -
--redis_tls_ocsp_client_from_cert=<policy>How to treat OCSP server URL described in a certificate from Redis server
use— try URL(s) from certificate after the one from configuration (if set)trust— try URL(s) from certificate, if server returns “Valid”, stop further checksprefer— (default) try URL(s) from certificate before the one from configuration (if set)ignore— completely ignore OCSP’s URL(s) specified in certificate
“URL from configuration” above means the one configured with
--redis_tls_ocsp_client_urlflags, see Configuring & maintaining > TLS > OCSP. If not specified, acra-addzone uses value from--tls_ocsp_from_certflag. -
--redis_tls_ocsp_client_required=<policy>How to handle situation when OCSP server doesn’t know about requested Redis' certificate and returns “Unknown”.
denyUnknown— (default) consider “Unknown” response an error, certificate will be rejectedallowUnknown— reverse ofdenyUnknown, allow certificates unknown to OCSP serverrequireGood— require all known OCSP servers to respond “Good” in order to allow certificate and continue TLS handshake, this includes all URLs validator can use, from certificate (if not ignored) and from configuration If not specified, acra-addzone uses value from--tls_ocsp_requiredflag.
-
--redis_tls_ocsp_client_url=<url>OCSP service URL for outgoing TLS connections to check Redis' certificates. Empty by default. If not specified, acra-addzone uses value from
--tls_ocsp_urlflag.
Keystore #
-
--keystore_encryption_type=<strategy>Keystore encryption strategy. Currently supported strategies:
env_master_key(Default) - Keystore using Acra Master Key, loaded from ENV (ACRA_MASTER_KEY) variable;vault_master_key- Keystore using Acra Master Key, loaded from Hashicorp Vaultkms_encrypted_master_key- Keystore using Acra Master Key, loaded from ENVACRA_MASTER_KEYvariable and decrypted via KMS key-encryption key.kms_per_client- Keystore using KMS for decryption Acra keys per ClientID and ZoneID. Create new KMS zone key-encryption key if not present on KMS.
KMS #
-
--kms_type=<type>Specify your KMS. Currently supported KMS types:
aws- AWS Key Management Service
-
--kms_credentials_path=<filepath>A path to a file with KMS credentials JSON format.
Example of KMS config:
-
AWS:
{"access_key_id":"<access_key_id>","secret_access_key":"<secret_access_key>","region":"<region>"}
Note:
Should be provided only with --keystore_encryption_type=<kms_encrypted_master_key|kms_per_client> flags.
Hashicorp Vault #
-
--vault_connection_api_string=<url>Connection string (like
http://x.x.x.x:yyyy) for loadingACRA_MASTER_KEYfrom HashiCorp Vault. Default is empty (ACRA_MASTER_KEYenvironment variable is expected). -
--vault_secrets_path=<path>KV Secret Path for reading
ACRA_MASTER_KEYfrom HashiCorp Vault. Default issecret/. -
--vault_tls_transport_enable=<true|false>Turns on/off TLS for connection with vault to
--vault_connection_api_stringendpoint.true— turns onfalse— (default) turns off.
-
--vault_tls_client_auth=<mode>Set authentication mode that will be used for TLS connection with Vault.
0— do not request client certificate, ignore it if received;1— request client certificate, but don’t require it;2— expect to receive at least one certificate to continue the handshake;3— don’t require client certificate, but validate it if client actually sent it;4— (default) request and validate client certificate.
These values correspond to crypto.tls.ClientAuthType.
-
--vault_tls_ca_path=<filename>Path to CA certificate for HashiCorp Vault certificate validation. Default is empty (deprecated since 0.94.0, use
vault_tls_client_cainstead). -
--vault_tls_client_ca=<filename>Path to acra-addzone TLS certificate’s CA certificate for Vault certificate validation (acra-addzone works as “client” when communicating with Vault). Empty by default.
-
--vault_tls_client_cert=<filename>Path to acra-addzone TLS certificate presented to Vault (acra-addzone works as “client” when communicating with Vault). Empty by default.
-
--vault_tls_client_key=<filename>Path to acra-addzone TLS certificate’s private key of the TLS certificate presented to Vault (acra-addzone works as “client” when communicating with Vault). Empty by default.
-
--vault_tls_client_sni=<SNI>Expected Server Name (SNI) of the Vault instance. Will be used
--vault_connection_api_stringvalue if is empty. Empty by default. -
--vault_tls_crl_client_cache_size=<count>How many CRLs to cache in memory in connections to Vault. Use
0to disable caching. Maximum is1000000. Default is16. Cache uses LRU policy. -
--vault_tls_crl_client_cache_time=<seconds>How long to keep CRLs cached, in seconds for connections to Vault. Use
0to disable caching. Maximum is300seconds. Default is0. -
--vault_tls_crl_client_check_only_leaf_certificate={true|false}This flag controls behavior of validator in cases when Vault certificate chain contains at least one intermediate certificate.
true— validate only leaf certificatefalse— (default) validate leaf certificate and all intermediate certificates
This option may be enabled in cases when intermediate CAs are trusted and there is no need to verify them all the time. Also, even if this flag is
falsebut there is no CRL’s URL configured and there is no CRL’s URL in intermediate CA certificates, these intermediate CAs won’t be validated since we don’t know which CRLs could be used for validation. -
--vault_tls_crl_client_from_cert=<policy>How to treat CRL’s URL described in a certificate from Vault server/agent
use— try URL(s) from certificate after the one from configuration (if set)trust— try first URL from certificate, if it does not contain checked certificate, stop further checksprefer— (default) try URL(s) from certificate before the one from configuration (if set)ignore— completely ignore CRL’s URL(s) specified in certificate
“URL from configuration” above means the one configured with
--vault_tls_crl_client_urlflags. -
--vault_tls_crl_client_url=<url>CRL’s URL for outcoming TLS connections to Vault. Empty by default.
-
--vault_tls_ocsp_client_check_only_leaf_certificate={true|false}This flag controls behavior of validator in cases when Vault certificate chain contains at least one intermediate certificate.
true— validate only leaf certificatefalse— (default) validate leaf certificate and all intermediate certificates
This option may be enabled in cases when intermediate CAs are trusted and there is no need to verify them all the time. Also, even if this flag is
falsebut there is no OCSP’s URL configured and there is no OCSP’s URL in intermediate CA certificates, these intermediate CAs won’t be validated since we don’t know whom to ask about them. -
--vault_tls_ocsp_client_from_cert=<policy>How to treat OCSP server URL described in a certificate from Vault server.
use— try URL(s) from certificate after the one from configuration (if set)trust— try URL(s) from certificate, if server returns “Valid”, stop further checksprefer— (default) try URL(s) from certificate before the one from configuration (if set)ignore— completely ignore OCSP’s URL(s) specified in certificate
“URL from configuration” above means the one configured with
--vault_tls_ocsp_client_urlflags. -
--vault_tls_ocsp_client_required=<policy>How to handle situation when OCSP server doesn’t know about requested Vault certificate and returns “Unknown”.
denyUnknown— (default) consider “Unknown” response an error, certificate will be rejectedallowUnknown— reverse ofdenyUnknown, allow certificates unknown to OCSP serverrequireGood— require all known OCSP servers to respond “Good” in order to allow certificate and continue TLS handshake, this includes all URLs validator can use, from certificate (if not ignored) and from configuration
-
--vault_tls_ocsp_client_url=<url>OCSP service URL for outgoing TLS connections to check Vaults' certificates. Empty by default.
Note:
Should be provided only with --keystore_encryption_type=<vault_master_key> flag.
Output #
$ acra-addzone
INFO[0000] Disabling future logs... Set -v to see logs
INFO[0000] Initializing ACRA_MASTER_KEY loader...
INFO[0000] Initialized default env ACRA_MASTER_KEY loader
{"id":"DDDDDDDDlMeojXNMDnMhrFNN","public_key":"VUVDMgAAAC1IbMPQAknSveiUj4xWzi7ZX50uzT+4/cbT7Tz5wZBbyDGAa3u8"}
Logs have written to stderr and JSON output with Zone data have written to stdout. To get only JSON output you can redirect stderr to /dev/null:
$ acra-addzone 2>/dev/null
{"id":"DDDDDDDDitpDYzEmbXWbBZzG","public_key":"VUVDMgAAAC1PF4yhAtF0ygbsRlEBMjY0E+9Pp694hauHyQfjC8gVAuOQJ0CX"}