DOC: 'jwt_verify' converter now supports certificates

The 'jwt_verify' converter can now accept certificates as a second
parameter, which can be updated via the CLI.

doc/configuration.txt

@@ -20518,9 +20518,14 @@ jwt_payload_query([<json_path>[,<output_type>]])
 jwt_verify(<alg>,<key>)
   Performs a signature verification for the JSON Web Token (JWT) given in input
   by using the <alg> algorithm and the <key> parameter, which should either
-  hold a secret or a path to a public key. The public key should either be in
+  hold a secret, a path to a public key or a path to a public certificate. When
-  the PKCS#1 format (for RSA keys, starting with BEGIN RSA PUBLIC KEY) or SPKI
+  using a public key, it should either be in the PKCS#1 format (for RSA keys,
-  format (Subject Public Key Info, starting with BEGIN PUBLIC KEY).
+  starting with BEGIN RSA PUBLIC KEY) or SPKI format (Subject Public Key Info,
+  starting with BEGIN PUBLIC KEY). Certificates should be a regular PEM
+  certificate (starting with BEGIN CERTIFICATE). If a full-on certificate is
+  used, it can either be used directly in the converter or passed via a
+  variable if it was already known by haproxy (previously loaded in a crt-store
+  for instance).
   Returns 1 in case of verification success, 0 in case of verification failure
   and a strictly negative value for any other error. Because of all those
   non-null error return values, the result of this converter should never be
@@ -20534,12 +20539,15 @@ jwt_verify(<alg>,<key>)
 
   If the used algorithm is of the HMAC family, <key> should be the secret used
   in the HMAC signature calculation. Otherwise, <key> should be the path to the
-  public key that can be used to validate the token's signature. All the public
+  public key or certificate that can be used to validate the token's signature.
-  keys that might be used to verify JWTs must be known during init in order to
+  All the public keys and certificates that might be used to verify JWTs must
-  be added into a dedicated cache so that no disk access is required during
+  be known during init in order to be added into a dedicated cache so that no
-  runtime. For this reason, any used public key must be mentioned explicitly at
+  disk access is required during runtime. For this reason, any used public key
-  least once in a jwt_verify call. Passing an intermediate variable as second
+  must be mentioned explicitly at least once in a jwt_verify call and every
-  parameter is then not advised.
+  certificate used must be loaded by haproxy (in a crt-store or mentioned
+  explicitly in a 'jwt_verify' call). Passing a variable as second parameter is
+  then not advised unless you only use certificates that fill one of those
+  prerequisites.
 
   This converter only verifies the signature of the token and does not perform
   a full JWT validation as specified in section 7.2 of RFC7519. We do not
@@ -20559,6 +20567,7 @@ jwt_verify(<alg>,<key>)
   | -3 | "Invalid token"                                                      |
   | -4 | "Out of memory"                                                      |
   | -5 | "Unknown certificate"                                                |
+  | -6 | "Internal error"                                                     |
   +----+----------------------------------------------------------------------+
 
   Please note that this converter is only available when HAProxy has been
@@ -20570,7 +20579,7 @@ jwt_verify(<alg>,<key>)
      http-request set-var(txn.bearer) http_auth_bearer
      http-request set-var(txn.jwt_alg) var(txn.bearer),jwt_header_query('$.alg')
      http-request deny unless { var(txn.jwt_alg) -m str "RS256" }
-     http-request deny unless { var(txn.bearer),jwt_verify(txn.jwt_alg,"/path/to/pubkey.pem") 1 }
+     http-request deny unless { var(txn.bearer),jwt_verify(txn.jwt_alg,"/path/to/cert.pem") 1 }
 
 language(<value>[,<default>])
   Returns the value with the highest q-factor from a list as extracted from the