Certificate chain verification logic - peer only about rabbitmq-trust-store HOT 25 CLOSED

Standard verification mechanism does verify the entire chain up to a certain depth (configurable for either peer). I think we should do the same thing here. Those who want to only match leaf certificates can set verification depth to 0 (default is 1 in case of Erlang/OTP). From the docs:

Depth: Maximum number of non-self-issued intermediate certificates that can follow
the peer certificate in a valid certification path. So, if depth is 0 the PEER must be
signed by the trusted ROOT-CA directly; if 1 the path can be PEER, CA, ROOT-CA;
if 2 the path can be PEER, CA, CA, ROOT-CA, and so on. The default value is 1.

from rabbitmq-trust-store.

To make sure we are on the same page -- there are two distinct cases here, and they do not work the same.

"Standard" cert verification logic (without the trust store plug-in) pays attention only to the CA certs (because only those are installed on the server). It does not pay attention to the peer cert (because peer cert is not installed on the server). Depth parameter tells the server how many CA certs to check before it accepts the peer cert.

Trust store plug-in looks at it from the other end -- starting with the peer cert. First, the peer cert has to match what's white-listed, and it must match it regardless whether the client sends the CA certs with the peer cert or not. In my opinion, this is necessary and sufficient. Lots of other systems do it like so. Alternative verification procedure is to also take the CA certs into account (I believe this approach is called "PKIX"), i.e. verify all certs sent by the client -- peer and CA. But, in order to support this option, the CA certs must also be made available to the plug-in. How is not quite clear, but there are choices -- in separate PEM files, combined with the peer cert, etc.

I have no idea how this translates to Erlang, unfortunately, but that is the desired behavior that is implemented in the other products.

Current plug-in implementation seems to fail to match the peer cert, even if it's white-listed, if the client sends the CA certs along with the peer cert. Since developers may not always control what certs are sent by the client stack, the trust store plug-in as it is may have limited application.

from rabbitmq-trust-store.

Fair enough, thanks for the explanation. @kjnilsson WDYT?

from rabbitmq-trust-store.

So it looks like we have two scenarios here where the first is more pressing than the second:

1. The client presents a certificate chain of say PEER, CA, ROOT-CA where the PEER is whitelisted but the CA and ROOT-CA or completely unknown to the server. In this instance we should continue validation until the provided PEER cert can be verified against the whitelist.
2. The trust store should accept files containing either some CA or a certificate chain. When a client presents a certificate chain all certificates in the chain should be optionally verified? or at least to some configurable depth.

Have I understood the requirements correctly?

from rabbitmq-trust-store.

@kjnilsson it makes sense to me. Note that from my experience certificate chains are often distributed as pem files with certificates concatenated together, e.g. Nginx is a widely used tool that requires doing this. So do some Python tools, including rabbitmqadmin.

So supporting certificate chains that way would require fewer novel solutions on our end. We should work out how chain verification must work for chains still.

from rabbitmq-trust-store.

We are going to post a comment with our findings in a bit but FTR, here's the RFC section that focusses on PKIX certificate chain/path validation.

from rabbitmq-trust-store.

Supporting the logic required for scenario 1 (above) with the current erlang ssl implementation isn't obvious or straight-forward, maybe not even possible.

The main issue is that when processing a certificate chain erlang starts with the top level CA certificate first proceeding downwards towards the peer. The API doesn't allow us to know where in the chain a certificate that is being processed is which makes it hard to skip over non-peer certificates in the chain until a peer is found without accidentally validating a peer certificate not known to the trust store.

Other erlang users have had similar issues: http://erlang.org/pipermail/erlang-questions/2015-November/086694.html

I think it may be possible at this point to support adding CAs into the trust store (scenario 2 above) so that a presented chain can be fully validated against the trust store but have not had a chance to test that yet.

More investigation is needed for both scenarios.

from rabbitmq-trust-store.

@kjnilsson You understood the requirement and priority as I suggested precisely.

The reason the first scenario (validating just the peer and not validating the CA certs) was more pressing, is because in our 10 years of experience integrating systems based on client SSL certs, we would always receive the client cert in the X.509v3 format, which does not include the CA certs. If we had to install the entire cert chain into the trust store, it would require an extra step, but is not impossible. The usual tool for doing this (in our experience) is the Certificates snap-in for the Microsoft Management Console -- we would have to load the peer cert into the Windows certificate store on the workstation, see who issued it, and export those CA certs. If Windows does not have those CA certs, we would have to go and find them. All of this work is for nothing, really, and generates quite a bit of administrative and operational overhead.

If the CA certs could be provided to the trust store in separate PEM files (not concatenated with the peer cert), then this substantially reduces administrative and operational overhead. In our 10 years of experience (in the US) we have seen maybe a dozen of different CAs being used (sometimes it's the same CA but the cert got refreshed, like VeriSign becoming Symantec).

from rabbitmq-trust-store.

@uvzubovs so if we introduce two verification modes for this plugin, which @kjnilsson has described above, it would work for you? I think only supporting option 1 won't satisfy everybody.

Now, we don't yet know if option 1 is technically possible with the released Erlang version but we have a prototype that looks promising (and needs more test cases).

from rabbitmq-trust-store.

Certainly, if you introduce 2 modes -- "only peer cert" and "peer + CA certs" -- it would work for us; we would just use "only peer cert" option. However, if "only peer cert" option is not technically feasible, it would help greatly if in the "peer + CA certs" option the CA certs could be loaded into the trust store in their own individual PEM files rather than being concatenated with the peer cert. Does this make sense?

from rabbitmq-trust-store.

It does and loading CA certificates one by one should be already possible.
We are still investigating the 1st option.

On Wed, Jun 22, 2016 at 8:38 PM, uvzubovs [email protected] wrote:

Certainly, if you introduce 2 modes -- "only peer cert" and "peer + CA
certs" -- it would work for us; we would just use "only peer cert" option.
However, if "only peer cert" option is not technically feasible, it would
help greatly if in the "peer + CA certs" option the CA certs could loaded
into the trust store in their own individual PEM files rather than being
concatenated with the peer cert. Does this make sense?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#34 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAAEQk8K61l9niesQkaKMFT1vEMjZqolks5qOXMCgaJpZM4I6xKX
.

MK

Staff Software Engineer, Pivotal/RabbitMQ

from rabbitmq-trust-store.

I've created a separate issue for validating peer + CAs. This issue is now for the scenario where by only the peer certificate needs to be checked against the whitelist.

from rabbitmq-trust-store.

#35 will cover the 2nd part of this issue and may introduce more significant user-facing changes.

from rabbitmq-trust-store.

Why is this issue closed?

from rabbitmq-trust-store.

Because it's done?

from rabbitmq-trust-store.

Sorry, is there new version of the plug-in that would accept peer+CA certs even though I only have peer cert in the trust store? I thought this was the 1st scenario, and @kjnilsson reported it may not be technically possible, or am I confused?

from rabbitmq-trust-store.

There is a merged pull request for the 1st scenario (#36) and #35 for the second part.

from rabbitmq-trust-store.

3.6.3 M3 (or RC, or whatever we call it) will include it.

from rabbitmq-trust-store.

So, 1st scenario was possible after all?

from rabbitmq-trust-store.

We found a way and few test cases pass. Only users like you can ultimately say how well it works but fingers crossed.

from rabbitmq-trust-store.

Wow! Any chance to get this plug-in for 3.6.2 (what I run now)? If not, I'll wait till 3.6.3.

from rabbitmq-trust-store.

I will build an .ez and send your way (using your Google Group email if that's OK) in a bit.

from rabbitmq-trust-store.

Here's the build (.zip as GitHub won't allow me to upload an .ez)
rabbitmq_trust_store-3.6.x.477961ff.ez.zip

from rabbitmq-trust-store.

This seems to have worked very well. Thank you very much!

from rabbitmq-trust-store.

Perfect. Thank you for reporting back.

We will look into #35 after 3.6.3 is out. I'm not sure what strategy should
be the default
but hopefully there will be little config tweaking involved in choosing one
or the other.

On Fri, Jun 24, 2016 at 12:30 AM, uvzubovs [email protected] wrote:

This seems to work very well. Thank you very much!

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#34 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAAEQpy_14FH-ii4Lv6dffXBono9-ZHbks5qOvrvgaJpZM4I6xKX
.

MK

Staff Software Engineer, Pivotal/RabbitMQ

from rabbitmq-trust-store.