Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cert selected from router CA bundle #1422

Closed
gberl002 opened this issue Oct 10, 2023 · 2 comments
Closed

Cert selected from router CA bundle #1422

gberl002 opened this issue Oct 10, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@gberl002
Copy link
Contributor

gberl002 commented Oct 10, 2023

Observed behavior
When using openssl to connect to a router with additional certs defined in the ca bundle, certs are returned from the ca bundle instead of the server cert field.

Expected behavior
Only certs defined in the identity.server_cert entry should be returned

Steps to reproduce

  • Append a cert to the ca bundle defined in the router's identity.ca configuration
  • Run openssl s_client -connect localhost:1282 -servername 150.136.141.199 (assuming the cert contains a SANS entry for 150.136.141.199)
  • Observe a cert from the ca bundle returned

Note This issue was discovered while upgrading from v0.26.5 to v0.30.3. After testing a few different versions, this issue begins presenting on v0.27.0 and later. Upgrading from v0.26.5 up to and including v0.26.11 all function as expected. The breaking change seems to be in v0.27.0 specifically.

@gberl002 gberl002 added the bug Something isn't working label Oct 10, 2023
@andrewpmartinez
Copy link
Member

andrewpmartinez commented Oct 12, 2023

I don't see this behavior. I see the ER returning a chain of certs

  • 0 - leaf ER server certificate
  • 1 - intermediate cert

Which is acceptable and expected.

Inspecting the environment that you gave me the ip/port to, I see the same results.

In your environment, I do see the following:

  • 0 - leaf ER server cert
  • 1 - intermediate signed by something called "spurious intermediate," which is oddly named.

I expected something that sounded like a root signing 1, but it may be a naming issue. If spurious intermediate is an intermediate, I would also expect it in the chain returned by the ER, and this is most likely a configuration issue with/ the PKI that used to work on older versions but doesn't work on newer versions. Specifically, the C SDK swapped to OpenSSL, which requires a path to a root. Previously, the implementation didn't.

@andrewpmartinez
Copy link
Member

After debugging the exact instance referenced by @gberl002, it turns out that the chain assembly logic is pulling leafs from the CA bundle. This is a two part fix.

  1. Chain assembly should not pull leafs from the CAs bundle
  2. The controller should filter leafs from the CA bundle

andrewpmartinez added a commit to openziti/identity that referenced this issue Oct 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants