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
Bug 1723400: fix haproxy reload crash when processing ECDSA keys #39
Bug 1723400: fix haproxy reload crash when processing ECDSA keys #39
Conversation
@ironcladlou: This pull request references Bugzilla bug 1723400, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
With extended validation enabled, if the router detects an ECDSA private key when processing TLS data, the sanitized key output is rendered with PEM block headers like: -----BEGIN ECDSA PARAMETERS----- -----END ECDSA PARAMETERS----- However, OpenSSL recognizes the following headers for ECDSA keys[1]: -----BEGIN EC PARAMETERS----- -----END EC PARAMETERS----- Consequently, when the router provides haproxy with such PEM files through `crt-list` option, haproxy (which uses OpenSSL) fails to load the key and reload fails. The impact is that a Route resource containing an ECDSA key in `.spec.tls.key` will cause haproxy reloads to crash loop, preventing any further router processing until the problematic Route is deleted. This patch ensures that sanitized ECDSA key output follows the OpenSSL conventions which indirectly apply to haproxy. [1] https://github.com/openssl/openssl/blob/master/include/openssl/pem.h#L54
53b5525
to
d9ab69e
Compare
/lgtm |
/cherrypick release-4.2 |
@Miciah: once the present PR merges, I will cherry-pick it on top of release-4.2 in a new PR and assign it to you. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ironcladlou, Miciah The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@ironcladlou: All pull requests linked via external trackers have merged. Bugzilla bug 1723400 has been moved to the MODIFIED state. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@Miciah: new pull request created: #41 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/cherrypick release-4.1 |
@Miciah: new pull request created: #42 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
With extended validation enabled, if the router detects an ECDSA private key when processing TLS data,
the sanitized key output is rendered with PEM block headers like:
However, OpenSSL recognizes the following headers for ECDSA keys[1]:
Consequently, when the router provides haproxy with such PEM files through
crt-list
option, haproxy (which uses OpenSSL) fails to load the key and reloadfails.
The impact is that a Route resource containing an ECDSA key in
.spec.tls.key
will cause haproxy reloads to crash loop, preventing any further router
processing until the problematic Route is deleted.
This patch ensures that sanitized RCDSA key output follows the OpenSSL
conventions which indirectly apply to haproxy.
[1] https://github.com/openssl/openssl/blob/master/include/openssl/pem.h#L54