SSL-CRL

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:

   apt yum zypper pkg

   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-config
  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 sslcrl-prod-1-config
  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-config
  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 sslcrl-prod-1-config
  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.

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.

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.

The directive has these parameters.

Example: Define an SSL-CRL filter named sslcrl-prod-1 having a 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

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.

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.

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 #

• Client certificate authentication tutorial

• Runtime API

  • abort ssl cert
  • add ssl crt-list
  • commit ssl cert
  • commit ssl crl-file
  • del ssl cert
  • del ssl crl-file
  • del ssl crt list
  • new ssl cert
  • new ssl crl-file
  • set ssl cert
  • set ssl crl-file
  • show ssl crl-file
  • show ssl crt list