TLS peer verification with SAN and CN

[Yusuke Masuda]

Hello,

I would like to ask a question regarding TLS peer verification described in the page below:

https://www.rabbitmq.com/ssl.html

This might be common description though, it describes as below:

When peer verification is enabled, it is common for clients to also check whether the the hostname of the server they are connecting to matches one of two fields in the server certificate: the SAN (Subject Alternative Name) or CN (Common Name).

I set two different names to SAN and CN in my certificate, and I set it up to RabbitMQ server, then I tried my application communicate with RabbitMQ. 

Then it has succeeded in only cases that the correct name being set to SAN.

By above description in RabbitMQ page, I had assumed when the RabbitMQ fails either field verification, then it fallback another field.

But actual behavior seems to be checking SAN field only in spite of both field being set.

I googled, and I found a post in stackoverflow.com

https://stackoverflow.com/questions/5935369/ssl-how-do-common-names-cn-and-subject-alternative-names-san-work-together

Its answer described below:

as per RFC 6125, published in '2011 the validator must check SAN first, and if SAN exists, then CN should not be checked.

The description gets the point to describes my application behavior, for me.

Here are a few questions,

Do I have to always set a valid name to SAN if I use both SAN and CN?

Does the RabbitMQ verification fallback to another field?

Thanks,

Yusuke Masuda,

[Luke Bakken]

Hi Yusuke,

When your application connects to RabbitMQ over TLS, the application verifies the server's identity based on SAN or CN, not the other way around.

Two questions:

• Are you using client certificate authentication as well?
• What programming language and RabbitMQ client library are you using?

 I would start by reading the TLS documentation for your application's environment.

Thanks,

Luke

[Yusuke Masuda]

Hi Luke,

Thank you for your quick response.

Our application and RabbitMQ are configured that they make mutual authentication by TLS.

So the answer for your first question is 'YES', we are using client certification, too.

And our client application is developed with .NET (C#).

It uses .NET RabbitMQ client via MassTransit.

We installed our application and RabbitMQ into Windows.

Just in case, I would let you know RabbitMQ and Erlang versions.

- RabbitMQ: 3.8.0

- Erlang: 22.0

Regards,

2020年4月19日日曜日 23時01分46秒 UTC+9 Luke Bakken:

[Yusuke Masuda]

Hi Luke,

I hope to check my message out.

Could you find any answers against my question?

It might be another matter, the RabbitMQ server doesn't verify the client certificate.
Did I misconfigure the RabbitMQ?

Please check my configuration.

The strings enclosed with "$$$" will be replaced after RabbitMQ installed.

[
  {rabbit, [
    {log, [
        {file, [
            {level, info},
            {size, 5242880},
            {count, 2}
        ]}
    ]},
    {config_entry_decoder, [
      {passphrase, {file, "$$$APP_DATA_LOCATION$$$/Config/G5BUFY35GE4R5ZVC/QKP4GX66.txt"}}
    ]},
    {tcp_listeners, []},
    {ssl_listeners, [5671]},
    {crl_check, false},
    {ssl_options, [
      {cacertfile,"$$$APP_DATA_LOCATION$$$/Certificates/RabbitMQ/ca.pem"},
      {certfile,  "$$$APP_DATA_LOCATION$$$/Certificates/RabbitMQ/RMQ_crt.pem"},
      {keyfile,   "$$$APP_DATA_LOCATION$$$/Certificates/RabbitMQ/RMQ_crt.key"},
      {password, $$$ENCRYPTED_PASSWORD$$$},
      {verify, verify_peer},
      {fail_if_no_peer_cert, true},
      {versions, ['tlsv1.2']},
      {depth, 2},
      {ciphers, [
        "ECDHE-ECDSA-AES256-GCM-SHA384",
        "ECDHE-ECDSA-AES128-GCM-SHA256",
        "ECDHE-RSA-AES256-GCM-SHA384",
        "ECDHE-RSA-AES128-GCM-SHA256",
        "DHE-RSA-AES256-GCM-SHA384",
        "DHE-RSA-AES128-GCM-SHA256",
        "ECDHE-ECDSA-AES256-SHA384",
        "ECDHE-ECDSA-AES128-SHA256",
        "ECDHE-RSA-AES256-SHA384",
        "ECDHE-RSA-AES128-SHA256",
        "ECDHE-ECDSA-AES256-SHA",
        "ECDHE-ECDSA-AES128-SHA",
        "ECDHE-RSA-AES256-SHA",
        "ECDHE-RSA-AES128-SHA",
        "AES256-GCM-SHA384",
        "AES128-GCM-SHA256",
        "AES256-SHA256",
        "AES128-SHA256",
        "AES256-SHA",
        "AES128-SHA"
        ]},
      {honor_cipher_order, true},
      {honor_ecc_order, true}
    ]}
  ]}
].

Regards,

Yusuke Masuda 

[Luke Bakken]

Hi Yusuke,

I have been busy working on issues for paying customers.

You need to figure out if your connection fails at server validation, or at client certificate validation.

Your configuration for RabbitMQ seems correct, but it may be too limiting. You should try removing versions, ciphers, honor_cipher_order and honor_ecc_order, and re-try.

You should be able to use openssl to test your environment - https://www.rabbitmq.com/troubleshooting-ssl.html#openssl-tools

I have helped out other users who would like to use the CN value for client certificate authentication - https://groups.google.com/forum/#!msg/pika-python/lHv1Ho_I_DU/L4uoxKu3DQAJ

If you can provide certificates, C# code and RabbitMQ configuration, with instructions to reproduce your issue, I can help quickly. I don't have time right now to try to set up an environment that matches yours.

Thanks -

Luke

[Yusuke Masuda]

Hi Luke,

Thank you for your reply.

We will attempt along with your advice.

When we will have prepared example code, we will post them.

Best Regards,

Yusuke.

2020年5月11日月曜日 22時00分53秒 UTC+9 Luke Bakken:

[Yusuke Masuda]

Luke, 

Sorry for my late reply.

I prepared a client source code which we can submit to this community.

Please see the attach.

It is utilize MassTransit to communicate RabbitMQ.

I believe that is essentially same as using .NET rabbitmq client.

I tried communication again with this example.

I got that we can communicate with a certificate being set to SAN properly, and without CN.
Also I got it with a certificate being set to CN properly, and without SAN.

Description in the RabbitMQ manual page below can probably mean this is.

https://www.rabbitmq.com/ssl.html

When peer verification is enabled, it is common for clients to also check whether the the hostname of the server they are connecting to matches one of two fields in the server certificate: the SAN (Subject Alternative Name) or CN (Common Name).

I thought it has configure both of SAN and CN, but it might mean it should be configured either one, not both, and it has to be proper value.
This trouble might have caused with my misunderstanding, but I hope you to correct the document that should reduce misunderstanding.

Best regards,

Yusuke.

[Michael Klishin]

Yusuke,

 

It’s more involved. In layman’s terms, it should be “any identity that passes verification”, as you

expect and our docs tries to communicate. However, if you read FC 5280, section 4.2.1.6 [1],

there are several additional, and fairly vaguely specified, requirements present.

 

In general, a SAN takes precedence over the CN. This has been the recommendation for over a decade IIRC.

Therefore if you have both set, the SAN will be checked first. However, different TLS implementations can have

slightly different interpretations of [1]. Our docs are not specific to .NET.

 

You can implement your own verification function. The client very much delegates this to standard available .NET validator functions [2]

or a user-provided one [3].

 

Therefore it’s not obvious to me that we should update our docs. Not only there can be implementation-specific aspects,

you or MassTransit can affect how exactly peer verification is performed.

 

1. https://tools.ietf.org/html/rfc5280#section-4.2.1.6
2. https://github.com/rabbitmq/rabbitmq-dotnet-client/blob/8617745f7ef20648e11a3e24c5b8f8964e5da204/projects/RabbitMQ.Client/client/impl/SslHelper.cs#L69
3. https://github.com/rabbitmq/rabbitmq-dotnet-client/blob/68545fb3f8f4f562b5b2e87ba3672297bedfd894/projects/RabbitMQ.Client/client/api/SslOption.cs#L101

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/861d76b9-e47c-4d59-a70d-0ef87fa016a8%40googlegroups.com.

[Yusuke Masuda]

Michel,

Sorry for my late reply.

I could understand that it was a difference on implementation which caused by interpretation of the spec.

And I support your opinion that you don't have to correct the document.

So I would like to close this topic, thanks.

Regards,

Yusuke