credhub.authentication.uaa.ca_certs needs a bogus value when using a cert from a trusted CA

[topherbullock]

From what I understand from this bit of code:
https://github.com/pivotal-cf/credhub-release/blob/897cc99ed19e712fb13b99e3a304d6e9b0a3c6da/jobs/credhub/templates/init_key_stores.erb#L86-L94

Credhub will enforce setting that property in your deployment manifest, but it can just be an empty array. This is an annoying behaviour in cases where the UAA cert is signed by a trusted Root CA, and we don't need to specify a CA cert.

Can this property just default to an empty array instead, and use the system ca certs?

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/150135261

The labels on this github issue will be updated when the story is started.

[topherbullock]

Correction; it still fails if there isn't a value in the array, so in the case of a Cert being signed by a trusted Root CA, one needs to provide something to prevent that error message. I understand that this might be trying to help avoid configuring something improperly, but this is overly defensive and annoying to configure when it is not required.

[danjahner]

Hey @topherbullock -

Our intention for credhub.authentication.uaa.ca_certs is to provide an exclusive list of CA certificates that should be trusted to validate the connection to UAA. We don't include CAs in the system trust store for this validation. We decided to make this trust explicit given the sensitive nature of the connection.

Given above, a certificate must always be provided for it to be a valid configuration. This is why we fail in templating if a value is not provided.

[aeijdenberg]

Hi @danjahner - I'm struggling a bit to understand how we're expecting this to be used.

Our UAA server is serving a certificate signed by a publicly trusted root, which, since user browsers need to interact with UAA for login, I'm assuming is quite a common case. Do we then need to explicitly add the public CA to this list for CredHub to use UAA?

[danjahner]

Hi @aeijdenberg - Yes, you will need to reference the CA when deploying, even if it is signed by a publicly trusted root.

[aeijdenberg]

Thanks @danjahner for getting back to me - that seems to be quite an unusual behavior though. That is, I'm glad there's an option to pass your own CA list to use in place of the system list, but it's surprising that there's no way to use the system roots. Could you consider at minimum providing a flag to allow use of publicly trusted roots?

Our use-case is that Amazon Certificate Manager is issuing our certs for our ELB - they have a number of public roots - I'm not keen to have to keep them all up to date in our config (this is normally a function of the system to handle for me).

(it's also not immediately clear to me the context in which the CredHub server is interacting with UAA directly, ie I'd have expected that being able to verify a signed JWT assertion would handle most use cases, but perhaps it will become clearer as I learn more about CredHub)

[danjahner]

• @crawsible

[aeijdenberg]

It's a year later, and I'm trying to deploy credhub again, and I'm hitting the same bug.

We have certificates signed by a publicly trusted CA (Let's Encrypt, this time). As an operator, I expect default behavior of application on my system to trust the root certificates trusted by my operating system (that's what pretty much every other component does).

At the very least, I expect an option to enable this. Can this please be considered?

[mdelillo]

@aeijdenberg we've reopened the story in our Tracker, we'll be prioritizing it soon. I don't see a reason why we couldn't make it an option for users to explicitly allow CredHub to use the system trust store when verifying the UAA cert.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/162217368

The labels on this github issue will be updated when the story is started.

[aeijdenberg]

Thanks @mdelillo

[gid0]

Hitting this here also, with the same use case : Credhub deployed and using an Application Load Balancer in AWS configured with a certificate signed by the Amazon public CA. Amazon has multiple root CAs so we don't want to maintain a list which will become out-of-date. That's good to be able to override the trust store for security reasons or when using self-signed certificates, but we should also have a way to make Credhub trust the system CAs.