-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Allow disabling certificate_authorities extension with peer-to-peer setup with TLS 1.3 #6106
Comments
It looks very similar to #6105 This change appears to be responsible for the new behaviour: e165a3368da#diff-280aa9e67bfae54121bde3ed8b7e1eea6f845f68ca0600c96331fbacb315672b |
@jjcarstens Would the solution in #6204 be sufficient to solve your use case? Or do you have uses cases where some but not all CA (except for ROOT Cas) would be excluded? |
Thanks @IngelaAndin ! I think this issue is technically different than #6105. I tested your #6204 solution and I technically can get it to work from the client (with the minor change from my PR comment), but it seems like it is still forcing the That said, I'm not too incredibly verse with SSL practices and there may be reasoning I'm missing and this new implementation could be totally acceptable |
I agree that this is different from #6105, I will now merge that solution and I think rather an option to not use the certificate_authorities extension is what would be appropriate for your use case. It would be fairly easy to add such an option, however, we are currently reworking the option handling so we would prefer to wait for that before introducing new options, but if you are in a hurry you are always welcome to make a suggestion in a PR. |
…erify_peer` Fixes erlang#6106 Based on the discussion from the issue (and erlang#6204), it was decided that adding the ability to disable the `certificate_authorities` extension on the server would be the fitting resolution for situations where you do not want that extension forced in TLS 1.3. This adds that ability to specify as a server option and defaults to `true` to keep with existing expected functionality.
…erify_peer` Fixes erlang#6106 Based on the discussion from the issue (and erlang#6204), it was decided that adding the ability to disable the `certificate_authorities` extension on the server would be the fitting resolution for situations where you do not want that extension forced in TLS 1.3. This adds that ability to specify as a server option and defaults to `true` to keep with existing expected functionality.
…erify_peer` Fixes erlang#6106 Based on the discussion from the issue (and erlang#6204), it was decided that adding the ability to disable the `certificate_authorities` extension on the server would be the fitting resolution for situations where you do not want that extension forced in TLS 1.3. This adds that ability to specify as a server option and defaults to `true` to keep with existing expected functionality.
…erify_peer` Fixes erlang#6106 Based on the discussion from the issue (and erlang#6204), it was decided that adding the ability to disable the `certificate_authorities` extension on the server would be the fitting resolution for situations where you do not want that extension forced in TLS 1.3. This adds that ability to specify as a server option and defaults to `true` to keep with existing expected functionality.
Is your feature request related to a problem? Please describe.
Since OTP >=24.3,
certificate_authorities
extension is configurable for the client and defaults tofalse
. However, in a peer-to-peer setup (i.e. withverify_peer
), the server may still try to use thecertificate_authorities
extension and fails to handshake in some situations, such as when you might manually manage a separate store of client signer CA certificates and are unable to include all CA's with all requests.Describe the solution you'd like
The ability to set
{certificate_authorities, false}
with usingverify_peer
for peer-to-peer connections to disable the extension for both client and serverAdditional context
This was originally investigated in nerves-project/nerves_system_rpi4#160 (comment) and more context is available there.
You can also see @tonnenpinguin bare minimum project to reproduce the error with this setup
/cc @fhunleth
The text was updated successfully, but these errors were encountered: