TLS Certificate Chain CRL support

[ostell]

Hello RabbitMQ team,

We are using RabbitMQ in a cloud environment deployed by Helm Chart - Helm Chart. To fulfill the requirements of the project we have to use mTLS so the clients of the broker to authenticate via client certificates.
The certificate infrastructure is as follows Root CA -> Intermediate CA A -> Intermediate CA B -> Server Certificate (used by RabbitMQ Broker)/ Client Certificates. Server and Client certificate are issued by same certificate chain. It's also mandatory for us to use CRL, so we can revoke certificates in every stage of the Certificate chain. All the certificates in the chain (except the Root CA cert) have valid working CRL Distribution Points. Server certificate have 1 distribution point, Intermediate CA A have 2, Intermediate CA B have 2 distribution points also. Our configuration in the Helm chart is as follows:

loadDefinition:
    enabled: true
    existingSecret: load-definition
  extraConfiguration: |-
    load_definitions = /app/load_definition.json
    auth_backends.1 = internal
    auth_mechanisms.1 = PLAIN
    auth_mechanisms.1 = AMQPLAIN
    auth_mechanisms.1 = EXTERNAL
    ssl_cert_login_from = common_name
    ssl_options.depth = 2
  advancedConfiguration: |-
    [
    {rabbit, [
        {ssl_options, [
            {keyfile,"/opt/bitnami/rabbitmq/certs/server_key.pem"},
            {certfile,"/opt/bitnami/rabbitmq/certs/server_certificate.pem"},
            {cacertfile,"/opt/bitnami/rabbitmq/certs/ca_certificate.pem"},
            {depth, 2},
            {verify, verify_peer},
            {fail_if_no_peer_cert, true},
            {crl_check, true},
            {crl_cache, {ssl_crl_cache, {internal, [{http, $TP_BACKEND_RABBITMQ_TLS_CRL_REFRESH_INTERVAL_MILLIS}]}}}
        ]}
    ]}
    ].

In server_certificate.pem we have the certificate chain - Server Certificatre, Intermediate CA B, Intermediate CA A, In ca_certificate.pem we have only Root CA Certificate and server_key.pem is server private key as follows. So we are expecting the CRL chain to work and every CRL to be checked along the chain. But when we try to connect to the broker via valid client certificate we get and error that the handshake is not successful. And we see the following error log in RabbitMQ:

[notice] <0.1679.0> TLS server: In state certify at ssl_handshake.erl:2093 generated SERVER ALERT: Fatal - Bad Certificate
[notice] <0.1679.0>  - {bad_crls,no_relevant_crls}

We try to set {crl_check, best_effort} and then manage to authenticate via the same client certificate, but CRLs are not checked correctly.
We also try the setup without intermediate CAs - Root CA -> Server Cert/Client Cert and when we use {crl_check, true} its working without errors.
So our question is are Multiple CRLs checked and supported by RabbitMQ?

P.S.: Intermediate CAs have two CRL distribution points each, but only one endpoint per CA is working. As far as we know we can have multiple distribution points for failsafe and shouldn't be a problem if one it now working if there is still accessible and working endpoint. What do you think can this cause a problem for RabbitMQ and Erlang?

Thanks,
Vasil

[lukebakken]

So our question is are Multiple CRLs checked and supported by RabbitMQ?

RabbitMQ runs on the Erlang VM, as you probably know, and it's Erlang that provides CRL support.

Questions / requests:

• Do you have a support contract with VMware/Broadcom for RabbitMQ?
• Can you provide a complete set of certificates as well as CRL file that demonstrate the issue that I can use to reproduce the problem? Please ensure that the CRL distribution points are simple hostnames and ports, like http://localhost:8000/issue-10802.crl