-
Notifications
You must be signed in to change notification settings - Fork 1.1k
[defect]: Partial chain support not working in 3.0.25 #4753
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
Comments
for reference here is the exactly same config / cert hierarchy working in 3.0.21 if it helps
|
Maybe set Much of this certificate handling is just OpenSSL magic. We pass things to OpenSSL and if it works, great. If not... magic. :( |
Thanks Alan, I just added that and tested again, same result, I can post another debug if needed but I do not see any differences in output. |
OK. Another debug output won't help then. All I can suggest is to walk through the commits from 3.0.21 to 3.0.25, and see which one breaks partial chain support. There's about 1000 commits, but few of them will affect anything TLS. So it shouldn't be more than 10 builds or so to find out which is the problem one. If you have a configuration && certificates to share, we could also take a look at adding them to the regression tests. That way this problem won't occur again. |
Sure, I can do that, will compile the other versions in between and let you know the result, shouldn't take long. |
The breakage seems to have occurred between 3.0.21 (working) and 3.0.22 (not working) |
commit a5e7995 breaks partial chain support freeradius-server/src/main/tls.c Lines 3150 to 3159 in a5e7995
|
@alandekok You missed the |
@zhangyoufu - Thanks for finding this, I had not managed to recreate the exact commit yet. @alandekok - Could this please be considered for the 3.0.X stable branch too ? |
thanks @alandekok |
Any guidance on when this will be part of a release? |
@bubbaandy89 In the new year. |
Awesome, thank you so much! |
Uh oh!
There was an error while loading. Please reload this page.
What type of defect/bug is this?
Unexpected behaviour (obvious or verified by project member)
How can the issue be reproduced?
I have been using 3.0.21 for some time and make use of partial chain support . Looks like that was introduced introduced here
#2162
I just upgraded to 3.0.25, by compiling from source and I now get a trust failure with the following (I mocked up in the lab, hence the nonsense CA names etc) :
config is identical as 3.0.21 which worked, also tried with 3.0.26 and the same error happens, the client cert is created from an intermediate CA and is trusted by that intermediate CA being in the "ca_file" , the root CA is not in the CA dir as it shouldn't need to be and we do not trust at that level , as soon as I swap back to 3.0.21 all is good again.
Just as a test I dropped the root CA cert into the CA dir and ran c_rehash and the client cert is now accepted in 3.0.25/26 , this is not ideal in our configuration however but does point to a possible issue with partial chain support not working.
All of the Freeradius versions tested are compiled on the same host with the same SSL libs and I can see the partial chain option is enabled (probably obvious since 3.0.21 and previous were still working).
The original code that was added for partial chain support seems untouched, so not sure what is going on.
Happy to grab any other info needed.
Log output from the FreeRADIUS daemon
Relevant log output from client utilities
No response
Backtrace from LLDB or GDB
No response
The text was updated successfully, but these errors were encountered: