Enterprise modules

SSL-CRL

Available since

  • HAProxy Enterprise 2.9r1

The SSL-CRL filter periodically checks SSL client certificates and closes any connections that rely on revoked or expired client certificates.

By default, the load balancer does not close an SSL connection between a client and backend server when an SSL certificate expires or is revoked. Consequently, the revocation of a client certificate does not prevent a client from accessing a server until the client closes their connection themselves.

A client can continue to use saved SSL session data as long as the server does not check the validity of the client certificate and the SSL session does not time out. Once the timeout period expires, new connections cannot be established, but existing connections are not closed. The timeout period is 7200 seconds or the HAProxy tune.ssl.lifetime configuration parameter.

To enable timely termination of connections when client certificates expire or are revoked, use the SSL-CRL module. The module implements a filter that periodically checks client certificates to see if they are valid. If a client SSL certificate expires or is revoked, the module closes the connection with the client.

For more information on certificates, see the Client certificate authentication tutorial.

Install the SSL-CRL module Jump to heading

  1. Install the module using your package manager:

    nix
    sudo apt-get install hapee-2.9r1-lb-sslcrl
    nix
    sudo apt-get install hapee-2.9r1-lb-sslcrl
    nix
    sudo yum install hapee-2.9r1-lb-sslcrl
    nix
    sudo yum install hapee-2.9r1-lb-sslcrl
    nix
    sudo zypper install hapee-2.9r1-lb-sslcrl
    nix
    sudo zypper install hapee-2.9r1-lb-sslcrl
    nix
    sudo pkg install hapee-2.9r1-lb-sslcrl
    nix
    sudo pkg install hapee-2.9r1-lb-sslcrl
  2. In the global section of your configuration file, load the module:

    haproxy
    global
    module-path /opt/hapee-2.9/modules
    module-load hapee-lb-sslcrl.so
    haproxy
    global
    module-path /opt/hapee-2.9/modules
    module-load hapee-lb-sslcrl.so
  3. In the frontend, listen, or backend sections where you want to enable the filter, add the filter sslcrl directive.

    • The listen, frontend, or backend section must be run in TCP mode by using mode tcp.
    • Add a bind directive that listens over HTTPS (port 443).
    • Verify client certificates by including verify required and the ca-file argument in the bind directive.
    • Reference a certificate revocation list file by using the crl-file argument. The SSL-CRL module will watch the in-memory representation of this CRL file.

    Example: Define a filter with all options set to the default values:

    haproxy
    frontend fe_production
    mode tcp
    bind :443 ssl crt /certs/site.pem verify required ca-file /certs/ca.crt crl-file /certs/revoked.crl
    filter sslcrl id sslcrl-prod-1
    haproxy
    frontend fe_production
    mode tcp
    bind :443 ssl crt /certs/site.pem verify required ca-file /certs/ca.crt crl-file /certs/revoked.crl
    filter sslcrl id sslcrl-prod-1

    Optionally, you can specify SSL-CRL configuration options in a named sslcrl section. Then refer to this section by name in any filter sslcrl directive where you wish to apply the configuration.

    Example: Define a filter named sslcrl-prod-1 with options set in a filter configuration section named sslcrl-prod-1-config:

    haproxy
    sslcrl sslcrl-prod-1-config
    log global
    log-format "%ci:%cp [%t] %ft %bi:%bp"
    option hard-errors
    check-interval 10s
    frontend fe_production
    mode tcp
    bind :443 ssl crt /certs/site.pem verify required ca-file /certs/ca.crt crl-file /certs/revoked.crl
    filter sslcrl id sslcrl-prod-1 config sslcrl-prod-1-config
    haproxy
    sslcrl sslcrl-prod-1-config
    log global
    log-format "%ci:%cp [%t] %ft %bi:%bp"
    option hard-errors
    check-interval 10s
    frontend fe_production
    mode tcp
    bind :443 ssl crt /certs/site.pem verify required ca-file /certs/ca.crt crl-file /certs/revoked.crl
    filter sslcrl id sslcrl-prod-1 config sslcrl-prod-1-config

Example Configuration Jump to heading

hapee-lb.cfg
haproxy
global
# Enable the Runtime API
stats socket /var/run/hapee-2.9/hapee-lb.sock user hapee-lb group hapee mode 660 level admin
# Load the module
module-path /opt/hapee-2.9/modules
module-load sslcrl.so
sslcrl sslcrl-prod-1
log global
log-format "%ci:%cp [%t] %ft %bi:%bp"
option hard-errors
check-interval 10s
frontend www
mode tcp
bind :443 ssl crt /certs/site.pem verify required ca-file /certs/self-signed.crt crl-file /certs/revoked.crl
filter sslcrl id sslcrl-prod-1 config myoptions
default_backend webservers
backend webservers
server webapp1 192.168.56.42:8080
server webapp2 192.168.56.43:8080
hapee-lb.cfg
haproxy
global
# Enable the Runtime API
stats socket /var/run/hapee-2.9/hapee-lb.sock user hapee-lb group hapee mode 660 level admin
# Load the module
module-path /opt/hapee-2.9/modules
module-load sslcrl.so
sslcrl sslcrl-prod-1
log global
log-format "%ci:%cp [%t] %ft %bi:%bp"
option hard-errors
check-interval 10s
frontend www
mode tcp
bind :443 ssl crt /certs/site.pem verify required ca-file /certs/self-signed.crt crl-file /certs/revoked.crl
filter sslcrl id sslcrl-prod-1 config myoptions
default_backend webservers
backend webservers
server webapp1 192.168.56.42:8080
server webapp2 192.168.56.43:8080

Certificate operations Jump to heading

The procedures in this section are based on a simple scenario where an organization has one self-signed Certificate Authority (CA) certificate that is used both to create client certificates and to authenticate clients.

Info

The certificates addressed in this section are the ones your server uses to authenticate and trust clients. These are not related to the site certificate that the server provides to clients so the clients can trust your server. The site certificate, typically issued by an external third-party vendor, is specified by the ssl crt parameter of the bind directive.

Create a self-signed Certificate Authority Jump to heading

A self-signed Certificate Authority (CA) is the certificate that your organization uses both to create client certificates and to authenticate clients. Your organization acts as the Certificate Authority, authenticating certificates when they are presented by clients.

You create your organization’s self-signed CA certificate yourself. You do not have to procure one from an external CA. In your load balancer configuration you specify the self-signed CA certificate file name using the ca-file parameter in the bind directive.

Creating a Certificate Authority involves generating a CA key pair, creating a self-signed CA certificate, and configuring the CA to sign other certificates. You can accomplish it all with a single openssl command.

  1. Generate a CA key pair and self-signed certificate:

    nix
    openssl req \
    -newkey rsa:2048 \
    -nodes \
    -x509 \
    -days 3650 \
    -keyout self-CA-key.pem \
    -out self-CA.crt
    nix
    openssl req \
    -newkey rsa:2048 \
    -nodes \
    -x509 \
    -days 3650 \
    -keyout self-CA-key.pem \
    -out self-CA.crt
    Learn more about this command

    The options of this command break down as follows:

    • openssl req creates and processes certificate signing requests (CSRs) and certificates.
    • -newkey rsa:2048 specifies the generation of a new RSA key pair with a key size of 2048 bits.
    • -nodes indicates that the private key should not be encrypted with a passphrase and will be saved in an unencrypted format.
    • -x509 tells OpenSSL to generate a self-signed certificate instead of a CSR.
    • -days 3650 specifies the validity period of the certificate as 3650 days (approximately 10 years).
    • -keyout designates the file name of self-CA-key.pem for the private key.
    • -out self-CA.crt sets the certificate.

    The command also prompts you to enter information for the certificate, such as the Common Name (CN), organization details, and so on. Fill in the required fields accordingly.

  2. To display the details of the CA certificate and verify its information, use the openssl x509 command:

    nix
    openssl x509 -in self-CA.crt -text -noout
    nix
    openssl x509 -in self-CA.crt -text -noout

    After following these steps, you should have the self-signed certificate self-CA.crt. Remember to adjust the file names and paths according to your specific setup. Keep the CA key self-CA-key.pem secret.

Verify client certificates Jump to heading

  1. In your load balancer configuration, enable verification of client certificates by setting verify to required on a bind line. The ca-file parameter specifies the CA file to use to verify:

    haproxy
    frontend www
    mode tcp
    bind :443 ssl crt /certs/site.pem verify required ca-file /certs/self-CA.crt
    haproxy
    frontend www
    mode tcp
    bind :443 ssl crt /certs/site.pem verify required ca-file /certs/self-CA.crt
  2. Reload the load balancer.

    nix
    sudo systemctl reload hapee-2.9-lb
    nix
    sudo systemctl reload hapee-2.9-lb

    With this change, only clients with properly signed client certificates can access the server.

    Info

    Reloading the load balancer does not affect open connections. It only affects new connections.

Create a client certificate Jump to heading

A client must have a signed certificate to access your server. The client certificate is known to be authentic and reliable because you have signed it using your organization’s self-signed CA certificate.

Creating a client certificate involves creating a certificate request, which can be completed by the client or by you, the administrator. Then the administrator signs the request and sends the resulting certificate to the client.

  1. The client or you, the administrator, create a certificate request (CSR). Create a request for Alice:

    nix
    openssl req \
    -newkey rsa:2048 \
    -nodes \
    -days 3650 \
    -subj "/CN=exampleUser/O=exampleOrganization" \
    -keyout alice-key.pem \
    -out alice-cert.csr
    nix
    openssl req \
    -newkey rsa:2048 \
    -nodes \
    -days 3650 \
    -subj "/CN=exampleUser/O=exampleOrganization" \
    -keyout alice-key.pem \
    -out alice-cert.csr

    In addition to the certificate request, this command creates the client key, alice-key.pem in this example. The client needs to keep this key in a secret place.

  2. You, the administrator, create an openssl configuration (CNF) file with these contents:

    client-cert-extensions.cnf
    text
    basicConstraints = CA:FALSE
    keyUsage = digitalSignature
    extendedKeyUsage = clientAuth
    subjectKeyIdentifier = hash
    authorityKeyIdentifier = keyid,issuer
    client-cert-extensions.cnf
    text
    basicConstraints = CA:FALSE
    keyUsage = digitalSignature
    extendedKeyUsage = clientAuth
    subjectKeyIdentifier = hash
    authorityKeyIdentifier = keyid,issuer
  3. Using your organization’s self-signed CA and client request (CSR), sign the certificate:

    nix
    openssl x509 \
    -req \
    -in alice-cert.csr \
    -out alice-cert.crt \
    -CA self-CA.crt \
    -CAkey self-CA-key.pem \
    -CAcreateserial \
    -days 7770 \
    -extfile client-cert-extensions.cnf
    nix
    openssl x509 \
    -req \
    -in alice-cert.csr \
    -out alice-cert.crt \
    -CA self-CA.crt \
    -CAkey self-CA-key.pem \
    -CAcreateserial \
    -days 7770 \
    -extfile client-cert-extensions.cnf

    Send the certificate, alice-cert.crt in this example, to user Alice. Alice can now use the certificate.

    If you also generated the CSR, also send the user’s key, alice-key.pem to the user. Again, user Alice needs to keep this key in a secret place.

Certificate Revocation Lists Jump to heading

A Certificate Revocation List (CRL) contains a list of the certificates that have been revoked.

Create a CRL Jump to heading

To create a CRL:

  1. Create the directory structure and necessary files. You can choose different directory paths, however ensure all created files are in the proper locations:

    nix
    mkdir -p ./databaseCA/certs ./databaseCA/private ./databaseCA/crl
    touch ./databaseCA/index.txt ./databaseCA/serial ./databaseCA/crlnumber
    echo 01 > ./databaseCA/serial
    echo 1000 > ./databaseCA/crlnumber
    nix
    mkdir -p ./databaseCA/certs ./databaseCA/private ./databaseCA/crl
    touch ./databaseCA/index.txt ./databaseCA/serial ./databaseCA/crlnumber
    echo 01 > ./databaseCA/serial
    echo 1000 > ./databaseCA/crlnumber
  2. Copy your CA certificate and private key into the databaseCA directory.

    nix
    cp self-CA.crt ./databaseCA
    cp self-CA-key.pem ./databaseCA/private
    nix
    cp self-CA.crt ./databaseCA
    cp self-CA-key.pem ./databaseCA/private
  3. You’ll need a configuration file for OpenSSL. An example file named openssl.cnf can usually be found in the directories /usr/lib/ssl/ or /etc/ssl/. Copy this to the current directory. Below is an example snippet from the file, modified for the certificates we created:

    openssl.cnf
    ini
    # OpenSSL example configuration file.
    # See doc/man5/config.pod for more info.
    ####################################################################
    [ ca ]
    default_ca = CA_default # The default ca section
    ####################################################################
    [ CA_default ]
    dir = ./databaseCA # Where everything is kept
    certs = $dir/certs # Where the issued certs are kept
    crl_dir = $dir/crl # Where the issued crl are kept
    database = $dir/index.txt # database index file.
    new_certs_dir = $dir/newcerts # default place for new certs.
    certificate = $dir/self-CA.crt # The CA certificate
    serial = $dir/serial # The current serial number
    crlnumber = $dir/crlnumber # the current crl number
    crl = $dir/crl.pem # The current CRL
    private_key = $dir/private/self-CA-key.pem # The private key
    x509_extensions = usr_cert # The extensions to add to the cert
    crl_extensions = crl_ext
    default_days = 3650 # how long to certify for
    default_crl_days = 30 # how long before next CRL
    default_md = sha256 # use SHA-256 by default
    preserve = no # keep passed DN ordering
    [ crl_ext ]
    authorityKeyIdentifier=keyid:always
    openssl.cnf
    ini
    # OpenSSL example configuration file.
    # See doc/man5/config.pod for more info.
    ####################################################################
    [ ca ]
    default_ca = CA_default # The default ca section
    ####################################################################
    [ CA_default ]
    dir = ./databaseCA # Where everything is kept
    certs = $dir/certs # Where the issued certs are kept
    crl_dir = $dir/crl # Where the issued crl are kept
    database = $dir/index.txt # database index file.
    new_certs_dir = $dir/newcerts # default place for new certs.
    certificate = $dir/self-CA.crt # The CA certificate
    serial = $dir/serial # The current serial number
    crlnumber = $dir/crlnumber # the current crl number
    crl = $dir/crl.pem # The current CRL
    private_key = $dir/private/self-CA-key.pem # The private key
    x509_extensions = usr_cert # The extensions to add to the cert
    crl_extensions = crl_ext
    default_days = 3650 # how long to certify for
    default_crl_days = 30 # how long before next CRL
    default_md = sha256 # use SHA-256 by default
    preserve = no # keep passed DN ordering
    [ crl_ext ]
    authorityKeyIdentifier=keyid:always

    The above is just the CA_default portion of a default OpenSSL configuration, not the entire openssl.cnf file.

    In this configuration, ./databaseCA is the directory where OpenSSL will store its database of certificates, ./databaseCA/private/self-CA-key.pem is the CA’s private key, and ./databaseCA/self-CA.crt is the CA’s certificate.

    • Ensure the directory and file paths match your environment, which we created in Step 1.
    • Consult the openssl ca documentation for a complete list of configuration options.
  4. Generate the file revoked.crl, which will contain the list of revoked certificates:

    nix
    sudo openssl ca -config openssl.cnf -gencrl -out /certs/revoked.crl
    nix
    sudo openssl ca -config openssl.cnf -gencrl -out /certs/revoked.crl

    You can create a CRL file even before a certificate has been revoked. In this case, the revocation list will be empty inside the CRL.

Configure the load balancer Jump to heading

By using Certificate Revocation Lists, you can revoke client certificates in your load balancer environment. Revoked certificates will be denied access based on your configured CRL file.

Here is an example snippet in which we add the crl-file argument to deny access to clients who have revoked certificates:

haproxy
frontend www
mode tcp
bind :443 ssl crt /certs/site.pem verify required ca-file /certs/self-CA.crt crl-file /certs/revoked.crl
filter sslcrl id sslcrl-prod-1
haproxy
frontend www
mode tcp
bind :443 ssl crt /certs/site.pem verify required ca-file /certs/self-CA.crt crl-file /certs/revoked.crl
filter sslcrl id sslcrl-prod-1

Revoke a certificate Jump to heading

To revoke a client certificate:

  1. Invoke the openssl ca command with the -revoke argument:

    nix
    sudo openssl ca -config openssl.cnf -revoke alice-cert.crt
    nix
    sudo openssl ca -config openssl.cnf -revoke alice-cert.crt

    This will immediately revoke the certificate alice-cert.crt as confirmed by the output:

    output
    text
    Using configuration from openssl.cnf
    Revoking Certificate 01.
    Data Base Updated
    output
    text
    Using configuration from openssl.cnf
    Revoking Certificate 01.
    Data Base Updated
  2. Update the CRL file:

    nix
    sudo openssl ca -config openssl.cnf -gencrl -out /certs/revoked.crl
    nix
    sudo openssl ca -config openssl.cnf -gencrl -out /certs/revoked.crl
  3. Reload the load balancer configuration.

Update the CRL in HAProxy Enterprise Jump to heading

Update the in-memory representation of the CRL file in HAProxy Enterprise by using the Runtime API.

  1. Replace the current CRL file with /certs/revoked.crl:

    nix
    echo -e "set ssl crl-file /certs/revoked.crl <<\n$(cat /certs/revoked.crl)\n" | \
    sudo socat stdio tcp4-connect:127.0.0.1:9999
    nix
    echo -e "set ssl crl-file /certs/revoked.crl <<\n$(cat /certs/revoked.crl)\n" | \
    sudo socat stdio tcp4-connect:127.0.0.1:9999
  2. Commit the in-memory CRL change, making the change effective immediately:

    nix
    echo -e "commit ssl crl-file /certs/revoked.crl" | \
    sudo socat stdio tcp4-connect:127.0.0.1:9999
    nix
    echo -e "commit ssl crl-file /certs/revoked.crl" | \
    sudo socat stdio tcp4-connect:127.0.0.1:9999

Always remember to persist Runtime API changes by making analogous changes to the corresponding files on disk.

Info

Even after a client’s certificate is revoked, web pages or other controlled resources from the server may persist in the client’s cache.

Configuration directive reference Jump to heading

To use the SSL-CRL module, configure HAProxy Enterprise as follows.

sslcrl-add-crls Jump to heading

Used in the global section, the sslcrl-add-crls directive specifies that when new revocation lists are added to the load balancer using the Runtime API, the previous revocation lists should be retained. With this option, you can add revocation lists incrementally, in multiple Runtime API commands. By default, adding a revocation list to the load balancer deletes the previously loaded lists from memory. Optional.

haproxy
global
sslcrl-add-crls
haproxy
global
sslcrl-add-crls

filter directive Jump to heading

The filter sslcrl directive enables the SSL-CRL filter for the listen, frontend, or backend section. Required. The filter sslcrl directive is supported in the listen, frontend, and backend sections.

Important

The listen, frontend, or backend section must be run in TCP mode.

The directive has these parameters.

Parameter Description
id <name> This parameter specifies an ID for the filter. If you do not specify an ID, the ID is set to <section>-<section-id>. Use the ID when using Runtime API commands. The ID identifies the filter in log messages. Optional.
config <section-name> This parameter specifies the name of the configuration section for the filter. You define a filter configuration section using the sslcrl directive when you need to override the default filter configuration values. The configuration section must precede the listen, frontend, or backend section that uses it. Optional.

Example: Define an SSL-CRL filter named sslcrl-prod-1 having a configuration file named sslcrl-prod-1-config.

haproxy
frontend fe_production
mode tcp
bind :443 ssl crt /certs/site.pem verify required ca-file /certs/ca.crt crl-file /certs/revoked.crl
filter sslcrl id sslcrl-prod-1 config sslcrl-prod-1-config
haproxy
frontend fe_production
mode tcp
bind :443 ssl crt /certs/site.pem verify required ca-file /certs/ca.crt crl-file /certs/revoked.crl
filter sslcrl id sslcrl-prod-1 config sslcrl-prod-1-config

sslcrl configuration directive Jump to heading

Create an sslcrl section to set additional options. It takes a name argument, which should match the value of the config argument on the filter sslcrl line. Multiple listen, frontend, and backend sections can refer to the same sslcrl configuration section.

You can specify the following directives in the sslcrl configuration section.

Directive Description
log { global | <addr> [len <len>] [format <fmt>] <facility> [<level> [<minlevel>]] } Configures the target log server. By default, logging from the filter is not permitted. Optional. The syntax and parameters are the same as for HAProxy Enterprise logs.
log-format <string> Specifies the log format string to use for the filter’s logs. For the log string, standard formats available for defining logs can be used. The default log format, if not explicitly defined, is %ci:%cp [%t] %ft. When logging, the prefix [SSLCRL]: <filter-id> and postfix <reason> are added to the log message. Optional.
option disabled At HAProxy startup, start the filter in the disabled state. By default, the filter is on if specified in a listen, frontend, or backend section. Optional.
option dontlog-normal In the case that logging in the filter is turned on, normal operation is not logged. Optional.
option hard-errors In case an error occurred during the operation of the filter, the filter is temporarily (for that connection) turned off. Optional.
check-interval <value> The frequency of SSL certificate validity checks. This is the maximum amount of time after which a revoked certificate causes the connection to be terminated. Default: 1 second. Optional.

Runtime API command reference Jump to heading

After starting the HAProxy Enterprise process, it is possible to manage the SSL-CRL filters using the Runtime API. This section describes the available commands.

Important

Changing filter parameters does not affect connections that are already established. Changes only apply to connections established after the change.

sslcrl add-crls Jump to heading

Syntax

sslcrl add-crls [on|off]

Description

Show or set the current sslcrl add-crls parameter setting, which determines whether existing CRLs are deleted when new ones are loaded. Optionally, specify on or off to set the parameter. By default, sslcrl add-crls is off, which means existing CRLs are deleted when new ones are loaded.

Example

Add new CRLs without deleting old ones:

nix
echo "sslcrl add-crls on" | sudo socat stdio /var/run/hapee-lb.sock
nix
echo "sslcrl add-crls on" | sudo socat stdio /var/run/hapee-lb.sock

sslcrl check-interval Jump to heading

Syntax

sslcrl check-interval [<value> <id>]

Description

Show or set the SSL certificate validation intervals for filters. The interval determines how often the validity of SSL certificates (client and server) is checked. Optionally, specify an interval and filter ID. The set value must be in milliseconds, between 1000 and 100000. Default: 1000.

Examples

Show check-interval for all SSL-CRL configurations:

nix
echo "sslcrl check-interval" | sudo socat stdio /var/run/hapee-lb.sock
nix
echo "sslcrl check-interval" | sudo socat stdio /var/run/hapee-lb.sock
output
text
sslcrl check-interval : sslcrl-prod-1 : check-interval is currently 5s
output
text
sslcrl check-interval : sslcrl-prod-1 : check-interval is currently 5s

Set the check-interval for SSL-CRL configuration sslcrl-prod-1 to 10 seconds:

nix
echo "sslcrl check-interval 10000 sslcrl-prod-1" | sudo socat stdio /var/run/hapee-lb.sock
nix
echo "sslcrl check-interval 10000 sslcrl-prod-1" | sudo socat stdio /var/run/hapee-lb.sock
output
text
sslcrl check-interval 10000 sslcrl-prod-1 : sslcrl-prod-1 : check-interval set to 10s
output
text
sslcrl check-interval 10000 sslcrl-prod-1 : sslcrl-prod-1 : check-interval set to 10s

sslcrl disable Jump to heading

Syntax

sslcrl disable <filter-id>

Description

Disable the SSL-CRL filter named <filter-id>.

Example

Disable the SSL-CRL filter named sslcrl-prod-1.

nix
echo "sslcrl disable sslcrl-prod-1" | sudo socat stdio /var/run/hapee-lb.sock
nix
echo "sslcrl disable sslcrl-prod-1" | sudo socat stdio /var/run/hapee-lb.sock

sslcrl enable Jump to heading

Syntax

sslcrl enable <filter-id>

Description

Enable the SSL-CRL filter named <filter-id>.

Example

Enable the SSL-CRL filter named sslcrl-prod-1.

nix
echo "sslcrl enable sslcrl-prod-1" | sudo socat stdio /var/run/hapee-lb.sock
nix
echo "sslcrl enable sslcrl-prod-1" | sudo socat stdio /var/run/hapee-lb.sock

sslcrl hard-errors Jump to heading

Syntax

sslcrl hard-errors <filter-id>

Description

Enable hard-errors mode. In this mode, in the event of an error occurring in the operation of the SSL-CRL filter, the filter is turned off and does not affect the further operation of the stream.

Example

Enable hard-errors mode on the filter named sslcrl-prod-1.

nix
echo "sslcrl hard-errors sslcrl-prod-1" | sudo socat stdio /var/run/hapee-lb.sock
nix
echo "sslcrl hard-errors sslcrl-prod-1" | sudo socat stdio /var/run/hapee-lb.sock

sslcrl logging Jump to heading

Syntax

sslcrl logging [<state> <filter-id>]

Description

Show the current logging state, where state may be off, on, or dontlog-normal (log only errors). Optionally, set the logging state of the specified filter.

Examples

Show logging state:

nix
echo "sslcrl logging" | sudo socat stdio /var/run/hapee-lb.sock
nix
echo "sslcrl logging" | sudo socat stdio /var/run/hapee-lb.sock
output
text
sslcrl logging : sslcrl-prod-1 : logging is currently enabled
output
text
sslcrl logging : sslcrl-prod-1 : logging is currently enabled

Disable logging for SSL-CRL filter configuration sslcrl-prod-1:

nix
echo "sslcrl logging off sslcrl-prod-1" | sudo socat stdio /var/run/hapee-lb.sock
nix
echo "sslcrl logging off sslcrl-prod-1" | sudo socat stdio /var/run/hapee-lb.sock
output
text
sslcrl logging off sslcrl-prod-1 : sslcrl-prod-1 : logging set to disabled
output
text
sslcrl logging off sslcrl-prod-1 : sslcrl-prod-1 : logging set to disabled

sslcrl soft-errors Jump to heading

Syntax

sslcrl soft-errors <filter-id>

Description

Restore soft-errors mode (that is, turn off hard-errors mode) for the specified SSL-CRL filter configuration. In this mode, filter errors are logged, but the operation of the filter is not interrupted.

Example

Restore soft-errors mode on the filter named sslcrl-prod-1.

nix
echo "sslcrl soft-errors sslcrl-prod-1" | sudo socat stdio /var/run/hapee-lb.sock
nix
echo "sslcrl soft-errors sslcrl-prod-1" | sudo socat stdio /var/run/hapee-lb.sock

sslcrl status Jump to heading

Syntax

sslcrl status [<filter-id>]

Description

Show the status of all SSL-CRL filter configurations. Optionally, specify a single filter configuration.

Example

Show the status of the filter named sslcrl-prod-1.

nix
echo "sslcrl status sslcrl-prod-1" | sudo socat stdio /var/run/hapee-lb.sock
nix
echo "sslcrl status sslcrl-prod-1" | sudo socat stdio /var/run/hapee-lb.sock

See also Jump to heading

Do you have any suggestions on how we can improve the content of this page?